AWS Well-Architectedフレームワークとは ― 6つの柱
Well-Architected
AWS Well-Architectedフレームワークとは、AWSで設計・運用するときのベストプラクティス集
AWS Well-Architectedフレームワークは、AWSで作ったシステムがよい設計になっているかを点検するときの基準です。AWSでシステムを設計し運用するときの考え方を、6つの柱に分けてまとめています。AWS公式ドキュメントは、設計と運用のベストプラクティスを学ぶためのものと説明しています。ベストプラクティスとは、実績に基づく最善のやり方のことです。目指すのは、信頼性・安全性・効率・費用対効果・持続可能性を備えたシステムです。
AWSで構築するときの判断について、長所と短所を理解するのにも役立ちます。構成を点検するレビューは監査ではなく、設計の判断について話し合う場とされています。想定する読者は、CTO・アーキテクト・開発者・運用担当などです。
6つの柱は、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性
AWS公式ドキュメントは、設計で見るべき観点を6つの柱として挙げています。柱の名前は、公式ドキュメントの日本語版の表記に合わせています。AWSの日本語の紹介ページでは、運用上の優秀性をオペレーショナルエクセレンスと書いています。表の右の列は、公式の説明を言い換えたものです。
| 柱 | 英語名 | 問う |
|---|---|---|
| 運用上の優秀性 | Operational excellence | 良い顧客体験を届け続けながら、ソフトウェアを正しく作るための取り組みです。チームの編成、ワークロードの設計、大規模な運用、継続的な改善のベストプラクティスを含みます。 |
| セキュリティ | Security | データ・システム・資産を保護する能力です。クラウドの技術を活用して、セキュリティを高めることを狙います。 |
| 信頼性 | Reliability | ワークロードが、求められるときに意図した機能を正しく一貫して実行できる能力です。ライフサイクル全体を通じて、運用とテストを行う能力を含みます。 |
| パフォーマンス効率 | Performance efficiency | 性能の要件を満たすように、クラウドのリソースを効率よく使う能力です。需要や技術が変わっても、その効率を保つことを含みます。 |
| コスト最適化 | Cost optimization | ビジネスの価値を、最も低い価格で届けられるようにシステムを動かす能力です。 |
| 持続可能性 | Sustainability | 環境への影響、とくにエネルギーの消費と効率に注目します。エネルギーの消費と効率は、設計者がリソースの使用量を減らす行動を決める手がかりになります。 |
公式ドキュメントは、柱のどれかを疎かにすると、要件どおりに動くシステムを作るのが難しくなると説明しています。柱を設計に組み込めば、システムは安定し、効率もよくなります。その分、機能要件など、設計のほかの面に集中できます。
混同しやすい柱は、問う対象で見分ける
運用上の優秀性と信頼性は、問う対象が違います。運用上の優秀性は、チームの編成・設計・運用・改善の進め方を問います。信頼性は、ワークロードが求められるときに正しく動き続ける能力を問います。ワークロードとは、1つの業務を動かすアプリとリソースのまとまりです。
パフォーマンス効率とコスト最適化は、どちらもリソースの使い方に関わる柱です。パフォーマンス効率は、性能の要件を満たせているかを問います。コスト最適化は、最も低い価格でビジネスの価値を届けられているかを問います。
セキュリティは、データ・システム・資産を保護する能力を問います。持続可能性は、エネルギーの消費と効率を中心に、環境への影響を問います。
柱の間では、ワークロードに応じてトレードオフする
6つの柱は、どのシステムでも同じ比重で満たすものではありません。AWS公式ドキュメントは、ビジネスの状況に応じて柱の間でトレードオフを行うと説明しています。トレードオフとは、何かを優先するために別の何かをある程度あきらめることです。公式の例は、開発環境とミッションクリティカルなシステムです。ミッションクリティカルとは、止まると業務に重大な影響が出ることを指します。
開発環境では、信頼性を犠牲にして、コストや持続可能性への影響を抑えることがあります。ミッションクリティカルなシステムでは、コストと持続可能性への影響が増えても、信頼性を優先することがあります。一方、セキュリティと運用上の優秀性は、ほかの柱のために犠牲にしないのが通常です。
動かして確かめる:柱を選ぶと、設計の問いと関連記事が出る
柱を選ぶと、その柱の定義と、設計のときに確かめる問いが表示されます。その柱に関係するこのサイトの記事も並びます。
運用上の優秀性(Operational excellence)良い顧客体験を届け続けながら、ソフトウェアを正しく作るための取り組みです。チームの編成、ワークロードの設計、大規模な運用、継続的な改善のベストプラクティスを含みます。
設計のときの問い:障害や変更が起きたとき、手順は自動化され、人の手作業を減らせているか。
セキュリティ(Security)データ・システム・資産を保護する能力です。クラウドの技術を活用して、セキュリティを高めることを狙います。
設計のときの問い:誰に、どのリソースへの、どこまでの権限を与えているか。守る範囲のうち、自分の担当はどこか。
信頼性(Reliability)ワークロードが、求められるときに意図した機能を正しく一貫して実行できる能力です。ライフサイクル全体を通じて、運用とテストを行う能力を含みます。
設計のときの問い:1台のサーバや1つのAZが止まっても、サービスは続くか。
- リージョンとAZ複数のAZに分けて置けば、1つのAZの障害がワークロード全体に及ぼす影響を減らせます。公式の設計原則:水平方向にスケールして総合的なワークロードの可用性を高める
- ELBとAuto ScalingAuto Scalingが需要を監視し、インスタンスの追加と削除を自動で行います。公式の設計原則:容量を推測しない
- RDSマルチAZ配置では、プライマリに障害が起きると、別のAZのスタンバイへ自動で切り替わります。公式の設計原則:障害から自動的に復旧する
パフォーマンス効率(Performance efficiency)性能の要件を満たすように、クラウドのリソースを効率よく使う能力です。需要や技術が変わっても、その効率を保つことを含みます。
設計のときの問い:利用者の近くで、必要な処理能力に見合った形で動いているか。
コスト最適化(Cost optimization)ビジネスの価値を、最も低い価格で届けられるようにシステムを動かす能力です。
設計のときの問い:使っていない分まで、料金を払っていないか。
- 料金の考え方使った分だけ支払う従量課金が、料金の基本です。公式の設計原則:消費モデルを導入する
- ELBとAuto ScalingAuto Scalingで、使用量に応じて台数を増減できます。公式の設計原則:消費モデルを導入する
- Lambda料金は、リクエスト数と実行時間で決まります。公式の設計原則:消費モデルを導入する
- RDSOSやデータベースソフトの管理を、AWSに任せられます。公式の設計原則:差別化につながらない手間のかかる作業にコストをかけるのをやめる
持続可能性(Sustainability)環境への影響、とくにエネルギーの消費と効率に注目します。エネルギーの消費と効率は、設計者がリソースの使用量を減らす行動を決める手がかりになります。
設計のときの問い:使われないリソースを、持ち続けていないか。
- ELBとAuto Scaling公式の原則は、需要に合わせて容量を調整する例に、EC2のAuto Scalingを挙げています。公式の設計原則:マネージドサービスを使用する
- S3公式の原則は、あまり使われないデータをコールドストレージへ自動で移す例に、S3のライフサイクル設定を挙げています。公式の設計原則:マネージドサービスを使用する
記事と柱の対応は、各記事の内容を公式の設計原則の見出しに照らして、このサイトが結びつけたものです。AWSがその記事を柱に割り当てているわけではありません。
問いは、公式の設計原則をもとに、このサイトで短くまとめたものです。原則の全文は、AWS公式ドキュメントの各柱のページにあります。
既存のAWS記事は、複数の柱にまたがる
1つのサービスや考え方が、1つの柱だけに収まることはあまりありません。このサイトのAWS記事を、公式の設計原則に照らして柱ごとに分けると、次のようになります。この対応はこのサイトが整理したもので、AWSが定めたものではありません。
責任共有モデルは、セキュリティの柱の資料にも節が設けられています。AWSの料金の考え方は、コスト最適化の柱と関わります。IAMの記事の最小権限の原則は、セキュリティの柱の原則「強力なアイデンティティ基盤を実装する」に含まれています。
ELBとAuto Scalingは、信頼性・コスト最適化・持続可能性の3つの柱に関わります。需要に合わせて台数を増減する仕組みは、柱によって使う理由が異なります。信頼性では、需要が容量を超えるのを防ぎます。コスト最適化では、使った分だけ払います。持続可能性では、使われない容量を減らします。
信頼性は、可用性とSLAの記事で説明した稼働率の考え方とも関係します。複数のAZに分けて置く設計は、リージョンとAZの記事で説明した内容です。
AWS Well-Architected Toolは、フレームワークで構成を確かめるサービス
AWS Well-Architected Toolは、クラウド上のサービスです。自分のワークロードのアーキテクチャを、フレームワークに沿ってレビューし、測定します。アーキテクチャとは、システムの構成のことです。AWS公式ドキュメントは、このツールを、ワークロードを無料でレビューできるサービスとして紹介しています。今の構成をコスト最適化やセキュリティなどの観点で自動点検する仕組みには、Trusted Advisorがあります。
参考にした資料
- AWS「AWS Well-Architected フレームワーク」(発行日2024年11月6日。フレームワークの位置づけ、AWS Well-Architected Tool)
- AWS「フレームワークの柱」(6つの柱の名称)
- AWS「定義」(柱の間のトレードオフ)
- AWS「AWS Well-Architected」(日本語の紹介ページ。オペレーショナルエクセレンスの表記)
- AWS「The pillars of the framework」(英語版)と各柱のページ(柱の定義と設計原則)
- AWS「Security Pillar:Shared responsibility」(セキュリティの柱の資料にある責任共有の節)
練習問題(全5問)
正解:AWSで
AWS公式ドキュメントは、
正解:拡張性
6つの
正解:信頼性
信頼性の
正解:コスト最適化
コスト最適化の
正解:フレームワークを
AWS公式ドキュメントに
選んでから「採点する」を押すと、解説つきで答え合わせができます。