AWS Well-Architected フレームワーク持続可能性（サステナビリティ）の柱をマインドマップ化してみた

コンバンハ、千葉（幸）です。

re:Invent 2021 にて、AWS Well-Architected フレームワーク 6 本目の柱としてサステナビリティが発表されました。

サステナビリティの柱のドキュメントは以下から参照できます。

そして、AWS Well-Architected フレームワーク全体のドキュメントの中でも概要が確認できます。（英語版に切り替えてから見てください。）

如何せんこういったドキュメントはボリュームが大きいので、全体像を把握するのがなかなか困難です。読みやすさのためにとりあえずマインドマップの形に落とし込んでみました。

マインドマップ

• 手元でツリーの開閉、拡大・縮小ができます
• 右上のアイコンから全画面表示ができます

右側が縦に長くなり過ぎてしまったのですが、一番下の階層を折り畳むと以下のような構成になります。

AWS Well-Architected フレームワークドキュメントの構成について

このマインドマップは AWS Well-Architected フレームワーク のドキュメントの構成に準じています。ドキュメントは大まかに以下の構成となります。

• 設計原則と定義が冒頭で示される
  • 設計原則はドキュメントのエッセンスを要約したもの
  • 定義は領域（分野とも訳される）と、場合によってはその他の事項が示される
• 各領域では質問とベストプラクティスが記される
• ベストプラクティスでは推奨事項が記される

特定の柱でのドキュメントと、フレームワーク全体のドキュメントで構成は微妙に異なります。以下も参考にしてください。

本マインドマップでは以下のような階層構造にしています。画像に映っていない折り畳まれている最下層は、ベストプラクティスごとの推奨事項です。

AWS Well-Architected フレームワーク サステナビリティの柱

マインドマップからエクスポートした概要を記載します。便宜上、「領域（分野）」に番号を振っています。

文中の文言は基本的に機械翻訳で、明らかに違和感がある部分のみ手動で修正しています。

設計原則

• 自身の影響を理解する
• 持続可能性の目標を設定する
• 使用率の最大化
• 新しい、より効率的なハードウェアとソフトウェアの提供を予測して採用する
• マネージドサービスを利用する
• クラウドワークロードのダウンストリームへの影響を減らす

領域1.地域の選択

• SUS 1：持続可能性の目標をサポートするために どのように地域を選択しますか？
  • アマゾンの再生可能エネルギープロジェクトに近い地域と、グリッドの炭素強度が他の場所（または地域）よりも低い地域を選択

領域2.ユーザーの行動パターン

• SUS 2：持続可能性の目標をサポートするために、 ユーザーの行動パターンをどのように活用しますか？
  • ユーザーの負荷に応じてインフラストラクチャを拡張する
    • 時間の経過に伴う負荷と容量の使用率に対するユーザーの影響を分析し、使用率が低い期間にリソースをスケーリングすることで需要の変化に対応する
    • 予測可能なパターンについてワークロードを評価し、需要の予測および計画された変化を予測するときにプロアクティブにスケーリングする
  • SLAを持続可能性の目標に合わせる
    • ビジネス要件を満たしながら、持続可能性の目標をサポートするSLAを定義する
    • SLAを再定義して、ビジネス要件を超えないよう定義する
    • サービスレベルの許容可能な低下と引き換えに、持続可能性への影響を大幅に削減するトレードオフを行う
    • ビジネスクリティカルな機能を優先し、重要でない機能のサービスレベル（応答時間や回復時間の目標など）を低くできるサーキットブレーカーとデザインパターンを使用する
  • 未使用の資産の作成と保守を排除する
    • 静的アセットを管理し、不要になったアセットを削除する
    • 生成されたアセットを管理し、生成を停止して、不要になったアセットを削除する
    • 重複する生成されたアセットを統合して、冗長な処理を排除する
    • 不要になったアセットの作成と保存を停止するようにサードパーティに指示する
    • 冗長なアセットを統合するようにサードパーティに指示する
  • ユーザーの場所に合わせてワークロードの地理的な配置を最適化する
    • 頻繁に使用されるリソースにはローカルキャッシュを使用する
    • 接続プールを使用して、接続の再利用を可能にし、必要なリソースを削減する
    • エッジキャッシングを使用して、オリジンサーバーからネットワークを通過するデータの量を減らす
    • 地域住民にサービスを提供するために、一貫性を保つための持続的な接続と同期更新に依存しない分散型データストアを使用する
    • あらかじめ用意された静的なネットワーク容量を共有の動的容量に置き換え、ネットワーク容量の持続可能性への影響を他の加入者と共有する
  • 実行されるアクティビティのためにチームメンバーのリソースを最適化する
    • ワークステーションやその他のデバイスを、それらの使用方法に合わせてプロビジョニングする
    • 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードとデバイスの要件を制限する
    • プロセッサまたはメモリを大量に消費するタスクをクラウドに移動する
    • プロセスとシステムがデバイスのライフサイクルに与える影響を評価し、ビジネス要件を満たしながらデバイス交換の要件を最小限に抑えるソリューションを選択する
    • デバイスのリモート管理を実装して、必要な出張を減らす

