The Basics of Provisioning and Deploy on AWS #jawdays #infra

6,438 views

Published on

2014/3/15に行われたJAWS DAYS 2014でのセッション資料です

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

No Downloads
Views
Total views
6,438
On SlideShare
0
From Embeds
0
Number of Embeds
327
Actions
Shares
0
Downloads
71
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

The Basics of Provisioning and Deploy on AWS #jawdays #infra

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

×