AWS CAF & Well-Architected Framework

2017.2.10株式会社セクションナイン吉田真吾

AWSコンサルの道具箱AWS Cloud Adoption Framework &

AWS Well-Architected Framework

吉田真吾n バックグラウンド

証券システム基盤開発p 基盤開発、Oracleチューニングなど

エバンジェリストp 講演年間113回(2013年実績)p AWS設計・構築・移行(2014-2015)

n 現在のしごと(株) セクションナイン代表取締役社長

p AWSコンサルティング・設計・構築p DevOps、Dockerize、Serverless 支援

(株) Cloud Paymentp 技術顧問

n 実績等p AWSウルトラクイズ

初代チャンピオン (2012年)p AWS Samurai 2014 / 2017 ←New!!p AWSエキスパート養成読本執筆p AWS認定全資格(5種類コンプリート)p Oracle Database 11g (Gold, Performance Tuning)

AWS Samurai 2016(2017) 受賞吉田真吾さん（JAWS-UG 横浜支部）新たなクラウドのアーキテクチャとして注目されているサーバーレスや開発効率を向上させるための関連フレームワークなど、インフラエンジニアやアプリ開発者向けのイベントや各種勉強会をオーガナイザーとして多くの仲間を集め、東京や大阪地域で積極的に企画および実施しました。また、JAWS-UG横浜をリブートし、次世代のコミュニティリーダーの発掘・育成など、ユーザーグループが今後さらに成長する為の施策を進めました。アプリ／ウェブデベロッパーやインフラエンジニアをはじめとした開発・運用に関わるエンジニアの方々にサーバーレスアーキテクチャを知ってもらい、サービスを活用してイノベーションを起こしてもらえるよう、今後もファンや仲間を増やす活動を進めていただきたいと思います。

AWS Samuraiユーザーコミュニティにおけるさまざまな継続的な活動において、ユーザーコミュニティの成長およびAWSクラウドの普及に大きく貢献または影響を与えた人たち

がんばります！

AWS導入移行計画を立て、移行できればはい終わり？→そんなわけない

AWS導入してみたものの…相談• 想定よりコストがかかっている• 知らない環境が増え、サーバーが何台あるかもわからない• 複数ステージが同一スタックに相乗りしていてノイジー• トライアルユーザーがどんどん増えてROIが低下• サブシステムごとに監視システムが乱立してる、監視レベル

もまちまち• 同一アプリで複数のワークロードさばいてて最適な設定値が

決められない• 増える(アプリ|ユーザー|インスタンス)

増えないインフラメンバー• 毎回全力で障害対応• AWSが得意な人がいなくてアーキテクチャがいじれない• RIの適切な買い方がわからない• 富豪なアプリのワークロードを札束で解決している

なにがたりない？あなたのクラウドジャーニー

クラウド導入時のプロセスと視点

AWS Cloud Adoption Framework https://aws.amazon.com/professional-services/CAF/

ビジネス視点

セキュリティ視点

プラットフォーム視点

プロセス視点

人視点

成熟度視点

運用視点

戦略

分析

ビジネス価値を基準にした計画づくり評

価設計

移行

繰り返し型の開発

デプ

ロイ

運用

改善

運用の洗練自動化最

適化

AWSコンサルの道具箱@セクションナイン導入前の相談、導入時に検討すべきだった内容が不足している導入後の相談・評価

AWS Cloud Adoption Framework AWS Well-Architected Framework

AWS 導入アセスメントシート(群) Well-Architectedレビューシート

AWS導入支援サービス• 計画策定やビジネスのゴール設定から

各種設計、アセスメント、 PoCやサーバレス化、DevOps相談〜実装まで一気通貫でサポート

• 業務コンサルタンシーやアプリ開発会社、専門分野のプロとの協業体制もバッチリ

移行後のチューニングだってやっちゃう

プロセスを選択して組み立て

例）中規模Web系サービス

ビジネス視点

セキュリティ視点

プロセス視点

人視点

成熟度視点

プラットフォーム視点

運用視点


ビジネスケースの定義• クラウドを使うことでビジネスにどういう

利益を得ることを目標とするか定義• ビジネスレベルでのクラウド利用の成功達

成基準の定義• 販売戦略

• BtoB,BtoC,チャネル…• グローバル展開

全体計画• 必要十分な視点、プロセスの定義

• 必要なプロセスがもれなく含まれていること

• 不必要なプロセスは排除すること• 各プロセスの主担当者、成果物の

定義

例）中規模Web系サービスアプリケーションポートフォリオ分析• プロダクト資産の棚卸し

• 移行対象／非対象• インベントリ収集• 設計書などの収集

