Provisioning & Deploy on AWS
•
27 likes•6,086 views
AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) Provisioning & Deploy on AWS
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Provisioning & Deploy on AWS
Similar to Provisioning & Deploy on AWS (20)
More from Amazon Web Services Japan
More from Amazon Web Services Japan (20)
Provisioning & Deploy on AWS
- 1. Provisioning & Deploy on AWS AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) アマゾンデータサービスジャパン株式会社 技術本部 プロフェッショナルサービス事業部 シニアコンサルタント 吉⽻羽⿓龍龍太郎郎
- 2. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 2
- 3. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 3
- 4. ビジネスは変化する 4
- 5. ビジネスはうまくいかないこともある • 1発1中は⽬目指さない • うまくいっていないこ とを把握できる仕掛け • ダメなものをやめる選 択肢 5
- 8. 0 50 100 150 200 250 300 2007 2008 2009 2010 2011 2012 2013 9 24 48 61 82 159 280 AWSのイノベーションのペース 8
- 12. インフラもアプリもコード化 12
- 13. Infrastructure as Code • コードによるインフラの記述 13
- 14. Infrastructure as Codeのメリット • サーバーの台数が増えても構築に時間がかからない • コード＝⼿手順書となるのでコードを常にメンテナン スしておけば良良い • ⼿手順を抜かしたり⼿手順を間違う⼼心配がない • 同じコードを動かせば同じサーバーが出来上がる • コードで記述されているので再利利⽤用が容易易である • 他のプロジェクトでコードを使いまわすことで無駄 を省省ける 14
- 15. Infrastructure as Codeのデメリット • 学習コスト・作るのに時間がかかる • 常に正しく動作するようにメンテナンスする必要が ある • 雑なやり⽅方をしてしまうと、保守にかえって時間が かかる可能性がある 15
- 16. キホン：連続体として捉える • インフラのプロビジョニングと アプリのデプロイは連続体 • 両者を⼀一緒に考える • キーワードは伸縮⾃自在性 16
- 18. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 18
- 19. 前提：作業は繰り返し⾏行行われる • デプロイ作業は繰り返し⾏行行われる • 環境構築作業も何度度も⾏行行われる – 開発環境 – テスト環境 – ステージング環境 – 本番環境 • リスク顕在化確率率率 x 実⾏行行回数 = ?? 19
- 22. リスク3：職⼈人芸への依存 22
- 23. リスク4：リリース失敗・戻し失敗 • ⼿手作業で⼤大変なので慎重 にレビューが必要 • なので、複数をまとめて リリース • =ビッグバンリリース • さらに失敗しやすく • しかも戻せない 23
- 27. リスク7：どんどんプロセスが重くなる • チェックリストが増える • トラブルごとに増える • ⼆二重チェック、三重 チェック… • ⼀一時的に問題が発⽣生しな くなるかもしれないが… • 持続できない… 27
- 29. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 29
- 30. 30
- 31. 投資対効果(ROI) 31
- 32. コストの考え⽅方 • ⾃自動化にはコストがかかる • 基本ができていない場合は達成まで時間もかかる • ⼿手作業でやった場合と⽐比較してどちらが安いか • 実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対 処コスト等を含めて考える • ただし、損益分岐点は思った以上に早い • 顧客が要求するスピードやアプリケーションのライ フサイクルを踏まえる 32
- 33. ⾃自動化に投資するか慎重な判断が必要な領領域 • たとえば、⼩小規模なキャンペーンサイト • 使い捨てのアプリケーション • 納品したら終わりのモノ 33
- 35. キホン：⾃自動化の5R • Rapid • Reliable • Repeatable • Reduce Risk • Roll back 35
- 37. キホン：顧客や上司の理理解を得る • 黙ってこっそりやるのは無理理 • 説明責任 • 個⼈人の便便利利ツール構築とは次 元の違う話として組織で取り 組む 37
- 38. キホン：全員で取り組む 38
- 39. キホン：カイゼンを続ける • Just in Time • かんばん • ムダ • 平準化 • アンドン • ポカヨケ • ⾃自働化 • 改善 • ⾒見見える化 • 作りすぎのムダ • ⼿手待ちのムダ • 運搬のムダ • 加⼯工のムダ • 在庫のムダ • 動作のムダ • 不不良良をつくるムダ 39
- 40. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 40
- 43. キホン：デプロイ⾃自動化に必要な要素 • バージョン管理理システム • ⾃自動化されたテスト • マイグレーション • 継続的インテグレーション • デプロイツール • (静的解析・コードレビュー) 43
- 44. キホン：バージョン管理理 • 全ての基本 • ブランチ、マージを含めて、チーム全員が使い ⽅方を理理解するのが当たり前。躾の問題 • コードの共同所有(XPの考え⽅方) • 設定ファイルやアセット含めて、いつでも環境 を再現できるようにしなければならない 44
- 45. ブランチモデルの理理解 • ブランチの戦略略がチーム 全員で理理解できている か？ • ブランチの戦略略はデプロ イの戦略略と密接な関係 A successful Git branching modelより図を引⽤用 (http://nvie.com/posts/a-‐‑‒successful-‐‑‒git-‐‑‒ branching-‐‑‒model/) 45
- 46. キホン：⾃自動化されたテスト • 速度度維持と品質維持 – 早期に問題を解決し続ける⽅方がコストが安い フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日 46
- 49. マイグレーション • 設定ファイルやアセット含めて、いつでも環境を 再現できるようにしなければならない原則 • いつの時点のリリースにも戻せるようにする原則 • 依存関係・前後関係は⼈人が判断しない原則 • →マイグレーションの活⽤用 49
- 50. マイグレーション⽤用ツール 50
- 51. キホン：継続的インテグレーション • バージョン管理理、テスト⾃自動化、マイグレー ションが実現できていれば継続的インテグレー ションの実現が可能 • 常にリリース可能か どうかを検証し続ける • プロジェクトの⽣生命線 51
- 52. 継続的インテグレーションアンチパターン • テストコードがない • テストコードと製品コードを同時にコミットし ない • 定時ビルドのみでコミットビルドがない・夜間 ビルドしかない • 帰り際にコミットしてそのままCIの結果を⾒見見ず に帰る • CIでテストを通すために⼿手作業の準備が必要 • メインラインのみで⼤大きなブランチをCI対象に していない • 様々な種類のテストをまとめて⾏行行っている • ビルドの失敗に気付かない / ビルドに失敗し ても放置している • ビルドの失敗に気づいても、修正コード以外の コードをコミットする • 何も変更更していないのにビルドが落落ちたり落落ち なかったり • 頻繁にビルドが失敗するので、失敗するのが普 通だと思う • CIからの通知メッセージが⼤大量量すぎる / CIが 落落ちても何も通知しない • CIサーバのリソースが貧弱 • ビルドが肥⼤大化して結果が出るまでに時間がか かる • 本番環境やステージング環境と環境が異異なる • コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う • CIサーバがおかしくなったときに直せる⼈人がい ない • ずっとCIでのチェック内容が変わらない、プロ セスが変わらない 52
- 53. 継続的インテグレーション on AWS • スローテストを避けるため、並列列実⾏行行 • 指定時刻にCIサーバを増やし、必要なくなったら⽌止める • クラウドならではのアプローチ 53 負荷テスト 性能テスト ユニットテスト 機能テスト 受け⼊入れテスト 結合テスト など…
- 55. キホン：デプロイプロセス設計 • いつ誰がどの環境にどの単位でデプロイするのか？ • どういうデプロイのパターンが存在するのか？ • どんなツールを使うのか？ • 誰がデプロイスクリプトを保守するのか？ • デプロイの成功/失敗をどのように判断するのか？ • デプロイ後に問題が分かったときにどのように対処 するのか？ • いまリリースされているバージョンをどのように知 ることができるのか？ 55
- 58. デプロイアンチパターン：様々な⽅方法 • パターンを多くし過ぎるとデプロイの信頼性が 低下 – 各パターンが⼗十分にテストされない • ⼀一般的には以下の2種類 – ⼤大規模リリース⽤用 – ⼩小規模リリース⽤用 58
- 60. ツールの選択 • 専⽤用のツールを使う – Capistrano、Fabric、Maven・・・・などなど • デプロイスクリプトの可読性と保守性は重要 – これがリリース⼿手順書の代わりになるので、担当者が変わっても保守 できるものを選択 – シェルスクリプトは複雑化しやすく保守しにくい • Elastic Beanstalk & OpsWorks が⾃自分たちのプロセ スに合いそうかどうかを確認 – どんなデプロイプロセスが必要なのかによって適合性がかわる 60
- 61. クラウドのメリットを活かす オンプレミス 新しいインフラの構築は 複雑かつ遅くなりがち クラウド ワンクリックで新しい インフラを⽤用意 新しいデプロイ環境を構築 新しいテスト環境を構築 新しい環境を海外に構築 1,000 サーバ追加 1,000 サーバ削除 必要 調査 評価 計画 設計 エンジニア 調達 契約 コミッショ ン デプロイ 61
- 62. ブルーグリーンデプロイ Webサーバー群 (Amazon EC2) データベースサーバ群 (Amazon RDS) ロードバランサー v1.1 v1.1 v1.1 v1.1 v1.2 v1.2 v1.2 v1.2 モニタリング (CloudWatch) 62 デプロイの後⼀一定期間たって戻すことがないと 判断できた時点で旧バージョン削除 クラウドの特性を活かしたデプロイ
- 63. Amazon Route 53 EC2 Instances ELB EC2 Instances ELB 90% 10% DynamoDB MySQL RDS Instance ElastiCache Cache Node ブルーグリーンデプロイ • Route53の重み付けラウンド ロビンで振り分けすることで、 新規機能をリリースする際に ⼀一部のユーザだけに公開 • 評価結果がよければ新機能側 を増やしてリクエストを寄せ ていく • これらの切切り替えを全てAPI の組み合わせで可能 63
- 64. v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.2 v1.2 v1.2.1 v1.2.1 v1.2.2 v1.2.2 DNS (Amazon route 53) Webサーバー群 (Amazon EC2) データベースサーバ群 (Amazon RDS) ロードバランサー 90% 5% 3% 2% ブルーグリーンデプロイ 64
- 66. • ELB + Web＋(DB)の 定番構成で利利⽤用 • Auto Scaling利利⽤用可能 • ログやアプリはS3に • 単純な構成を容易易に管 理理 • VPC内でも利利⽤用可能 • システム全体ではなく ⼀一部での利利⽤用も可能 66
- 68. Elastic Beanstalkでワンクリックデプロイ • たとえばCIサーバでテストが終わったあとに、 CIサーバから直接ステージング環境にデプロイ する、といったことも簡単に出来る • もちろん本番環境でも 68
- 69. Elastic Beanstalk + Docker Developer 1. docker push4. docker pull 2. deploy registry registry registry registry Region app app app registry app 3. docker run registry 5. docker stop registry Docker registry container with AWS credentials 69
- 72. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 72
- 73. プロビジョニング⾃自動化の進め⽅方 • 基本的な考え⽅方はデプロイ⾃自動化と同じ • デプロイとプロビジョニングは連続体 • プロセスの設計 • ベストなツールの選択 • ⾃自動化しやすいアーキテクチャー 73
- 74. VPC 10.0.0.0/16 Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet 10.0.0.0/24 Public Subnet 10.0.2.0/24 Private Subnet 10.0.1.0/24 Private Subnet 10.0.3.0/24 AMI Amazon RDS Amazon RDS AZ-‐‑‒A-‐‑‒WP1 10.0.0.6 EC2 Instance EC2 Instance AZ-‐‑‒B-‐‑‒WP2 10.0.2.8 こんな環境の作成を⾃自動化できる 74
- 75. AWSのプロダクトの位置づけ Elastic Beanstalk OpsWorks CloudFormation EC2 ⼿手軽 ⾃自由度度⾼高 サービス型 ⾃自⼰己管理理型 75
- 76. プロダクト Elastic Beanstalk OpsWorks Cloud Formation Amazon EC2 できること 定番構成＋アプ リデプロイ カスタム構成＋ アプリデプロイ スタックの⼀一括 構築 なんでも 利利⽤用頻度度 アプリデプロイ ごと アプリデプロ イ・プロビジョ ニングごと 初回１回や 似た環境を作る とき ⾃自分で管理理 (Chef、 Capistrano等) ⼿手軽さ・ ⾃自由度度 ⼿手軽 ⼿手軽 ⾃自由 ⾃自由 考慮点 定番アーキテク チャかどうか Cookbookのテ ストをどうする か アプリデプロイ は別で考える 構築のコストを 考慮 76 組み合わせ技も可能。例例えばCloudFormationを使って Elastic Beanstalkのアプリケーションや OpsWorksのスタックを作成したりできる
- 77. AWS OpsWorks • アプリケーションをAWS上で管理理するための DevOpsソリューション • Chef-‐‑‒Solo(Chefのスタンドアローン版)を採⽤用 • 幅広いアプリケーションアーキテクチャをサポート • Elastic Beanstalkよりインフラおよびミドルウェアレイヤーでの ⾃自由度度が⾼高い 77
- 78. 78 User AWS Management Console Stack例例 Load Balancerレイヤー App Serverレイヤー Databaseレイヤー レシピ レシピ レシピ DB Web /App Web /App LB ①スタックの作成 ②レイヤーの作成 ③レシピの設定 ④レイヤーに インスタンス追加・起動 ⑤ライフサイクルイベント により、レシピが実⾏行行 構成情報 (JSON) ⾃自分でレイヤーを複数定義し、適⽤用するレシピを指定して いくことで環境構築・デプロイを⾃自動化。⾃自由度度⾼高
- 79. CloudFormation • JSONで環境を記述 • このテンプレートを使っ て何個でも同じ環境をつ くれる • テキストファイルなので バージョン管理理システム にも登録可能 79
- 81. AMI作成の3つの選択肢 1. 全部⼊入り仮想マシンイメージを作成し維持 2. OSおよびベースとなるソフトウェアを導⼊入した仮想マシンイメー ジを作成し、初回作成時に追加部分のみプロビジョニング 3. OSの仮想マシンイメージを起動し、初回作成時に、必要な全てを プロビジョニング Packer + Chef-‐‑‒Solo等を利利⽤用して⾃自動化も可能 →⾃自動化できればCIできる！ 81
- 82. Chefを使った場合の構成例例 Amazon Linux EC2 Instanceを起動 Chef Clientのみインストール済み Custom AMI ami-‐‑‒1ab34567 Amazon Linux and Chef Agent installed Chef Client EC2インスタンス Chef Server EBS インストール⽤用の ファイルが配置された S3バケット Amazon Linux Running EC2 Instance Loaded with Applications Installed by Chef Chef Client Monitoring Agent PHP Nginx Other Libraries 適⽤用するCookbook やAttributeを取得 82
- 83. Chef 83
- 84. 84
- 85. IF YOU CAN PROGRAM IT YOU CAN AUTOMATE IT ⾃自動化しやすいものを選択せよ ⾃自動化できれば継続的インテグレー ションできる 85
- 87. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 Graphite 87
- 88. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 CloudFormationで 環境を定義 Graphite 88
- 89. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 Graphite コードはGitHubへ 89
- 90. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 Graphite コードがコミットされる とCI実⾏行行 90
- 91. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 Graphite サーバ⼀一覧をAPI経由で 取得しデプロイしつつS3 にアーカイブ配置 91
- 92. VPC Availability Zone -‐‑‒ C Availability Zone -‐‑‒ A Internet Anyone Internet Gateway Public Subnet Public Subnet Private Subnet Private Subnet AMI Amazon RDS Amazon RDS 実例例 Graphite EC2起動時にAMIとChef Server利利⽤用。⾃自動で最新 コードをS3から取得 監視システムに⾃自動登録 92
- 93. アジェンダ • ビジネスの要求と⾃自動化が必要な背景 • デプロイやプロビジョニングを⾃自動化しないリスク • デプロイやプロビジョニングの⾃自動化に向けた戦略略 • デプロイの⾃自動化 • プロビジョニングの⾃自動化 • まとめ 93
- 94. まとめ • デプロイ⾃自動化・環境構築の⾃自動化には順番がある • やるならプロジェクトの最初から • プロセス設計をする • APIを活⽤用する • 継続的インテグレーション重要 • ⾃自動化された作業と⼿手作業を混ぜない • 適切切なツールを使う – AWSなら CloudFormation / Elastic Beanstalk / OpsWorks 94