👀概要
パーソルホールディングス デジタル開発部 テクニカルアライアンス室 でSREをしている
古田です。
今回は、所属部署で定期開催している社内勉強会で過去に取り上げた、
AWS Well-Architected フレームワークの概要について内容をご紹介します。
できるだけわかりやすくまとめるよう心がけました。
みなさまの学習の一助となれば幸いです。
👨👩👧👦対象者(Who)
- AWS Well-Architected フレームワークを知らない方
- AWS Well-Architected フレームワークの概要・構成・特徴を知りたい方
📌関連リンク
- 公式ドキュメント : AWS
- 公式ドキュメント : AWS以外
🗒️目次
- 背景
- AWS Well-Architected フレームワークとは
- 何か
- なぜ必要か
- 概要紹介
- ドキュメント構成
- 一般的な設計原則
- フレームワークの柱
- 3大クラウド比較
- 共通点
- 相違点
- サポート
- AWS Well-Architected Tool
- AWS Well-Architected ラボ
📝 内容
背景
私たちの組織で開発するプロダクトは、基本的にAWSを利用しています。
AWSのクラウド利用においては、過去の経験や実績から導き出された最も効率的で効果的な方法(ベストプラクティス)がフレームワークとしてまとめられています。
このフレームワークを理解して利用方法の現状評価をすることは、今後もAWSを継続活用するにあたっての有効な手段だと考えたので、チームで知識を深めることにしました。
AWS Well-Architected フレームワークとは
公式ドキュメントを読み、私たちは次のように考えています。
何か
AWS Well-Architected フレームワークとは、以下を提供するもの
- アーキテクチャの設計原則
- 設計原則を実現するためのベストプラクティス
- ベストプラクティスに適合しているかの質問
なぜ必要か
"ベスト" プラクティスなので、このアーキテクチャにしておけば完璧だ！とか、このやり方なら絶対に間違いない！といった、唯一無二の手法が示されているように感じるが、
そうではない。
アーキテクチャは多様であり、何を重視するかはケースバイケースで変わり、
トレードオフの関係がある。
だから、個別のケースにおける "ベスト" を目指すため に存在している。
概要紹介
ドキュメント構成
下図のようになっています。
一般的な設計原則
クラウドでの適切な設計を可能にする汎用的な原則がまとめられています。
| 設計原則 | 説明 |
|---|---|
| 容量ニーズの推測が不要 | 自動的にスケールイン／スケールアウトするので、容量過不足の問題がない |
| 本稼働スケールでシステムをテストする | 本稼働規模のテスト環境を作成 → テストが完了したらリソースを削除、を少ないコストで素早くできる |
| アーキテクチャの実験を念頭に置いた自動化 | ワークロードの作成や複製を手作業で行う必要がなく、検証や実験を行いやすい |
| 発展するアーキテクチャを検討する | ビジネス要件に合わせた柔軟なシステム構成変更がしやすい |
| データに基づいてアーキテクチャを駆動する | ワークロードの動作データが収集できるので、事実に基づいたアーキテクチャの改善ができる |
| ゲームデーを利用して改善する | ゲームデー(障害訓練のような演習)を定期的に行い、アーキテクチャをテストすることで、組織に知見と経験を蓄える |
フレームワークの柱
トレードオフの要素は、6つの「柱」として定義されています。
2021年に持続可能性(サステナビリティ)が追加され、従来の5つから増えました。
<柱の説明と各項目数>
| 柱 | 説明 | 設計原則 | 領域 | 質問 |
|---|---|---|---|---|
| オペレーショナルエクセレンス (運用上の優秀性) |
優れたカスタマーエクスペリエンスを着実に提供しながら、ソフトウェアを正しく構築する取り組み | 8 | 4 | 11 |
| セキュリティ | データ、システム、資産を保護し、クラウドテクノロジーを活用してセキュリティを強化する能力 | 7 | 7 | 11 |
| 信頼性 | 意図した機能を期待どおりに、正しく、一貫して実行するワークロードの能力 | 5 | 4 | 13 |
| パフォーマンス 効率 |
クラウドリソースを効率的に使用してパフォーマンス要件を満たし、需要の変化や技術の進歩に合わせてこの効率性を維持する能力 | 5 | 5 | 5 |
| コスト最適化 | 最低価格でビジネス価値を実現するシステムを実行できる能力 | 5 | 5 | 11 |
| 持続可能性 (サステナビリティ) |
環境に対する影響、特にエネルギーの消費と効率性 | 6 | 6 | 6 |
3大クラウド比較
Well-Architected フレームワークは、AzureやGCPでも提供されています。
共通点
- フレームワーク名称が同じ。英語で「Well-Architected Framework」
- どのクラウドも「柱」の名称を使っている
- どのクラウドも中心となる柱は同じ
- ただし持続可能性の柱は位置づけに多少の違いがある
<柱の名称>
| 柱 | AWS | Azure | GCP |
|---|---|---|---|
| 運用 | オペレーショナル エクセレンス (運用上の優秀性) |
オペレーショナル エクセレンス |
オペレーショナル エクセレンス |
| セキュリティ | セキュリティ | セキュリティ | セキュリティ、 プライバシー、 コンプライアンス |
| 信頼性 | 信頼性 | 信頼性 | 信頼性 |
| パフォーマンス | パフォーマンス 効率 |
パフォーマンス 効率 |
パフォーマンスの 最適化 |
| コスト | コスト最適化 | コストの最適化 | 費用の最適化 |
| 持続可能性 | 持続可能性 (サステナビリティ) |
(なし) ※ | (なし) ※ |
※ 「柱」としては定義されていない
- Azure
- 「持続可能性ワークロード」として別のドキュメントに設計原則や考慮事項がまとめられている
- GCP
- Well-Architected Framework ドキュメント内に「サステナビリティ」のページがある
相違点
Azure
- 柱の中の要素として「設計原則」「チェックリスト」「トレードオフ」などがある
- 柱の次のレイヤーとして「ワークロード」「サービスガイド」などがある
GCP
- 柱の他に 視点(ビュー) が存在する
- AI(人工知能)、ML(機械学習)、FSI(金融サービス業界)
サポート
AWS Well-Architected フレームワークをさらに理解し、適用をサポートするツールが提供されています。
-
AWS Well-Architected Tool
- ワークロードの状態をベストプラクティスと比較・レビューできる
- 無料で利用できる
- AWSマネジメントコンソール上からアクセスできる
- 測定対象となるワークロードを定義 → レビューを開始 → 柱ごとの質問に回答 → 測定結果が示される
-
AWS Well-Architected Labs
- 6つの柱に沿ったハンズオンが用意されている
- 環境を自前で準備する必要がある
- このためリソース作成で料金が発生する場合がある
まとめ
以上、AWS Well-Architected フレームワークについて概要をご紹介しました。
記事中でも触れたように、アーキテクチャは多様であり、唯一無二の正解がありません。
これからも私たちは、私たちなりの "ベスト" を模索しながら、より良いプロダクトを開発していきます。