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

プロビジョニング＆デプロイ on AWS のキホン 2014年年3⽉月15⽇日アマゾンデータサービスジャパン株式会社シニアコンサルタント吉⽻羽⿓龍龍太郎郎 1 JAWS DAYS 2014 #jawsdays #infra

⾃自⼰己紹介 !   名前：吉⽻羽⿓龍龍太郎郎 •  @ryuzee •  www.ryuzee.com •  専⾨門領領域は、プロビジョニング・デプロイの⾃自動化、開発プロセスとか個⼈人の著作・翻訳・寄稿 2

Immutable Infrastructureってすぐ実現できるの？ 3 ⇒No

キホン：⾃自動化する 4

キホン：ビッグバンを避ける 5

インフラもアプリもソフトウェア化 http://aws.amazon.com/tools/ 6

Infrastructure as Code !   コードによるインフラの記述 !   サーバーの台数が増えても構築に時間がかからない !   コード＝⼿手順書となるのでコードを常にメンテナンスしておけば良良い !   ⼿手順を抜かしたり⼿手順を間違う⼼心配がない !   同じコードを動かせば同じサーバーが出来上がる !   コードで記述されているので再利利⽤用が容易易である !   他のプロジェクトでコードを使いまわすことで無駄を省省ける 7

キホン：連続体として捉える !   インフラのプロビジョニングとアプリのデプロイは連続体 !   両者を⼀一緒に考える !   キーワードは伸縮⾃自在性 8

(例例) AutoScalingではインフラ・アプリが⼀一体 !   a 9

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

⾃自動化しないリスク

前提：作業は繰り返し⾏行行われる !  デプロイ作業は繰り返し⾏行行われる !  環境構築作業も何度度も⾏行行われる •  開発環境 •  テスト環境 •  ステージング環境 •  本番環境 !  リスク顕在化確率率率 x 実⾏行行回数 = ??

⼿手順書がメンテされないリスク !   よくある…

マニュアル作業によって間違うリスク !   いままで何度度デプロイしているか覚えているか？ !   いままで間違えたことはないのか？ 14

職⼈人芸依存へのリスク

リリースに失敗するリスク/戻れないリスク !   ⼿手作業で⼤大変なので慎重にレビューが必要 !   なので、複数をまとめてリリース !   ビッグバンリリース !   さらに失敗しやすく !   しかも戻せない 16

対象が増えると作業時間と失敗リスクが増加 (^_^;) ( ﾟ皿ﾟ)ｷｰｯ!! 17

コスト流流出のリスク 18

http://bit.ly/tnB8i0 結果的にいつも⾃自信を持てない !   清⽔水の舞台から⾶飛び降降りる… 19

そしてさらにプロセスが重くなるリスク !   リスクを恐れてチェックリストが増える !   トラブルごとに増える !   ⼆二重チェック、三重チェック… !   ⼀一時的には問題が発⽣生しなくなるかもしれないが… !   持続可能性に問題 20

でも時間がないので⼈人海戦術… !   単なる問題の先送り。あとになってもっと⼤大変 !   ⼀一時的に負債を許容しても、すぐに返済すべき 21

⾃自動化に向けた全体戦略略

投資対効果 (ROI) 24

基本的な考え⽅方 !   ⾃自動化にはコストがかかる !   基本ができていない場合は達成まで時間もかかる !   ⼿手作業でやった場合と⽐比較してどちらが安いか !   実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対処コスト等を含めて考える !   ただし、損益分岐点は思った以上に早い !   顧客が要求するスピードやアプリケーションのライフサイクルを踏まえる 25

⾃自動化に投資するか慎重な判断が必要な領領域 !   たとえば、⼩小規模なキャンペーンサイト !   使い捨てのアプリケーション !   納品したら終わりのモノ 26

