2022バージョンについて

新バージョンをリリースしています。 今後はこちらをご参照ください。

以下2021バージョン

AWS認定トレーニング講師の平野@おんせん県おおいたです。

今日はWell-Architectedがテーマです。

はじめに

AWS Well-Architected フレームワークとは

AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティクス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。

とはいえ...

とはいえ、このドキュメントなかなか読みづらいです。 私も正直最初は？？？という感じでした。 そこで、これからWell-Architected ドキュメントを読む方のサポートができないかと思い、このブログを描いてみました。 皆様のWell-Architectedライフをにお役立てください。

こんな人にオススメ

AWSの勉強を始めた人

これからAWSを始める方には、どのようなベストプラクティクスがあるのか全体に目を通して、頭の片隅に置いていてもらいたいです。 ベストプラクティクスには、AWSが解決しようとしている顧客の課題が反映されています。 解決したい課題が頭に入っていると、AWSのサービスを学ぶ際、理解の助けになります。

様々なプロジェクトに携わっている人

業務でAWSを利用する際は、AWSへの投資対効果を最大限に発揮するために、Well-Architectedレビューが推奨されています。 レビューにWell-Architected Toolを活用することも多いと思います。 その際、ドキュメントを調べるための索引集/ハンドブックとしてこのブログを活用いただけると嬉しいです。

Well-Architected ドキュメントの歩き方 -読み方ガイド-

ますは、ドキュメントの読み方として、ドキュメントの構成（読むポイント）を紹介します。 そして、このブログが取り上げる索引集について説明します。

ドキュメントの全体構成

Well-Architected ドキュメントの構成をまとめたものがこの図になります。

階層構造が深くて、無意識に先頭から読み進んでいると今どこにいるか迷宮に入ってしまいます。 一方で、この構造を理解しておくと、とても読みやすくなります。

とはいえ、最初からこの構造を全て見ていくのは大変です。

そこで、最初は「柱」と「質問」からおさえていくことをお勧めします。

「柱」はWell-Architectedのカテゴリを示していて、５つの柱から構成されています。まずは各柱の目的を考えてみてください。

「質問」はベストプラクティクスが解決すべきゴールです。言い換えれば、「AWSを活用して得られる効果」ということになります。どういうお困りごとを解決できるか想像しながら考えてみてください。

このブログに取り上げる範囲

このブログでは、１ページにおさまる範囲で「ドキュメント索引集」としてまとめました。 そして、まずおさえてもらいたい「柱」と「質問」にフォーカスが当たるように、全体構成の中の次の黄色部分をピックアップしてまとめています。

さらに詳細を調べたい場合は、各柱/質問ごとにAWSドキュメントの詳細ページへのリンクを貼っていますので、活用してください。

AWS Well-Architected ドキュメント索引集

ここからがこのブログの本題です。各柱/質問を中心にまとめています。 各質問ごとにぺストプラクティクスを箇条書きに記載しています。ぺストプラクティクスの詳細を調べる際は各質問に公式ページのリンクを貼ってますので、参考にしてください。

また、上から順に読む必要はありません。興味が持てる柱、ベストプラクティクスから始めてみましょう。挫折しないよう工夫してご利用ください。

一般的な設計原則

設計原則

• キャパシティーニーズの推測が不要
• 本稼働スケールでシステムをテストする
• ⾃動化によってアーキテクチャでの実験が容易に
• 発展するアーキテクチャが可能に
• データに基づいてアーキテクチャを駆動
• ゲームデーを利用して改善する

運用上の優秀性の柱

設計原則

• 運用をコードとして実行する
• 小規模かつ可逆的な変更を頻繁に行う
• 運用手順を定期的に改善する
• 障害を予想する
• 運用上のすべての障害から学ぶ

ベストプラクティス

