Amazon Web Services ブログ

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

Well-Architected Framework Review (WAFR) を成功させるには、準備、レビュー、改善の 3 つのフェーズがあります。このブログシリーズのパート 1 では、準備フェーズについて説明しました。このパートでは、第 2 フェーズ、つまり実際のレビューにおけるベストプラクティスについて詳しく説明します。

図 1 – WAFR のフェーズ

準備フェーズの推奨事項に従っていると仮定すると、この時点で、レビューしたいワークロードを特定し、スポンサーを特定し、レビューする柱とその優先順位を決定し、使用するレンズ（ある場合）とレビューセッションの形式を決定しているはずです。また、レビューの質問に答えるために、ワークロードに関する必要なデータも収集しているはずです。

WAFR のゴール

WAFR の成功のためのいくつかの推奨事項について深く掘り下げる前に、レビューの最終目標はシステムアーキテクチャを改善して、これらのシステムがビジネスニーズをより良くサポートできるようにすることであることを再確認しておくことが重要です。アーキテクチャ改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと比較することから始まります。レビューの質問に回答することでこれを行います。各柱に対し質問のセットがあります。回答に基づいて、改善領域、つまり高リスクの問題 (High-Risk-Issues, HRI) および中リスクの問題 (Medium-Risk-Issues, MRI) を特定します。次に、優先順位に基づいたアプローチを使用して、これらのリスクを改善するための対応計画の作成に取り組みます。

WAFR のベストプラクティス

1- 期待値を設定します。

WAFR は全ての参加者にとって大きなコミットメントです。メインのステークホルダーと事前にこの話し合いを行い、レビューの前・最中・後の期待値と役割を明確にします。彼らのサポートが得られることを確認しましょう。

2- 監査ではなく対話であることを意識します。

WAFR セッションで最も良い結果を出すのは、チェックリストや採点の機会としてではなく、対話の機会としてステークホルダーが捉える場合です。これにより、ベストプラクティスの見逃しを責められることなく、全てのチームメンバーがシステムについて自由に話すことを促します。これはアーキテクチャリスクの発見に役立ちます。

3- チームスポーツの精神を持って、チームの全員が役割を果たすべきです。

例えば、柱のスポンサーはその柱内のすべての質問に正しく答えるべきです。スポンサーは、レビュー中に特定されたリスクの改善計画を所有する必要があります。これはレビューの改善フェーズで異なるチーム間で特定されたリスクの優先順位付けと解決策を見つける必要がある場合に、より重要になります。これはこのブログシリーズのパート 3 で議論されています。

4- 1 回きりのチェックではなく、継続的なチェックが必要です。

物事は常に変化するので、その変化を放っておかないようにすべきです。組織内で WAFR（またはそのカスタマイズバージョン）を定期的に実施することを習慣化させる、もしくは、テストから本番への移行など、ワークロードのライフサイクルの大きなマイルストーンごとに合わせて実施することを推奨します。

5- より早いうちに実施することが望ましいです。

本番ではなく設計段階にあるうちは、意思決定に影響を与え変更を促進することがより容易であるからです。

6- AWS Well-Architected Tool (AWS WA Tool) を使用します。

WAFR の質問はホワイトペーパーとして利用できます。しかし、レビューには AWS WA Tool を使用することを推奨します。このツールを使用することで、質問を追跡したり、メモを取ったり、様々なマイルストーンを作成したり、質問のコンテキストを理解したり、実証済みのベストプラクティスを理解したり、ブログ、re:Invent トーク、ドキュメントなどの質問に含まれているベストプラクティスに対する追加リソースを検索したりできます。

AWS WA Tool の使用は、カスタムレンズを作成することにも役立ちます。カスタムレンズを使用することで、独自の柱、質問、ベストプラクティスを作成できます。カスタムレンズの質問は、特定のテクノロジーに合わせてカスタマイズできるため、組織内のガバナンスニーズを満たすのに役立ちます。

こちらの例をご覧ください:

レビューフェーズでは、特定のベストプラクティスが実装されているかどうかを説明するために必要なメモを取ることが重要です。実装されている場合は、質問のチェックボックスにチェックを入れます。実装されていない場合は、なぜ実装されていないのかを説明するためにメモ欄にメモを取ります。「ロードマップ上にあるか？」「他の要件と競合しているか？」「単に見落とされただけか？」これらの質問への回答は、チームが後で改善計画を作成する場合に役立ち、他のレビュアーにとってもチームと所有者が変更される場合に役に立ちます。

マイルストーンは私がお勧めするもう 1 つの機能です。マイルストーンは特定の時点でのワークロードの状態を記録します。複数のセッションを実施する場合や、改善項目に取り組む場合に、マイルストーンを保存して進捗を測定できます。

7- 時間を有効活用します。

WAFR は短時間で完了し、数日ではなく数時間で終わらせるべきです。 レビュープロセスを簡潔に保つために、ベストプラクティスを検証するためのフォローアップ質問をすることと、質問のコンテキスト内に留め、技術的な深い議論に時間をかけすぎずに、バランスを保つことが重要です。

例えば、モニタリングは 6 つの柱全てにわたって取り上げられるトピックです。しかし、コンテキストは柱ごとに異なります。運用上の優秀性の柱をレビューする際のモニタリングは、可観測性についてであり、メトリクスと KPI を設定することにより、ワークロードの健全性を理解することです。セキュリティの柱では、モニタリングのコンテキストは、環境の監査、悪意のあるアクティビティの追跡、不正な動作の理解などにシフトします。

もう 1 つ注意点としては、レビュー中に技術的な議論に深入りしすぎないことです。例えば、サービスの設定の詳細を調べる場合などです。また、解決策の部分に飛び込むことも避けてください。レビュー中に正しいソリューションをその場で推奨するのに十分な時間と必要な詳細がないからです。代わりにメモを取り、パート 3 でみていくように、改善フェーズの一環としてこのトピックをフォローアップしてください。

8- 「多分」は「違う」と捉えるようにします。

場合によっては、ベストプラクティスが実装されているかどうかチームで確信が持てないことがあります。その場合は、実装されていないベストプラクティスを考慮し、WA Tool のメモにそのことを文書化する必要があります。このようにすることで、改善フェーズの一環として、ソリューション（またはさらなる検証）をフォローアップとして含めることができます。

9- 必要に応じてスケールさせ、自動化を図ります。

大規模な組織で多数のワークロードがある場合は、ワークロードをレビューし、リスクを特定し、それらを修正するための自動化された拡張性のあるプロセスを構築することを検討してください。

ここに私の同僚が作成した、組織に WAFR を統合する方法の例がいくつかあります。組織に合わせて、これらのソリューションを調整および再利用できます。

まとめ

このブログ記事では、様々な業界のお客様と実施した多数の Well-Architected Framework Reviews から得た教訓の一部を紹介しました。WAFR の最終目的は、アーキテクチャのリスクを特定し、対処することです。そこに辿り着くには、まずワークロードアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューする必要があります。WAFR を実施する際、いくつかの推奨事項に従い、回避すべきアンチパターンがあります。レビューは会話形式で、正直であり、文書化されており、週ではなく日単位で完了する必要があります。複数のワークロードのレビューを実施する場合は、組織のベストプラクティスに従ってプロセスを自動化およびスケールする必要があります。SA やお客様からのリソースの例をいくつか示し、その方法を紹介しました。次のステップでは、リスクを特定した後、それらに対処するための改善計画を作成する必要があります。これはパート 3 でカバーされます。

著者について

Ebrahim (EB) Khiyami

Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。

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