AWS の技術ブログ

全3157件

2024/02/28

Well-Architected Framework Review の実施方法 – パート 3

これまでのブログ投稿で、Well-Architected Framework Review(WAFR) を実行するための最初の 2 つのフェーズについて説明しました。最初のフェーズは準備で、2 番目のフェーズはレビューを実施することです。このブログ投稿では、3 番目のフェーズである改善について詳しく説明します。図1 – WAFR のフェーズ改善フェーズワークロードのアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューしているこの時点で、以前説明した通り、レビューのための必要な準備を行い、こちらの推奨事項に従って実際のレビューを完了させたはずです。その結果、レビュー中に収集した回答に基づいて、アーキテクチャのリスクを特定したはずです。これらのリスクを、高リスクの問題 (High Risk Issues, HRI) と中リスクの問題 (Medium Risk Issues, MRI) と呼びます（詳細は後ほど説明します）。改善フェーズでは、改善計画（時には対応計画 (Treatment Plan) と呼ばれる）の作成を開始します。つまり、これらのリスクのリストを作成し、ビジネスへの影響を理解し、ソリューションを見つけ、最後に組織の優先事項に従ってこれらのソリューションを実装していきます。以下のサイクルは、WAFR の改善フェーズに含まれる主なステップを示しています。各ステップの詳細について説明します。 1- リスクの特定（別名：改善機会） [所要時間: 1日] WAFR の文脈上で使用されるリスクには 2 つのカテゴリがあります。高リスクの問題 ( HRI ) と中リスクの問題 ( MRI ) です。 HRI はビジネスに重大な悪影響を及ぼす可能性のあるアーキテクチャと運用の選択肢です。組織の業務、資産、個人に影響を与える可能性があります。セキュリティの柱における HRI の例は、AWS アカウントを保護していないことです。 MRI もビジネスに悪影響を与える可能性がありますが、その影響度は HRI ほどではありません。セキュリティの柱における MRI の例は、定期的に認証情報の監査とローテーションを行っていないことです。 HRI/MRI レポートの生成 HRI/MRI を視覚的に特定する最初のステップは、確認した各ワークロードのリスクを示すレポートを生成することです。 AWS Well-Architected Tool (AWS WA Tool) のダッシュボードから、ワークロードとそれに関連する HRI および MRI にアクセスできます。また、共有されたワークロードも含めることができます。ダッシュボードを使用すると、ワークロード、柱、または重要度（高または中）で問題をフィルタリングできます。この図は、いくつかのサンプルワークロードを含むダッシュボードの例を示しています。下にスクロールさせると、HRI/MRI のリストが表示されます。柱または重要度でフィルタリングできます。例えば、これは信頼性の柱で発見された HRI/MRI のリストです。改善項目を選択すると、Well-Architected Framework からそれに関連するベストプラクティスに直接移動します。そこから、問題を修復するために必要な推奨アクションと必要なリソースについて読むことができます。これらの全ての結果を 1 つのレポートにまとめるには、WA Tool のダッシュボードから [レポートの生成] を選択します。このレポートを組織内のレビューチームと共有することを推奨します。通常、私はお客様に対して、次のステップに備えるために、実施した内容、主な調査結果、改善案をまとめた要約メールをお送りしています。 2- リスクの理解 [所要時間: 2-3 週間] リスクに対処する前に、ビジネスに対するその潜在的な重大性と影響、組織にもたらす価値、およびその改善を実装するためのチームの労力を理解することが重要です。HRI と MRI の定義に基づいてビジネスに対するリスクのレベルを評価する際には、次の質問を考えてみましょう。リスクが影響を及ぼす可能性はどの程度か？お客様への影響は何か？結果としてのビジネスへの影響は何か？リスクを完全に排除できるか、それとも軽減するのみか？誰がリスクを負っているか？誰がリスクの排除や軽減のための改善作業を担うか? 主要なステークホルダーやビジネスオーナーにこれらの質問に答えてもらうことで、焦点を当てるべき最も重要なリスクのリストの作成と、それらに対処するための時間を予測するのに役立ちます。架空のワークロードを使用して、例を示しましょう。 HRI/MRI やビジネスにもたらすリスクについてチームと話し合った後、対処が必要な次の HRI を特定しました。 3- 規範的なソリューションの決定 [所要時間: 4-5 週間] 組織のコンテキスト上でリスクと改善の機会を理解したら、チームと協力して、リスクに対する適切で規範的なソリューションを決定する必要があります。このフェーズでは、各チームが自分の領域で発見された HRI に取り組み、HRI に対処するための規範的なソリューションを決定する必要があります。このステップでは、追加の調査、ディスカッション、概念実証の構築が必要になる場合があります。このフェーズでは、ソリューションの実装の詳細に急がないことが重要です。次のステップで説明するように、質問に含まれている HRI がワークロードの優先事項であると決まった際に、後でそれを行います。このステップの目的は、ソリューションの複雑さと必要なリソースを理解することで、ステップ 4 の優先順位リストの作成時にそれらを考慮できるようにすることです。今回の例では、3 つの HRI について次のソリューションを決定しました。 4- 実装と追跡 [所要時間: 3-6 ヶ月] まず優先順位をつけましょう。無制限の時間とリソースを持っている組織は存在しません。WAFR の結果として特定された全ての HRI/MRI に同時に取り組もうとするのは、WAFR から最大限のメリットを得る正しい方法とは限りません。私はいつもお客様に、ビジネスへの影響が大きく、実装がそれほど難しくない HRI/MRI の数を選んで始めることを推奨しています。ソリューションを実装します。改善を追跡し、そのアプローチを反復します。しかし、実装する上で最も重要な項目に優先順位を付けるにはどうしたらよいでしょうか? ソリューションの優先順位を可視化するのに役立つツールの 1 つが、アイゼンハワースタイルのプロットです。このツールを使用する方法は様々です。評価する際には、改善の重要性（ビジネスにもたらす価値の大きさ）と改善を実装するための労力（必要な時間、実装の複雑さ、人数など）の両方を考慮してください。分析を行うと、ビジネスに最も影響を与えるリスクのセットが得られます。同時に、これらのリスクは実装が複雑ではありません。これらは、最初の反復で実装を開始するのに適した候補となります。このモデルを今回の例に適用してみましょう。今回の例で特定された HRI をレビューした結果、次のことが判明しました。これはプロットを使用した分析の様子です。REL1、COST1、OPS4 を優先順位として決定した後、実装を開始し、次の HRI/MRI のセットについてこのプロセスを繰り返します。図 9 – 影響度/複雑さを考慮したソリューションの優先順位付けソリューションの特性特定されたリスクに対するソリューションを選択する際には、次の点を考慮してください。 S.M.A.R.T : ソリューションを SMART の観点から考えましょう。良いソリューションは、具体的な (Specific) アウトプットがあるもので、測定可能 (Measurable) で、達成可能 (Achievable) で、問題と関連性があり (Relevant) 、期限が設定されている (Time-bound) べきです。オーナー: 全てのソリューションについて、オーナーを特定しましょう。シンプルで複雑でない: 複雑なソリューションは機能しますが、改善をより困難で長期化させます。常に複雑性よりもシンプルさを選択しましょう。 Two-way Door ソリューション: ソリューションは拡張可能で、時間とともに改善・進化するように設計されるべきです。可能であれば、アーキテクチャが発展しても適応できない静的なソリューションは避けてください。パターンベース: コード化、再利用、再共有できるソリューションを目指しましょう。車輪の再発明は避けましょう。いくつかの例をチェックしてください。タイムライン「これらのステップを実行していくための典型的なタイムラインはどのようなものか」と疑問に思われるかもしれません。それに対する一概に決まった答えはありません。組織はそれぞれ異なり、独自の課題があるからです。しかし、多くのお客様との成功した WAFR の事例から見る限り、このフェーズには 90-180 日かけることを推奨します。この期間がより長くなるような HRI/MRI のリストである場合は、優先順位を付けて短いリストを取り出すことを推奨します。そうすれば、プロセスの実践を始めて改善を図ることができます。その後、残りの項目に対して繰り返し実施できます。まとめこのブログ投稿では、WAFR の結果として特定されたアーキテクチャの HRI/MRI に対処するための改善計画を策定する際に踏むステップについて順を追って説明しました。改善計画を策定する前に、リスクを理解して分析し、優先順位を付け、そのソリューションを見極め、最も影響力のあるリスクを対象に優先的なアプローチを決定する必要があります。それを達成するのに役立ついくつかのツールとリソースを紹介しました。また、優れたソリューションを生み出す特性についてもいくつか紹介しました。皆さんの次のステップは、組織にある 2,3 のワークロードに対して Well-Architected Framework Review(WAFR) を実施することの重要性についてチームと話し合うことです。著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。翻訳はソリューションアーキテクトの安藤が担当しました。原文はこちらです。

AWS の技術ブログ

コンテンツ