AWS Well-Architected Frameworkに「持続可能性」の柱が増えた話

はじめまして、kubotaです。

AWS Well-Architected Frameworkに6番目の柱、「持続可能性」が追加されましたのでご紹介します。

目次

• AWS Well-Architected Frameworkとは
• 持続可能性の柱
• まとめ

AWS Well-Architected Frameworkとは

そもそも、Well-Architected Frameworkとは何ぞや？という方もいらっしゃるかと思いますので、
Well-Architected Frameworkの簡単な解説から始めたいと思います。

まず、AWS公式の説明を引用してみます。

AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。
AWS Well-Architected Framework には、ドメイン固有のレンズやハンズオンラボ、そして AWS Well-Architected Tool が含まれています。追加コストなしで AWS マネジメントコンソールで利用できる AWS Well-Architected Tool は、ワークロードの定期的な評価、リスクの高い問題の識別、向上の記録を行うメカニズムを提供します。

引用元 : https://aws.amazon.com/jp/architecture/well-architected/

噛み砕きますと、Well-Architected Frameworkとは「AWS内に蓄積されたシステム構築に関するベストプラクティス集」になります。

Well-Architected Frameworkと比較することによって、構築されたシステムがAWSのベストプラクティスにどれだけ沿っているか、検証することが可能です。

Frameworkの内容は文書(ホワイトペーパー)として公開されていますが、相当な分量があり、それを読み込んだうえで、実際のシステム構成と比較検証・・・というのはかなり難易度が高いため、AWSから「AWS Well-Architected Tool」という補助用のサービスもAWSより提供されています。

ツールではベストプラクティスが質問形式で収録されており、各質問にYes/Noで回答していくことで、ベストプラクティスとの比較が可能になっています。

Well-Architected Frameworkについては下記の弊社コラムでも詳しく解説しておりますので、もし興味のある方はご一読ください。
https://www.skyarch.net/column/aws-well-architected/

持続可能性の柱について

Well-Architected Frameworkは従来、「優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化」の5本柱を軸に構成されていました。
その後2021年末に「持続可能性」が新たに追加され、全部で6本柱となりました。

AWS公式では下記のような設計原則が紹介されていました。

• 影響を把握する — ビジネス上の成果と関連するサステナビリティへの影響を測定して、パフォーマンス指標を確立し、改善を評価し、提案された変更が経時的に与える影響を推定します。
• サステナビリティ目標の設定 — ワークロードごとに長期的な目標を設定し、投資収益率 (ROI) をモデル化し、サステナビリティ目標に投資するリソースを所有者に提供します。ユーザーごと、オペレーションごとなど、作業当たりの影響を軽減するために、拡大を計画し、アーキテクチャを設計します。
• 使用率の最大化 — 各ワークロードのサイズを適切に調整して、基盤となるハードウェアのエネルギー効率を最大化し、アイドル状態のリソースを最小限に抑えます。
• より効率的な新しいハードウェアとソフトウェアの提供を予測して採用する — パートナーによるアップストリームの改善をサポートし、ハードウェアとソフトウェアの選択の効率性を継続的に評価し、新しいテクノロジーを長期にわたって採用できる柔軟性を考慮して設計します。
• マネージドサービスの使用 — 共有サービスは、幅広いワークロードをサポートするために必要なインフラストラクチャの量を削減します。マネージドサービスを活用することで、アクセス頻度の低いデータをコールドストレージに移動したり、コンピューティング性能を調整したりするなど、影響を最小限に抑え、サステナビリティのベストプラクティスを自動化できます。
• クラウドワークロードのダウンストリームの影響を軽減 — サービスの使用に必要なエネルギーやリソースの量を削減し、お客様がデバイスをアップグレードする必要性を減らします。また、デバイスファームを使用したテストで影響を測定し、お客様と直接テストして、それらへの実際の影響を把握します。

引用: https://aws.amazon.com/jp/blogs/news/sustainability-pillar-well-architected-framework/

上記の設計原則が落とし込まれた、具体的なベストプラクティスの例も紹介されていました。

• ユーザーの所在地に合わせて、ワークロードの地理的配置を最適化
• 時間やリソースを最も多く消費するコード領域を最適化
• お客様のデバイスや機器への影響を最適化
• データ分類ポリシーを実装
• ライフサイクルポリシーを使用して不要なデータを削除
• ネットワーク間でのデータ移動を最小化
• GPU の使用を最適化
• 潜在的なサステナビリティの改善を迅速に導入できる開発方法とテスト方法を採用
• ビルド環境の使用率を向上

引用: https://aws.amazon.com/jp/blogs/news/sustainability-pillar-well-architected-framework/

持続可能性ということで、主にエネルギー削減や効率化に重点が置かれているようです。
既存の5本柱と重複していそうな項目もありますが、「GPUの使用を最適化」あたりは目新しい項目かと思います。
単にエネルギー削減や効率化というだけではなく、コスト削減にもつながりそうです。

ちなみにフレームワークの柱には「トレードオフ」という概念があります。
あちらを立てればこちらが立たぬ・・・ということで全てを最適化することは不可能なため、柱の間で優先順位を付けなくてはなりません。例えば、信頼性を犠牲にしてコスト効率を向上させる、などですね。
(なお、運用上の優秀性とセキュリティに関してはその他の柱とのトレードオフは通常発生しません)

「持続可能性」も他の柱とのトレードオフが発生するようです。
ホワイトペーパーには「可用性の要件を緩和することで、インスタンスの使用率を向上させる」などの例が紹介されていました。

まとめ

AWS Well-Architected Frameworkに新しく追加された柱、「持続可能性」をご紹介しました。
SDGsに取り組む企業は年々増えておりますので、今後開発・構築を行っていくうえで、エネルギー効率などを重視した、”サステナブル”なシステムが求められる可能性は十分考えられます。
中には実施が難しそうなベストプラクティスもありますが、比較的容易そうなものから少しずつ取り入れていきたいと思います。