• プロダクトの構成、利用サービス、ミドルウェア、開発・運用関係者、開発ライフサイクル、運用ワークフロー、プロダクトごとの利用顧客など


ガバナンス設計• コスト管理計画• ワークフローの標準策定• 組織別の権限設計など

スキルマップ、研修・認定資格• 開発・維持運用に必要なスキルマップ

の作成• 既存メンバーのスキルマッピング• 不足スキルの習得計画• 研修や認定資格受験


ネットワーク設計• AWS環境と運用拠点、複

数アカウント間とのネットワーク設計など

クラウド環境設計• AWSアカウント・IAMユーザーの運用ポリシー作成、MFA設定

手順など準備• CloudTrailなどの監査ログ取得設計、定期的な監視ルールの作

成• トレーサビリティとしてのタグルールの整備(有効期限、強制

削除ルールなども)• 対象システムとそれぞれの役割・特徴・設計方針の作成• ランドスケープ／ステージの設計


セキュリティ要求策定• データ種別• 資産管理• セキュリティランク

セキュリティ運用設計・手順書作成• セキュリティ要求に準拠し

たシステムの設計・構築• システムのセキュリティ運

用ルール・手順書の作成


運用統合計画• 運用標準の作成

• 標準監視・バックアップ項目• トラブル復旧フロー• エスカレーションフロー• システムごとのサービスレベルの定義

• 既存環境との統合計画• 統合監視への移行• テンプレート化

クラウド最適化• 定期的なWell-Architectedレビューの

実施• コストの可視化に必要な仕組みの構築• インベントリの整備など• RIの購入計画、スポット活用• Dockerize、サーバーレス化の検討


コスト分析• 収集した情報から分析を

行い、改善計画を立てる• 予実績管理、リソースの利用率など

アーキテクチャのポリシー策定、標準化• システム全体のアーキテ

クチャを最適に保つためのポリシー、禁止事項などの設計

AWS導入してみたものの…相談• 想定よりコストがかかっている• 知らない環境が増え、サーバーが何台あるかもわからない• 複数ステージが同一スタックに相乗りしていてノイジー• トライアルユーザーがどんどん増えてROIが低下• サブシステムごとに監視システムが乱立してる、監視レベル

もまちまち• 同一アプリで複数のワークロードさばいてて最適な設定値が

決められない• 増える(アプリ|ユーザー|インスタンス)

増えないインフラメンバー• 毎回全力で障害対応• AWSが得意な人がいなくてアーキテクチャがいじれない• RIの適切な買い方がわからない• 富豪なアプリのワークロードを札束で解決している

インベントリ収集コスト管理・分析

クラウド最適化運⽤統合

クラウド最適化⾃動化SLA/SLO教育研修コスト管理

標準ワークフロー

AWS エンタープライズプロフェッショナルサービスAWS クラウド導入フレームワークAWS エンタープライズアクセラレーター

アーキテクチャに特化して評価したい

Well-Architected Framework• 基本の設計原則

• キャパシティの精緻な需要予測はやめる• 本番と同等の環境でテストする• アーキテクチャ検証を簡単に行うための自動化• 漸進的なアーキテクチャ変更• データドリブンアーキテクチャ• リハーサルを通じて改善しよう

• 五本柱1. セキュリティ2. 信頼性3. パフォーマンス効率4. コストの最適化5. 運用上の優秀性 ※詳細編はまだ公開されてない

AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/

Well-Architected を実践するための5本柱1. セキュリティ• すべてのレイヤーでセ

キュリティを作り込む• トレーサビリティの確保• 最小権限の原則の実践• ユーザー責任範囲のセ

キュリティにフォーカス• セキュリティの自動化

2. 信頼性• リカバリー試験の実施• エラー発生時の自動リカ

バリ• 水平スケールでシステム

の可用性を向上• キャパシティを必要以上

に気にしない• 変更管理の自動化


Well-Architected を実践するための5本柱

3. パフォーマンス効率• 高度な技術の採用を仕組

み化• いつでもグローバル化で

きるようにつくる• サーバーレスアーキテク

チャを採用する• すぐに検証する• 組合せの相性を考慮する

4. コスト最適化• 使った分だけ支払うモデル

に対応する• 規模のスケールの恩恵を受

ける• データセンターの運用には

お金を使わない• システムごとのROIを可視

化して分析する• マネージド・サービスを利

用することで所有コストを減らす