プロダクトバックログ製品の機能をストーリー形式で記載プロダクトオーナーが優先順位を付け、プランニングポーカーで相対⾒見見積もり。項⽬目の追加はいつでも⾃自由だが実施有無や優先順位はPOが決める。開発チーム (6±3⼈人) プロダクトの開発を⾏行行う。製品の成功に向けて最⼤大限の努⼒力力をコミットするスクラムマスタースクラムプロセスがうまくいくようにする。外部から開発チームを守るプロダクトオーナー製品に対して責任をもち機能に優先順位を付けるステークホルダー製品の利利⽤用者、出資者、管理理職などの利利害関係者。鶏と称すスプリントバックログそのスプリント期間中に⾏行行うタスクのリストスプリント最⼤大4週間までのタイムボックス各スプリントの⻑⾧長さは同⼀一。この間は外部からの変更更を受け⼊入れないスプリントレビュースプリント中の成果である動作するソフトウェアをデモするレトロスペクティブスプリントの中での改善事項を話合い次に繋げる複数回スプリントを繰り返す出荷可能な製品の増分スプリント計画会議プロダクトバックログを再度度分析・評価し、そのスプリントで開発するプロダクトバックログアイテムを選択する。また選択した項⽬目をタスクにばらす完了了の定義何をもって「完了了」とするかを定義したリスト毎⽇日の繰り返しデイリースクラム毎⽇日開発チームが以下の３つの質問に答える・昨⽇日やったこと・今⽇日やること・困っていることバーンダウンチャートスプリントタスクの「推定残り時間」を更更新してグラフにプロットするタスク時間で⾒見見積もりプロセスの設計の必要性やみくもにやらない

キホン：⾃自動化の5R !  Rapid !  Reliable !  Repeatable !  Reduce Risk !  Roll back 28

プロジェクトの最初から始める !   プロジェクト期間中は何度度もテスト環境にデプロイしたりプロビジョニングするはずなのでコスト効率率率が向上 !   何度度もテストされ信頼性向上 29

顧客や上司の理理解を得る !   黙ってこっそりやるのは無理理 !   説明責任 !   個⼈人の便便利利ツール構築とは次元の違う話 30

全員がチャンピョン !   ただ与えられたモノを使うだけのチームでは破綻する 31

継続的に改善できる仕掛けを作る !   作りすぎのムダ !   ⼿手待ちのムダ !   運搬のムダ !   加⼯工のムダ !   在庫のムダ !   動作のムダ !   不不良良をつくるムダ !   Just in Time !   かんばん !   ムダ !   平準化 !   アンドン !   ポカヨケ !   ⾃自働化 !   改善 !   ⾒見見える化

デプロイの⾃自動化

デプロイしやすいアーキテクチャーの維持 !   アプリケーションを常にデプロイしやすいように維持 !   疎結合アーキテクチャー 34

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

http://bit.ly/utD8aA バージョン管理理は躾 37

バージョン管理理 !   全ての基本 !   ブランチ、マージを含めて、チーム全員が使い⽅方を理理解するのが当たり前。躾の問題 !   コードの共同所有 !   設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない !   ここがちゃんとできずに先に進む意味がない 38

ブランチの戦略略がチーム全員で理理解できているか？ブランチの戦略略はデプロイの戦略略と密接な関係 A successful Git branching modelより図を引⽤用 http://nvie.com/posts/a-‐‑‒ successful-‐‑‒git-‐‑‒branching-‐‑‒model/ 39

⾃自動化されたテスト !   速度度維持と品質維持の観点フェーズ修正までの時間要求や設計 5分コードやユニットテスト 15分結合テストやシステムテスト 1時間ベータテスト 2時間リリース後 1⽇日 40

どこまでテストを⽤用意するか？ !   ユニットテスト、結合テスト、受け⼊入れテスト、スモークテスト !   それはプロセスとして設計 41

テストしやすさ＝デプロイしやすさ 42

マイグレーション !   設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない原則 !   いつの時点のリリースにも戻せるようにする原則 !   依存関係・前後関係は⼈人が判断しない原則 !   →マイグレーションの活⽤用 43

継続的インテグレーション !   バージョン管理理、テスト⾃自動化、マイグレーションが実現できていれば継続的インテグレーションの実現が可能 !   常にリリース可能かどうかを検証し続ける !   プロジェクトの⽣生命線 44

継続的インテグレーションアンチパターン !   テストコードがない !   テストコードと製品コードを同時にコミットしない !   定時ビルドのみでコミットビルドがない・夜間ビルドしかない !   帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る !   CIでテストを通すために⼿手作業の準備が必要 !   メインラインのみで⼤大きなブランチをCI対象にしていない !   様々な種類のテストをまとめて⾏行行っている !   ビルドの失敗に気付かない / ビルドに失敗しても放置している !   ビルドの失敗に気づいても、修正コード以外のコードをコミットする !   何も変更更していないのにビルドが落落ちたり落落ちなかったり !   頻繁にビルドが失敗するので、失敗するのが普通だと思う !   CIからの通知メッセージが⼤大量量すぎる / CIが落落ちても何も通知しない !   CIサーバのリソースが貧弱 !   ビルドが肥⼤大化して結果が出るまでに時間がかかる !   本番環境やステージング環境と⼤大幅に環境が異異なる !   コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う !   CIサーバがおかしくなったときに直せる⼈人がいない !   ずっとCIでのチェック内容が変わらない、プロセスが変わらない 45

