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

「私のワークロードは “Well-Architected” だと言えますか？私のチームはクラウドのベストプラクティスに従っていますか？他のお客様はソリューション X をどのように実装していますか？サービス Y を構成する最適な方法は何ですか？」

これらは、お客様のアーキテクチャが AWS のベストプラクティスに沿っているかどうかを検証したいというお客様から普段いただく質問の例です。その答えの内容はお客様の技術ドメインの種類によって異なりますが、一般的にお客様が従う確立された設計原則があり、これらに従うことで、システムが期待通りに機能する可能性が高まります。これらの設計原則とベストプラクティスは、AWS Well-Architected Framework の中核をなしており、運用上の優位性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 本の柱に渡っています。

AWS では、あらゆるものにベストプラクティスがあり、ワークロードに対して実施する Well-Architected Framework Review(WAFR) も例外ではありません。チームの経験、ワークロードの複雑さ、レビューする柱、後に取り上げるその他の要因など、複数の要因によって、WAFR は大掛かりな取り組みになる可能性があります。これらのベストプラクティスを認識していることは、チームがレビューに投資している時間がアーキテクチャのリスクを特定し、それらに対処するという期待される結果につながることを確実にするための鍵となります。この 3 部構成のブログシリーズでは、AWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有します。パート 1 では、レビューの準備方法をお話しします。パート 2 では実施方法をカバーし、パート 3 ではアーキテクチャのリスクを特定し、それらを修正するための計画を作成する方法をカバーしています。

WAFR とは何か

テクノロジーシステムを構築することは、他の製品を構築することと変わりません。製品を業界の標準に沿って構築するためには、守るべきプラクティス (practices) と規範があります。しかし、プラクティスを整備するだけでは不十分です。チームがこれらのプラクティスを認識 (aware) し、準拠 (follow) していることを確認するための仕組み (mechanism) を実装する必要があります。

AWS のベストプラクティスを学習 (Learn) し、アーキテクチャをこれらのベストプラクティスと照らし合わせて計測 (Measure) し、アーキテクチャのリスクを特定して、それらに対処するための改善 (Improve) 計画を作成する一貫したプロセス (Consistent process) が、AWS Well-Architected Framework Review(WAFR) と呼ばれるものです。

図 1 – Well-Architected Framework Review サイクル

WAFR の目的は何か？なぜ必要なのか？

WAFR の最終的な目標は、システムアーキテクチャを改善することで、そのシステムがビジネスニーズをより適切にサポートできるようにすることです。アーキテクチャの改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと照らして比較することから始まります。これを実現するために、レビューの質問に回答します。各柱に対して質問のセットがあります。これらの質問は、特定のベストプラクティスがアーキテクチャに実装されているかどうかを検証します。回答に基づき、AWS Well-Architected Tool (AWS WA Tool) の支援を受けて、アーキテクチャ内で高リスク、中リスク、低リスクの領域を特定します（後ほど詳しく説明します）。次のステップは、これらのリスクの影響の高いものを特定することにより、優先順位に基づいたアプローチでリスクの解決に取り組み始めることです。その後、それらに対処するための改善計画を作成します。今回の投稿と本シリーズの次の投稿で、これらの各ステップの詳細を説明します。

WAFR のフェーズ

WAFR には、準備 (Prepare), レビュー (Review), 改善 (Improve) の 3 つのフェーズがあります。以降のセクションでは、各フェーズについて詳しく説明し、そこから最大限のメリットを引き出すためのベストプラクティスを紹介します。

図 2 – Well-Architected Framework Review のフェーズ

準備

WAFR の準備は、平均して実際のレビュー日の約 3 週間前から開始されます。 これは、レビューチームの結成にかかる時間、レビューする柱の数、組織によってレビューを完了することに与えられた優先順位などの要因に左右されます。 このフェーズでは、レビューセッションに招待するチーム、レビューする作業量、レビューセッションの形式を決定します。 また、レビューの質問に答えるのに役立つアーキテクチャに関する必要なデータを収集する必要があります。

それぞれをより詳しく見ていきましょう。

1- ワークロードを定義する

WAFR の準備の最初のステップは、レビューしたいワークロードを特定することです。ワークロードとは、組織にビジネス価値を提供するコンポーネント（テクノロジー、人、プロセス）の集合です。これは、リーダーがコミュニケーションするビジネスとテクノロジーのレベルです。例えば、お客様が注文およびそれを追跡できるウェブサイトと、そのバックエンドをサポートするインフラストラクチャおよびプロセスは、ワークロードです。

2- コアチーム（スポンサー）を定義する

WAFR を成功させるための重要な要素は、最初から適切な人に参加してもらうことです。

レビューするワークロードを特定した後、ワークロードの所有者を特定する必要があります。時にスポンサーと呼ばれることもあります。ワークロードのスポンサーとは、そのワークロードの成功（または失敗）に最終的に責任を持つ個人（またはチーム）のことです。この人物は、レビューの結果として特定されたアーキテクチャ上のリスクに対処するための影響力と行動をとる適切な権限を持っている必要があります。例えば、チームの優先事項を変更したり、外部委託したりすることが考えられます。