領域3. ソフトウェアとアーキテクチャのパターン

• SUS 3：持続可能性の目標をサポートするために、 ソフトウェアとアーキテクチャのパターンをどのように活用しますか？
  • 非同期およびスケジュールされたジョブ用にソフトウェアとアーキテクチャを最適化する
    • 即時処理を必要としないキュー要求
    • シリアル化を増やして、パイプライン全体の使用率をフラットにする
    • 個々のコンポーネントの容量を変更して、アイドリングリソースが入力を待機しないようにする
    • バッファを作成し、レート制限を確立して、外部サービスの消費をスムーズにする
    • ソフトウェアの最適化のために利用可能な最も効率的なハードウェアを使用する
    • キュー駆動型アーキテクチャ、パイプライン管理、およびオンデマンドワーカーを使用して、バッチ処理の使用率を最大化する
    • 同時実行による負荷の急増とリソースの競合を回避するようにタスクをスケジュールする
    • 電力の炭素強度が最も低い時間帯にジョブをスケジュールする
  • 使用率が低いか使用されていないワークロードコンポーネントを削除またはリファクタリングする
    • 機能コンポーネントの負荷を（トランザクションフローやAPI呼び出しなどのインジケーターを使用して）分析し、未使用および十分に活用されていないコンポーネントを特定する
    • 不要になったコンポーネントを廃棄する
    • 十分に活用されていないコンポーネントをリファクタリングする
    • 十分に活用されていないコンポーネントを他のリソースと統合して、利用効率を向上させる
  • 最も多くの時間またはリソースを消費するコードの領域を最適化する
    • リソース使用量の関数としてパフォーマンスを監視し、最適化のターゲットとして作業単位あたりのリソース要件が高いコンポーネントを特定する
    • コードプロファイラーを使用して、最適化のターゲットとして最も時間またはリソースを使用するコードの領域を特定する
    • アルゴリズムを、同じ結果を生成するより効率的なバージョンに置き換える
    • ハードウェアアクセラレーションを使用して、実行時間が長いコードブロックの効率を向上させる
    • ワークロードに最も効率的なオペレーティングシステムとプログラミング言語を使用する
    • 不要な並べ替えとフォーマッティングを削除する
    • データの変更頻度と消費方法に基づいて、使用されるリソースを最小限に抑えるデータ転送パターンを使用する
  • カスタマーのデバイスと機器への影響を最適化する
    • カスタマーが使用するデバイスのインベントリを作成する
    • 代表的なハードウェアセットを備えた管理対象デバイスファームを使用してテストし、変更の影響を理解し、開発を繰り返して、サポートされるデバイスを最大化する
    • ペイロードを構築するときにネットワーク帯域幅と遅延を考慮し、アプリケーションが低帯域幅、高遅延のリンクで適切に機能するのに役立つ機能を実装する
    • データペイロードを前処理して、ローカル処理要件を減らし、データ転送要件を制限する
    • サーバー側で計算量の多いアクティビティ（画像レンダリングなど）を実行するか、アプリケーションストリーミングを使用して、古いデバイスでのユーザーエクスペリエンスを向上させる
    • ペイロードを管理し、ローカルストレージ要件を制限するために、特にインタラクティブセッションの場合、出力をセグメント化してページ分割する
  • データアクセスとストレージパターンを最適にサポートするソフトウェアパターンとアーキテクチャを使用する
    • データアクセスとストレージのパターンを分析する
    • データファイルをParquetなどの効率的なファイル形式で保存して、不要な処理（分析の実行時など）を防ぎ、プロビジョニングされるストレージの合計を減らす
    • 圧縮データをネイティブに処理するテクノロジーを使用する
    • 支配的なクエリパターンを最もよくサポートするデータベースエンジンを使用する
    • データベースインデックスを管理して、インデックスデザインが効率的なクエリ実行をサポートするようにする
    • 消費されるネットワーク容量の量を減らすネットワークプロトコルを選択する