質問	ベストプラクティス
OPS 1: 優先順位はどのように決定すればよいでしょうか?	外部顧客のニーズを評価する 内部顧客のニーズを評価する ガバナンス要件を評価する コンプライアンス要件を評価する 脅威の状況を評価する トレードオフを評価する メリットとリスクを管理する
OPS 2: ビジネスの成果をサポートするために、組織をどのように構築しますか?	特定された所有者がリソースについて存在している プロセスと手順が所有者を特定 パフォーマンスに責任を持つ所有者が運用アクティビティについて存在している チームメンバーが自らの責任範囲を知る 責任と所有権を特定するためのメカニズムが存在する 追加、変更、例外をリクエストするメカニズムが存在する チーム間の責任は事前定義済みまたは交渉済み
OPS 3: 組織の文化はビジネスの成果をどのようにサポートしますか?	エグゼクティブスポンサー 結果にリスクがあるときにアクションを実行する権限が、チームメンバーに付与されている エスカレーションが推奨されている コミュニケーションがタイムリーで明確で実用的なものである 実験が推奨されている チームメンバーがスキルセットを維持し、強化することが可能であり、推奨されている チームに適正なリソースを提供する チーム内およびチーム間でさまざまな意見が奨励され、求められる
OPS 4: どのようにワークロードを設計して、その状態を理解できるようにするのですか?	アプリケーションテレメトリーを実装する ワークロードテレメトリーを実装して設定する ユーザーアクティビティテレメトリーを実装する 依存関係のテレメトリーを実装する トランザクショントレーサビリティを実装する
OPS 5: どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?	バージョン管理を使用する 変更をテストし、検証する 設定管理システムを使用する 構築およびデプロイ管理システムを使用する パッチ管理を実行する 設計標準を共有する コード品質の向上のためにプラクティスを実装する 複数の環境を使用する 小規模かつ可逆的な変更を頻繁に行う 統合とデプロイを完全に自動化する
OPS 6: どのようにデプロイのリスクを軽減しますか?	変更の失敗に備える 変更をテストし、検証する デプロイ管理システムを使用する 限定的なデプロイを使用してテストする 並列環境でデプロイする 小規模で可逆的な変更を頻繁にデプロイする 統合とデプロイを完全自動化する テストとロールバックを自動化する
OPS 7: ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?	従業員の対応力を確保する 運用準備状況の継続的な確認を実現する ランブックを使用して手順を実行する プレイブックを使用して問題を調査する システムや変更をデプロイするために十分な情報に基づいて決定を下す
OPS 8: ワークロードの正常性をどのように把握しますか?	主要業績評価指標 (KPI) を特定する ワークロードのメトリクスを定義する ワークロードメトリクスを収集および分析する ワークロードメトリクスの基準値を設定する ワークロードに対して予想されるアクティビティのパターンを知る ワークロードの結果にリスクがある場合に警告する ワークロードの異常が検出された場合に警告する KPI とメトリクスの成果の達成度と有効性を検証する
OPS 9: オペレーションの正常性をどのように把握しますか?	主要業績評価指標 (KPI) を特定する 運用メトリクスを定義する 運用メトリクスを収集し、分析する 運用メトリクスの基準値を設定する 運用に対して予想されるアクティビティのパターンを知る 運用の結果にリスクがある場合に警告する 運用の異常が検出された場合に警告する KPI とメトリクスの成果の達成度と有効性を検証する
OPS 10: ワークロードと運用イベントはどのように管理しますか?	イベント、インシデント、問題に対する管理プロセスを使用する アラートごとのプロセスを使用する ビジネスへの影響に基づき、運用上のイベントを優先します エスカレーション経路を決定する プッシュ通知を有効にする ダッシュボードでステータスを知らせる イベントへの対応を自動化する
OPS 11: オペレーションを進化させる方法	継続的改善のプロセスを用意する インシデント後の分析を実行する フィードバックループを実装する ナレッジマネジメントを実行する 改善の推進要因を定義する 洞察を検証する オペレーションメトリクスのレビューを実行する 教訓を文書化して共有する 改善を行うための時間を割り当てる

セキュリティの柱

設計原則

• 強力なアイデンティティ基盤の実装
• トレーサビリティの実現
• 全レイヤーでセキュリティを適用する
• セキュリティのベストプラクティスを自動化する
• 伝送中および保管中のデータの保護
• データに人の手を入れない
• セキュリティイベントに備える

ベストプラクティス

