Provisioning & Deploy on AWS

3,396 views

Published on

AWS Black Belt Tech Webinar 2014
(旧マイスターシリーズ)

Provisioning & Deploy on AWS

Published in: Technology
0 Comments
24 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,396
On SlideShare
0
From Embeds
0
Number of Embeds
56
Actions
Shares
0
Downloads
57
Comments
0
Likes
24
Embeds 0
No embeds

No notes for slide

Provisioning & Deploy on AWS

  1. 1. Provisioning & Deploy on AWS AWS  Black  Belt  Tech  Webinar  2014  (旧マイスターシリーズ) アマゾンデータサービスジャパン株式会社 技術本部  プロフェッショナルサービス事業部 シニアコンサルタント  吉⽻羽⿓龍龍太郎郎
  2. 2. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 2
  3. 3. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 3
  4. 4. ビジネスは変化する 4
  5. 5. ビジネスはうまくいかないこともある •  1発1中は⽬目指さない •  うまくいっていないこ とを把握できる仕掛け •  ダメなものをやめる選 択肢 5
  6. 6. Build Measure Learn 6
  7. 7. フィードバックループ •  顧客とビジネスの間のフィードバックループを 加速する •  顧客の期待に応え続ける 7
  8. 8. 0 50 100 150 200 250 300 2007 2008 2009 2010 2011 2012 2013 9 24 48 61 82 159 280 AWSのイノベーションのペース 8
  9. 9. キホン:ビッグバンを避ける 9 利利⽤用者の反応やシステムの安定性を ⾒見見ながら⼩小規模単位でリリース
  10. 10. 11.6秒 平⽇日の デプロイ間隔 1,079 1時間あたりの最⾼高 デプロイ回数 10,000 1回のデプロイで 同時に変更更をうけ る平均ホスト数 30,000 1回のデプロイで 同時に変更更をうけ る最⾼高ホスト数 AMAZON.COM におけるデプロイ 10
  11. 11. キホン:⾃自動化する 11 繰り返し⾼高頻度度で⾏行行うには ⾃自動化が必要!!
  12. 12. インフラもアプリもコード化   12
  13. 13. Infrastructure  as  Code •  コードによるインフラの記述 13
  14. 14. Infrastructure  as  Codeのメリット •  サーバーの台数が増えても構築に時間がかからない •  コード=⼿手順書となるのでコードを常にメンテナン スしておけば良良い •  ⼿手順を抜かしたり⼿手順を間違う⼼心配がない •  同じコードを動かせば同じサーバーが出来上がる •  コードで記述されているので再利利⽤用が容易易である •  他のプロジェクトでコードを使いまわすことで無駄 を省省ける 14
  15. 15. Infrastructure  as  Codeのデメリット •  学習コスト・作るのに時間がかかる •  常に正しく動作するようにメンテナンスする必要が ある •  雑なやり⽅方をしてしまうと、保守にかえって時間が かかる可能性がある 15
  16. 16. キホン:連続体として捉える •  インフラのプロビジョニングと アプリのデプロイは連続体 •  両者を⼀一緒に考える •  キーワードは伸縮⾃自在性 16
  17. 17. (例例)  AutoScalingではインフラ・アプリが⼀一体 17 インスタンスが増える(=プロビジョニング)タイ ミングでアプリも最新のものをデプロイ
  18. 18. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 18
  19. 19. 前提:作業は繰り返し⾏行行われる •  デプロイ作業は繰り返し⾏行行われる •  環境構築作業も何度度も⾏行行われる –  開発環境 –  テスト環境 –  ステージング環境 –  本番環境 •  リスク顕在化確率率率  x  実⾏行行回数  =  ?? 19
  20. 20. リスク1:⼿手順書がメンテナンスされない 20
  21. 21. リスク2:⼿手作業で間違う •  いままで何度度も何度度もデプロイしているはず •  何度度か間違ったことありますよね? 21
  22. 22. リスク3:職⼈人芸への依存 22
  23. 23. リスク4:リリース失敗・戻し失敗 •  ⼿手作業で⼤大変なので慎重 にレビューが必要 •  なので、複数をまとめて リリース •  =ビッグバンリリース •  さらに失敗しやすく •  しかも戻せない 23
  24. 24. リスク5:⻑⾧長時間作業と失敗確率率率増⼤大 (^_^;) ( ゚皿゚)キーッ!! 24
  25. 25. リスク6:結果としてコスト増⼤大・流流出 25
  26. 26. リリースにいつも⾃自信を持てない •  清⽔水の舞台から⾶飛び降降りる… •  (そして失敗することも…) 26
  27. 27. リスク7:どんどんプロセスが重くなる •  チェックリストが増える •  トラブルごとに増える •  ⼆二重チェック、三重 チェック… •  ⼀一時的に問題が発⽣生しな くなるかもしれないが… •  持続できない… 27
  28. 28. でも時間がないので⼈人海戦術…(負の連鎖) •  問題の先送りであとになって更更に⼤大変に •  ⼀一時的に負債を許容してもすぐに返済すべき 28
  29. 29. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 29
  30. 30. 30
  31. 31. 投資対効果(ROI) 31
  32. 32. コストの考え⽅方 •  ⾃自動化にはコストがかかる •  基本ができていない場合は達成まで時間もかかる •  ⼿手作業でやった場合と⽐比較してどちらが安いか •  実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対 処コスト等を含めて考える •  ただし、損益分岐点は思った以上に早い •  顧客が要求するスピードやアプリケーションのライ フサイクルを踏まえる 32
  33. 33. ⾃自動化に投資するか慎重な判断が必要な領領域 •  たとえば、⼩小規模なキャンペーンサイト •  使い捨てのアプリケーション •  納品したら終わりのモノ 33
  34. 34. プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 開発チーム  (6±3⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部から開発チームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 完了了の定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日開発チームが以下の3つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり プロセス設計の重要性
  35. 35. キホン:⾃自動化の5R •  Rapid •  Reliable •  Repeatable •  Reduce  Risk •  Roll  back 35
  36. 36. キホン:プロジェクト最初から始める •  プロジェクト期間中は何度度もテスト環境にデプ ロイしたりプロビジョニングするはずなのでコ スト効率率率が向上 •  何度度もテストされ信頼性向上 36
  37. 37. キホン:顧客や上司の理理解を得る •  黙ってこっそりやるのは無理理 •  説明責任 •  個⼈人の便便利利ツール構築とは次 元の違う話として組織で取り 組む 37
  38. 38. キホン:全員で取り組む 38
  39. 39. キホン:カイゼンを続ける •  Just  in  Time •  かんばん •  ムダ •  平準化 •  アンドン •  ポカヨケ •  ⾃自働化 •  改善 •  ⾒見見える化 •  作りすぎのムダ •  ⼿手待ちのムダ •  運搬のムダ •  加⼯工のムダ •  在庫のムダ •  動作のムダ •  不不良良をつくるムダ 39
  40. 40. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 40
  41. 41. キホン:デプロイしやすいアーキテクチャーの維持 •  アプリケーションを常にデプロイしやすいよう に維持 •  疎結合アーキテクチャー(ステートレス) 41
  42. 42. q あらゆるものはいつでも故障 する前提で設計。単⼀一障害点 を避ける q サーバコピーを取得しいつで も起動可能に q スナップショットでのバック アップ q 障害時の⾃自動復復旧のために AutoScalingを活⽤用 q 複数AZ利利⽤用による冗⻑⾧長化 故障のための設計 q コンポーネントを独⽴立立させ、 各コンポーネントはブラック ボックスとして設計 q コンポーネント間を疎結合に q アプリケーションをステート レスに。この実現のためにEL Bを活⽤用し、スティッキーセ ッションを避ける q セッションデータはデータベー ス(RDS、DynamoDB)に保存 疎結合なコンポーネント q コンポーネントの健全性や配 置場所を決めつけない q いつでもリブート可能になる ように設計 q 動的なコンフィグレーション (起動時に⾃自動でアプリケー ションやライブラリ等をイン ストールする)の活⽤用 q 設定済みAMIの活⽤用による時 間短縮 弾⼒力力性の実装 q AWSのセキュリティは責任分 担モデル。OS以上の層やセキ ュリティグループの設定、デ ータ暗号化、秘密鍵の管理理等 は利利⽤用者側の責任 q OSの層とアプリの層、ネット ワークの層など各所でセキュ リティを担保すること。必要 に応じてアプリケーションの ペネトレーション試験も推奨 全レイヤでセキュリティ担保 q AWSの特性は時間単位でリソ ースを使⽤用可能な点。これを 活かしてアプリケーションや バッチ処理理の並列列化、マルチ スレッド化を検討する q ELBやAutoScalingを活⽤用し て並列列処理理、分散処理理を実装 並列列処理理の実装 q EBSや、データベース、S3 等データを保存するストレー ジには多種多様なものがある q 読み書きの特性(読み書きの ⽐比率率率や頻度度)や、データ喪失 の可能性、ステートレスの実 現可否を踏まえて適切切なスト レージを選択する 異異なるストレージの使い分け 42
  43. 43. キホン:デプロイ⾃自動化に必要な要素 •  バージョン管理理システム •  ⾃自動化されたテスト •  マイグレーション •  継続的インテグレーション •  デプロイツール •  (静的解析・コードレビュー) 43
  44. 44. キホン:バージョン管理理 •  全ての基本 •  ブランチ、マージを含めて、チーム全員が使い ⽅方を理理解するのが当たり前。躾の問題 •  コードの共同所有(XPの考え⽅方) •  設定ファイルやアセット含めて、いつでも環境 を再現できるようにしなければならない 44
  45. 45. ブランチモデルの理理解 •  ブランチの戦略略がチーム 全員で理理解できている か? •  ブランチの戦略略はデプロ イの戦略略と密接な関係 A  successful  Git  branching  modelより図を引⽤用 (http://nvie.com/posts/a-‐‑‒successful-‐‑‒git-‐‑‒ branching-‐‑‒model/) 45
  46. 46. キホン:⾃自動化されたテスト •  速度度維持と品質維持 –  早期に問題を解決し続ける⽅方がコストが安い フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日 46
  47. 47. どこまでテストを⽤用意するか? •  ユニットテスト、結合 テスト、受け⼊入れテス ト、スモークテスト •  それはプロセスとして 設計 47
  48. 48. キホン:テストしやすさ=デプロイしやすさ 48
  49. 49. マイグレーション •  設定ファイルやアセット含めて、いつでも環境を 再現できるようにしなければならない原則 •  いつの時点のリリースにも戻せるようにする原則 •  依存関係・前後関係は⼈人が判断しない原則 •  →マイグレーションの活⽤用 49
  50. 50. マイグレーション⽤用ツール 50
  51. 51. キホン:継続的インテグレーション •  バージョン管理理、テスト⾃自動化、マイグレー ションが実現できていれば継続的インテグレー ションの実現が可能 •  常にリリース可能か どうかを検証し続ける •  プロジェクトの⽣生命線 51
  52. 52. 継続的インテグレーションアンチパターン •  テストコードがない •  テストコードと製品コードを同時にコミットし ない •  定時ビルドのみでコミットビルドがない・夜間 ビルドしかない •  帰り際にコミットしてそのままCIの結果を⾒見見ず に帰る •  CIでテストを通すために⼿手作業の準備が必要 •  メインラインのみで⼤大きなブランチをCI対象に していない •  様々な種類のテストをまとめて⾏行行っている •  ビルドの失敗に気付かない  /  ビルドに失敗し ても放置している •  ビルドの失敗に気づいても、修正コード以外の コードをコミットする •  何も変更更していないのにビルドが落落ちたり落落ち なかったり •  頻繁にビルドが失敗するので、失敗するのが普 通だと思う •  CIからの通知メッセージが⼤大量量すぎる  /  CIが 落落ちても何も通知しない   •  CIサーバのリソースが貧弱 •  ビルドが肥⼤大化して結果が出るまでに時間がか かる •  本番環境やステージング環境と環境が異異なる •  コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う •  CIサーバがおかしくなったときに直せる⼈人がい ない •  ずっとCIでのチェック内容が変わらない、プロ セスが変わらない 52
  53. 53. 継続的インテグレーション  on  AWS •  スローテストを避けるため、並列列実⾏行行 •  指定時刻にCIサーバを増やし、必要なくなったら⽌止める •  クラウドならではのアプローチ 53 負荷テスト 性能テスト ユニットテスト 機能テスト 受け⼊入れテスト 結合テスト など…
  54. 54. デプロイ⾃自動化 •  ここまで出来ていればデプロイ⾃自動化まであと ちょっと •  まずデプロイプロセスの設計を 54
  55. 55. キホン:デプロイプロセス設計 •  いつ誰がどの環境にどの単位でデプロイするのか? •  どういうデプロイのパターンが存在するのか? •  どんなツールを使うのか? •  誰がデプロイスクリプトを保守するのか? •  デプロイの成功/失敗をどのように判断するのか? •  デプロイ後に問題が分かったときにどのように対処 するのか? •  いまリリースされているバージョンをどのように知 ることができるのか? 55
  56. 56. キホン:粒粒度度を⼩小さく コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け⼊入れテスト クロスブラウザ 静的解析 フィーチャー 56
  57. 57. デプロイのよくあるパターン LBから切切り離離す アプリケーションの デプロイ スモークテスト LB対象に戻す アプリケーションの デプロイ メンテ中ページに 差し替える アプリケーションの デプロイ データベースの マイグレーション スモークテスト メンテ中ページから 戻す 新規環境構築 アプリケーションの デプロイ スモークテスト LB切切り替え 57
  58. 58. デプロイアンチパターン:様々な⽅方法 •  パターンを多くし過ぎるとデプロイの信頼性が 低下 –  各パターンが⼗十分にテストされない •  ⼀一般的には以下の2種類 –  ⼤大規模リリース⽤用 –  ⼩小規模リリース⽤用 58
  59. 59. デプロイアンチパターン:⼿手作業混合 •  デプロイ作業の中に⼿手作業を混ぜない。間違い によるデプロイの失敗に直結 59
  60. 60. ツールの選択 •  専⽤用のツールを使う –  Capistrano、Fabric、Maven・・・・などなど •  デプロイスクリプトの可読性と保守性は重要 –  これがリリース⼿手順書の代わりになるので、担当者が変わっても保守 できるものを選択 –  シェルスクリプトは複雑化しやすく保守しにくい •  Elastic  Beanstalk  &  OpsWorks  が⾃自分たちのプロセ スに合いそうかどうかを確認 –  どんなデプロイプロセスが必要なのかによって適合性がかわる 60
  61. 61. クラウドのメリットを活かす オンプレミス   新しいインフラの構築は 複雑かつ遅くなりがち クラウド   ワンクリックで新しい インフラを⽤用意 新しいデプロイ環境を構築 新しいテスト環境を構築 新しい環境を海外に構築 1,000  サーバ追加 1,000  サーバ削除 必要 調査 評価 計画 設計 エンジニア 調達 契約 コミッショ ン デプロイ 61
  62. 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. 63. Amazon Route 53 EC2 Instances ELB EC2 Instances ELB 90% 10% DynamoDB MySQL RDS Instance ElastiCache Cache Node ブルーグリーンデプロイ •  Route53の重み付けラウンド ロビンで振り分けすることで、 新規機能をリリースする際に ⼀一部のユーザだけに公開 •  評価結果がよければ新機能側 を増やしてリクエストを寄せ ていく •  これらの切切り替えを全てAPI の組み合わせで可能 63
  64. 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
  65. 65. Elastic  Beanstalk 65 定番構成の構築・デプロイの ⾃自動化サービス
  66. 66. •  ELB  +  Web+(DB)の 定番構成で利利⽤用 •  Auto  Scaling利利⽤用可能 •  ログやアプリはS3に •  単純な構成を容易易に管 理理 •  VPC内でも利利⽤用可能 •  システム全体ではなく ⼀一部での利利⽤用も可能 66
  67. 67. •  アプリケーションを簡単にデ プロイ •  複数環境を切切り替え可能 (ブルーグリーンデプロイ) 67
  68. 68. Elastic  Beanstalkでワンクリックデプロイ •  たとえばCIサーバでテストが終わったあとに、 CIサーバから直接ステージング環境にデプロイ する、といったことも簡単に出来る •  もちろん本番環境でも 68
  69. 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
  70. 70. キホン:デプロイ失敗の検知をおこなう •  スモークテストの実⾏行行 •  監視システムによるログ監視やプロセス監視 70
  71. 71. あとからデプロイ⾃自動化する場合 •  各ステップが実現できているか確認 •  アプリケーションのアーキテクチャー修正が必要になる可能性も バ ー ジ ン 管 理理 テ ス ト ⾃自 動 化 マ イ グ レ ー シ ン 継 続 的 イ ン テ グ レ ー シ ン デ プ ロ イ ⾃自 動 化 71
  72. 72. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 72
  73. 73. プロビジョニング⾃自動化の進め⽅方 •  基本的な考え⽅方はデプロイ⾃自動化と同じ •  デプロイとプロビジョニングは連続体 •  プロセスの設計 •  ベストなツールの選択 •  ⾃自動化しやすいアーキテクチャー 73
  74. 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. 75. AWSのプロダクトの位置づけ Elastic  Beanstalk OpsWorks CloudFormation EC2 ⼿手軽 ⾃自由度度⾼高 サービス型 ⾃自⼰己管理理型 75
  76. 76. プロダクト Elastic Beanstalk OpsWorks Cloud Formation Amazon  EC2 できること 定番構成+アプ リデプロイ カスタム構成+ アプリデプロイ スタックの⼀一括 構築 なんでも 利利⽤用頻度度 アプリデプロイ ごと アプリデプロ イ・プロビジョ ニングごと 初回1回や 似た環境を作る とき ⾃自分で管理理 (Chef、 Capistrano等) ⼿手軽さ・ ⾃自由度度 ⼿手軽 ⼿手軽 ⾃自由 ⾃自由 考慮点 定番アーキテク チャかどうか Cookbookのテ ストをどうする か アプリデプロイ は別で考える 構築のコストを 考慮 76 組み合わせ技も可能。例例えばCloudFormationを使って Elastic  Beanstalkのアプリケーションや OpsWorksのスタックを作成したりできる
  77. 77. AWS  OpsWorks •  アプリケーションをAWS上で管理理するための DevOpsソリューション •  Chef-‐‑‒Solo(Chefのスタンドアローン版)を採⽤用 •  幅広いアプリケーションアーキテクチャをサポート •  Elastic  Beanstalkよりインフラおよびミドルウェアレイヤーでの ⾃自由度度が⾼高い 77
  78. 78. 78 User AWS  Management   Console Stack例例 Load  Balancerレイヤー App  Serverレイヤー Databaseレイヤー レシピ レシピ レシピ DB Web /App Web /App LB ①スタックの作成 ②レイヤーの作成 ③レシピの設定 ④レイヤーに   インスタンス追加・起動 ⑤ライフサイクルイベント により、レシピが実⾏行行 構成情報 (JSON) ⾃自分でレイヤーを複数定義し、適⽤用するレシピを指定して いくことで環境構築・デプロイを⾃自動化。⾃自由度度⾼高
  79. 79. CloudFormation •  JSONで環境を記述 •  このテンプレートを使っ て何個でも同じ環境をつ くれる •  テキストファイルなので バージョン管理理システム にも登録可能 79
  80. 80. AMI作成の3つの選択肢 AMI コード 共通サービス サードパーティ ライブラリ OS AMI コード 共通サービス サードパーティ ライブラリ OS AMI コード 共通サービス サードパーティ ライブラリ OS 80
  81. 81. AMI作成の3つの選択肢 1.  全部⼊入り仮想マシンイメージを作成し維持 2.  OSおよびベースとなるソフトウェアを導⼊入した仮想マシンイメー ジを作成し、初回作成時に追加部分のみプロビジョニング 3.  OSの仮想マシンイメージを起動し、初回作成時に、必要な全てを プロビジョニング Packer  +  Chef-‐‑‒Solo等を利利⽤用して⾃自動化も可能 →⾃自動化できればCIできる! 81
  82. 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. 83. Chef 83
  84. 84. 84
  85. 85. IF  YOU  CAN  PROGRAM  IT YOU  CAN  AUTOMATE  IT ⾃自動化しやすいものを選択せよ ⾃自動化できれば継続的インテグレー ションできる 85
  86. 86. Chefのクックブックも 継続的インテグレーション テスト駆動型インフラストラクチャー 86
  87. 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. 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. 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. 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. 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. 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. アジェンダ •  ビジネスの要求と⾃自動化が必要な背景 •  デプロイやプロビジョニングを⾃自動化しないリスク •  デプロイやプロビジョニングの⾃自動化に向けた戦略略 •  デプロイの⾃自動化 •  プロビジョニングの⾃自動化 •  まとめ 93
  94. 94. まとめ •  デプロイ⾃自動化・環境構築の⾃自動化には順番がある •  やるならプロジェクトの最初から •  プロセス設計をする •  APIを活⽤用する •  継続的インテグレーション重要 •  ⾃自動化された作業と⼿手作業を混ぜない •  適切切なツールを使う –  AWSなら  CloudFormation  /  Elastic  Beanstalk  /  OpsWorks   94

×