領域4. データパターン

• SUS 4：持続可能性の目標をサポートするために、 データアクセスと使用パターンをどのように活用しますか？
  • データ分類ポリシーの実装
    • データの配布、保持、および削除の要件を決定する
    • ボリュームとオブジェクトのタグ付けを使用して、データ分類など、管理方法を決定するために使用されるメタデータを記録する
    • タグなしおよび未分類のデータについて環境を定期的に監査し、データを適切に分類およびタグ付けする
  • データアクセスとストレージパターンをサポートするテクノロジーを使用する
    • データアクセスパターンをモニタリングする
    • アクセスパターンに基づいて、データを適切なテクノロジーに移行する
    • アーカイブデータはそのために設計されたストレージへ移行する
  • ライフサイクルポリシーを使用して不要なデータを削除する
    • すべてのデータ分類タイプのライフサイクルポリシーを定義する
    • 自動化されたライフサイクルポリシーを設定して、ライフサイクルルールを適用する
    • 未使用のボリュームとスナップショットを削除する
    • ライフサイクルルールに基づいて、該当する場合はデータを集約する
  • ブロックストレージでの過剰プロビジョニングを最小限に抑える
    • データボリュームの使用率をモニタリングする
    • エラスティックボリュームとマネージドブロックデータサービスを使用して、永続データの増大に応じて追加のストレージの割り当てを自動化する
    • データボリュームの使用率の目標レベルを設定し、予想される範囲外のボリュームのサイズを変更する
    • データに合わせて読み取り専用ボリュームのサイズを設定する
    • データをオブジェクトストアに移行して、ブロックストレージの固定ボリュームサイズから過剰な容量をプロビジョニングしないようにする
  • 不要なデータまたは冗長なデータを削除する
    • ブロックおよびオブジェクトレベルでデータを重複排除できるメカニズムを使用する
    • ブロック、ファイル、およびオブジェクトレベルで増分バックアップを作成し、データを重複排除できるバックアップテクノロジを使用する
    • SLAを満たすために必要な場合にのみRAIDを使用する
    • ログとトレースデータを一元化し、同一のログエントリを重複排除し、必要に応じて冗長性を調整するメカニズムを確立する
    • 正当な理由がある場合にのみ、キャッシュの事前投入を行う
    • キャッシュの監視と自動化を確立して、それに応じてキャッシュのサイズを変更する
    • ワークロードの新しいバージョンをプッシュするときに、オブジェクトストアとエッジキャッシュから古いデプロイメントとアセットを削除する
  • 共有ファイルシステムまたはオブジェクトストレージを使用して、共通データにアクセスする
    • データに複数のコンシューマーがある場合は、データを共有ストレージに移行する
    • 必要な場合にのみ、共有ストレージからデータを取得する
    • 使用パターンに応じてデータを削除し、キャッシュされたデータを管理するための存続時間機能を実装する
    • ボリュームをアクティブに使用していないクライアントからボリュームを切り離す
  • ネットワーク間のデータ移動を最小限に抑える
    • できるだけ消費者の近くにデータを保存する
    • 地域ごとに消費されるサービスを分割し、その地域固有のデータが消費される地域内に保存されるようにする
    • ネットワーク全体で変更をコピーする場合は、ファイルレベルまたはオブジェクトレベルの複製ではなく、ブロックレベルの複製を使用する
    • ネットワーク上に移動する前にデータを圧縮する
  • 再作成が困難な場合にのみデータをバックアップする
    • データ分類を使用して、バックアップする必要のあるデータを確立する
    • 簡単に再作成できるデータを除外する
    • バックアップから一時的なデータを除外する
    • 共通の場所からデータを復元するために必要な時間がSLAを超えない限り、データのローカルコピーを除外する

領域5. ハードウェアパターン

