AWS Well-Architected フレームワークの概要について整理した

Posted at 2024-12-20

背景・目的

クラウドの設計原則などあらためて理解したく、AWS Well-Architected フレームワークを整理してみます。
また、Well-Architected Framework toolについても簡単に動かします。

まとめ

下記に特徴を整理します。

特徴	説明
AWS Well-Architected フレームワークとは	AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立つこのフレームワークを使用することによって、下記を設計して運用するためのアーキテクチャに関するベストプラクティスを学ぶ事ができる・信頼性が高く・安全・効率的・費用対効果が高く・持続可能なシステム
AWS Well-Architected フレームワークの特徴	ベストプラクティスに照らしてアーキテクチャを評価し、改善すべき分野を特定する一貫した方法を提供するアーキテクチャをレビューするプロセスは、アーキテクチャの決定に関する建設的な話し合いであり、監査メカニズムではない
AWS Well-Architected Tool	AWS Well-Architected フレームワークを使用してアーキテクチャをレビューおよび測定するための一貫したプロセスを提供する、クラウド上のサービスより信頼性が高く、安全で、効率やコスト効果に優れたワークロード処理を実行するための推奨事項を提供する
AWS Well-Architected ラボ	コードとドキュメントのリポジトリを使用して、ベストプラクティスの実装を実践的に体験できる
AWS Well-Architected フレームワークの6つの柱	・オペレーショナルエクセレンス・セキュリティの柱・信頼性・パフォーマンス効率・コスト最適化・持続可能性
用語の整理	-----------
コンポーネント	・最も基本的な単位・特定の技術要件に基づいたコード、構成、AWSリソースなど・例：API Gateway、Lambdaなど
ワークロード	・ビジネス価値を実現するために使用される・コンポーネントの集合・例：Eコマースアプリ（API Gateway + Lambda+ DDBなどで構成）
アーキテクチャ	・ワークロード内で、コンポーネントがどのように連携し、通信・対話するかの構造・アーキテクチャ図では、コンポーネント間の依存関係、データフローが焦点・例：API Gatewayを通じてリクエストがLambdaに送信され、DDB空データを取得する等
テクノロジーポートフォリオ	・複数のワークロードの集合体・組織のビジネス運営全体を支えるワークロード例・Eコマースシステム（ワークロードA）・社内データ分析プラットフォーム（ワークロードB）・顧客サポートシステム（ワークロードC）
AWS WA Tool	-----------
AWS WA Toolとは	AWS のベストプラクティスを使用してアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービス以下を実行することで製品のライフサイクル全体を支援・決定事項のドキュメント化を支援する・ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供する・ワークロードの信頼性、安全性、効率性、費用対効果の向上

概要

下記を基に整理します。

AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを使用することによって、信頼性が高く、安全で、効率的で、費用対効果が高く、持続可能なシステムを設計して運用するための、アーキテクチャに関するベストプラクティスを学ぶことができます。

AWS Well-Architected フレームワーク
- AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立つ
- このフレームワークを使用することによって、下記を設計して運用するためのアーキテクチャに関するベストプラクティスを学ぶ事ができる
  - 信頼性が高く
  - 安全
  - 効率的
  - 費用対効果が高く
  - 持続可能なシステム

序章

AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを利用すると、安全で信頼性および有効性が高く、コスト効率に優れた持続可能なワークロードを AWS クラウドで設計し、運用するためのアーキテクチャに関するベストプラクティスを学ぶことができます。また、このフレームワークは、ベストプラクティスに照らしてアーキテクチャを評価し、改善すべき分野を特定する一貫した方法を提供します。アーキテクチャをレビューするプロセスは、アーキテクチャの決定に関する建設的な話し合いであり、監査メカニズムではありません。当社は、Well-Architected システムによってビジネスの成功の可能性が大いに高まると確信しています。

ベストプラクティスに照らしてアーキテクチャを評価し、改善すべき分野を特定する一貫した方法を提供する
アーキテクチャをレビューするプロセスは、アーキテクチャの決定に関する建設的な話し合いであり、監査メカニズムではない

AWS ソリューションアーキテクトは、さまざまな業種やユースケースに対応するソリューションのアーキテクトとして長年の経験を持っています。これまで、何千ものお客様の AWS でのアーキテクチャの設計とレビューをお手伝いしてきました。その経験に基づいて、クラウド対応システムを設計するための核となる、戦略とベストプラクティスを確立しました。