質問	ベストプラクティス
SEC 1: ワークロードを安全に運用するには、どうすればよいですか?	アカウントを使用してワークロードを分ける AWS アカウントのセキュリティを確保する 管理目標を特定および検証する セキュリティ脅威に関する最新情報を入手する セキュリティのレコメンデーションに関する更新情報を入手する パイプラインのセキュリティコントロールのテストと検証を自動化する 脅威モデルを使用してリスクを特定し、優先順位を付ける 新しいセキュリティサービスと機能を定期的に評価および実装する
SEC 2: ユーザー ID とマシン ID はどのように管理したらよいでしょうか?	強力なサインインメカニズムを使用する 一時的な認証情報を使用する シークレットを安全に保存して使用する 一元化された ID プロバイダーを利用する 定期的に認証情報を監査およびローテーションする ユーザーグループと属性を活用する
SEC 3: 人とマシンのアクセス許可はどのように管理すればよいでしょうか?	アクセス要件を定義する 最小権限のアクセスを付与する 緊急アクセスのプロセスを確立する アクセス許可を継続的に削減する 組織のアクセス許可ガードレールを定義する ライフサイクルに基づいてアクセスを管理する パブリックおよびクロスアカウントアクセスの分析 リソースを安全に共有する
SEC 4: セキュリティイベントをどのように検出し、調査していますか？	サービスとアプリケーションのログ記録を設定する ログ、結果、メトリクスを一元的に分析する イベントへの応答を自動化する 実用的なセキュリティイベントを実装する
SEC 5: ネットワークリソースをどのように保護しますか?	ネットワークレイヤーを作成する すべてのレイヤーでトラフィックをコントロールする ネットワーク保護を自動化する 検査および保護を実装する
SEC 6: コンピューティングリソースをどのように保護していますか?	脆弱性管理を実行する 攻撃領域を削減する マネージドサービスを活用する コンピューティング保護を自動化する ユーザーが遠距離でアクションを実行できるようにする ソフトウェアの整合性を検証する
SEC 7: どのようにデータを分類していますか?	ワークロード内のデータを特定する データ保護コントロールを定義する 識別および分類を自動化する データのライフサイクル管理を定義する
SEC 8: 保管時のデータをどのように保護していますか?	安全なキー管理を実装する 保管中に暗号化を適用する 保管時のデータの保護を自動化する アクセスコントロールを適用する 人をデータから遠ざけるメカニズムを使用する
SEC 9: 転送時のデータをどのように保護していますか?	安全な鍵および証明書管理を実装する 伝送中に暗号化を適用する 意図しないデータアクセスの検出を自動化する ネットワーク通信を認証する
SEC 10: インシデントの予測、対応、復旧はどのように行いますか?	重要な人員と外部リソースを特定する インシデント管理計画を作成する フォレンジック機能を備える 封じ込め機能を自動化する アクセスを事前プロビジョニングする ツールを事前デプロイする ゲームデーを実施する

信頼性の柱

設計原則

• 障害から自動的に復旧する
• 復旧手順をテストする
• 水平方向にスケールしてワークロード全体の可用性を高める
• キャパシティーを推測することをやめる
• オートメーションで変更を管理する

ベストプラクティス

