プロビジョニングの今 ーフルマネージド・サービスを目指してー #cmdevio2016 #E
•
5 likes•2,780 views
DevelopersIO 2016 E5 セッションのスライドです。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to プロビジョニングの今 ーフルマネージド・サービスを目指してー #cmdevio2016 #E
Similar to プロビジョニングの今 ーフルマネージド・サービスを目指してー #cmdevio2016 #E (20)
More from Shuji Watanabe
More from Shuji Watanabe (20)
Recently uploaded
Recently uploaded (7)
プロビジョニングの今 ーフルマネージド・サービスを目指してー #cmdevio2016 #E
- 1. Developers.IO 2016 E-3 AWSコンサルティング部 渡辺修司 Ⓒ Classmethod, Inc. 2016年02月20日 プロビジョニングの今 ーフルマネージド・サービスを目指してー 1
- 3. クラスメソッド雪山部 3
- 4. 渡辺修司 • AWSコンサルティング部 • 札幌オフィス • 開発系案件担当 • 自動化担当 • プログラミング • Java, Groovy, JavaScript • 趣味 • ロードバイク（夏） • スノーボード（冬） 4Ⓒ Classmethod, Inc.
- 5. プロビジョニングと自動化
- 6. プロビジョニングとは？ • リソース調達 • サーバ(EC2), ロードバランサ(ELB) • インフラセットアップ • ネットワーク, ファイヤウォール • サーバ・プロビジョニング • OSの設定, ミドルウェアのインストール・設定 • サービス・プロビジョニング • アプリケーションのデプロイなど 6Ⓒ Classmethod, Inc. サービスを利用可能にするまでの行程
- 7. 自動化は正義！ • 手作業によるミス防止 • 人が実行する以上はミスは防げない • 属人化防止 • コードや設定ファイルで定義 • 担当者が異動になっても設定は残る • 再利用 • 同じような設定は繰り返して利用 • 時間短縮 • 実行中の待機時間で他の作業ができる 7Ⓒ Classmethod, Inc.
- 8. 自動化の落とし穴 • ツールの選定と習熟 • 学習コスト • ハマった時に解決できるか？ → 有識者やネットの情報量 • ワンショットか繰り返し実行か？ • 汎用性が低くワンショットであれば手動のが良いことも多々 8Ⓒ Classmethod, Inc.
- 9. プロビジョニングを支援するツール・サービス • CloudFormation • VPCやEC2などAWSリソースを構築・管理 • Ansible • サーバの構成管理（ミドルウェアなど） • CodeDeploy • アプリケーションの配備・設定 • その他 • Elastic Beanstalk • Docker 9Ⓒ Classmethod, Inc.
- 10. プロビジョニング自動化のステップ 10Ⓒ Classmethod, Inc. レベル0 すべてを調べながら、手作業で行っている レベル1 セットアップ手順などがドキュメントにまとまっている レベル2 手順の一部が、スクリプト化またはプロビジョニングツー ルで記述されている レベル3 手順のほとんどがスクリプト化またはプロビジョニングツ ールで記述されており、何時でも環境を即時に作成できる レベル4 手順のほとんどが自動化されており、環境の変更時にはバ ージョン管理されたスクリプトや設定ファイルを更新する フローが確率されている レベル5 運用を踏まえた自動化の仕組みが完備されている
- 11. 自動化のゴールは運用 • 開発者の自己満足にしない • 新しいツールは使ってみたくなる • 自動化は楽しいため陥りがち • 長期運用を前提とする • メンテ不能な秘伝のレシピを作らない • メンテしない前提で使い切り（ワンショット）も検討 • スキルの底上げが必要な場合もある • 学習コスト ＜ メンテコストを見極める • バージョン管理システムが使えない場合は危機感を持つ • 自分たちで運用すると考えよう 11Ⓒ Classmethod, Inc.
- 12. CloudFormation
- 13. CloudFormationとは？ • AWSが提供するサービスのひとつ • AWSリソースを設定ファイルで定義（JSON形式） • VPCの作成からEC2の作成までカバー • アップデートによる成長するインフラ 13Ⓒ Classmethod, Inc. { "AWSTemplateFormatVersion" : "2010-09-09", "Resources" : { "EC2Instance" : { "Type" : "AWS::EC2::Instance", "Properties" : { "InstanceType" : { "Ref" : "InstanceType" }, "SecurityGroups" : [ { "Ref" : "InstanceSecurityGroup" } ], "KeyName" : { "Ref" : "KeyName" }, "ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" }, { "Fn::FindInMap" : [ "AWSInstanceType2Arch", { "Ref" : "InstanceType" }, "Arch" ] } ] } } } } }
- 14. テンプレートのパターン • サービス・テンプレート • 特定サービス（例: WordPress）環境をワンクリックで構築 • ビッグバン・テンプレート http://dev.classmethod.jp/series/ac2013-aws/ • フルスタック・テンプレート • 全AWSリソースの管理をCloudFormationで行う • クイックスタート・テンプレート • ネットワーク（VPC）などの基本部分のみを作成 • 構築後は手動でリソースを追加 • スニペット・テンプレート • 特定用途のIAMロールやセキュリティグループの作成 14Ⓒ Classmethod, Inc.
- 15. サービス・テンプレート • AWSアカウントがあれば、ワンクリックで利用可能 • WordPressなどのCMS, Jenkins • アップデートは基本的に考えない • お試し環境に相性が良い • ミドルウェアのセットアップはちょっと辛い • cloud-initを利用 • 基本的にシェルスクリプトで記述 • アップデート時のスクリプト実行などは未サポート 15Ⓒ Classmethod, Inc.
- 16. フルスタック・テンプレート • 全AWSリソースをCFnで管理 • 更新の履歴がCFnで一元管理される • 何時でもCFnで環境をコピー/再構築できる • メンテコストの問題 • マネジメントコンソールから更新できなくなる • ちょっとした修正でもCFnを修正しなければらならない • 気軽にインスタンスタイプの変更などができなくなる • CFnが対応していないこともある（後追い） • テンプレート変更の影響範囲を見極めるのが大変 16Ⓒ Classmethod, Inc.
- 17. クイックスタート・テンプレート • 環境をレイヤーで分ける • ネットワーク層は幾つかのパターンで整理可能 • EC2やRDSはプロジェクト毎に異なる • ネットワークレイヤのみCFnで作成してしまう • アプリレイヤもCFnにするならテンプレートを分割 • http://dev.classmethod.jp/cloud/aws/reinvent-2014-app304-aws-cloudformation-best-practice-report/ 17Ⓒ Classmethod, Inc.
- 18. スニペット・テンプレート • 各環境に横断的に適用したい • オフィスIPからSSH許可を行うセキュリティグループ • 特定の権限を持ったIAM Role • 監視用のEC2インスタンス • パラメータを利用してVPC IDなどを指定 • 作成・更新・撤収が簡単 18Ⓒ Classmethod, Inc.
- 19. CloudFormation活用のポイント • どこまでCFnで管理するかを決める • すべてを管理する場合は運用できるか？ • 初期構築時のみの割り切りもあり。 • テンプレートを分割 • ネットワーク層とサービス層は必ず分けること • 肥大化したテンプレートは維持するのがキツい • テンプレートを資産化して再利用を促進する • JSONの編集がつらいのでエディタ必須 • コメント化できないので変換ツールも活用すると良い 19Ⓒ Classmethod, Inc.
- 20. Ansible
- 21. Ansibleとは？ • サーバの構成管理ツール • OSやミドルウェアの設定をファイル定義（YAML） • OSユーザの作成からミドルウェアの設定までカバー • SSH接続で実行（エージェントレス） • サーバの冪等性を保つ 21Ⓒ Classmethod, Inc. - hosts: webservers tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf
- 22. Ansibleの実行 • クライアントマシンからのSSH接続 • AWS環境内からでもOK • ローカル実行（ansible-local） • ansibleのインストールが必要 22Ⓒ Classmethod, Inc.
- 23. 冪等性 • 設定ファイルがサーバの状態を定義 • 設定ファイルを変更しなければサーバの状態も変更されない • ok → 状態が変わっていない • changed → 状態が変わった • 冪等性を保つ運用がキモ 23Ⓒ Classmethod, Inc. - hosts: webservers tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf
- 24. Role • 構成管理の最小単位 • 再利用しやすく作成・管理 • 各プロジェクトでは組み合わせて実行 • プロジェクト固有の構成は別途記述 • CMの共通Role • system/lang • aws/awscli • aws/codedeploy 24Ⓒ Classmethod, Inc.
- 25. Ansibleの活用 • 共通部分だけAnsibleを流す • システム基本設定 • 共通スクリプトの設定 • セキュリティパッチの適用 • 流した後は手動運用 • 構成管理をすべてAnsibleで行う • 設定ファイルが構成の定義 • 設定ファイルなどをバージョン管理 • 何時でもインスタンスを追加可能（スケールアウト） 25Ⓒ Classmethod, Inc.
- 26. EC2インスタンスの初期設定 • 言語設定（system/lang） • タイムゾーン（system/timezone） • カスタムメトリクス（classmethod/monitoring） • CloudWatch Logs（aws/cloudwatchlogs） 26Ⓒ Classmethod, Inc. Ansibleを流せば完了！ 属人化防止
- 27. Ansibleの活用のポイント • どこまでAnsibleで管理するかを決める • 適切な単位でRoleとして分割 • 社内やチームでシェア • 設定ファイルはgitなどでバージョン管理 • 冪等性を保つように設定ファイルを書く • commandなどは常にchangedになるので工夫する • Windows Serverは諦める • インストーラなどGUIと相性が悪い • 設定ファイルで定義できないと辛い 27Ⓒ Classmethod, Inc.
- 28. CodeDeploy
- 29. アプリケーション・デプロイの課題 • アプリケーションは頻繁にアップデート • ミドルウェアの追加や設定変更は稀 • リリースまでは特に頻繁になる • アプリケーション式を各サーバにコピー • 設定ファイル・スクリプトファイル • 必要に応じてコンパイルなども必要 • ミドルウェアの再起動などが必要な場合もある • デプロイツール • capistrano • fabric • gradle 29Ⓒ Classmethod, Inc.
- 30. CodeDeploy • アプリケーションのデプロイサービス • アプリケーションはS3などにアップロード • CodeCommitなども利用可能 • 設定されたデプロイメント・グループにデプロイ • AutoScalingにも対応 • オンプレ対応 30Ⓒ Classmethod, Inc.
- 31. アプリケーション/デプロイメントグループ • アプリケーション • CodeDeployのプロジェクトのような概念 • リビジョンはアプリケーションに紐付く • デプロイメントグループ • デプロイする単位 • タグで識別したECインスタンス • AutoScaling Group • デプロイ先にエージェント必要 • codedeploy-agent 31Ⓒ Classmethod, Inc.
- 32. ビルド • アップロードするリビジョンを作成する • ビルドツールはプログラミング言語など合わせて選択 • Maven3, Gradle, gulp, rake … • 基本的な流れ 1. git などのSCMからソースの取得 2. ソースの変換（コンパイルや難読化） 3. 環境（dev, staging, production）などの差異を吸収 32Ⓒ Classmethod, Inc. $ git pull $ gulp -env production build
- 33. リビジョンのアップロード • リビジョン＝アプリケーションのアーカイブ • S3にアップロード • バージョンや日付を付けて作成 • v1.0, v1.2, 20160223 • 本番環境・検証環境などで異なる設定はここで吸収 • appspec.yml に配備時の設定を記述 33Ⓒ Classmethod, Inc. aws deploy push --application-name WordPress_App --description "This is a revision for the application WordPress_App" --ignore-hidden-files --s3-location s3://codedeploydemobucket/WordPressApp.zip --source .
- 34. デプロイ • AWS CLIまたはコンソールからデプロイ • フックスクリプト • インストール前に停止、インストール後に起動など • ファイルの配置/パーミッション 34Ⓒ Classmethod, Inc. version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings
- 35. ビルド履歴と再デプロイ • マネジメントコンソールで履歴の参照が可能 • 再デプロイなども簡単 35Ⓒ Classmethod, Inc.
- 36. CodeDeploy活用のポイント • デプロイメントグループの設計 • Blue/Greenに対応するか？ • AutoScalingか否か？ • バージョン管理ポリシーの設計 • ミドルウェアなどは事前にセットアップ • Ansible, CloudFormationなどを活用 • ビルドまでは開発側で解決する 36Ⓒ Classmethod, Inc.
- 38. フルマネージドを目指して • リリース後の運用を考える • 監視 • 障害対応 • バックアップ • 可能な限りお任せなシステムが理想 • RDSのようなフルマネージド・サービス • 稀に発生するトラブルのみに対応したい • Elastic Beanstalkは敷居が高い… 38Ⓒ Classmethod, Inc. AutoScaling + CodeDeploy
- 39. AutoScaling • 必要に応じたインスタンスの縮退・拡張 • 負荷に応じてスケールアップ/ダウン • 特定時間のみスケールアップ/ダウン • インスタンスの死活監視 • 応答のないインスタンスを破棄 • インスタンスを新規起動 • ELB配下に置くのが定石 39Ⓒ Classmethod, Inc.
- 40. インスタンス起動時の制約 • 起動時にサービス有効化必須 • ゴールデンAMIの準備 • 全設定完了済みのインスタンスイメージ • 更新（デプロイ）毎に設定する必要がある • cloud-initによる初期化 • スクリプトのみはかなり辛い 40Ⓒ Classmethod, Inc.
- 42. AutoScaling+CodeDeployのキモ • EC2障害はAutoScalingで自動対応 • ゴールデンAMI不要 • AMIは素のAMIを利用できる • ミドルウェアはAnsible（ローカル）でセットアップ • この部分は起動コストを考慮してAMIを作成するのも手 • アプリケーションはCodeDeployでデプロイ • アップデート毎にゴールデンAMIを作成しなくて良い 42Ⓒ Classmethod, Inc.
- 43. Advanced Topic
- 44. 継続的デリバリー • コード更新からリリースまでを自動化する 1. ソースコードの更新とSCMへのコミット 2. 自動テストの実行 3. CodeDeployによるデプロイ • CodePipelineの活用 • 開発チームが運用まで担当していることが前提 • 自動テストは特にハードルが高い • トラブル時に開発チームが解決する体制も必須 • 開発を外注の場合は責任分解点を設定する方が良い 44Ⓒ Classmethod, Inc.
- 45. Blue Green Deployment • 本番環境のリリースのダウンタイム無し • デプロイメントグループをふたつ用意する • EC2であれば2系統用意（片系は通常は停止） • AutoScalingであれば希望インスタンス数で調整 • バッチ処理などは注意すること • RDSのスキーマ変更時は、ダウンタイムを許容 • 許容できない場合はスキーマ変更による互換性（高コスト） 45Ⓒ Classmethod, Inc.