デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
•
36 gostaram•5,186 visualizações
ビジネスの速度にあわせて頻繁にインフラストラクチャーを伸縮させたりアプリケーションをデプロイするためには、不安定なマニュアルプロセスではなく、再現可能な自動化されたプロセスを作り上げていかなければなりません。本セッションではこれからクラウド環境上での自動化を進めていくことを検討されている方のために、自動化の始め方や戦略、そして具体的なケーススタディを紹介いたします。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
Semelhante a デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略 (20)
Mais de Developers Summit
Mais de Developers Summit (20)
Último
Último (9)
デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
- 2. ⾃自⼰己紹介 ! 名前：吉⽻羽⿓龍龍太郎郎 • アマゾン データ サービス ジャパン株式会社 • シニア・コンサルタント ! ソーシャル • @ryuzee • www.ryuzee.com 2 個⼈人の著作・翻訳
- 11. Amazonの3つのコアビジネス セラー向け ビジネス コンシューマ向け ビジネス 1億を超えるアクティブなア カウント ８カ国で展開 : ⽶米国, 英国, ドイツ, ⽇日本, フ ランス, カナダ, 中国, イタリア アマゾンの ウェブサイト上で販売 ⾃自社⼩小売ウェブサイトに Amazonの技術を利利⽤用 アマゾンフルフィルメント センター（物流流センター） の活⽤用 IT インフラストラクチャ 11 ITインフラ ビジネス スケーラビリティ 2006年年開始 ウェブスケールでの クラウド基盤の提供 ⾼高可⽤用性 190以上の国において、数⼗十 万に及ぶ登録アカウント
- 12. ビジネスは変化する 12
- 13. ビジネスはうまくいかないこともある ! 1発1中は⽬目指さない ! うまくいっていないこ とを把握できる仕掛け ! ダメなものをやめる選 択肢 13
- 14. Build Measure Learn 14
- 15. フィードバックループ ! 顧客とビジネスの間のフィードバックループを加速する ! 顧客の期待に応え続ける 15
- 17. ビッグバンを避ける 17
- 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. ⾃自動化しないリスク
- 22. マニュアル作業によって間違うリスク ! いままで何度度デプロイしているか覚えているか？ ! いままで間違えたことはないのか？ 22
- 23. 職⼈人芸依存へのリスク
- 24. リリースに失敗するリスク/戻れないリスク ! ⼿手作業で⼤大変なので慎重 にレビューが必要 ! なので、複数をまとめて リリース ! ビッグバンリリース ! さらに失敗しやすく ! しかも戻せない 24
- 26. コスト垂れ流流しのリスク 26
- 28. そしてさらにプロセスが重くなるリスク ! リスクを恐れてチェッ クリストが増える ! トラブルごとに増える ! ⼆二重チェック、三重 チェック… ! ⼀一時的には問題が発⽣生 しなくなるかもしれな いが… ! 持続可能性に問題 28
- 29. でも時間がないので⼈人海戦術… ! 単なる問題の先送り。あとになってもっと⼤大変 ! ⼀一時的に負債を許容しても、すぐに返済すべき 29
- 30. ⾃自動化に向けた全体戦略略
- 31. 31
- 32. 投資対効果 (ROI) 32
- 33. 基本的な考え⽅方 ! ⾃自動化にはコストがかかる ! 基本ができていない場合は達成まで時間もかかる ! ⼿手作業でやった場合と⽐比較してどちらが安いか ! 実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対処コ スト等を含めて考える ! ただし、損益分岐点は思った以上に早い ! 顧客が要求するスピードやアプリケーションのライフサ イクルを踏まえる 33
- 34. ⾃自動化に投資するか慎重な判断が必要な領領域 ! たとえば、⼩小規模なキャンペーンサイト ! 使い捨てのアプリケーション ! 納品したら終わりのモノ 34
- 37. 怠惰 短気 傲慢 37
- 39. 顧客や上司の理理解を得る ! 黙ってこっそりやるのは無理理 ! 説明責任 ! 個⼈人の便便利利ツール構築とは次 元の違う話 39
- 42. デプロイの⾃自動化戦略略
- 43. プロジェクトの最初から始める ! プロジェクト期間中は何度度もテスト環境にデプロイする はずなのでコスト効率率率が⾼高くなる ! 何度度もテストされ信頼性向上 43
- 44. デプロイしやすいアーキテクチャーの維持 ! アプリケーションを常にデプロイしやすいように維持 ! 疎結合アーキテクチャー 44
- 45. デプロイ⾃自動化に必要な要素 ! ! ! ! ! ! 45 バージョン管理理システム ⾃自動化されたテスト マイグレーション 継続的インテグレーション デプロイツール (静的解析・コードレビュー)
- 47. バージョン管理理 ! 全ての基本 ! ブランチ、マージを含めて、チーム全員が使い⽅方を理理解 するのが当たり前。躾の問題 ! コードの共同所有 ! 設定ファイルやアセット含めて、いつでも環境を再現で きるようにしなければならない ! ここがちゃんとできずに先に進む意味がない 47
- 48. ブランチの戦略略がチー ム全員で理理解できてい るか？ ブランチの戦略略は デプロイの戦略略と 密接な関係 A successful Git branching modelよ り図を引⽤用 http://nvie.com/posts/a-‐‑‒ successful-‐‑‒git-‐‑‒branching-‐‑‒model/ 48
- 50. どこまでテストを⽤用意するか？ ! ユニットテスト、結合テスト、受け⼊入れテスト、スモー クテスト ! それはプロセスとして設計 50
- 52. マイグレーション ! 設定ファイルやアセット含めて、いつでも環境を再現で きるようにしなければならない原則 ! いつの時点のリリースにも戻せるようにする原則 ! 依存関係・前後関係は⼈人が判断しない原則 ! →マイグレーションの活⽤用 52
- 53. 継続的インテグレーション ! バージョン管理理、テスト⾃自動化、マイグレーションが実 現できていれば継続的インテグレーションの実現が可能 ! 常にリリース可能かどうかを検証し続ける ! プロジェクトの⽣生命線 53
- 54. 継続的インテグレーションアンチパターン ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 54 テストコードがない テストコードと製品コードを同時にコミットしない 定時ビルドのみでコミットビルドがない・夜間ビルドしかない 帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る CIでテストを通すために⼿手作業の準備が必要 メインラインのみで⼤大きなブランチをCI対象にしていない 様々な種類のテストをまとめて⾏行行っている ビルドの失敗に気付かない / ビルドに失敗しても放置している ビルドの失敗に気づいても、修正コード以外のコードをコミットする 何も変更更していないのにビルドが落落ちたり落落ちなかったり 頻繁にビルドが失敗するので、失敗するのが普通だと思う CIからの通知メッセージが⼤大量量すぎる / CIが落落ちても何も通知しない CIサーバのリソースが貧弱 ビルドが肥⼤大化して結果が出るまでに時間がかかる 本番環境やステージング環境と⼤大幅に環境が異異なる コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う CIサーバがおかしくなったときに直せる⼈人がいない ずっとCIでのチェック内容が変わらない、プロセスが変わらない
- 55. デプロイ⾃自動化 ! ここまで出来ていればデプロイ⾃自動化まであとちょっと ! まずデプロイプロセスの設計を 55
- 60. クラウドのメリットを活かす オンプレミス 新しいインフラの構築は複雑 かつ遅くなりがち 必要 計画 調査 設計 評価 エンジニア クラウド ワンクリックで新しい インフラを⽤用意 新しいデプロイ環境を構築 新しいテスト環境を構築 新しい環境を海外に構築 調達 契約 コミッション 1,000 サーバ追加 デプロイ 60 1,000 サーバ削除
- 61. デプロイアンチパターン：様々な⽅方法 ! パターンを多くし過ぎるとデプロイの信頼性が低下 • 各パターンが⼗十分にテストされない ! ⼀一般的には以下の2種類 • ⼤大規模リリース⽤用 • ⼩小規模リリース⽤用 61
- 63. ツールの選択 ! 専⽤用のツールを使うことを強く推奨 ! Capistrano、Fabric、Maven・・・・などなど ! デプロイスクリプトの可読性と保守性は重要 ! これがリリース⼿手順書の代わりになるので、担当者が変 わっても保守できるものを選択 ! シェルスクリプトは複雑化しやすく保守しにくい 63
- 64. デプロイ失敗の検知 ! スモークテストの実⾏行行 ! 監視システムによるログ監視やプロセス監視 64
- 65. あとからデプロイ⾃自動化する場合 ー バ ジ ー シ ン ー ン 管 理理 テ ス ト ⾃自 動 化 マ イ グ レ 継 続 的 イ ン テ グ レ シ デ プ ロ イ ⾃自 動 化 ン ! 各ステップが実現できているか確認 ! アプリケーションのアーキテクチャー修正が必要になる 可能性も 65
- 66. 環境構築の⾃自動化戦略略
- 67. 環境構築⾃自動化の進め⽅方 ! 基本的な考え⽅方はデプロイ⾃自動化と同じ ! プロセスの設計 ! ベストなツールの選択。 ! デプロイツールとは違うツールを使った⽅方が良良い ! ⾃自動化しやすいアーキテクチャー 67
- 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. CloudFormation ! JSONで環境を記述 ! このテンプレートを使って何 個でも同じ環境をつくれる ! テキストファイルなのでバー ジョン管理理システムにも登録 可能 71
- 72. Vagrant ! a 72
- 73. Puppet 73
- 74. Chef 74
- 75. 75
- 76. IF YOU CAN PROGRAM IT YOU CAN AUTOMATE IT ⾃自動化しやすいものを選択せよ ⾃自動化できれば継続的インテグ レーションできる
- 78. インフラCI構成例例 ! Amazon EC2 • インスタンスストレージにSSDがあるものを選択 ! Ubuntu 12.04 LTS ! Jenkins ! Vagrant • vagrant-‐‑‒lxcプラグイン ! LXC • インスタンスストレージ上に仮想マシンを作成し⾼高速化 ! Chef • Test-‐‑‒Kitchen、Berkshelf • CookbookはGitHubに ! Serverspec 78
- 79. 環境構築の3つの選択肢 (クラウドの場合) ! 全部⼊入り仮想マシンイメージを作成し維持 ! OSおよびベースとなるソフトウェアを導⼊入した仮想マ シンイメージを作成し、初回作成時に追加部分のみプロ ビジョニング ! OSの仮想マシンイメージを起動し、初回作成時に、必 要な全てをプロビジョニング 79
- 81. アンチパターン：⼿手作業との併⽤用 ! ⾃自動化されているサーバに⼊入って⼿手作業で変更更… ! 次回にロールバックされたりする 81
- 82. アンチパターン：テストがない ! ⾃自動化スクリプトは⼿手順書と同等 ! 常時テストしていなければ、次回使う時に正しく動くか わからない 82
- 83. 途中からの環境構築⾃自動化 ! デプロイ⾃自動化に較べると、既に存在する環境に対して 途中から適⽤用するのは難易易度度が⾼高い ! 途中からの場合はまず開発環境から⾃自動化 ! サービス系のようにサーバの台数が増えるものについて は、追加分のみ⾃自動化機構で管理理し、徐々に⼊入れ替える 83
- 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. 実例例 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. 実例例 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. 実例例 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. 実例例 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. 実例例 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. 実例例 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. まとめ ! デプロイ⾃自動化・環境構築の⾃自動化には順番がある ! やるならプロジェクトの最初から ! プロセス設計をする ! 適切切なツールを使う ! APIを活⽤用する ! 継続的インテグレーション重要 ! ⾃自動化された作業と⼿手作業を混ぜない 91