【AWS初心者向けWebinar】AWSのプロビジョニングからデプロイまで

【AWS初心者向けWebinar】AWSのプロビジョニングからデプロイまで

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