質問	ベストプラクティス
REL 1: サービスクォータと制約はどのように管理しますか?	サービスクォータと制約を認識する アカウントおよびリージョンをまたいでサービスクォータを管理する アーキテクチャを通じて、固定サービスクォータと制約に対応する クォータをモニタリングおよび管理する クォータ管理を自動化する フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
REL 2: ネットワークトポロジをどのように計画しますか?	ワークロードのパブリックエンドポイントに可用性が高いネットワーク接続を使用する クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする 拡張や可用性のために割り当てる IP サブネットを確保する 多対多メッシュよりもハブアンドスポークトポロジを優先する 接続されているすべてのプライベートアドレス空間において、重複しないプライベート IP アドレス範囲を指定します
REL 3: どのようにワークロードサービスアーキテクチャを設計すればよいですか?	ワークロードをセグメント化する方法を選択する 特定のビジネスドメインと機能に重点を置いたサービスを構築する API ごとにサービス契約を提供する
REL 4: 障害を防ぐために、分散システムの操作をどのように設計しますか?	必要な分散システムの種類を特定する 疎結合の依存関係を実装する すべての応答にべき等性を持たせる 動作を継続的に行う
REL 5: 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?	該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する スロットルリクエスト 再試行呼び出しを制御および制限する すぐに失敗し、キューを制限する クライアントタイムアウトを設定する 可能な場合はサービスをステートレスにする 緊急レバーを実装する
REL 6: ワークロードリソースをモニタリングするにはどうすればよいですか?	ワークロードのすべてのコンポーネントをモニタリングする (生成) メトリクスを定義および計算する (集計) 通知を送信する (リアルタイム処理とアラーム) レスポンスを自動化する (リアルタイム処理とアラーム) ストレージと分析 定期的にレビューを実施する システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
REL 7: 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?	リソースの取得またはスケーリング時に自動化を使用する ワークロードの障害を検出したときにリソースを取得する ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する ワークロードの負荷テストを実施する
REL 8: 変更はどのように実装するのですか?	デプロイなどの標準的なアクティビティにランブックを使用する デプロイの一部として機能テストを統合する デプロイの一部として回復力テストを統合する イミュータブルなインフラストラクチャを使用してデプロイする 自動化を使用して変更をデプロイする
REL 9: データはどのようにバックアップするのですか?	バックアップする必要があるすべてのデータを特定してバックアップするか、ソースからデータを再現する バックアップを保護し、暗号化する データバックアップを自動的に実行する データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
REL 10: ワークロードを保護するために障害分離をどのように使用しますか?	複数の場所にワークロードをデプロイする 単一のロケーションに制約されるコンポーネントのリカバリを自動化する バルクヘッドアーキテクチャを使用する
REL 11: コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか?	ワークロードのすべてのコンポーネントをモニタリングしてエラーを検知する 正常なリソースにフェイルオーバーする すべてのレイヤーの修復を自動化する 静的安定性を使用してバイモーダル動作を防止する イベントが可用性に影響する場合に通知を送信する
REL 12: どのように信頼性をテストしますか?	プレイブックを使用して失敗を調査する インシデント後の分析を実行する 機能要件をテストする スケーリングおよびパフォーマンス要件をテストする カオスエンジニアリングを使用して回復力をテストする 定期的にゲームデーを実施する
REL 13: 災害対策 (DR) はどのように計画するのですか?	ダウンタイムやデータ消失に関する復旧目標を定義する 復旧目標を満たすため、定義された復旧戦略を活用する 災害対策の実装をテストし、検証する DR サイトまたはリージョンでの設定ドリフトを管理する 復旧を自動化する

パフォーマンス効率の柱

設計原則

• 最新テクノロジーの標準化
• わずか数分でグローバル展開する
• サーバーレスアーキテクチャを使用する
• より頻繁に実験する
• システムに対する精通の程度を考慮する

ベストプラクティス

質問	ベストプラクティス
PERF 1: どのように最良パフォーマンスのアーキテクチャを選択するのですか?	利用可能なサービスやリソースを理解する アーキテクチャにかかわる選択プロセスを決める 意思決定においてコスト要件を考慮する ポリシーやリファレンスアーキテクチャを使用する クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する 既存のワークロードのベンチマークを実施する ワークロードの負荷テストを実施する
PERF 2: コンピューティングソリューションはどのように選択するのですか?	使用可能なコンピューティングオプションを評価する 利用可能なコンピューティング設定オプションについて理解する コンピューティング関連のメトリクスを収集する 適切なサイジングによって必要な設定を決定する 利用可能な伸縮性のあるリソースを使用する メトリクスに基づいてコンピューティングニーズを再評価する
PERF 3: ストレージソリューションをどのように選択していますか?	ストレージ特性と要件を理解する 利用可能な設定オプションを評価する アクセスパターンとメトリクスに基づいて意思決定を行う
PERF 4: データベースソリューションをどのように選択していますか。	データの特性を理解する 使用可能なオプションを評価する データベースのパフォーマンスメトリクスを収集して記録する アクセスパターンに基づいてデータストレージを選択する アクセスパターンとメトリクスに基づいてデータストレージを最適化する
PERF 5: どのようにネットワーキングソリューションを選択するのですか?	ネットワーキングがパフォーマンスに与える影響を理解する 使用可能なネットワーク機能を評価する ハイブリッドワークロード用に適切なサイズの専用接続または VPN を選択する ロードバランシングと暗号化のオフロードを活用する パフォーマンスを高めるネットワークプロトコルを選択する ネットワーク要件に基づいてワークロードのロケーションを選択する メトリクスに基づいてネットワーク設定を最適化する
PERF 6: ワークロードを進化させるためにどのように新機能を取り込んでいますか？	リソースとサービスに関する最新情報を常に入手する ワークロードのパフォーマンス向上プロセスを定める ワークロードのパフォーマンスを時間の経過とともに進化させる
PERF 7: リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか?	パフォーマンスに関連するメトリクスを記録する イベントやインシデントが発生したときにメトリクスを分析する ワークロードのパフォーマンスを測定するための主要業績評価指標 (KPI) を確立する モニタリングを使用してアラームベースの通知を生成する メトリクスを定期的に見直す モニタリングしてプロアクティブに警告する
PERF 8: トレードオフをどのように使用するとパフォーマンスが向上するのですか?	パフォーマンスが最も重要な分野を理解する デザインパターンとサービスについて理解する トレードオフが顧客と効率性にどのように影響するかを明らかにする パフォーマンス向上の影響を測定する さまざまなパフォーマンス関連戦略を使用する