各柱についてスポンサーを特定する必要があります。組織の構造や規模によっては、1 人が複数の柱を担当したり、1 つの柱を複数のチームが担当したり、あるいはその両方の場合があります。ここでの目的は、各柱についてレビューの質問に答える適任者がいることを確認し、後に対応計画の一環としてその柱で特定されたリスクに対処できるようにすることです。

レビュー対象の柱をより全体的に俯瞰するために、異なるチームから個人を招待する必要があるかもしれません。例えば、信頼性の柱をレビューする場合、データベース、ネットワーク、セキュリティ、運用の専門家 (Subject Matter Expert, SME) を含める必要があるかもしれません。運用上の優秀性の柱をレビューする場合は、エンタープライズアーキテクトやアプリケーション開発部門、ビジネス/ファイナンス部門などを含める必要があるかもしれません。

3- 柱とレンズを決定する

6 つの柱の視点からワークロードを包括的に見ることが最も理想的です。しかし、特定の柱にだけ焦点を当てる必要がある状況もあるかもしれません。例えば、セキュリティの慣行を変更した場合、ベストプラクティスとの整合性を確認したいと考えるかもしれません。この場合、セキュリティの柱のみをレビューすることを選択する可能性があります。

Well-Architected Framework に記載されている通りの柱の順序に従うことを推奨します。運用上の優秀性の柱から始めて、持続可能性の柱で終わるようにします。しかし、組織の優先事項は異なる可能性があります。このフェーズでは、レビューする柱の順序を決定する必要があります。

レビューする際に検討するもう1つの点は、AWS Well-Architected レンズを使用するかどうかです。このレンズは Well-Architected のガイダンスを特定の業界や技術領域に特化して拡張したものです。例えば、ワークロードが主にサーバーレスを利用している場合は、サーバーレスアプリケーションレンズに対してレビューする必要があるかもしれません。データ分析ワークロードを実行している場合は、レビューにデータ分析レンズを含める必要があるでしょう。このように業界や領域に応じてレンズを選択します。利用可能なレンズの一覧はこちらから確認できます。

4- セッションのタイプを決定する

選択した柱とチームの参加可能性に応じて、レビューセッションの形式を決定する必要があります。選択肢としては、6 つの柱の 1 日レビュー、または選択されたいくつかの柱について数日かけて複数のセッションを実施する方法があります。1 日レビューを実施することは通常、スケジュール設定が難しいですが、すべてのステークホルダーがベストプラクティスを議論するために集まることができるので、最も価値があります。通常、この形式は最も改善の機会を明らかにするのに役立ちます。複数のセッションは、地理的に分散したチーム、または大規模なチームがあり、同時に集まることが困難な場合の良い選択肢です。このアプローチは維持しやすいですが、異なるマイルストーンで異なるチームに更新するために、少し余分な作業が必要になる場合があります。

レビュー中のチーム間のコミュニケーションが重要です。なぜなら、質問への回答や問題の特定を集団で行うのに役立つからです。そのため、AWS WA Tool の質問にチームで回答する際は、非同期的ではなく、ライブセッションとして WAFR を実施し、回答をその場で共有することを推奨します。

5- レビューに必要なデータを収集する

レビューセッションを実施する前に、レビュー対象のワークロードについての詳細な情報を収集することを推奨します。例えば、システムの主要コンポーネント、バックエンド、運用を担当する主要なプロセスとチームを説明しているアーキテクチャ図やドキュメントを確認します。

より複雑なワークロードの場合は、AWS Trusted Advisor におけるベストプラクティスに対する自動評価を行うチェック機能を利用できます。これには、コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービス制限が含まれます（訳注：2024 年 2 月 26 日翻訳時点で運用上の優秀性も含みます）。Trusted Advisor を有効にして、AWS Organizations のすべてのアカウントをチェックできます。 詳細はこちらをご確認ください。そして、Trusted Advisor の推奨アクションを利用して、ベストプラクティスへの準拠状況をより深く理解し、レビューや後の対応計画の策定にこれらの詳細を取り入れることができます。 AWS Well Architected と AWS Trusted Advisor を利用したデータドリブンなコスト最適化の達成方法の例もご参照ください。

まとめ

このブログ記事では、Well-Architected Framework Review の最初のフェーズである「準備フェーズ」について詳しく取り上げました。 お客様とレビューを実施する中で学んだステップと教訓の一部をご紹介しました。 これらの推奨事項により、レビューがよりスムーズに進み、参加者の時間を最大限に活用できるようになります。 ステップには、レビュー対象のワークロードの定義、適切なコアチームとスポンサーの特定、 柱とセッションタイプの選択、そして事前に必要なデータの収集が含まれます。 これらのステップにより、レビュー日の準備が整います。 このブログシリーズのパート 2 とパート 3 で、WAFR についてさらに詳しく取り上げます。

著者について

翻訳はソリューションアーキテクトの安藤が担当しました。原文はこちらです。