デプロイ⾃自動化 !   ここまで出来ていればデプロイ⾃自動化まであとちょっと !   まずデプロイプロセスの設計を 46

デプロイプロセス設計 !   いつ誰がどの環境にどの単位でデプロイするのか？ !   どういうデプロイのパターンが存在するのか？ !   どんなツールを使うのか？ !   誰がデプロイスクリプトを保守するのか？ !   デプロイの成功/失敗をどのように判断するのか？ !   デプロイ後に問題が分かったときにどのように対処するのか？ !   いまリリースされているバージョンをどのように知ることができるのか？これらによって実現⽅方法は変化する 47

キホン：粒粒度度を⼩小さくコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャーコードレビューチェックインユニットテストカバレッジドキュメント性能セキュリティデプロイ結合テスト受け⼊入れテストクロスブラウザ静的解析フィーチャー 48

デプロイのパターン LBから切切り離離すアプリケーションのデプロイスモークテスト LB対象に戻すアプリケーションのデプロイメンテ中ページに差し替えるアプリケーションのデプロイデータベースのマイグレーションスモークテストメンテ中ページから戻す新規環境構築アプリケーションのデプロイスモークテスト LB切切り替え 49

デプロイアンチパターン：様々な⽅方法 !   パターンを多くし過ぎるとデプロイの信頼性が低下 •  各パターンが⼗十分にテストされない !   ⼀一般的には以下の2種類 •  ⼤大規模リリース⽤用 •  ⼩小規模リリース⽤用 50

デプロイアンチパターン：⼿手作業混合 !   デプロイ作業の中に⼿手作業を混ぜない。間違いによるデプロイの失敗に直結 51

ツールの選択 !   専⽤用のツールを使うことを強く推奨 !   Capistrano、Fabric、Maven・・・・などなど !   デプロイスクリプトの可読性と保守性は重要 !   これがリリース⼿手順書の代わりになるので、担当者が変わっても保守できるものを選択 !   シェルスクリプトは複雑化しやすく保守しにくい !   Elastic Beanstalk & OpsWorks !! 52

オンプレミス新しいインフラの構築は複雑かつ遅くなりがちクラウドワンクリックで新しいインフラを⽤用意新しいデプロイ環境を構築新しいテスト環境を構築新しい環境を海外に構築 1,000 サーバ追加 1,000 サーバ削除必要調査評価計画設計エンジニア調達契約コミッションデプロイクラウドのメリットを活かす 53

Webサーバー群 (Amazon EC2) データベースサーバ群 (Amazon RDS) ロードバランサー v1.1 v1.1 v1.1 v1.1 v1.2 v1.2 v1.2 v1.2 モニタリング (CloudWatch) ブルーグリーンデプロイ 54

55 Elastic Beanstalk 55

!   ELB + Web(AutoScaling) !   ログやアプリはS3に !   単純な構成を容易易に管理理 !   VPC内でも利利⽤用可能 !   システム全体ではなく⼀一部での利利⽤用も可能 56

!   アプリケーションを簡単にデプロイ !   複数環境を切切り替え可能（ブルーグリーンデプロイ） 57

Elastic Beanstalkでワンクリックデプロイ !   たとえばCIサーバでテストが終わったあとに、CIサーバから直接ステージング環境にデプロイする、といったことも簡単に出来る !   もちろん本番環境でも 58

デプロイ失敗の検知 !   スモークテストの実⾏行行 !   監視システムによるログ監視やプロセス監視 59

あとからデプロイ⾃自動化する場合 !   各ステップが実現できているか確認 !   アプリケーションのアーキテクチャー修正が必要になる可能性もバージン管理理テスト⾃自動化マイグレーシン継続的インテグレーシンデプロイ⾃自動化 60

プロビジョニング

プロビジョニング⾃自動化の進め⽅方 !   基本的な考え⽅方はデプロイ⾃自動化と同じ !   デプロイとプロビジョニングは連続体 !   プロセスの設計 !   ベストなツールの選択 !   ⾃自動化しやすいアーキテクチャー 62

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

AWSのプロダクトの位置づけ Elastic Beanstalk OpsWorks CloudFormation EC2 ⼿手軽⾃自由度度⾼高サービス型⾃自⼰己管理理型 64