コスト最適化の柱

設計原則

• クラウド財務管理の実装
• 消費モデルを導入
• 全体的な効率を測定する
• 差別化につながらない高負荷の作業に費用をかけるのをやめる
• 費用を分析および属性化する

ベストプラクティス

質問	ベストプラクティス
COST 1: クラウド財務管理はどのように実装しますか?	コスト最適化担当を設定する 財務とテクノロジーの連携を確立する クラウドの予算および予測を確立する 組織のプロセスにコスト意識を採り入れる コスト最適化に関して報告および通知する コストをプロアクティブにモニタリングする 新しいサービスリリースに関する最新情報を入手する
COST 2: 使用状況をどのように管理しますか?	組織の要件に基づいてポリシーを策定する 目標およびターゲットを策定する アカウント構造を実装する グループとロールを実装する コストコントロールを実装する プロジェクトのライフサイクルを追跡する
COST 3: 使用状況とコストをどのようにモニタリングしますか?	詳細情報ソースを設定する コスト属性カテゴリを特定する 組織のメトリクスを確立する 請求およびコスト管理ツールを設定する コストと使用状況に組織情報を追加する ワークロードメトリクスに基づいてコストを配分する
COST 4: 不要なリソースをどのように削除しますか？	ライフタイム全体にわたってリソースを追跡する 削除プロセスを実装する リソースを削除する 自動的にリソースを削除する
COST 5: サービスを選択するとき、どのようにコストを評価しますか?	組織のコスト要件を特定する このワークロードのすべてのコンポーネントを分析する 各コンポーネントの詳細な分析を実行する コスト効率の高いライセンスを提供するソフトウェアを選択する 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する 異なる使用量について経時的なコスト分析を実行する
COST 6: コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか?	コストモデリングの実行 データに基づいてリソースのタイプやサイズを選択する メトリクスに基づいて自動的にリソースタイプとサイズを選択する
COST 7: コストを削減するには、料金モデルをどのように使用したらよいでしょうか?	料金モデルの分析を実行する コストに基づいてリージョンを選択する 費用対効果の高い条件を提供するサードパーティーの契約を選択する このワークロードのすべてのコンポーネントに対して料金モデルを実装します マスターアカウントレベルで料金モデル分析を実行する
COST 8: データ転送料金についてどのように計画していますか？	データ転送モデリングの実行 データ転送コストを最適化するコンポーネントを選択する データ転送コストを削減するサービスを実装する
COST 9: どのように需要を管理し、リソースを供給しますか?	ワークロードの需要に関する分析を実行する 需要を管理するためのバッファまたはスロットルを実装する リソースを動的に供給する
COST 10: 新しいサービスをどのように評価していますか？	ワークロードレビュープロセスを開発する このワークロードを定期的にレビューして分析する

まとめ

AWSを理解する上でWell-Architectedは大切なものです。ただ、ドキュメントのボリュームの多さに二の足を踏む方もたくさんいると思います（私もそうでした）。このブログがそういう方の背中を押せれば幸いです。