[新要素]サステナビリティ(持続可能性)が6本目の柱としてAWS Well-Architectedフレームワークに追加されました #reinvent

こんにちは、臼田です。

みなさん、re:Inventエキサイトしてますか！？(挨拶

re:Invent 2021でAWS Well-Architectedフレームワークの新しい柱としてサステナビリティ(持続可能性)の柱が登場しました。

New Sustainability Pillar for the AWS Well-Architected Framework

概要

AWS Well-ArchitectedフレームワークはAWSのベストプラクティス集です。長らく5つの柱(運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コストの最適化)を軸にやってきました。

今回ついに新しい柱としてSustainability Pillar(サステナビリティ/持続可能性の柱)が追加されました。AWS Well-Architectedの公式サイトでは以下のように概要説明されています。

持続可能性の柱は、実行中のクラウドワークロードによる環境への影響を最小限に抑えることに重点を置いています。重要なトピックには、持続可能性の共有責任モデル、影響の理解、および必要なリソースを最小化し、ダウンストリームの影響を減らすための使用率の最大化が含まれます。

AWSを含むAmazonとして2019年にThe Climate Pledgeを発表し、パリ協定よりも10年早く、2040年までに炭素排出量を実質ゼロ化を達成することに誓約しています。

このサステナビリティの柱の追加はその流れもあるでしょうが、対象はAWS自体ではなくAWSを利用するユーザーがこれに賛同し、自身がサステナビリティへの取り組みを行っていくために参照できるベストプラクティスという位置づけです。

単純にコストを抑えることとは違う目的であるため、新しい柱となったのではと考えます。

柱の位置づけ

通常Well-Architectedに基づいて設計を行っていく場合、柱の間でトレードオフを行います。これはワークロードの特性やビジネスコンテキストに基づいて判断をしていきます。セキュリティとオペレーショナルエクセレンスは、通常、他の柱とトレードオフされません。

今回の追加に伴い以下のように表現が追加されていました。

持続可能性への影響を改善しコストを削減するために開発環境の信頼性を犠牲にすることもあります。逆にミッションクリティカルなソリューションの場合、コストと持続可能性への影響を増やして信頼性を最適化することができます。

AWS Well-Architected Framework - AWS Well-Architected Framework

サステナビリティの柱の内容

Well-Architectedフレームワークの各柱は設計原則・定義・質問とベストプラクティスで構成されています。詳細は以下を確認していただくと非常に読みやすいのでオススメです。

設計原則

6つの設計原則があります。

• 自身の影響を理解する
  • クラウドワークロードの影響を測定し、ワークロードの将来の影響をモデル化する
• 持続可能性の目標を設定する
  • クラウドワークロードごとに、トランザクションごとに必要なコンピューティングリソースとストレージリソースの削減など、長期的な持続可能性の目標を設定する
• 使用率の最大化
  • 高い使用率を確保し、基盤となるハードウェアのエネルギー効率を最大化する
  • 30％の使用率で実行されている2つのホストは、60％で実行されている1つのホストよりも効率が低くなる
• より効率的な新しいハードウェアやソフトウェアの提供を予測し、採用する
  • より効率的な新しいハードウェアおよびソフトウェア製品を継続的に監視および評価する
• マネージドサービスを使用する
  • 幅広い顧客ベースでサービスを共有することで、リソースの使用率を最大化する
  • たとえば、AWS Fargateを採用することで、電力やネットワークなどの一般的なデータセンターコンポーネントの影響を共有できる
• クラウドワークロードのダウンストリームへの影響を減らす
  • サービスの使用に必要なエネルギーまたはリソースの量を減らす

定義

6つの定義があります。

各項目に基づいた質問とベストプラクティスがあります。

質問とベストプラクティス

• SUS 1：持続可能性の目標をサポートするためにどのように地域を選択しますか？
  • Amazonの再生可能エネルギープロジェクトに近い地域と、グリッドの公開炭素強度が他の場所（または地域）よりも低い地域を選択します。
• SUS 2：持続可能性の目標をサポートするために、ユーザーの行動パターンをどのように活用しますか？
  • ユーザーがワークロードやその他のリソースを消費する方法は、持続可能性の目標を達成するための改善点を特定するのに役立ちます。ユーザーの負荷に継続的に一致するようにインフラストラクチャを拡張し、ユーザーをサポートするために必要な最小限のリソースのみが展開されるようにします。サービスレベルを顧客のニーズに合わせます。リソースを配置して、ユーザーがリソースを消費するために必要なネットワークを制限します。既存の未使用のアセットを削除します。未使用の作成済みアセットを特定し、それらの生成を停止します。
• SUS 3：持続可能性の目標をサポートするために、ソフトウェアとアーキテクチャのパターンをどのように活用しますか？
  • 負荷の平滑化を実行し、デプロイされたリソースの一貫した高い使用率を維持して、消費されるリソースを最小限に抑えるためのパターンを実装します。時間の経過とともにユーザーの動作が変化するため、コンポーネントが使用されなくなるとアイドル状態になる可能性があります。パターンとアーキテクチャを改訂して、十分に活用されていないコンポーネントを統合し、全体的な利用率を高めます。不要になったコンポーネントを廃止します。ワークロードコンポーネントのパフォーマンスを理解し、最も多くのリソースを消費するコンポーネントを最適化します。
• SUS 4：持続可能性の目標をサポートするために、データアクセスと使用パターンをどのように活用しますか？
  • データ管理手法を実装して、ワークロードをサポートするために必要なプロビジョニングされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とその使用方法を最もよくサポートするストレージテクノロジーと構成を使用します。要件が減少した場合は、データをより効率的でパフォーマンスの低いストレージにライフサイクルし、不要になったデータを削除します。
• SUS 5：ハードウェアの管理と使用方法は持続可能性の目標をどのようにサポートしていますか？
  • ハードウェア管理方法を変更することにより、ワークロードの持続可能性への影響を減らす機会を探します。プロビジョニングと展開に必要なハードウェアの量を最小限に抑え、個々のワークロードに最も効率的なハードウェアを選択します。
• SUS 6：開発および展開プロセスは持続可能性の目標をどのようにサポートしますか？
  • 開発、テスト、および展開のプラクティスに変更を加えることで、持続可能性への影響を減らす機会を探します。

各ベストプラクティスに対する詳細はサステナビリティの柱の詳細ページもご確認ください。

私的な注目ポイント

以下ハードウェアについてのペストプラクティスではGPU利用の最適化がありました。不要なマイニングはだめだぞ！

Optimize your use of GPUs - Sustainability Pillar

おまけ: AWS Customer Carbon Footprint Tool

サステナビリティの文脈でAWS Customer Carbon Footprint Toolというものも提供されることが予告されました。サステナビリティの実現状況がより可視化できそうな雰囲気ですね。

まとめ

AWS Well-Architectedフレームワークに新しく追加された6本目の柱であるサステナビリティの柱を紹介しました。

これまでと少し毛色の違う柱です。トレードオフを意識しつつ、ベストプラクティスを活用しましょう！