65 プロダクト Elastic Beanstalk OpsWorks CloudForm ation Amazon EC2 できること定番構成＋アプリデプロイカスタム構成＋アプリデプロイスタックの⼀一括構築なんでも利利⽤用頻度度アプリデプロイごとアプリデプロイ・プロビジョニングごと初回１回や似た環境を作るとき⾃自分で管理理 (Chef、 Capistrano 等) ⼿手軽さ・⾃自由度度⼿手軽⼿手軽⾃自由⾃自由考慮点定番アーキテクチャかどうか Cookbookのテストをどうするかアプリデプロイは別で考える構築のコストを考慮 !   組み合わせ技も可能

!   アプリケーションをAWS上で管理理するための DevOpsソリューション •  Chef-‐‑‒Solo(Chefのスタンドアローン版)を採⽤用 •  幅広いアプリケーションアーキテクチャをサポート •  Elastic Beanstalkよりインフラおよびミドルウェアレイヤーでの⾃自由度度が⾼高い AWS OpsWorks 66

CloudFormation !   JSONで環境を記述 !   このテンプレートを使って何個でも同じ環境をつくれる !   テキストファイルなのでバージョン管理理システムにも登録可能 67

AMI作成の3つの選択肢 AMI コード共通サービスサードパーティライブラリ OS AMI コード共通サービスサードパーティライブラリ OS AMI コード共通サービスサードパーティライブラリ OS 68

AMI作成の3つの選択肢 !   全部⼊入り仮想マシンイメージを作成し維持 !   OSおよびベースとなるソフトウェアを導⼊入した仮想マシンイメージを作成し、初回作成時に追加部分のみプロビジョニング !   OSの仮想マシンイメージを起動し、初回作成時に、必要な全てをプロビジョニング 69 Packer + Chef-‐‑‒Soloなんかで作ると⾃自動化も可能 →⾃自動化できればCIできる！

Chef 70

IF YOU CAN PROGRAM IT YOU CAN AUTOMATE IT ⾃自動化しやすいものを選択せよ⾃自動化できれば継続的インテグレーションできる

Chefのクックブックも継続的インテグレーションテスト駆動型インフラストラクチャー 73

インフラCI構成例例 !   Amazon EC2 •  インスタンスストレージにSSDがあるものを選択 !   Ubuntu 12.04 LTS !   Jenkins !   Vagrant •  vagrant-‐‑‒lxcプラグイン !   LXC •  インスタンスストレージ上に仮想マシンを作成し⾼高速化 !   Chef •  Test-‐‑‒Kitchen、Berkshelf •  CookbookはGitHubに ! Serverspec 74

監視の例例 (Sensu) !   a 75 !   ⾃自動で監視システムに登録 !   ⾃自動で監視システムから離離脱 !   従来と異異なる監視アーキテクチャ !   ⼿手作業での監視設定も排除!!!

監視の例例 (Sensu + Graphite) !   a 76 ※Sensu → Graphite を⾃自動化

ベストプラクティス !   プロジェクトの最初から始める !   最初からやれば、ずっとテストされ続ける !   環境構築のテストも⾃自動化する !   チームに⼈人が増えても困らない 77

アンチパターン：⼿手作業との併⽤用 !   ⾃自動化されているサーバに⼊入って⼿手作業で変更更… !   次回にロールバックされたりする 78

アンチパターン：テストがない !   ⾃自動化スクリプトは⼿手順書と同等 !   常時テストしていなければ、次回使う時に正しく動くかわからない 79

途中からの環境構築⾃自動化 !   デプロイ⾃自動化に較べると、既に存在する環境に対して途中から適⽤用するのは難易易度度が⾼高い !   途中からの場合はまず開発環境から⾃自動化 !   サービス系のようにサーバの台数が増えるものについては、追加分のみ⾃自動化機構で管理理し、徐々に⼊入れ替える 80

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

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

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

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

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

まとめ !   デプロイ⾃自動化・環境構築の⾃自動化には順番がある !   やるならプロジェクトの最初から !   プロセス設計をする !   APIを活⽤用する !   継続的インテグレーション重要 !   ⾃自動化された作業と⼿手作業を混ぜない !   適切切なツールを使う •  AWSなら CloudFormation / Elastic Beanstalk / OpsWorks 86

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

by Ryuzee YOSHIBA, CTO, Agile Coach at Somewhere on Mar 15, 2014

Statistics

Views

Actions

0 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

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