AWS Well-Architected フレームワークは、特定のアーキテクチャがクラウドのベストプラクティスと整合しているかどうかを理解するための、一連の基本的な質問を文書化したものです。このフレームワークは、最新のクラウドベースのシステムに期待する品質を評価するための一貫したアプローチと、その品質を達成するために必要な修正を提供します。AWS が進化を続けるのにつれて、当社はお客様との共同作業から多くのことを学び、Well-Architected (よくできたアーキテクチャ) の定義に磨きをかけています。

特定のアーキテクチャがクラウドのベストプラクティスと整合しているかどうかを理解するための、一連の基本的な質問を文書化したもの
最新のクラウドベースのシステムに期待する品質を評価するための一貫したアプローチと、その品質を達成するために必要な修正を提供する

このフレームワークは、最高技術責任者 (CTO)、設計者、開発者、オペレーションチームメンバーなどの技術担当者を対象としています。本ドキュメントは、クラウドワークロードを設計、運用する際に使用する AWS のベストプラクティスや戦略について説明し、さらなる実装の詳細やアーキテクチャパターンへのリンクも提供しています。詳細については、「AWS Well-Architected」を参照してください。

下記のロールを対象としている
- 最高技術責任者 (CTO)
- 設計者
- 開発者
- オペレーションチームメンバーなどの技術担当者

AWS では、ワークロードをレビューする無料サービスも提供しています。AWS Well-Architected Tool (AWS WA ツール) は、AWS Well-Architected フレームワークを使用してアーキテクチャをレビューおよび測定するための一貫したプロセスを提供する、クラウド上のサービスです。AWS WA ツールでは、より信頼性が高く、安全で、効率やコスト効果に優れたワークロード処理を実行するための推奨事項を提供します。

AWSでは、AWS Well-Architected Toolを提供している
- AWS Well-Architected フレームワークを使用してアーキテクチャをレビューおよび測定するための一貫したプロセスを提供する、クラウド上のサービス
- より信頼性が高く、安全で、効率やコスト効果に優れたワークロード処理を実行するための推奨事項を提供する

当社は、ベストプラクティスの適用をサポートするために、AWS Well-Architected ラボを作成しました。このラボでは、コードとドキュメントのリポジトリを使用して、ベストプラクティスの実装を実践的に体験できます。当社は、AWS Well-Architected パートナープログラムのメンバーである、厳選された AWS パートナーネットワーク (APN) パートナーと提携しています。これらの AWS パートナーは AWS に関する深い知識を有しており、ワークロードのレビューと改善をサポートします。

AWS Well-Architected ラボがある
- コードとドキュメントのリポジトリを使用して、ベストプラクティスの実装を実践的に体験できる

定義

AWS Well-Architected フレームワークは、オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性という 6 つの柱に基づいています。

柱	説明
オペレーショナルエクセレンス	開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすサポートプロセスと手順を継続的に改善する能力。
セキュリティ	セキュリティの柱では、クラウドテクノロジーを活用して、ユーザーのセキュリティ体制を向上させる方法でデータ、システム、アセットを保護する方法について説明
信頼性	信頼性の柱には、意図した機能を期待どおりに、正しく、一貫して実行するワークロードの能力が含まれる。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。このホワイトペーパーでは、AWS に信頼性の高いワークロードを実装するための、詳細なベストプラクティスのガイダンスを提供する
パフォーマンス効率	コンピューティングリソースを効率的に使用してシステム要件を満たし、需要の変化や技術の進歩に合わせてこの効率性を維持する能力
コスト最適化	最も安価にシステムを実行して、ビジネス価値を実現する能力
持続可能性	プロビジョニングされたリソースのメリットを最大化し、必要な合計リソースを最小化することにより、エネルギー消費を削減し、ワークロードのすべてのコンポーネントにおいて効率を向上させ、持続可能性への影響を継続的に改善する能力

用語の定義

用語	説明
コンポーネント	要件に合わせて提供されるコード、構成、および AWS リソースコンポーネントは多くの場合、技術的所有権の単位であり、他のコンポーネントとは切り離されている
ワークロード	ビジネス価値を実現する一連のコンポーネントを特定するために使用します。ワークロードの詳細レベルは通常、ビジネスリーダーとテクノロジーリーダーが話し合いで決定する
アーキテクチャ	ワークロード内でコンポーネントが連携する方法であると考えられる多くの場合、コンポーネントが通信や対話をする方法が、アーキテクチャ図の焦点となる
マイルストーン	アーキテクチャにおける設計、実装、テスト、稼働、本番という製品のライフサイクル全体を通した進化において、重要な変更を記録する
組織内のテクノロジーポートフォリオ	ビジネスの運営に必要なワークロードの集合
工数レベル	タスクの実行に必要な時間、労力、複雑さの度合いを分類したもの各組織は、組織の工数レベルを適切に分類するために、チームの規模や専門性、ワークロードの複雑性など、追加のコンテキストを考慮する必要がある・高: 作業には数週間または数か月かかる可能性があります。これは複数のストーリー、リリース、タスクに分割することができる・中: 作業には数日または数週間かかる可能性がありる。これは複数のリリースおよびタスクに分割することができる・低: 作業には数時間または数日かかる可能性がある。これは複数のタスクに分割することができる

