前段
Well-Architected Framework自体はよく聞くワードですが、その分量の多さ（とAWSドキュメントあるあるの若干の読みにくさ）にしっかりと読む機会がなかなかなかったため、ここで改めて自分なりに落とし込もうと思いました。
Well-Architected Frameworkを読んで、「直訳過ぎて、何を言っているかわからないなぁ」となった時に見ていただけるような記事を目指しています。
※解釈に誤りがある場合はご指摘ください。
※ドキュメント本文そのままではないため、個人の解釈が入っている部分があります。
関連記事
・AWS Well-Architected Frameworkについて詳しく見てみる【運用上の優秀性】
・AWS Well-Architected Frameworkについて詳しく見てみる【パフォーマンス】
記事内でワークロードという言葉が頻繁に出てくるので、解説を入れておきます。
ワークロードとは：
ビジネス価値をもたらすリソースとコード (顧客向けアプリケーションやバックエンドプロセスなど) の集合のことです。
引用元：ワークロード
設計原則
・持続可能性を検討するにあたっての影響を理解する
・持続可能性の目標を設定する
・動的リソース確保などにより、リソースの使用率を最大化する
・より効率的な新しいハードウェア及びソフトウェアの提供を予測して採用する
・マネージドサービスを利用することにより、持続可能性の確保をAWS責任範囲にする
・サービスを顧客が使用するにあたって必要なエネルギーやリソースの量を削減する
① 地域選択
ビジネス要件と持続可能性の目標に基づいて地域を選択する
Amazon の再生可能エネルギー プロジェクトまたは公表されている炭素強度が低いリージョンの近くに配置すると、クラウド ワークロードの炭素フットプリントを削減できるらしいです。
各国の電力マップを確認し、炭素強度を調査します。
以下リンクに、炭素強度の調査方法が示されています。
② 需要への対応
ワークロードインフラストラクチャを動的に拡張する
サーバレスまたはオートスケーリングによる動的な容量確保により、過剰なリソースの使用を抑えます。
SLA を持続可能性の目標と整合させる
SLAを確認し、持続可能性とのトレードオフをどう検討するかを決めましょう、とあります。
方法としては
① 可能であれば持続可能性を定義する
② SLAを調整する
が挙げられています。
未使用資産の作成と保守を停止する
自身のアカウントの中で、テスト用に作ったリソースや消し忘れているものが発生すると思います。そういった類の未使用のリソースを削除します。
もしくは保守不要になったデータなどに対してライフサイクルを定義し、自動的に削除するようにします。
ネットワーク要件に基づいてワークロードの地理的配置を最適化する
最適なサービス、地理的配置を検討することで、ネットワークトラフィックの移動距離を減らし、必要なネットワークリソースの合計を減らします。
例えば、リージョン・アベイラビリティゾーン・プレイスメント・Outposts・LocalZone、エッジロケーションを最適にすることで、ネットワークトラフィックの移動距離の削減＝ネットワークリソースの削減を実施します。
ほかにはDBの接続プールを使用することや、同期更新に依存しない分散データストアの利用、ネットワーク容量の動的確保なども採用することでリソースの削減が可能になります。
実行される活動のためにチームメンバーのリソースを最適化する
開発や保守運用で使用するクラウドアプリケーションについても検討します。
・エネルギー効率の高い作業環境（PC等も含め）を検討する
・仮想化を使用（デスクトップなど）を使用する
・出張や移動に伴う炭素排出を減らすためにオンラインでの共同作業（Zoomなどのビデオ会議やコラボレーションツールの使用）を行う
などが提唱されています。
需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
突発的なピークに対しスロットリングをかけることで、動的確保であったとしても総合的に確保する容量の削減を目指します。例えば、SQSを使用したキューによる非同期処理の利用などを想定しています。
（１）バッファリング・スロットリング前
（２）バッファリング・スロットリング後
画像引用元：https://docs.aws.amazon.com/images/wellarchitected/latest/sustainability-pillar/images/provisioned-capacity-2.png
③ソフトウェアとアーキテクチャ
非同期ジョブとスケジュールジョブのソフトウェアとアーキテクチャを最適化する
キュー駆動(= イベント駆動）型などの効率的なソフトウェアおよびアーキテクチャを構成して、一貫した高い使用率を維持します。
AWS Batchを使用したり、EventBridgeスケジューラによる必要なタイミングでのリソース確保も行います。
使用頻度が低い、またはまったく使用されていないワークロードコンポーネントを削除またはリファクタリングする
ワークロードを確認して、アイドル状態または未使用のコンポーネントを特定します。その後、改善の余地を検討し、不要であれば削除します。
最も多くの時間やリソースを消費するコード領域を最適化する
アーキテクチャのさまざまなコンポーネント内で実行されるコードを最適化して、リソースの使用を最小限に抑えながらパフォーマンスを最大化します。
デバイスと機器への影響を最適化する
アーキテクチャで使用されているデバイスと機器を理解し、それらの使用量を削減する戦略を採用します。例えば、
モバイル、タブレット、IoT デバイス、スマート ライト、さらには工場内のスマート デバイスに関して、より電源消費が少なる方法を検討します。
データアクセスとストレージパターンを最適にサポートするソフトウェアパターンとアーキテクチャを使用する
データ アクセスとストレージを最適にサポートするソフトウェア パターンとアーキテクチャを使用して、ワークロードをサポートするために必要なコンピューティング、ネットワーク、およびストレージ リソースを最小限に抑えます。
④ データ管理
データ分類ポリシーを実装する
データを分類して重要性を理解し、データを格納するための適切なエネルギー効率の高いストレージ層を選択します。例えばS3に格納するかEFSのようなファイスストレージに格納するかが検討できます。
データアクセスとストレージパターンをサポートするテクノロジーを使用する
データの特性/アクセスパターンは以下
・データの種類:構造化、半構造化、非構造化
・データの増加:制限あり、制限なし
・データの耐久性:永続的、一時的、一時的
・アクセスパターン:読み取りまたは書き込み、頻度、スパイク、または一貫性
ストレージの種類は以下があります
・オブジェクトストレージ
- S3
・アーカイブストレージ
- S3 Glacier
・共有ファイルシステム
- EFS
- Amazon FSx
・ブロックストレージ
- EBS
・RDB
- RDS
・キーバリューデータベース
- DynamoDB
これに加え、S3はデータのアクセスパターンに合わせて、ストレージクラスを指定することができます。
ポリシーを使用してデータセットのライフサイクルを管理する
S3ライフサイクルや、Amazon Data Lifecycle Manager、その他のライフサイクル管理サービスを使用して、よりエネルギー効率の良いストレージ層に移動します。もしくは削除します。
弾力性と自動化を使用してブロックストレージまたはファイルシステムを拡張する
データの増加に合わせて自動的に拡張できるようにします。それにより容量の確保を最小限に抑えます。
不要または冗長なデータを削除する
不要なデータや冗長なデータを削除して、データセットを保存するために必要なストレージ リソースを最小限に抑えます。
共有ファイルシステムまたはストレージを使用して共通データにアクセスする
データの重複を回避し、ワークロードのより効率的なインフラストラクチャを実現するために、共有ファイルシステムまたはストレージを採用します。
共有ストレージ テクノロジを使用すると、複数のコンピューティング リソースが同時に並行してデータにアクセスして処理できるため、コンピューティング能力をより効率的に使用できます。
ネットワーク間のデータ移動を最小限に抑える
共有ファイル システムまたはオブジェクト ストレージを使用して共通データにアクセスし、ワークロードのデータ移動をサポートするために必要なネットワーク リソースの合計を最小限に抑えます。
再現が困難な場合にのみデータをバックアップする
ビジネス価値のないデータのバックアップは避けてください、と記載があります。簡単に再作成できるデータのバックアップは不要ということです。
⑤ ハードウェアとサービス
ニーズを満たすために最小限のハードウェアを使用する
ワークロードに最小限のハードウェアを使用して、ビジネス ニーズを効率的に満たします。動的なリソース確保も視野に入れたアーキテクチャを実装します。
影響が最も少ないインスタンスタイプを使用する
直訳なので分かりづらいですが、要するに「エネルギー効率のよいインスタンスタイプを使用する」です。
AWS Gravitonは同等のEC2に比べ、最大60%すくない消費電力で同じパフォーマンスを発揮します。
マネージドサービスを使用する
マネージド サービスを使用して、クラウドでより効率的に運用します。マネージドサービスは、導入されたハードウェアの高い使用率と持続可能性の最適化を維持する責任を AWS に移行します。
ハードウェアベースのコンピューティングアクセラレータの使用を最適化する
高い処理能力が必要な場合は、グラフィックス プロセッシング ユニット (GPU) やフィールド プログラマブル ゲート アレイ (FPGA) などのハードウェア ベースのコンピューティング アクセラレータにアクセスできる高速コンピューティング インスタンスを使用すると効果的です。
⑥ プロセスと文化
持続可能性の改善を迅速に導入できる方法を採用する
潜在的な改善を検証し、テスト コストを最小限に抑え、小さな改善を実現するための方法とプロセスを採用します。
ワークロードを最新の状態に保つ
ワークロードを最新の状態に保ち、効率的な機能を導入し、問題を排除し、ワークロードの全体的な効率を向上させます。
ビルド環境の利用率の向上
ワークロードの開発、テスト、構築のためのリソースの利用率を高めます。例えば、自動化と Infrastructure as Code を使用して、必要なときにビルド環境を起動し、使用されていないときは停止します。（CodePipeline, CodeBuildなど）
テスト用に管理対象デバイスファームを使用する
管理対象デバイス ファームを使用して、代表的なハードウェア セットで新しい機能を効率的にテストします。
管理対象デバイス ファームは、古いハードウェアやあまり人気のないハードウェアを含むさまざまなデバイス タイプを提供し、不要なデバイス アップグレードによる顧客の持続可能性への影響を回避します。