Upload
shuji-watanabe
View
1.267
Download
2
Embed Size (px)
Citation preview
Developers.IO 2016
E-3
AWSコンサルティング部 渡辺修司
Ⓒ Classmethod, Inc.
2016年02月20日
プロビジョニングの今 ーフルマネージド・サービスを目指してー
1
渡辺修司• AWSコンサルティング部 • 札幌オフィス • 開発系案件担当 • 自動化担当
• プログラミング • Java, Groovy, JavaScript
• 趣味 • ロードバイク(夏) • スノーボード(冬)
4Ⓒ Classmethod, Inc.
プロビジョニングとは?• リソース調達 • サーバ(EC2), ロードバランサ(ELB)
• インフラセットアップ • ネットワーク, ファイヤウォール
• サーバ・プロビジョニング • OSの設定, ミドルウェアのインストール・設定
• サービス・プロビジョニング • アプリケーションのデプロイなど
6Ⓒ Classmethod, Inc.
サービスを利用可能にするまでの行程
自動化は正義!• 手作業によるミス防止 • 人が実行する以上はミスは防げない
• 属人化防止 • コードや設定ファイルで定義 • 担当者が異動になっても設定は残る
• 再利用 • 同じような設定は繰り返して利用
• 時間短縮 • 実行中の待機時間で他の作業ができる
7Ⓒ Classmethod, Inc.
自動化の落とし穴• ツールの選定と習熟 • 学習コスト • ハマった時に解決できるか? → 有識者やネットの情報量
• ワンショットか繰り返し実行か? • 汎用性が低くワンショットであれば手動のが良いことも多々
8Ⓒ Classmethod, Inc.
プロビジョニングを支援するツール・サービス• CloudFormation • VPCやEC2などAWSリソースを構築・管理
• Ansible • サーバの構成管理(ミドルウェアなど)
• CodeDeploy • アプリケーションの配備・設定
• その他 • Elastic Beanstalk • Docker
9Ⓒ Classmethod, Inc.
プロビジョニング自動化のステップ
10Ⓒ Classmethod, Inc.
レベル0 すべてを調べながら、手作業で行っている
レベル1 セットアップ手順などがドキュメントにまとまっている
レベル2手順の一部が、スクリプト化またはプロビジョニングツールで記述されている
レベル3手順のほとんどがスクリプト化またはプロビジョニングツールで記述されており、何時でも環境を即時に作成できる
レベル4手順のほとんどが自動化されており、環境の変更時にはバージョン管理されたスクリプトや設定ファイルを更新するフローが確率されている
レベル5 運用を踏まえた自動化の仕組みが完備されている
自動化のゴールは運用• 開発者の自己満足にしない • 新しいツールは使ってみたくなる • 自動化は楽しいため陥りがち
• 長期運用を前提とする • メンテ不能な秘伝のレシピを作らない • メンテしない前提で使い切り(ワンショット)も検討
• スキルの底上げが必要な場合もある • 学習コスト < メンテコストを見極める • バージョン管理システムが使えない場合は危機感を持つ
• 自分たちで運用すると考えよう
11Ⓒ Classmethod, Inc.
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" ] } ] } } } } }
テンプレートのパターン• サービス・テンプレート • 特定サービス(例: WordPress)環境をワンクリックで構築 • ビッグバン・テンプレート http://dev.classmethod.jp/series/ac2013-aws/
• フルスタック・テンプレート • 全AWSリソースの管理をCloudFormationで行う
• クイックスタート・テンプレート • ネットワーク(VPC)などの基本部分のみを作成 • 構築後は手動でリソースを追加
• スニペット・テンプレート • 特定用途のIAMロールやセキュリティグループの作成
14Ⓒ Classmethod, Inc.
サービス・テンプレート• AWSアカウントがあれば、ワンクリックで利用可能 • WordPressなどのCMS, Jenkins
• アップデートは基本的に考えない • お試し環境に相性が良い
• ミドルウェアのセットアップはちょっと辛い • cloud-initを利用 • 基本的にシェルスクリプトで記述 • アップデート時のスクリプト実行などは未サポート
15Ⓒ Classmethod, Inc.
フルスタック・テンプレート• 全AWSリソースをCFnで管理 • 更新の履歴がCFnで一元管理される • 何時でもCFnで環境をコピー/再構築できる • メンテコストの問題 • マネジメントコンソールから更新できなくなる • ちょっとした修正でもCFnを修正しなければらならない • 気軽にインスタンスタイプの変更などができなくなる • CFnが対応していないこともある(後追い) • テンプレート変更の影響範囲を見極めるのが大変
16Ⓒ Classmethod, Inc.
クイックスタート・テンプレート• 環境をレイヤーで分ける • ネットワーク層は幾つかのパターンで整理可能 • EC2やRDSはプロジェクト毎に異なる
• ネットワークレイヤのみCFnで作成してしまう • アプリレイヤもCFnにするならテンプレートを分割
• http://dev.classmethod.jp/cloud/aws/reinvent-2014-app304-aws-cloudformation-best-practice-report/
17Ⓒ Classmethod, Inc.
スニペット・テンプレート• 各環境に横断的に適用したい • オフィスIPからSSH許可を行うセキュリティグループ • 特定の権限を持ったIAM Role • 監視用のEC2インスタンス
• パラメータを利用してVPC IDなどを指定 • 作成・更新・撤収が簡単
18Ⓒ Classmethod, Inc.
CloudFormation活用のポイント• どこまでCFnで管理するかを決める • すべてを管理する場合は運用できるか? • 初期構築時のみの割り切りもあり。
• テンプレートを分割 • ネットワーク層とサービス層は必ず分けること • 肥大化したテンプレートは維持するのがキツい
• テンプレートを資産化して再利用を促進する • JSONの編集がつらいのでエディタ必須 • コメント化できないので変換ツールも活用すると良い
19Ⓒ Classmethod, Inc.
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
Ansibleの実行• クライアントマシンからのSSH接続 • AWS環境内からでもOK
• ローカル実行(ansible-local) • ansibleのインストールが必要
22Ⓒ Classmethod, Inc.
冪等性• 設定ファイルがサーバの状態を定義 • 設定ファイルを変更しなければサーバの状態も変更されない • 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
Role• 構成管理の最小単位 • 再利用しやすく作成・管理 • 各プロジェクトでは組み合わせて実行 • プロジェクト固有の構成は別途記述
• CMの共通Role • system/lang • aws/awscli • aws/codedeploy
24Ⓒ Classmethod, Inc.
Ansibleの活用• 共通部分だけAnsibleを流す • システム基本設定 • 共通スクリプトの設定 • セキュリティパッチの適用 • 流した後は手動運用
• 構成管理をすべてAnsibleで行う • 設定ファイルが構成の定義 • 設定ファイルなどをバージョン管理 • 何時でもインスタンスを追加可能(スケールアウト)
25Ⓒ Classmethod, Inc.
EC2インスタンスの初期設定• 言語設定(system/lang) • タイムゾーン(system/timezone) • カスタムメトリクス(classmethod/monitoring) • CloudWatch Logs(aws/cloudwatchlogs)
26Ⓒ Classmethod, Inc.
Ansibleを流せば完了!
属人化防止
Ansibleの活用のポイント• どこまでAnsibleで管理するかを決める • 適切な単位でRoleとして分割 • 社内やチームでシェア
• 設定ファイルはgitなどでバージョン管理 • 冪等性を保つように設定ファイルを書く • commandなどは常にchangedになるので工夫する
• Windows Serverは諦める • インストーラなどGUIと相性が悪い • 設定ファイルで定義できないと辛い
27Ⓒ Classmethod, Inc.
アプリケーション・デプロイの課題• アプリケーションは頻繁にアップデート • ミドルウェアの追加や設定変更は稀 • リリースまでは特に頻繁になる
• アプリケーション式を各サーバにコピー • 設定ファイル・スクリプトファイル • 必要に応じてコンパイルなども必要
• ミドルウェアの再起動などが必要な場合もある • デプロイツール • capistrano • fabric • gradle
29Ⓒ Classmethod, Inc.
CodeDeploy• アプリケーションのデプロイサービス • アプリケーションはS3などにアップロード • CodeCommitなども利用可能
• 設定されたデプロイメント・グループにデプロイ • AutoScalingにも対応 • オンプレ対応
30Ⓒ Classmethod, Inc.
アプリケーション/デプロイメントグループ• アプリケーション • CodeDeployのプロジェクトのような概念 • リビジョンはアプリケーションに紐付く
• デプロイメントグループ • デプロイする単位 • タグで識別したECインスタンス • AutoScaling Group
• デプロイ先にエージェント必要 • codedeploy-agent
31Ⓒ Classmethod, Inc.
ビルド• アップロードするリビジョンを作成する • ビルドツールはプログラミング言語など合わせて選択 • Maven3, Gradle, gulp, rake …
• 基本的な流れ 1. git などのSCMからソースの取得 2. ソースの変換(コンパイルや難読化) 3. 環境(dev, staging, production)などの差異を吸収
32Ⓒ Classmethod, Inc.
$ git pull $ gulp -env production build
リビジョンのアップロード• リビジョン=アプリケーションのアーカイブ • 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 .
デプロイ• 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
CodeDeploy活用のポイント• デプロイメントグループの設計 • Blue/Greenに対応するか? • AutoScalingか否か?
• バージョン管理ポリシーの設計 • ミドルウェアなどは事前にセットアップ • Ansible, CloudFormationなどを活用
• ビルドまでは開発側で解決する
36Ⓒ Classmethod, Inc.
フルマネージドを目指して• リリース後の運用を考える • 監視 • 障害対応 • バックアップ
• 可能な限りお任せなシステムが理想 • RDSのようなフルマネージド・サービス • 稀に発生するトラブルのみに対応したい • Elastic Beanstalkは敷居が高い…
38Ⓒ Classmethod, Inc.
AutoScaling + CodeDeploy
AutoScaling• 必要に応じたインスタンスの縮退・拡張 • 負荷に応じてスケールアップ/ダウン • 特定時間のみスケールアップ/ダウン
• インスタンスの死活監視 • 応答のないインスタンスを破棄 • インスタンスを新規起動 • ELB配下に置くのが定石
39Ⓒ Classmethod, Inc.
インスタンス起動時の制約• 起動時にサービス有効化必須 • ゴールデンAMIの準備 • 全設定完了済みのインスタンスイメージ • 更新(デプロイ)毎に設定する必要がある
• cloud-initによる初期化 • スクリプトのみはかなり辛い
40Ⓒ Classmethod, Inc.
AutoScaling+CodeDeployのキモ• EC2障害はAutoScalingで自動対応 • ゴールデンAMI不要 • AMIは素のAMIを利用できる
• ミドルウェアはAnsible(ローカル)でセットアップ • この部分は起動コストを考慮してAMIを作成するのも手
• アプリケーションはCodeDeployでデプロイ • アップデート毎にゴールデンAMIを作成しなくて良い
42Ⓒ Classmethod, Inc.
継続的デリバリー• コード更新からリリースまでを自動化する 1. ソースコードの更新とSCMへのコミット 2. 自動テストの実行 3. CodeDeployによるデプロイ
• CodePipelineの活用 • 開発チームが運用まで担当していることが前提 • 自動テストは特にハードルが高い • トラブル時に開発チームが解決する体制も必須 • 開発を外注の場合は責任分解点を設定する方が良い
44Ⓒ Classmethod, Inc.
Blue Green Deployment• 本番環境のリリースのダウンタイム無し • デプロイメントグループをふたつ用意する • EC2であれば2系統用意(片系は通常は停止) • AutoScalingであれば希望インスタンス数で調整 • バッチ処理などは注意すること
• RDSのスキーマ変更時は、ダウンタイムを許容 • 許容できない場合はスキーマ変更による互換性(高コスト)
45Ⓒ Classmethod, Inc.