Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 47 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (16)

Advertisement

Similar to プロビジョニングの今 ーフルマネージド・サービスを目指してー #cmdevio2016 #E (20)

More from Shuji Watanabe (20)

Advertisement

Recently uploaded (20)

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

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

×