5. Operational Excellence - 設計原則コードで運用する構成変更(CM)やメンテナンスの自動化運用プロセスをビジネス目標に合わせるビジネス目標を達成するための運用指標値を設定しトラッキングする定期的／小規模／断続的に変更を加えるダウンタイムなしで変更でき、いつでもロールバックできる運用手順の整備予期せぬイベントへの対応の試験をするインシデント対応のリハーサルをするインシデント対応やエラーから学び改善する障害やインシデントを記録し、レビューし、改善する運用手順をつねに最新化する運用手順書とインシデント対応ガイドを最新化し、wikiなどでナレッジベースにするインシデント発生→チケット化などを自動化する


↑2016.11 追加 ※詳細編はまだ公開されてない

準備運用インシデント対応• 本番作業チェックリストの文書化と最新化• インシデント対応ガイドの文書化と最新化

• 障害対応手順• エスカレーションパス• 関係連絡先（メーリングリストなど）

• 販売イベントなどの対応内容レビュー• アプリケーション設計、環境構成、リソース構成、対応計画、パラメータなどの文書化と最新化• CloudFormationによるデプロイやAuto Scalingの

実装、AWS Configによる構成変更の追跡の自動化の実装AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/

OPS 1.クラウド上での運用のためにどんなベストプラクティス（フレームワークやツール）を採用していますか？

運用チェックリストビジネス的なイベント（キャンペーンなど）での積極的な運用計画セキュリティチェックリスト

OPS 2.運用作業に対してどのような設定

変更方法などを採用していますか？リソーストラッキング／アーキテクチャの文書化ナレッジベース（wiki、ナレッジベース、チケット）Immutable Infrastructure ／変更管理の自動化／構成管理データベース（CMDB）

準備運用インシデント対応• 運用業務の標準化

• 自動化• 定期的な品質テスト• 変更の追跡、監査、ロールバック• ダウンタイムの削減• 主要な指標値の収集に必要なログとメトリックの収集、レビュー

• リリース管理• 小規模で段階的な変更、テスト（大規模変更はロールバックしにくい）• 変更作業の品質担保のため、Blue/Green、Canaryリリース、

A/Bテストなどを実践• 統合監視

• アラートの通知、エスカレーション、自動応答


OPS 3.変更影響を最小限にしながら運用作業をどう進化させていますか？

CI / CDパイプラインの設置（ソースコードリポジトリ、ビルドシステム、自動テスト、自動デプロイ）リリース管理プロセスの確立小さく漸進的な変更、ロールバック可能な変更リスクを軽減したデプロイ方法（Blue / Green、Canary、A / Bテスト）

OPS 4.運用作業はどのように監視し

期待どおりに動作していることをどう確認していますか？

CloudWatchやサードパーティの監視ツールでパフォーマンス監視ログの集計自動アラート通知トリガベースで自動アクション

準備運用インシデント対応• インシデント対応の自動化• 影響範囲の緩和、自動修復、ロールバック、自動復旧• それでもダメなら事前に定義したフローにもとづきエ

スカレーション• デプロイ失敗時の自動ロールバック

• 根本原因分析（RCA）を行い、アーキテクチャやインシデント対応手順の両方を改善する


OPS 5.想定外のインシデントにどう対応していますか？

インシデント対応手順書の作成、更新根本原因分析と改善自動化（Auto Scaling、自動サポートチケット発行）

OPS 6.想定外のインシデントにに対応する場合のエスカレーション管理や手順

はどうなっていますか？必要なステークホルダーや通知システムの設置キューベース（優先度、影響度など）に基づくエスカレーション影響度、影響範囲による、またはインシデントの解決/回復までの時間をベースにしたエスカレーション優先順位外部サポート、AWSサポート、AWSパートナー、サードパーティのサポート契約エスカレーションフロー自体の自動化

キーになるAWSのサービス準備AWS Config• インベントリ• 設定変更の継続記録AWS Service Catalog• 標準化されたサービ

スのテンプレートAuto ScalingAmazon SQS

運用AWS CodeCommitAWS CodeDeployAWS CodePipeline• CI/CDパイプラインAWS CloudTrail• AWS環境の変更を監

査、追跡

インシデント対応Amazon CloudWatch• アラート通知Amazon CloudWatchEvents• 通知と自動処理のト

リガー

Well-Architected レビュー• インタビュー形式• 全項目答えられるよう複数担当者

• 2016年末に3社アセスメント→改善• 評価結果出すまでの効率が良い• ヒアリング 2時間半〜3時間• 評価 6時間程度• 低い評価項目を中心に改善する→決裁しやすい

• 社内だけで定期的に回せるようにスキルトランスファー

Amazon Web Services 企業導入ガイドブック

Happy AWS Life!!http://amzn.asia/e1uiMQ2

AWS CAF & Well-Architected Framework

Technology