presentation title here · cloudformation aws direct connect aws elastic beanstalk govcloud amazon...
TRANSCRIPT
【AWS初心者向けWebinar】AWSのプロビジョニングからデプロイまで
2015/10/21
アマゾンデータサービスジャパン株式会社
プロフェッショナルサービス
佐藤聖規
ご質問を受け付け致します！
質問を投げることができます！• Adobe Connectのチャット機能を使って、質問を書き込んでください。（書き込んだ質問は、主催者にしか見えません）
• できるだけ回答させていただきます。
①画面右下のチャットボックスに質問を書き込んでください
②吹き出しマークで送信してください
2
AWS初心者向けWebinarのご紹介
• AWSについてこれから学ぶ方向けのソリューションカットの技術Webinarです。
• 過去のWebinar資料– AWSクラウドサービス活用資料集ページにて公開
http://aws.amazon.com/jp/aws-jp-introduction/
• イベントの告知– 国内のイベント・セミナースケジュールページにて告知
http://aws.amazon.com/jp/about-aws/events/（オンラインセミナー枠）
3
自己紹介
• 名前：佐藤 聖規（さとう まさのり）
• 所属：アマゾンデータサービスジャパン株式会社プロフェッショナル・サービスコンサルタント
• 得意分野：インフラストラクチャー最適化/自動化、アジャイル開発
• 好きなAWSサービス：AWS Trusted Advisor
4
本日の内容
• AWSでプロビジョニングやデプロイをする上でのポイントを紹介します。
• ビジネスの成功において、サービスの頻繁かつ正確なリリースの重要性は日々増しています。頻繁にリリースをするには、プロビジョニングやデプロイを自動化する必要があります。
• AWSを使うと、クラウドの伸縮自在性やプログラマブルなインフラストラクチャーを活かして、ビジネスのサイクルに合わせたリリースができるようになります。
5
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
6
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
7
ビジネスは変化する、しかも速度は早い
• ビジネスは常に変化する– Amazon.comはインターネット書店としてスタート
– 現在はAWSやKindleなど創業当時とは違う多くのビジネスを手がけている
8
ビジネスはうまくいかないこともある
9
• 一発必中は難しい
• うまくいっていないことを把握
• ダメなものをやめる選択肢
Lean Startup
10
IDEAS
Build
Product
Measure
Data
Learn
フィードバックループ
• 顧客とビジネスの間のフィードバックループを加速する
• 顧客の期待に応え続ける
11
皆さんに質問
• How long does it take to deploy one line of code to production? – Mary & Tom Poppendieck, Lean Software Development
12
AWSのイノベーションのペース
13
2008 2009 2010 2011
Amazon EBS
Amazon EC2
Amazon SNS
AWS Identity
& Access
Management
AWS Import
& Export
Amazon
CloudWatch
Amazon EMR
Amazon RDS
Amazon VPC
Auto Scaling
Elastic Load
Balancing
Amazon
ElastiCache
Amazon SES
AWS
CloudFormation
AWS Direct
Connect
AWS Elastic
Beanstalk
GovCloud
Amazon SWF
Amazon Route 53
Amazon Redshift
Amazon Glacier
Amazon
Dynamo DB
Amazon
CloudSearch
AWS Storage
Gateway
Amazon
CloudTrail
Amazon
CloudHSM
Amazon
WorkSpaces
Amazon Kinesis
Amazon Elastic
Transcoder
Amazon
AppStream
AWS OpsWorks
AWS Data
Pipeline
20132012 2014
Amazon
Zocalo
EBS
Encripion
Amazon Cloud
Trail
EC2 T2
Instances
VPC
Peering
AWS Lambda
AWS Directory
Service
AWS CodeDeploy
Amazon EC2
Container Service
Amazon Aurora
ビックバンリリースを避ける
• 顧客の反応を確認し
• システムの安定性もチェックし
• 小規模にリリース
14
繰り返し高頻度でリリースするには自動化が必要
• デプロイは何度も行なわれる
• 環境構築作業も何度も行なわれる
15
個人開発環境 共用開発環境 CI環境スモークテスト環境
ステージング性能テスト環境
セキュリティテスト環境
受け入れテスト環境
本番環境 負荷試験環境パッチ検証環境
デグレ検証環境
繰り返し高頻度でリリースするには自動化が必要
• デプロイは何度も行なわれる
• 環境構築作業も何度も行なわれる
16
個人開発環境 共用開発環境 CI環境スモークテスト環境
ステージング性能テスト環境
セキュリティテスト環境
受け入れテスト環境
本番環境 負荷試験環境パッチ検証環境
デグレ検証環境
手作業でリリースすると様々なリスクが顕在化する
手作業でのリリースで考えられるリスク
1. 手順書がメンテンスされない– リリース担当者だけが知る暗黙知が秘伝のタレとして入る
2. 手順書に従って手作業して間違う– 人間必ずミスをする
3. リリース失敗・切り戻し– リリースが一大イベントとなり、複数リリース(ビックバンリリース)になり複
雑化、そして失敗しやすく、切り戻しにくくなる。
4. 長い作業時間とそれに伴う失敗増– 作業対象が増えると作業時間が増える
5. (失敗により)リリースに対する自信を失う6. (失敗により)リリースプロセスが重厚長大に
1. 二重チェック、三重チェック、膨大なチェックリスト。維持が難しい。
17
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
18
プロビジョニングとデプロイ
• コードやバイナリ、アセットなどの配布をデプロイと定義
• インフラストラクチャー構築をプロビジョニングと定義
19
Availability Zone Availability Zone
v2
AWSサービスの位置づけ
20
MonitorProvisionDeployTestBuildCode
Elastic Beanstalk
OpsWorks
Cloud
Watch
Cloud
Formation
Code
Deploy
Code
Commit
Code
Pipeline
Infrastructure as Code
• コードによるインフラストラクチャーの記述
• コードを書くことでインフラストラクチャーのプロビジョニングを自動化できる
21
AWSでのInfrastructure as Code
22
Java Python (boto) PHP .NET Ruby Node.js
AWS Tools for Windows
PowerShell
AWS CLI
JavaScript
CloudFormation OpsWorks ElasticBeanstalk
Infrastructure as Codeのメリット
• サーバーの台数が増えても構築に時間がかからない
• コード＝手順書となるのでコードを常にメンテナンスしておけば良い
• 手順を抜かしたり手順を間違う心配がない
• 同じコードを動かせば同じサーバーが出来上がる
• コードで記述されているので再利用が容易である
• 他のプロジェクトでコードを使いまわすことで無駄を省ける
23
Infrastructure as Codeのデメリット
• 学習コスト・作るのに時間がかかる
• 常に正しく動作するようにメンテナンスする必要がある
• 雑なやり方をしてしまうと、保守にかえって時間がかかる可能性がある
24
持続的に運用・メンテナンス可能に保つ
AWSでのデプロイ
25
Code Deploy Code Pipeline
連続体として捉える
• インフラストラクチャーのプロビジョニングとアプリのデプロイは連続体
• 両者を一緒に考える
• キーワードは伸縮自在性
26
(例) AutoScalingではインフラストラクチャーとアプリが一体
27
(例) AutoScalingではインフラストラクチャーとアプリが一体
28
インスタンスが増える(=プロビジョニング)タイミングでアプリも最新のものをデプロイ
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
29
ROIを意識するコストの考え方
• 自動化にはコストがかかる
• 基本ができていない場合は達成まで時間もかかる
• 手作業でやった場合と比較してどちらが安いか
• 実行回数や問題が発生した場合(リスク顕在化)の対処コスト等を含めて考える
• ただし、損益分岐点は思った以上に低い
• 顧客が要求するスピードやアプリケーションのライフサイクルを踏まえる
30
自動化に投資するか慎重な判断が必要な領域
• たとえば、小規模なキャンペーンサイト
• 使い捨てのアプリケーション
• 納品したら終わりのモノ
31
自動化の5R
• Rapid
• Reliable
• Repeatable
• Reduce Risk
• Roll back
32
プロジェクトの最初から始める
• プロジェクト期間中は何度もテスト環境にデプロイしたりプロビジョニングするはずなのでコスト効率が向上
• 何度もテストされ信頼性向上
33
顧客や上司の理解を得る
• 黙ってこっそりやるのは無理
• 説明責任
• 個人の便利ツール構築とは次元の違う話として組織で取り組む
• 全員で取り組む
34
カイゼンを続ける
• 一度プロセスや仕組みを作って終わりではなく、継続して改善をしていく
• 改善のループを回していく
35
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
36
デプロイしやすいアーキテクチャーの維持
• アプリケーションを常に繰り返し高頻度でデプロイしやすいように維持
• 疎結合アーキテクチャー(ステートレス)
37
あらゆるものはいつでも故障する前提で設計。単一障害点を避ける
サーバコピーを取得しいつでも起動可能に
スナップショットでのバックアップ
障害時の自動復旧のためにAutoScalingを活用
複数AZ利用による冗長化
故障のための設計
コンポーネントを独立させ、各コンポーネントはブラックボックスとして設計
コンポーネント間を疎結合にアプリケーションをステートレスに。この実現のためにELBを活用し、スティッキーセッションを避ける
セッションデータはデータベース(RDS、DynamoDB)に保存
疎結合なコンポーネント
コンポーネントの健全性や配置場所を決めつけない
いつでもリブート可能になるように設計
動的なコンフィグレーション(起動時に自動でアプリケーションやライブラリ等をインストールする)の活用
設定済みAMIの活用による時間短縮
弾力性の実装
AWSのセキュリティは責任分担モデル。OS以上の層やセキュリティグループの設定、データ暗号化、秘密鍵の管理等は利用者側の責任
OSの層とアプリの層、ネットワークの層など各所でセキュリティを担保すること。必要に応じてアプリケーションのペネトレーション試験も推奨
全レイヤでセキュリティ担保
AWSの特性は時間単位でリソースを使用可能な点。これを活かしてアプリケーションやバッチ処理の並列化、マルチスレッド化を検討する
ELBやAutoScalingを活用して並列処理、分散処理を実装
並列処理の実装
EBSや、データベース、S3等データを保存するストレージには多種多様なものがある
読み書きの特性(読み書きの比率や頻度)や、データ喪失の可能性、ステートレスの実現可否を踏まえて適切なストレージを選択する
異なるストレージの使い分け
38
デプロイ自動化に必要な要素
1. バージョン管理
2. 自動化されたテスト
3. マイグレーション
4. 継続的インテグレーション
5. デプロイツール
• (静的解析・コードレビュー)
39
バージョン管理
• 全ての基本
• ブランチ、マージを含めて、チーム全員が使い方を理解する。
• 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない
40
AWS CodeCommit
ブランチモデルの理解
41
• ブランチの戦略がチーム全員で理解できているか？
• ブランチの戦略はデプロイの戦略と密接な関係
A successful Git branching modelより図を引用(http://nvie.com/posts/a-successful-git-branching-model/)
AWS CodeCommit
• Availability Zoneを跨ぎデータを冗長化
• データは暗号化されて保存
• IAMとの統合
• レポジトリのサイズは無制限
git push AWS CodeCommit
GitのオブジェクトはAmazon S3
GitのインデックスはAmazon DynamoDB
暗号化鍵はAWS KMS
SSH or HTTPS
安全、スケーラブル、マネージドな、Gitソース管理
42
バージョン管理システム on AWS
• AWS CodeCommitを使うとセキュリティやディスクサイズ、バックアップなどの運用の負担を減らすことができる
• AWS上にVCSを構築する場合も、パフォーマンスが不足するときのスケールアップや、スナップショット取得の容易性によるデータの耐久性など多くのメリットがある
43
テストの自動化
• 速度維持と品質維持– 早期に問題を発見し、すぐに解決し続ける方がコストが安い
フェーズ 修正までの時間(例)
要求や設計 5分
コードやユニットテスト 15分
結合テストやシステムテスト 1時間
ベータテスト 2時間
リリース後 1日
44
どこまでテストを用意するか？
• ユニットテスト、結合テスト、受け入れテスト、スモークテスト
• テストもRIOを意識して考える
• テスト戦略として考える
45
マイグレーション
• 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない原則
• いつの時点のリリースにも戻せるようにする原則
• 依存関係・前後関係は人が判断しない原則
• マイグレーションの活用
46
マイグレーション用ツール
47
継続的インテグレーション
• バージョン管理、テスト自動化、マイグレーションが実現できていれば継続的インテグレーションの実現が可能
• 常にリリース可能かどうかを検証し続ける
48
継続的インテグレーション on AWS
• スローテスト問題に対して並列実行
• 指定時刻に継続的インテグレーションサーバを増やし、必要なくなったら止める
• バイナリを大量に生成しても、AWSに保存すれば容量は気にしなくても良くなる
• クラウドならではのアプローチ
49
デプロイプロセス設計
• いつ誰がどの環境にどの単位でデプロイするのか？• どういうデプロイのパターンが存在するのか？• どんなツールを使うのか？• 誰がデプロイスクリプトを保守するのか？• デプロイの成功/失敗をどのように判断するのか？• デプロイ後に問題が分かったときにどのように対処するのか？
• いまリリースされているバージョンをどのように知ることができるのか？
50
粒度を小さく
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
51
AWS CodePipeline
• カスタマイズ可能なワークフローエンジン
• パートナーやカスタムのシステムと連携
• ビジュアルエディターと可視化されたステータス
継続的デリバリー、リリース自動化を、Amazonの様に
Build1) ビルド
2) Unitテスト
1) デプロイ
2) UIテスト
Source Beta Production
1) デプロイ
2) 負荷テスト
Gamma
1) カナリア デプロイ
2) リージョン1 デプロイ
3) リージョン2 デプロイ
52
デプロイのよくあるパターン
LBから切り離す
アプリケーションのデプロイ
スモークテスト
LB対象に戻す
アプリケーションのデプロイ
メンテ中ページに差し替える
アプリケーションのデプロイ
データベースのマイグレーション
スモークテスト
メンテ中ページから戻す
新規環境構築
アプリケーションのデプロイ
スモークテスト
LB切り替え
53
ブルーグリーンデプロイ
Webサーバー群(Amazon EC2)
データベースサーバ群(Amazon RDS)
ロードバランサー
v1.1 v1.1
v1.1 v1.1
v1.2
v1.2
v1.2
v1.2
モニタリング(CloudWatch)
54
ブルーグリーンデプロイ
Webサーバー群(Amazon EC2)
データベースサーバ群(Amazon RDS)
ロードバランサー
v1.1 v1.1
v1.1 v1.1
v1.2
v1.2
v1.2
v1.2
モニタリング(CloudWatch)
55
デプロイの後一定期間たって戻すことがないと判断できた時点で旧バージョン削除クラウドの特性を活かしたデプロイ
ツールの選択
• 専用のツールを使う– Capistrano、Fabric、など
• デプロイスクリプトの可読性と保守性は重要– これがリリース手順書の代わりになるので、担当者が変わっても保守できるものを選択
– シェルスクリプトは複雑化しやすく保守しにくい
• AWS CodeDeploy、Elastic Beanstalkなどが自分たちのプロセスに合いそうかどうかを確認– どんなデプロイプロセスが必要なのかによって適合性がかわる
56
AWS CodeDeploy
• 1台も数千台も同じやり方で
• ダウンタイム無くデプロイ
• 中央でデプロイをコントロール・モニタリング
Staging
AWS CodeDeployv1, v2, v3
Production
Dev
自動デプロイのコーディネートを、Amazonの様に
Application
revisions
Deployment groups
57
AWS Elastic Beanstalk
• 特徴 (http://aws.amazon.com/jp/elasticbeanstalk/)
– 速く簡単にアプリケーションをデプロイ可能
– インフラストラクチャーの準備＆運営からアプリケーションスタックの管理まで自動化
– Auto Scaling によりコストを抑えながらスケーラビリティを確保
– Java, PHP, Ruby, Python, Node.js, .NET, Docker などに対応
インフラストラクチャー構成の構築・アプリデプロイの自動化サービス
58
• アプリケーションを簡単にデプロイ
• 複数環境を切り替え可能（ブルーグリーンデプロイ）
59
Elastic Beanstalkでデプロイ
• たとえばCIサーバでテストが終わったあとに、CIサーバからステージング環境や本番環境デプロイできる
60
Elastic Beanstalk + Docker
Developer
1. docker push4. docker pull
2. deploy
registryregistry
registry
registry
Region
app
app
app
registry
app
3. docker run registry
5. docker stop registry
Docker registry container with AWS credentials
61
デプロイ自動化ワンポイント
• デプロイ失敗の検知をおこなう– スモークテストの実行
– 監視システムによるログ監視やプロセス監視
• 例:ELBのHTTPCode_Backend_4x,5xx
– 失敗を検知したらロールバック
• 手作業を混ぜない– リリース可否などの判断は可
62
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
63
プロビジョニング自動化の進め方
• 基本的な考え方はデプロイ自動化と同じ
• デプロイとプロビジョニングは連続体
• プロセスの設計
• ベストなツールの選択
• 自動化しやすいアーキテクチャー
64
クラウドのメリットを活かす
オンプレミス新しいインフラストラクチャーの構築は複雑かつ遅くなりがち
クラウドワンクリックで新しい
インフラストラクチャーを用意
新しいデプロイ環境を構築
新しいテスト環境を構築
新しい環境を海外に構築
1,000 サーバ追加
1,000 サーバ削除
必要 調査 評価
計画 設計 エンジニア
調達 契約コミッショ
ン
デプロイ
65
VPC 10.0.0.0/16
Availability Zone - C
Availability Zone - A
Internet
Anyone
Internet Gateway
Public Subnet 10.0.0.0/24
Public Subnet 10.0.2.0/24
Private Subnet 10.0.1.0/24
Private Subnet 10.0.3.0/24
AMI
Amazon RDS
Amazon RDS
AZ-A-WP110.0.0.6
EC2 Instance
EC2 Instance
AZ-B-WP210.0.2.8
こんな環境の作成を自動化できる
66
AWSのプロダクトの位置づけ
Elastic Beanstalk OpsWorks CloudFormation EC2
手軽 自由度高
67
プロダクト ElasticBeanstalk
OpsWorks CloudFormation
Amazon EC2
できること 定番構成＋アプリデプロイ
カスタム構成＋アプリデプロイ
スタックの一括構築
なんでも
利用頻度 アプリデプロイごと
アプリデプロイ・プロビジョニングごと
初回１回や似た環境を作るとき
自分で管理(Chef、Capistrano等)
手軽さ・自由度
手軽 手軽 自由 自由
考慮点 定番アーキテクチャかどうか
Chefの習得Cookbookのテストをどうするか(ServerSpecなどを使うか)
アプリデプロイは別で考える
構築のコストを考慮
68
プロダクト ElasticBeanstalk
OpsWorks CloudFormation
Amazon EC2
できること 定番構成＋アプリデプロイ
カスタム構成＋アプリデプロイ
スタックの一括構築
なんでも
利用頻度 アプリデプロイごと
アプリデプロイ・プロビジョニングごと
初回１回や似た環境を作るとき
自分で管理(Chef、Capistrano等)
手軽さ・自由度
手軽 手軽 自由 自由
考慮点 定番アーキテクチャかどうか
Chefの習得Cookbookのテストをどうするか(ServerSpecなどを使うか)
アプリデプロイは別で考える
構築のコストを考慮
69
組み合わせ技も可能。例えばCloudFormationを使ってElastic BeanstalkのアプリケーションやOpsWorksのスタックを作成したりできる
AWS CloudFormation
• 特徴 (http://aws.amazon.com/jp/cloudformation/)
– テンプレートを元に、EC2やELBといったAWSリソースの環境構築を自動化
– JSONフォーマットのテキストで、テンプレートを自由に記述可能
– Microsoft Windows Server や SAP HANA などのリファレンス実装を用意（http://aws.amazon.com/quickstart/）
設定管理 & クラウドのオーケストレーション サービス
スタック
EC2
AutoScaling
テンプレート（設定ファイル）
テンプレートに基づき各リソースが自動起動
EC2
Cloud
Formation
70
AWS OpsWorks
• 特徴 (http://aws.amazon.com/jp/opsworks/)
– Chefのレシピを使って、デプロイや運用タスクを自動化可能
– ライフサイクルイベントにより動的な構成変更への対応が可能
– 継続的な構成管理
アプリケーションのデプロイ・管理サービス
AWS OpsWorks
スタック
LBレイヤー
Webレイヤー
DBレイヤー
EC2インスタンス上のOpsWorksエージェント
71
どんなAMIを使うか？
Linux
J2EE
アプリコード
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Linux
J2EE
アプリコード
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
EC2
L
in
u
x
JE
E
Yo
u
r C
od
e
L
o
g4
J
S
pr
in
gHi
be
r
na
te
St
r
u
ts
Tom
c
a
t
Apa
ch
e
L
in
u
x
JE
E
Yo
u
r C
od
e
L
o
g
4J
S
pr
in
gHi
be
r
na
te
St
r
u
ts
Tomc
a
t
Apa
che
Li
n
ux
JE
E
Yo
u
r C
od
e
L
o
g4
J
S
pr
in
gHi
be
r
na
te
St
r
u
ts
Tom
c
a
t
Apa
c
h
e
Li
n
ux
JE
E
Yo
u
r C
od
e
L
o
g4
J
S
pr
in
gHi
be
rn
a
te
St
r
u
ts
Tom
c
a
t
Apa
c
h
e
アプリコード
Amazon S3
Log4JSpring
Struts
Linux
J2EE
Hibernate
Tomcat
Apache
Linux
J2EE
アプリコード
Amazon S3
Hibernate
TomcatLog4J
Spring
StrutsApache
EC2
L
in
ux
JE
E
Hi
b
er
na
t
e
T
omcat
A
pache
L
in
ux
J
EE
Hi
b
er
na
t
e
T
o
mca
t
A
pac
h
e
L
in
ux
J
EE
Hi
b
er
na
t
e
T
o
mca
t
A
pac
h
e
EC2
Linux
JEE
Linux
JEE
Chef
Chef
スクリプト
Java AMIJavaスタック Java AMIAMI
起動時取得
起動時取得起動時取得
[1]全部入りAMI [2]Golden Image [3]最小構成AMI
72
AMIによるデプロイのPros/Cons
方式 利点 欠点
[1]全部入りAMI 同一性の確保起動時間が早い
デプロイ毎にAMIを作り直す必要がある(作成プロセスを自動化すれば欠点とはならない)。
[2]GoldenImage あとはアプリコードのみ最新を取得すれば良く扱いやすい
[3]最小構成AMI 柔軟に中身を変更できる 起動処理に時間がかかる。場合によっては外部ライブラリが取得できないことも
73
インフラストラクチャーも含めた継続的インテグレーションが可能に
• インフラストラクチャーのプロビジョニングも自動化
• 自動化しやすいアーキテクチャを作り、維持する
• プロビジョニングとデプロイを連続体として捉える
• 自動化できれば継続的インテグレーションができる
74
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
75
Developers
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
76
Developers
アプリコードとCloudFormationテンプ
レートをプッシュ
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
77
Developers
CloudFormationで新しいインスタンスを展開
AMIとChef Serverを利用
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
78
Developers
CIを実行
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
79
Developers
CodeDeployが新しいコードをデプロイ
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
80
Developers
新しい環境にELBを切り替え
監視システムへ登録
VPC
Availability Zone - C
Availability Zone - A
Internet
Client
Internet Gateway
Public Subnet
Public Subnet
Private Subnet
Private Subnet
Amazon RDS
Amazon RDS
実例
81
Developers
古い環境の削除
アジェンダ
• ビジネスの要求と自動化が必要な背景
• AWSでのデプロイとプロビジョニングの基本
• デプロイやプロビジョニングの自動化に向けた戦略
• デプロイの自動化
• プロビジョニングの自動化
• まとめ
82
まとめAWSサービスの位置づけ
83
MonitorProvisionDeployTestBuildCode
Elastic Beanstalk
OpsWorks
Cloud
Watch
Cloud
Formation
Code
Deploy
Code
Commit
Code
Pipeline
まとめ
• デプロイ自動化・環境構築の自動化には順番がある
• プロジェクトの最初から全員で取り組む
• バージョン管理・自動テスト・継続的インテグレーショ
ン重要
• デプロイ・プロビジョニングプロセス設計をする
• 適切なツールを使う– AWSなら CodeCommit / CodeDeploy / CodePipeline /
CloudFormation / OpsWorks / Elastic Beanstalk
84
Q&A
85
参考文献・リンク
• AWS Tokyo Summit 2015DEV-04 (Developer Productivity）:【デベロッパー向け】開発生産性を上げるためのデプロイ戦略– http://media.amazonwebservices.com/jp/summit2015/docs/Dev-
04d-Tokyo-Summit-2015.pdf
• AWS Tokyo Summit 2015TA-05:AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ– http://media.amazonwebservices.com/jp/summit2015/docs/TA-05-
Tokyo-Summit-2015.pdf
86
詳しくは、http://aws.amazon.com/training をご覧ください
メリット
• AWS について実習や実践練習を通じて学習できる
• AWS を熟知したエキスパートから直接 AWS の機能について学び、疑問の答えを得られる
• 自信をもって IT ソリューションに関する決定を下せるようになる
提供方法
e ラーニングや動画
セルフペースラボ
クラスルームトレーニング
AWSトレーニングでは様々な学習方法をご提供しています
87
公式Twitter/FacebookAWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！
もしくはhttp://on.fb.me/1vR8yWm
88
AWS初心者向けWebinar
• AWSをこれからご使用になる技術者向け、ソリューションカットのセミナー
• 今後の配信予定
【AWS初心者向けWebinarOct】AWS上にWebサーバーシステムを作ってみましょう～仮想サーバーから[演習つき]
※12時~13時15分の時間帯です！
• 申し込みサイト
– http://aws.amazon.com/jp/about-aws/events/
89
AWS Black Belt Tech Webinar 2015
AWSのサービスをディープにご紹介
• 今後の配信予定 デプロイ&プロビジョニング月間!– 10/21（水）18:00～ AWS Directory Service
– 10/28（水）18:00～ AWS CodeCommit & CodePipeline & CodeCommit
– 11/4 (水) お休み
– 11月11日(水)18:00～ AWS OpsWorks
– 11月18日(水)18:00～ AWS CloudFormation
– 11月25日(水)18:00～ AWS Elastic Beanstalk
• 申し込みサイト– http://aws.amazon.com/jp/about-aws/events/
90
AWSの導入、お問い合わせのご相談
• AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は、以下のリンクよりお気軽にご相談くださいhttps://aws.amazon.com/jp/contact-us/aws-sales/
※「AWS 問い合わせ」で検索してください91
ご参加ありがとうございました