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