• SUS 5：ハードウェアの管理と使用方法は 持続可能性の目標をどのようにサポートしていますか？
  • ニーズを満たすために最小限のハードウェアを使用する
    • 水平スケーリングを有効にし、自動化を使用して、負荷が増加するとスケールアウトし、負荷が減少するとスケールインさせる
    • 変動するワークロードに対して小さな増分を使用してスケーリングする
    • 負荷が日、週、月、年単位で変化するため、周期的な利用パターンに合わせてスケーリングを調整する
    • 自動化が代替リソースを展開している間の容量の一時的な削減を許容できるようSLAをネゴシエートする
  • 影響を最小限に抑えたインスタンスタイプを使用する
    • ワークロードと互換性のある最も効率的なインスタンスタイプを使用する
    • さまざまな数のCPUとさまざまな量のメモリで動作するようにワークロードを変更して、インスタンスタイプの選択を最大化する
    • 持続可能性への影響が最も少なく、SLAを満たすインスタンスを提供するリージョンにワークロードを移行する
    • バースト可能なインスタンスを使用して、追加容量の要件がまれなワークロードをサポートする
    • ステートレスでフォールトトレラントなワークロードにスポットインスタンスを使用して、クラウドの全体的な使用率を高め、未使用のリソースの持続可能性への影響を減らす
  • マネージドサービスの使用
    • セルフホストサービスからマネージドサービスに移行する
  • GPUの使用を最適化する
    • GPUは、CPUベースの代替手段よりも効率的なタスクにのみ使用する

領域6. 開発と展開のプロセス

• SUS 6：開発および展開プロセスは 持続可能性の目標をどのようにサポートしますか？
  • 持続可能性の改善を迅速に導入できる方法を採用する
    • 開発プロセスに持続可能性の要件を追加する
    • リソースが並行して機能し、持続可能性の改善を開発、テスト、および展開できるようにする
    • 本番環境に導入する前に、潜在的な持続可能性への影響の改善をテストおよび検証できるようにする
    • 実行可能な最小限の代表的なコンポーネントを使用して、潜在的な改善をテストする
    • テスト済みの持続可能性の改善が利用可能になったら、本番環境に展開する
  • ワークロードを最新の状態に保つ
    • システムを更新して、パフォーマンスを効率化する
    • 計画された改善のための障壁を取り除くためにシステムを更新する
    • システムを更新してソフトウェア機能を取得し、持続可能性への影響を減らす
    • システムを更新して、持続可能性への影響を測定および管理する能力を向上させる
  • ビルド環境の使用率を高める
    • 自動化を使用して、開発環境とテスト環境を最大限に活用する
    • 自動化を使用して、開発環境とテスト環境のライフサイクルを管理する
    • 最小限の実行可能な代表的な環境を使用して、潜在的な改善を開発およびテストする
    • オンデマンドリソースを使用して、開発者デバイスを補完する
    • 自動化を使用して、ビルドリソースの効率を最大化する
    • バーストキャパシティを持つインスタンスタイプ、スポットインスタンス、その他の技術を使用し、ビルドキャパシティと利用を一致させる
    • 踏み台フリートを展開するのではなく、安全なインスタンスシェルアクセスのためにネイティブクラウドサービスを採用する
  • テストに管理対象デバイスファームを使用する
    • 代表的なハードウェアセットを備えた管理対象デバイスファームを使用してテストし、変更の影響を理解し、開発を繰り返して、サポートされるデバイスを最大化する

終わりに

AWS Well-Architected フレームワーク持続可能性（サステナビリティ）の柱の内容を確認してみました。

過去には以下のように他の 5 本の柱をマインドマップ化したこともあります。

上記の場合 AWS Well-Architected Tool との結びつきを強く意識していたのですが、サステナビリティの柱はまだ対応しておらず、少し毛色の異なるものになりました。

改めてサステナビリティの柱を眺めると、適切なインスタンスタイプの選定、不要なデータの削除など、コストの柱、パフォーマンスの柱とも関連が強い項目が並んでいるな、という感想を抱きます。

「デバイスにリモートで接続できるようにして出張を減らす」という項目があるのは少し意表を突かれて笑ってしまいました。

ワークロードやそれに関わるユーザーの行動を最適化していくと、結果的にサステナビリティにつながっていくのかなと感じます。ドキュメントを読み込む際のお供にご利用ください。

以上、 チバユキ (@batchicchi) がお送りしました。