これらをまとめると、下記のように解釈した。

コンポーネント
- 最も基本的な単位
- 特定の技術要件に基づいたコード、構成、AWSリソースなど
- 例：API Gateway、Lambdaなど
ワークロード
- ビジネス価値を実現するために使用される
- コンポーネントの集合
- 例：Eコマースアプリ（API Gateway + Lambda+ DDBなどで構成）
アーキテクチャ
- ワークロード内で、コンポーネントがどのように連携し、通信・対話するかの構造
- アーキテクチャ図では、コンポーネント間の依存関係、データフローが焦点
- 例：API Gatewayを通じてリクエストがLambdaに送信され、DDB空データを取得する等
テクノロジーポートフォリオ
- 複数のワークロードの集合体
- 組織のビジネス運営全体を支えるワークロード
- 各ワークロードが異なる
- 例
  - Eコマースシステム（ワークロードA）
  - 社内データ分析プラットフォーム（ワークロードB）
  - 顧客差サポートシステム（ワークロードC）

レビュープロセス

アーキテクチャのレビューは、徹底的な調査を促進する非難のないアプローチにより、一貫した方法で行う必要があります。話し合いで行う簡易なプロセス (数日ではなく時間) であり、監査ではありません。アーキテクチャレビューの目的は、対策を必要とする重大な問題や改善可能な領域を特定することです。レビュー結果は、お客様のワークロードの扱いやすさを改善する一連のアクションになります。

話し合いで行う簡易なプロセス (数日ではなく時間) であり、監査ではない
アーキテクチャレビューの目的
- 対策を必要とする重大な問題や改善可能な領域を特定すること
- レビュー結果は、お客様のワークロードの扱いやすさを改善する一連のアクション

「アーキテクチャ」セクションで説明したとおり、各チームメンバーがアーキテクチャの品質に責任を持つ必要があります。Well-Architected フレームワークに基づいてアーキテクチャを構築するチームメンバーには、形式ばったレビューミーティングを開催するよりも、アーキテクチャを継続的にレビューすることをお勧めします。レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善したりすることができます。

各チームメンバーがアーキテクチャの品質に責任を持つ必要がある
アーキテクチャを継続的にレビューすることを推奨
レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善できる

AWS Well-Architected フレームワークは、AWS がシステムとサービスについて内部でレビューを行う方法に適合しています。これは、アーキテクチャのアプローチに影響を与える一連の設計原則と、根本原因分析 (RCA) でよく取り上げられる領域が軽視されないようにするための質問を前提としています。内部システム、AWS のサービス、またはお客様に重大な問題があるときは、RCA を検討し、使用するレビュープロセスを改善できるかどうかを確認します。

アーキテクチャのアプローチに影響を与える一連の設計原則と、根本原因分析 (RCA) でよく取り上げられる領域が軽視されないようにするための質問を前提としている

レビューは、変更が難しい「一方向ドア」を避けるために、設計の早い段階で製品ライフサイクルの主要なマイルストーンで適用し、その後は運用開始日の前に適用する必要があります。（多くの決定は、リバーシブルの双方向ドアです。これらの決定には軽量なプロセスを使用できます。一方向ドアは反転するのが困難または不可能であり、ドアを作成する前にさらに検査する必要があります。）本番稼働開始後に新しい機能の追加や技術の実装の変更を行うにしたがい、ワークロードは進化し続けるようになります。ワークロードのアーキテクチャは経時的に変化します。アーキテクチャを進化させるにつれてアーキテクチャの特性が劣化しないように、適切な予防策を取る必要があります。アーキテクチャを大幅に変更するときは、Well-Architected レビューを含めて、一連の予防プロセスに従う必要があります。

変更が難しい「一方向ドア」を避けるために、設計の早い段階で製品ライフサイクルの主要なマイルストーンで適用し、その後は運用開始日の前に適用する必要がある
本番稼働開始後に新しい機能の追加や技術の実装の変更を行うにしたがい、ワークロードは進化し続けるようになる

