Download as PDF, PPTX
Uploaded byAmazon Web Services Japan
PDF, PPTX6,102 views
Provisioning & Deploy on AWS
AWS Black Belt Tech Webinar 2014(旧マイスターシリーズ)Provisioning & Deploy on AWS
More Related Content
What's hot
Similar to Provisioning & Deploy on AWS
More from Amazon Web Services Japan
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2f20220126-anti-220126190603-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
Provisioning & Deploy on AWS
- 1.Provisioning & Deployon AWSAWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ)アマゾンデータサービスジャパン株式会社技術本部 プロフェッショナルサービス事業部シニアコンサルタント 吉⽻羽⿓龍龍太郎郎
- 2.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ2
- 3.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ3
- 4.
- 5.ビジネスはうまくいかないこともある• 1発1中は⽬目指さない• うまくいっていないことを把握できる仕掛け• ダメなものをやめる選択肢5
- 6.
- 7.
- 8.05010015020025030020072008200920102011201220139 24 4861 82159280AWSのイノベーションのペース8
- 9.
- 10.
- 11.
- 12.
- 13.Infrastructure as Code• コードによるインフラの記述13
- 14.Infrastructure as Codeのメリット• サーバーの台数が増えても構築に時間がかからない• コード＝⼿手順書となるのでコードを常にメンテナンスしておけば良良い• ⼿手順を抜かしたり⼿手順を間違う⼼心配がない• 同じコードを動かせば同じサーバーが出来上がる• コードで記述されているので再利利⽤用が容易易である• 他のプロジェクトでコードを使いまわすことで無駄を省省ける14
- 15.Infrastructure as Codeのデメリット• 学習コスト・作るのに時間がかかる• 常に正しく動作するようにメンテナンスする必要がある• 雑なやり⽅方をしてしまうと、保守にかえって時間がかかる可能性がある15
- 16.キホン：連続体として捉える• インフラのプロビジョニングとアプリのデプロイは連続体• 両者を⼀一緒に考える• キーワードは伸縮⾃自在性16
- 17.
- 18.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ18
- 19.前提：作業は繰り返し⾏行行われる• デプロイ作業は繰り返し⾏行行われる• 環境構築作業も何度度も⾏行行われる– 開発環境– テスト環境– ステージング環境– 本番環境• リスク顕在化確率率率 x 実⾏行行回数 = ??19
- 20.
- 21.
- 22.
- 23.リスク4：リリース失敗・戻し失敗• ⼿手作業で⼤大変なので慎重にレビューが必要• なので、複数をまとめてリリース• =ビッグバンリリース• さらに失敗しやすく• しかも戻せない23
- 24.
- 25.
- 26.
- 27.リスク7：どんどんプロセスが重くなる• チェックリストが増える• トラブルごとに増える• ⼆二重チェック、三重チェック…• ⼀一時的に問題が発⽣生しなくなるかもしれないが…• 持続できない…27
- 28.
- 29.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ29
- 30.
- 31.
- 32.コストの考え⽅方• ⾃自動化にはコストがかかる• 基本ができていない場合は達成まで時間もかかる• ⼿手作業でやった場合と⽐比較してどちらが安いか• 実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対処コスト等を含めて考える• ただし、損益分岐点は思った以上に早い• 顧客が要求するスピードやアプリケーションのライフサイクルを踏まえる32
- 33.
- 34.
- 35.キホン：⾃自動化の5R• Rapid• Reliable• Repeatable• Reduce Risk• Roll back35
- 36.
- 37.キホン：顧客や上司の理理解を得る• 黙ってこっそりやるのは無理理• 説明責任• 個⼈人の便便利利ツール構築とは次元の違う話として組織で取り組む37
- 38.
- 39.キホン：カイゼンを続ける• Just in Time• かんばん• ムダ• 平準化• アンドン• ポカヨケ• ⾃自働化• 改善• ⾒見見える化• 作りすぎのムダ• ⼿手待ちのムダ• 運搬のムダ• 加⼯工のムダ• 在庫のムダ• 動作のムダ• 不不良良をつくるムダ39
- 40.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ40
- 41.
- 42.
- 43.キホン：デプロイ⾃自動化に必要な要素• バージョン管理理システム• ⾃自動化されたテスト• マイグレーション• 継続的インテグレーション• デプロイツール• (静的解析・コードレビュー)43
- 44.キホン：バージョン管理理• 全ての基本• ブランチ、マージを含めて、チーム全員が使い⽅方を理理解するのが当たり前。躾の問題• コードの共同所有(XPの考え⽅方)• 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない44
- 45.ブランチモデルの理理解• ブランチの戦略略がチーム全員で理理解できているか？• ブランチの戦略略はデプロイの戦略略と密接な関係A successful Git branching modelより図を引⽤用(http://nvie.com/posts/a-‐‑‒successful-‐‑‒git-‐‑‒branching-‐‑‒model/)45
- 46.キホン：⾃自動化されたテスト• 速度度維持と品質維持– 早期に問題を解決し続ける⽅方がコストが安いフェーズ修正までの時間要求や設計 5分コードやユニットテスト 15分結合テストやシステムテスト 1時間ベータテスト 2時間リリース後 1⽇日46
- 47.
- 48.
- 49.マイグレーション• 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない原則• いつの時点のリリースにも戻せるようにする原則• 依存関係・前後関係は⼈人が判断しない原則• →マイグレーションの活⽤用49
- 50.
- 51.
- 52.継続的インテグレーションアンチパターン• テストコードがない• テストコードと製品コードを同時にコミットしない• 定時ビルドのみでコミットビルドがない・夜間ビルドしかない• 帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る• CIでテストを通すために⼿手作業の準備が必要• メインラインのみで⼤大きなブランチをCI対象にしていない• 様々な種類のテストをまとめて⾏行行っている• ビルドの失敗に気付かない / ビルドに失敗しても放置している• ビルドの失敗に気づいても、修正コード以外のコードをコミットする• 何も変更更していないのにビルドが落落ちたり落落ちなかったり• 頻繁にビルドが失敗するので、失敗するのが普通だと思う• CIからの通知メッセージが⼤大量量すぎる / CIが落落ちても何も通知しない • CIサーバのリソースが貧弱• ビルドが肥⼤大化して結果が出るまでに時間がかかる• 本番環境やステージング環境と環境が異異なる• コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う• CIサーバがおかしくなったときに直せる⼈人がいない• ずっとCIでのチェック内容が変わらない、プロセスが変わらない52
- 53.継続的インテグレーション on AWS• スローテストを避けるため、並列列実⾏行行• 指定時刻にCIサーバを増やし、必要なくなったら⽌止める• クラウドならではのアプローチ53負荷テスト性能テストユニットテスト機能テスト受け⼊入れテスト結合テストなど…
- 54.
- 55.キホン：デプロイプロセス設計• いつ誰がどの環境にどの単位でデプロイするのか？• どういうデプロイのパターンが存在するのか？• どんなツールを使うのか？• 誰がデプロイスクリプトを保守するのか？• デプロイの成功/失敗をどのように判断するのか？• デプロイ後に問題が分かったときにどのように対処するのか？• いまリリースされているバージョンをどのように知ることができるのか？55
- 56.
- 57.
- 58.デプロイアンチパターン：様々な⽅方法• パターンを多くし過ぎるとデプロイの信頼性が低下– 各パターンが⼗十分にテストされない• ⼀一般的には以下の2種類– ⼤大規模リリース⽤用– ⼩小規模リリース⽤用58
- 59.
- 60.ツールの選択• 専⽤用のツールを使う– Capistrano、Fabric、Maven・・・・などなど• デプロイスクリプトの可読性と保守性は重要– これがリリース⼿手順書の代わりになるので、担当者が変わっても保守できるものを選択– シェルスクリプトは複雑化しやすく保守しにくい• Elastic Beanstalk & OpsWorks が⾃自分たちのプロセスに合いそうかどうかを確認– どんなデプロイプロセスが必要なのかによって適合性がかわる60
- 61.クラウドのメリットを活かすオンプレミス 新しいインフラの構築は複雑かつ遅くなりがちクラウド ワンクリックで新しいインフラを⽤用意新しいデプロイ環境を構築新しいテスト環境を構築新しい環境を海外に構築1,000 サーバ追加1,000 サーバ削除必要 調査 評価計画 設計 エンジニア調達 契約コミッションデプロイ61
- 62.ブルーグリーンデプロイWebサーバー群(Amazon EC2)データベースサーバ群(Amazon RDS)ロードバランサーv1.1v1.1v1.1 v1.1v1.2v1.2v1.2v1.2モニタリング(CloudWatch)62デプロイの後⼀一定期間たって戻すことがないと判断できた時点で旧バージョン削除クラウドの特性を活かしたデプロイ
- 63.AmazonRoute53EC2InstancesELBEC2InstancesELB90% 10%DynamoDB MySQLRDSInstanceElastiCacheCacheNodeブルーグリーンデプロイ• Route53の重み付けラウンドロビンで振り分けすることで、新規機能をリリースする際に⼀一部のユーザだけに公開• 評価結果がよければ新機能側を増やしてリクエストを寄せていく• これらの切切り替えを全てAPIの組み合わせで可能63
- 64.v1.1 v1.1v1.1 v1.1v1.1v1.1v1.1 v1.1v1.2v1.2v1.2.1v1.2.1v1.2.2v1.2.2DNS(Amazon route 53)Webサーバー群(Amazon EC2)データベースサーバ群(Amazon RDS)ロードバランサー90% 5% 3% 2%ブルーグリーンデプロイ64
- 65.
- 66.• ELB + Web＋(DB)の定番構成で利利⽤用• Auto Scaling利利⽤用可能• ログやアプリはS3に• 単純な構成を容易易に管理理• VPC内でも利利⽤用可能• システム全体ではなく⼀一部での利利⽤用も可能66
- 67.
- 68.
- 69.Elastic Beanstalk + DockerDeveloper1. docker push4. docker pull2. deployregistryregistryregistryregistryRegionappappappregistryapp3. docker run registry5. docker stop registryDocker registry container with AWS credentials69
- 70.
- 71.
- 72.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ72
- 73.プロビジョニング⾃自動化の進め⽅方• 基本的な考え⽅方はデプロイ⾃自動化と同じ• デプロイとプロビジョニングは連続体• プロセスの設計• ベストなツールの選択• ⾃自動化しやすいアーキテクチャー73
- 74.VPC 10.0.0.0/16Availability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic Subnet 10.0.0.0/24Public Subnet 10.0.2.0/24Private Subnet 10.0.1.0/24Private Subnet 10.0.3.0/24AMIAmazon RDSAmazon RDSAZ-‐‑‒A-‐‑‒WP110.0.0.6EC2 InstanceEC2 InstanceAZ-‐‑‒B-‐‑‒WP210.0.2.8こんな環境の作成を⾃自動化できる74
- 75.AWSのプロダクトの位置づけElastic Beanstalk OpsWorksCloudFormation EC2⼿手軽 ⾃自由度度⾼高サービス型 ⾃自⼰己管理理型75
- 76.プロダクト ElasticBeanstalkOpsWorks CloudFormationAmazon EC2できること 定番構成＋アプリデプロイカスタム構成＋アプリデプロイスタックの⼀一括構築なんでも利利⽤用頻度度 アプリデプロイごとアプリデプロイ・プロビジョニングごと初回１回や似た環境を作るとき⾃自分で管理理(Chef、Capistrano等)⼿手軽さ・⾃自由度度⼿手軽 ⼿手軽 ⾃自由 ⾃自由考慮点 定番アーキテクチャかどうかCookbookのテストをどうするかアプリデプロイは別で考える構築のコストを考慮76組み合わせ技も可能。例例えばCloudFormationを使ってElastic BeanstalkのアプリケーションやOpsWorksのスタックを作成したりできる
- 77.AWS OpsWorks• アプリケーションをAWS上で管理理するためのDevOpsソリューション• Chef-‐‑‒Solo(Chefのスタンドアローン版)を採⽤用• 幅広いアプリケーションアーキテクチャをサポート• Elastic Beanstalkよりインフラおよびミドルウェアレイヤーでの⾃自由度度が⾼高い77
- 78.78 UserAWS Management ConsoleStack例例Load BalancerレイヤーApp ServerレイヤーDatabaseレイヤーレシピレシピレシピ DBWeb/AppWeb/AppLB①スタックの作成②レイヤーの作成③レシピの設定④レイヤーに インスタンス追加・起動⑤ライフサイクルイベントにより、レシピが実⾏行行構成情報(JSON)⾃自分でレイヤーを複数定義し、適⽤用するレシピを指定していくことで環境構築・デプロイを⾃自動化。⾃自由度度⾼高
- 79.CloudFormation• JSONで環境を記述• このテンプレートを使って何個でも同じ環境をつくれる• テキストファイルなのでバージョン管理理システムにも登録可能79
- 80.
- 81.AMI作成の3つの選択肢1. 全部⼊入り仮想マシンイメージを作成し維持2. OSおよびベースとなるソフトウェアを導⼊入した仮想マシンイメージを作成し、初回作成時に追加部分のみプロビジョニング3. OSの仮想マシンイメージを起動し、初回作成時に、必要な全てをプロビジョニングPacker + Chef-‐‑‒Solo等を利利⽤用して⾃自動化も可能→⾃自動化できればCIできる！81
- 82.Chefを使った場合の構成例例Amazon LinuxEC2 Instanceを起動 Chef Clientのみインストール済みCustom AMIami-‐‑‒1ab34567Amazon Linux and Chef Agent installedChef ClientEC2インスタンスChef ServerEBSインストール⽤用のファイルが配置されたS3バケットAmazon LinuxRunning EC2 InstanceLoaded with Applications Installed by ChefChef ClientMonitoring AgentPHPNginxOther Libraries 適⽤用するCookbookやAttributeを取得82
- 83.
- 84.
- 85.IF YOU CAN PROGRAM ITYOU CAN AUTOMATE IT⾃自動化しやすいものを選択せよ⾃自動化できれば継続的インテグレーションできる85
- 86.
- 87.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例Graphite87
- 88.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例CloudFormationで環境を定義Graphite88
- 89.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例GraphiteコードはGitHubへ89
- 90.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例GraphiteコードがコミットされるとCI実⾏行行90
- 91.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例Graphiteサーバ⼀一覧をAPI経由で取得しデプロイしつつS3にアーカイブ配置91
- 92.VPCAvailability Zone -‐‑‒ CAvailability Zone -‐‑‒ AInternetAnyoneInternet GatewayPublic SubnetPublic Subnet Private SubnetPrivate SubnetAMIAmazon RDSAmazon RDS実例例GraphiteEC2起動時にAMIとChef Server利利⽤用。⾃自動で最新コードをS3から取得監視システムに⾃自動登録92
- 93.アジェンダ• ビジネスの要求と⾃自動化が必要な背景• デプロイやプロビジョニングを⾃自動化しないリスク• デプロイやプロビジョニングの⾃自動化に向けた戦略略• デプロイの⾃自動化• プロビジョニングの⾃自動化• まとめ93
- 94.まとめ• デプロイ⾃自動化・環境構築の⾃自動化には順番がある• やるならプロジェクトの最初から• プロセス設計をする• APIを活⽤用する• 継続的インテグレーション重要• ⾃自動化された作業と⼿手作業を混ぜない• 適切切なツールを使う– AWSなら CloudFormation / Elastic Beanstalk / OpsWorks 94