【AWS解説 基本編 #5】Well-Architectedフレームワーク入門
前回までは、クラウドとオンプレミスの違い、AWSサービスの組み合わせ、リージョンとAZ、責任共有モデルについて整理してきました。
前回までの記事はこちらです。
- 【AWS解説 基本編 #1】AWSとは？クラウドとオンプレミスの違いを整理
- 【AWS解説 基本編 #2】AWSは「サービス」を組み合わせて使う
- 【AWS解説 基本編 #3】リージョンとAZ、マルチAZの違い
- 【AWS解説 基本編 #4】責任共有モデル入門
AWSサービスを組み合わせてシステムを作れるようになると、次に気になるのが設計の良し悪しです。
セキュリティ対策は足りているか
障害が起きても復旧できるか
必要な性能を出せているか
無駄なコストは発生していないか
このような観点をAWSが整理したものが、AWS Well-Architectedフレームワークです。
この記事では、詳細なチェック項目ではなく、Well-Architectedフレームワークを構成する「6つの柱」が何を意味するのかを、初学者向けに整理します。
Well-Architectedフレームワークとは
Well-Architectedフレームワークは、AWS上のシステムを設計・構築・運用し、継続的に改善していくためのベストプラクティスをまとめた枠組みです。
ただし、
このAWSサービスを使えば、必ず正しい構成になる
という単一の正解を示すものではありません。
現在の構成を複数の視点から確認し、設計上のリスクや改善点を見つけるための観点集に近いものです。
Well-Architectedフレームワークは、次の6つの柱で構成されています。
| 柱 | 初学者向けの捉え方 |
|---|---|
| オペレーショナルエクセレンス | 運用を見える化し、継続的に改善できるか |
| セキュリティ | データ、システム、アカウントを守れているか |
| 信頼性 | 必要な機能を安定して提供し、障害から復旧できるか |
| パフォーマンス効率 | 目的に合ったリソースで、必要な性能を効率よく出せるか |
| コスト最適化 | 支出を把握し、目的や価値に見合う使い方ができているか |
| 持続可能性 | 必要な成果を、より少ない資源と環境負荷で実現できるか |
6つの柱に沿って構成を確認することで、特定の観点だけに偏らず、改善すべき点を見つけやすくなります。
オペレーショナルエクセレンス
オペレーショナルエクセレンスは、システムを運用しやすくし、運用を通じて継続的に改善するための柱です。
たとえば、次のような点を考えます。
- システムの状態をログやメトリクスで確認できるか
- 構成変更や作業手順を記録できているか
- 問題発生時の対応や復旧手順を用意しているか
- 運用で得た情報を次の改善につなげられるか
学習環境でも、エラー内容と解決方法を記録する、作成・削除手順を残すといった行動が、この柱につながります。
CloudFormationなどを使って構成をコード化し、同じ環境を再現しやすくすることも、運用を改善する方法の一つです。
セキュリティ
セキュリティは、データ、システム、アカウントなどを守るための柱です。
前回説明した責任共有モデルとも強く関係します。
AWSがデータセンターや物理サーバーなどの基盤を管理していても、利用者は次のような項目を適切に設計・管理する必要があります。
- IAMユーザーやIAMロールの権限
- パスワードやMFA
- データの公開範囲
- セキュリティグループ
- データの暗号化
- アクセスキー
- アプリケーションの脆弱性
たとえばS3では、物理ディスクの管理はAWS側の責任です。一方で、誰がバケットへアクセスできるか、外部へ公開するかといった設定は利用者側が管理します。
信頼性
信頼性は、システムが必要な機能を安定して提供し、障害が発生した場合にも復旧できるようにするための柱です。
代表的な観点には、次のようなものがあります。
- 複数のAZを利用しているか
- データをバックアップしているか
- 障害を検知できるか
- 必要な時間内に復旧できるか
- アクセス数などの需要変化に対応できるか
基本編 #3で説明したマルチAZも、この柱と関係します。
信頼性は、「絶対に止まらないシステムを作る」という意味ではありません。問題が起きる可能性を考えたうえで、影響を抑え、復旧できる設計にすることが重要です。
パフォーマンス効率
パフォーマンス効率は、必要な性能を満たすために、適切なサービスやリソースを選べているかを確認する柱です。
たとえば、次のような点を考えます。
- 処理内容に合ったAWSサービスを選べているか
- 適切なインスタンスタイプを選べているか
- 需要に応じてリソースを増減できるか
- キャッシュを使って処理を効率化できるか
重要なのは、単純に最も性能の高いリソースを選ぶことではありません。
必要な性能を、目的に合った方法で効率よく提供できるか
を考えることが、この柱の中心です。
コスト最適化
コスト最適化は、AWSに支払っている費用を把握し、目的や得られる価値に見合った使い方ができているかを確認する柱です。
単純に費用を最小にすることだけが目的ではありません。コストを下げた結果、必要な性能や信頼性を失ってしまえば、適切な設計とはいえない場合があります。
代表的な観点は次のとおりです。
- 不要なリソースが残っていないか
- 使用していないEC2を起動し続けていないか
- 必要以上のスペックを選んでいないか
- 現在の利用料金を把握できているか
- 費用に対して十分な価値を得られているか
個人の学習環境でも、AWS Budgetsで予算を設定する、定期的に料金を確認する、学習後に不要なリソースを削除するといった対策が重要です。
パフォーマンス効率が「必要な性能をどう提供するか」を考えるのに対し、コスト最適化では「その構成に支払う費用が価値に見合っているか」を考えます。
持続可能性
持続可能性は、システムの稼働による環境への影響を減らすための柱です。
必要以上のリソースを使用せず、少ない資源で必要な成果を得ることを考えます。
- 不要なリソースを常時動かしていないか
- リソースの利用率を高められないか
- 不要なデータや処理を減らせないか
- データ転送や保存方法を効率化できないか
コスト最適化と重なる取り組みもありますが、持続可能性では費用だけではなく、主にエネルギー消費や環境負荷の削減という観点から考えます。
6つの柱は互いに関係する
6つの柱は、完全に独立しているわけではありません。
たとえば、EC2インスタンスを小さくするとコストは下がるかもしれませんが、性能不足になる可能性があります。反対に、障害対策としてリソースを増やすと信頼性は高まりますが、コストや使用する資源も増加します。
そのため、特定の柱だけを最大化するのではなく、システムの目的や要件に応じたバランスを考えることが大切です。
小さなWebサイトで考える
たとえば、S3とCloudFrontを使って静的Webサイトを公開する場合でも、6つの柱から構成を確認できます。
| 柱 | 確認例 |
|---|---|
| オペレーショナルエクセレンス | デプロイや変更手順を再現できるか |
| セキュリティ | S3を直接公開せず、IAM権限を絞っているか |
| 信頼性 | 誤削除やデプロイ失敗から復旧できるか |
| パフォーマンス効率 | CloudFrontのキャッシュを活用できているか |
| コスト最適化 | 不要なファイルやログを残していないか |
| 持続可能性 | 不要な保存やデータ転送を減らせているか |
Well-Architectedフレームワークは、大規模な業務システムだけに使うものではありません。小さな学習用の構成でも、設計を振り返るための視点として活用できます。
これまでの基本編とのつながり
Well-Architectedフレームワークは、これまで説明してきた内容と別のものではありません。
- 責任共有モデルは、セキュリティの柱を考える前提になる
- リージョン、AZ、マルチAZは、信頼性の柱と関係する
- AWSサービスの選び方は、パフォーマンス効率やコスト最適化に影響する
- CloudFormationによる構成管理は、オペレーショナルエクセレンスにつながる
最初から、6つの柱に関するすべてのベストプラクティスを実装する必要はありません。
まずは6つの柱を一通り確認し、
現在の構成には、どのようなリスクや改善点があるのか
を知ることが大切です。そのうえで、目的、リスク、予算などに応じて、改善の優先順位を決めていきます。
つまずきやすいポイント
ベストプラクティスをすべて一度に実装しようとする
学習用の小さな構成に、本番向けの対策をすべて実装しようとすると、構築そのものが進まなくなる可能性があります。
まずは6つの柱を一通り確認し、現在のリスクを把握したうえで、優先度の高いものから改善します。
「AWSが推奨している構成が唯一の正解」と考える
Well-Architectedフレームワークは、特定の構成をコピーするための完成図ではありません。
適切な構成は、システムの目的、利用者数、予算、必要な可用性、運用体制などによって変わります。
フレームワークは、構成を比較・検討するための地図と考えると分かりやすいです。
一度確認したら終わりだと思う
システムの利用状況や要件は、時間とともに変化します。
最初は問題のなかった構成でも、利用者数の増加や機能追加によって、性能、コスト、運用方法などを見直す必要が出てきます。
Well-Architectedフレームワークは、設計時に一度だけ確認するものではなく、継続的な改善に使う枠組みです。
まとめ
Well-Architectedフレームワークは、AWS上のシステムを複数の視点から振り返り、設計上のリスクや改善点を見つけるための枠組みです。
次の6つの柱で構成されています。
- オペレーショナルエクセレンス
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
初学者は、各柱の正式な定義や、すべてのベストプラクティスを最初から暗記する必要はありません。
まずは、
セキュリティに問題はないか
障害から復旧できるか
必要な性能を出せているか
コストは目的に見合っているか
と、自分の構成に問いかけられるようになることが大切です。
詳細なベストプラクティスや最新の説明については、AWS公式のWell-Architectedドキュメントを参照してください。
次回は、基本編の締めとして、典型的なAWS構成パターンの見方を整理します。