Developers.IO 2016

E-3

AWSコンサルティング部 渡辺修司

Ⓒ Classmethod, Inc.

2016年02月20日

プロビジョニングの今 ーフルマネージド・サービスを目指してー

1

クラスメソッド雪山部

3

渡辺修司• 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

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

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.

CodeDeploy

アプリケーション・デプロイの課題• アプリケーションは頻繁にアップデート • ミドルウェアの追加や設定変更は稀 • リリースまでは特に頻繁になる

• アプリケーション式を各サーバにコピー • 設定ファイル・スクリプトファイル • 必要に応じてコンパイルなども必要

• ミドルウェアの再起動などが必要な場合もある • デプロイツール • 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

ビルド履歴と再デプロイ• マネジメントコンソールで履歴の参照が可能 • 再デプロイなども簡単

35Ⓒ Classmethod, Inc.

CodeDeploy活用のポイント• デプロイメントグループの設計 • Blue/Greenに対応するか？ • AutoScalingか否か？

• バージョン管理ポリシーの設計 • ミドルウェアなどは事前にセットアップ • Ansible, CloudFormationなどを活用

• ビルドまでは開発側で解決する

36Ⓒ Classmethod, Inc.

AutoScalingによる フルマネージドサービス

フルマネージドを目指して• リリース後の運用を考える • 監視 • 障害対応 • バックアップ

• 可能な限りお任せなシステムが理想 • RDSのようなフルマネージド・サービス • 稀に発生するトラブルのみに対応したい • Elastic Beanstalkは敷居が高い…

38Ⓒ Classmethod, Inc.

AutoScaling + CodeDeploy

AutoScaling• 必要に応じたインスタンスの縮退・拡張 • 負荷に応じてスケールアップ/ダウン • 特定時間のみスケールアップ/ダウン

• インスタンスの死活監視 • 応答のないインスタンスを破棄 • インスタンスを新規起動 • ELB配下に置くのが定石

39Ⓒ Classmethod, Inc.

インスタンス起動時の制約• 起動時にサービス有効化必須 • ゴールデンAMIの準備 • 全設定完了済みのインスタンスイメージ • 更新（デプロイ）毎に設定する必要がある

• cloud-initによる初期化 • スクリプトのみはかなり辛い

40Ⓒ Classmethod, Inc.

AutoScalingによるフルマネージドサービス

41Ⓒ Classmethod, Inc.

※詳細はブログで解説します！

AutoScaling+CodeDeployのキモ• EC2障害はAutoScalingで自動対応 • ゴールデンAMI不要 • AMIは素のAMIを利用できる

• ミドルウェアはAnsible（ローカル）でセットアップ • この部分は起動コストを考慮してAMIを作成するのも手

• アプリケーションはCodeDeployでデプロイ • アップデート毎にゴールデンAMIを作成しなくて良い

42Ⓒ Classmethod, Inc.

Advanced Topic

継続的デリバリー• コード更新からリリースまでを自動化する 1. ソースコードの更新とSCMへのコミット 2. 自動テストの実行 3. CodeDeployによるデプロイ

• CodePipelineの活用 • 開発チームが運用まで担当していることが前提 • 自動テストは特にハードルが高い • トラブル時に開発チームが解決する体制も必須 • 開発を外注の場合は責任分解点を設定する方が良い

44Ⓒ Classmethod, Inc.

Blue Green Deployment• 本番環境のリリースのダウンタイム無し • デプロイメントグループをふたつ用意する • EC2であれば2系統用意（片系は通常は停止） • AutoScalingであれば希望インスタンス数で調整 • バッチ処理などは注意すること

• RDSのスキーマ変更時は、ダウンタイムを許容 • 許容できない場合はスキーマ変更による互換性（高コスト）

45Ⓒ Classmethod, Inc.

まとめ•レイヤに適した自動化ツールを選択しよう •自動化により属人化と作業ミス防止 •構成はコードでバージョン管理しよう •ゴールはフルマネージドサービス

46Ⓒ Classmethod, Inc.