Download as PDF, PPTX
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to AWS CAF & Well-Architected Framework
![[JAWS Days 2020] AWS Well-Architected フレームワークのご紹介](https://cdn.slidesharecdn.com/ss_thumbnails/202003-jaws-daywellarchitectedframework-200325072902-thumbnail.jpg?width=640&height=640&fit=bounds)
AWS CAF & Well-Architected Framework
- 1. 2017.2.10 株式会社セクションナイン 吉田真吾 AWSコンサルの道具箱 AWS CloudAdoption Framework & AWS Well-Architected Framework
- 2. 吉田真吾 n バックグラウンド 証券システム基盤開発 p 基盤開発、Oracleチューニングなど エバンジェリスト p講演年間113回(2013年実績) p AWS設計・構築・移行(2014-2015) n 現在のしごと (株) セクションナイン 代表取締役社長 p AWSコンサルティング・設計・構築 p DevOps、Dockerize、Serverless 支援 (株) Cloud Payment p 技術顧問 n 実績等 p AWSウルトラクイズ 初代チャンピオン (2012年) p AWS Samurai 2014 / 2017 ←New!! p AWSエキスパート養成読本 執筆 p AWS認定全資格(5種類コンプリート) p Oracle Database 11g (Gold, Performance Tuning)
- 3. AWS Samurai 2016(2017)受賞 吉田 真吾 さん（JAWS-UG 横浜支部） 新たなクラウドのアーキテクチャとして注目されてい るサーバーレスや開発効率を向上させるための関連フ レームワークなど、インフラエンジニアやアプリ開発 者向けのイベントや各種勉強会をオーガナイザーとし て多くの仲間を集め、東京や大阪地域で積極的に企画 および実施しました。また、JAWS-UG横浜をリブート し、次世代のコミュニティリーダーの発掘・育成など、 ユーザーグループが今後さらに成長する為の施策を進 めました。アプリ／ウェブデベロッパーやインフラエ ンジニアをはじめとした開発・運用に関わるエンジニ アの方々にサーバーレスアーキテクチャを知ってもら い、サービスを活用してイノベーションを起こしても らえるよう、今後もファンや仲間を増やす活動を進め ていただきたいと思います。 AWS Samurai ユーザーコミュニティにおけるさまざまな 継続的な活動において、ユーザーコミュニ ティの成長およびAWSクラウドの普及に大 きく貢献または影響を与えた人たち がんばります！
- 4.
- 5. AWS導入してみたものの…相談 • 想定よりコストがかかっている • 知らない環境が増え、サーバーが何台あるかもわからない •複数ステージが同一スタックに相乗りしていてノイジー • トライアルユーザーがどんどん増えてROIが低下 • サブシステムごとに監視システムが乱立してる、監視レベル もまちまち • 同一アプリで複数のワークロードさばいてて最適な設定値が 決められない • 増える(アプリ|ユーザー|インスタンス) 増えないインフラメンバー • 毎回全力で障害対応 • AWSが得意な人がいなくてアーキテクチャがいじれない • RIの適切な買い方がわからない • 富豪なアプリのワークロードを札束で解決している
- 6.
- 7. クラウド導入時のプロセスと視点 AWS Cloud AdoptionFramework https://aws.amazon.com/professional-services/CAF/ ビジネス 視点 セキュリティ 視点 プラットフォーム 視点 プロセス 視点 人 視点 成熟度 視点 運用 視点 戦略 分析 ビジネス価値を 基準にした 計画づくり 評価 設計 移行 繰り返し型の 開発 デプロイ 運用 改善 運用の洗練 自動化 最適化
- 8. AWSコンサルの道具箱@セクションナイン 導入前の相談、導入時に検討す べきだった内容が不足している 導入後の相談・評価 AWS CloudAdoption Framework AWS Well-Architected Framework AWS 導入アセスメントシート(群) Well-Architectedレビューシート
- 9. AWS導入支援サービス • 計画策定やビジネスのゴール設定から 各種設計、アセスメント、 PoCやサーバレス化、 DevOps相談〜実装まで一気通貫でサポート •業務コンサルタンシーやアプリ開発会社、専門 分野のプロとの協業体制もバッチリ 移行後のチューニングだってやっちゃう
- 10.
- 11. 例）中規模Web系サービス ビジネスケースの定義 • クラウドを使うことでビジネスにどういう 利益を得ることを目標とするか定義 • ビジネスレベルでのクラウド利用の成功達 成基準の定義 •販売戦略 • BtoB,BtoC,チャネル… • グローバル展開 全体計画 • 必要十分な視点、プロセスの定義 • 必要なプロセスがもれなく含まれて いること • 不必要なプロセスは排除すること • 各プロセスの主担当者、成果物の 定義
- 12. 例）中規模Web系サービス アプリケーションポート フォリオ分析 • プロダクト資産の棚卸し • 移行対象／非対象 •インベントリ収集 • 設計書などの収集 • プロダクトの構成、利用 サービス、ミドルウェア、 開発・運用関係者、開発 ライフサイクル、運用 ワークフロー、プロダク トごとの利用顧客など
- 13. 例）中規模Web系サービス ガバナンス設計 • コスト管理計画 • ワークフローの標準策定 •組織別の権限設計など スキルマップ、研修・認定資格 • 開発・維持運用に必要なスキルマップ の作成 • 既存メンバーのスキルマッピング • 不足スキルの習得計画 • 研修や認定資格受験
- 14. 例）中規模Web系サービス ネットワーク設計 • AWS環境と運用拠点、複 数アカウント間とのネット ワーク設計など クラウド環境設計 • AWSアカウント・IAMユーザーの運用ポリシー作成、MFA設定 手順など準備 •CloudTrailなどの監査ログ取得設計、定期的な監視ルールの作 成 • トレーサビリティとしてのタグルールの整備(有効期限、強制 削除ルールなども) • 対象システムとそれぞれの役割・特徴・設計方針の作成 • ランドスケープ／ステージの設計
- 15. 例）中規模Web系サービス セキュリティ要求策定 • データ種別 • 資産管理 •セキュリティランク セキュリティ運用設計・手順 書作成 • セキュリティ要求に準拠し たシステムの設計・構築 • システムのセキュリティ運 用ルール・手順書の作成
- 16. 例）中規模Web系サービス 運用統合計画 • 運用標準の作成 • 標準監視・バックアップ項目 •トラブル復旧フロー • エスカレーションフロー • システムごとのサービスレベルの定義 • 既存環境との統合計画 • 統合監視への移行 • テンプレート化 クラウド最適化 • 定期的なWell-Architectedレビューの 実施 • コストの可視化に必要な仕組みの構築 • インベントリの整備など • RIの購入計画、スポット活用 • Dockerize、サーバーレス化の検討
- 17. 例）中規模Web系サービス コスト分析 • 収集した情報から分析を 行い、改善計画を立てる • 予実績管理、リソースの 利用率など アーキテクチャのポリシー 策定、標準化 •システム全体のアーキテ クチャを最適に保つため のポリシー、禁止事項な どの設計
- 18. AWS導入してみたものの…相談 • 想定よりコストがかかっている • 知らない環境が増え、サーバーが何台あるかもわからない •複数ステージが同一スタックに相乗りしていてノイジー • トライアルユーザーがどんどん増えてROIが低下 • サブシステムごとに監視システムが乱立してる、監視レベル もまちまち • 同一アプリで複数のワークロードさばいてて最適な設定値が 決められない • 増える(アプリ|ユーザー|インスタンス) 増えないインフラメンバー • 毎回全力で障害対応 • AWSが得意な人がいなくてアーキテクチャがいじれない • RIの適切な買い方がわからない • 富豪なアプリのワークロードを札束で解決している インベントリ収集 コスト管理・分析 クラウド最適化 運⽤統合 クラウド最適化 ⾃動化 SLA/SLO 教育研修 コスト管理 標準ワークフロー
- 19. AWS エンタープライズ プロフェッショナルサービス AWS クラウド導入フレームワーク AWSエンタープライズアクセラレーター
- 20.
- 21. Well-Architected Framework • 基本の設計原則 •キャパシティの精緻な需要予測はやめる • 本番と同等の環境でテストする • アーキテクチャ検証を簡単に行うための自動化 • 漸進的なアーキテクチャ変更 • データドリブンアーキテクチャ • リハーサルを通じて改善しよう • 五本柱 1. セキュリティ 2. 信頼性 3. パフォーマンス効率 4. コストの最適化 5. 運用上の優秀性 ※詳細編はまだ公開されてない AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 22. Well-Architected を実践するための5本柱 1. セキュリティ •すべてのレイヤーでセ キュリティを作り込む • トレーサビリティの確保 • 最小権限の原則の実践 • ユーザー責任範囲のセ キュリティにフォーカス • セキュリティの自動化 2. 信頼性 • リカバリー試験の実施 • エラー発生時の自動リカ バリ • 水平スケールでシステム の可用性を向上 • キャパシティを必要以上 に気にしない • 変更管理の自動化 AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 23. Well-Architected を実践するための5本柱 3. パフォーマンス効率 •高度な技術の採用を仕組 み化 • いつでもグローバル化で きるようにつくる • サーバーレスアーキテク チャを採用する • すぐに検証する • 組合せの相性を考慮する 4. コスト最適化 • 使った分だけ支払うモデル に対応する • 規模のスケールの恩恵を受 ける • データセンターの運用には お金を使わない • システムごとのROIを可視 化して分析する • マネージド・サービスを利 用することで所有コストを 減らす AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 24. 5. Operational Excellence- 設計原則 コードで運用する 構成変更(CM)やメンテナンスの自動化 運用プロセスをビジネス目標に合わせる ビジネス目標を達成するための運用指標値を設定しトラッキングする 定期的／小規模／断続的に変更を加える ダウンタイムなしで変更でき、いつでもロールバックできる運用手順の整備 予期せぬイベントへの対応の試験をする インシデント対応のリハーサルをする インシデント対応やエラーから学び改善する 障害やインシデントを記録し、レビューし、改善する 運用手順をつねに最新化する 運用手順書とインシデント対応ガイドを最新化し、wikiなどでナレッジベースにする インシデント発生→チケット化などを自動化する AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/ ↑2016.11 追加 ※詳細編はまだ公開されてない
- 25. 準備 運用 インシデント対応 •本番作業チェックリストの文書化と最新化 • インシデント対応ガイドの文書化と最新化 • 障害対応手順 • エスカレーションパス • 関係連絡先（メーリングリストなど） • 販売イベントなどの対応内容レビュー • アプリケーション設計、環境構成、リソース構成、 対応計画、パラメータなどの文書化と最新化 • CloudFormationによるデプロイやAuto Scalingの 実装、AWS Configによる構成変更の追跡の自動化 の実装 AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 26.
- 27. OPS 2. 運用作業に対してどのような設定 変更方法などを採用していますか？ リソーストラッキング ／アーキテクチャの文書化 ナレッジベース（wiki、ナレッジベース、チケット） Immutable Infrastructure ／ 変更管理の自動化 ／ 構成管理データベース（CMDB）
- 28. 準備 運用 インシデント対応 •運用業務の標準化 • 自動化 • 定期的な品質テスト • 変更の追跡、監査、ロールバック • ダウンタイムの削減 • 主要な指標値の収集に必要なログとメトリックの収集、レビュー • リリース管理 • 小規模で段階的な変更、テスト（大規模変更はロールバックしにくい） • 変更作業の品質担保のため、Blue/Green、Canaryリリース、 A/Bテストなどを実践 • 統合監視 • アラートの通知、エスカレーション、自動応答 AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 29. OPS 3. 変更影響を最小限にしながら運用 作業をどう進化させていますか？ CI /CDパイプラインの設置（ソースコードリポジトリ、ビルドシステム、 自動テスト、自動デプロイ） リリース管理プロセスの確立 小さく漸進的な変更、ロールバック可能な変更 リスクを軽減したデプロイ方法（Blue / Green、Canary、A / Bテスト）
- 30.
- 31. 準備 運用 インシデント対応 •インシデント対応の自動化 • 影響範囲の緩和、自動修復、ロールバック、自動復旧 • それでもダメなら事前に定義したフローにもとづきエ スカレーション • デプロイ失敗時の自動ロールバック • 根本原因分析（RCA）を行い、アーキテクチャや インシデント対応手順の両方を改善する AWS Well-Architected Framework https://aws.amazon.com/jp/architecture/well-architected/
- 32.
- 33.
- 34. キーになるAWSのサービス 準備 AWS Config • インベントリ •設定変更の継続記録 AWS Service Catalog • 標準化されたサービ スのテンプレート Auto Scaling Amazon SQS 運用 AWS CodeCommit AWS CodeDeploy AWS CodePipeline • CI/CDパイプライン AWS CloudTrail • AWS環境の変更を監 査、追跡 インシデント対応 Amazon CloudWatch • アラート通知 Amazon CloudWatch Events • 通知と自動処理のト リガー
- 36. Well-Architected レビュー • インタビュー形式 •全項目答えられるよう複数担当者 • 2016年末に3社アセスメント→改善 • 評価結果出すまでの効率が良い • ヒアリング 2時間半〜3時間 • 評価 6時間程度 • 低い評価項目を中心に改善する→決裁しやすい • 社内だけで定期的に回せるようにスキルトラン スファー
- 37. Amazon Web Services企業導入ガイドブック Happy AWS Life!! http://amzn.asia/e1uiMQ2