デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略

4,273 views

Published on

ビジネスの速度にあわせて頻繁にインフラストラクチャーを伸縮させたりアプリケーションをデプロイするためには、不安定なマニュアルプロセスではなく、再現可能な自動化されたプロセスを作り上げていかなければなりません。本セッションではこれからクラウド環境上での自動化を進めていくことを検討されている方のために、自動化の始め方や戦略、そして具体的なケーススタディを紹介いたします。

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

No Downloads
Views
Total views
4,273
On SlideShare
0
From Embeds
0
Number of Embeds
338
Actions
Shares
0
Downloads
64
Comments
0
Likes
35
Embeds 0
No embeds

No notes for slide

デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略

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

×