1 回限りのスナップショットまたは独立した測定としてレビューを活用するには、すべての適切な担当者を話し合いに参加させる必要があります。レビューを実施したことにより、チームが実装した内容を初めて本当に理解したということはよくあります。別のチームのワークロードをレビューするときに有効な方法は、そのアーキテクチャについて何度か気軽に話し合うことです。ほとんどの質問に対する回答はそれで得られます。その後、数回の会議で曖昧な領域や気付いたリスクについて解明したり、掘り下げたりすることができます。

1 回限りのスナップショットまたは独立した測定としてレビューを活用するには、すべての適切な担当者を話し合いに参加させる必要がある

レビューが完了すると、ビジネスの状況に基づいて優先順位を付けることができる問題の一覧が提示されます。それらの課題がチームの日常業務に及ぼす影響を考慮する必要もあります。これらの問題を早期に解決すれば、繰り返し発生する問題を解決する時間を、ビジネス価値を創出するための時間に充てることができます。課題に対処する際にレビューを更新することで、アーキテクチャの改善具合を確認できます。
レビューの価値は 1 度やってみると明らかになりますが、新しいチームでは最初に抵抗があるかもしれません。レビューの利点をチームに知らせることで、次のような反論に対処できます。

「忙しすぎる」 (チームが大きな仕事を始める準備の段階でよくある発言)

大きな仕事を始める準備をしているならば、それを円滑に進める必要があります。レビューを実施することで、見逃していたかもしれない問題を把握できます。

製品ライフサイクルの早い段階でレビューを実施してリスクを洗い出し、機能提供ロードマップに沿ったリスク軽減計画を立てることをお勧めします。

「結果に対して何かをする時間はありません。」 (スーパーボウルなど、動かせないイベントを目標としている場合によくある発言)

そのようなイベントを動かすことはできません。アーキテクチャのリスクを把握せずに、本当に進めるつもりですか。これらの問題のすべてに対策を講じることができない場合でも、問題が生じたときの対処法を準備しておくことはできます。

「ソリューション実装の秘密を他人に知られたくない。」

Well-Architected フレームワークに関する質問をチームに示したら、取り引きや技術に関する専有情報を開示する質問が 1 つもないことをチームは理解するでしょう。

レビューが完了すると、ビジネスの状況に基づいて優先順位を付けることができる問題の一覧が提示される

AWS Well-Architected Tool

AWS Well-Architected Tool (AWS WA Tool) は、AWS のベストプラクティスを使用してアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービスです。AWS WA Tool は、以下を実行することで製品ライフサイクル全体を支援します。

決定事項のドキュメント化を支援する

ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供する

ワークロードの信頼性、安全性、効率性、費用対効果の向上

AWS WA Tool
- AWS のベストプラクティスを使用してアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービス
- 以下を実行することで製品のライフサイクル全体を支援
  - 決定事項のドキュメント化を支援する
  - ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供する
  - ワークロードの信頼性、安全性、効率性、費用対効果の向上

AWS WA Tool を使用すると、AWS Well-Architected フレームワークのベストプラクティスを使用して、ワークロードを文書化して測定します。これらのベストプラクティスは、AWS ソリューションアーキテクトがさまざまなビジネスでソリューションを構築してきた長年の経験を基に開発されています。このフレームワークは、アーキテクチャを測定するための一貫したアプローチを提供します。また、時間の経過とともにニーズに応じてスケーリングする設計を実装するのに役立つガイダンスも提供します。

AWS Well-Architected フレームワークのベストプラクティスを使用して、ワークロードを文書化して測定する

AWS のベストプラクティスに加えてカスタムレンズを使用することで、独自のベストプラクティスに照らしてワークロードを測定できます。カスタムレンズ内の質問は、特定のテクノロジーに特化したり、組織内のガバナンスニーズに対応したりできるようにカスタマイズできます。カスタムレンズは、AWS レンズが提供するガイダンスを補足するものです。

AWS のベストプラクティスに加えてカスタムレンズを使用することで、独自のベストプラクティスに照らしてワークロードを測定できる

AWS Trusted Advisor と AWS Service Catalog AppRegistry を統合することで、AWS Well-Architected Tool のレビューに関する質問に回答するために必要な情報をより簡単に見つけることができます。

AWS Trusted AdvisorとAWS Service Catalog AppRegistry を統合することで、AWS Well-Architected Tool のレビューに関する質問に回答するために必要な情報をより簡単に見つけることできる

このサービスは、最高技術責任者 (CTO)、アーキテクト、デベロッパー、運用チームのメンバーなど、技術的な製品開発に携わる方を対象としています。AWS のお客様は、アーキテクチャの文書化、製品起動のガバナンス、テクノロジーポートフォリオのリスクの把握と管理のために AWS WA Tool を利用しています。