AWSを利用している皆さん！
「パフォーマンスを改善させた！」「AWS利用料をこんだけ削減できた！」
そんな日頃行っているシステム改善活動が、知らない間に環境問題の改善に貢献してますよ！
せっかくの社会貢献なので、
「自分たちがどんな環境問題に貢献できているのか？」
「もっと貢献するにはどうしたらよいか？」
を知るきっかけになればと思い記事にしてみました。
いろんな記事や文献を漁ったので、情報量多めのちょっぴりDeep Diveチックな内容になっています。
興味のある個所だけでも読んでもらえると嬉しいです
まず、AWSにおけるサステナビリティとは
AWSは、2025年までに再生可能エネルギーのみでオペレーションを行うため、グローバルインフラストラクチャ全体の効率と継続的なイノベーションに重点的に取り組んでいます。
AWSは、2040年までにネットゼロにするというAmazonの目標の達成に向けて取り組んでいます。
ネットゼロとは？
温室効果ガスの排出量を「正味ゼロ」にすること。
カーボンニュートラルと同じ意味でつかわれることがありますが、細かい定義は下記のように異なります。
https://gurilabo.igrid.co.jp/article/2929/
■エネルギー効率
AWSはデータセンターやハードウェアの設計、継続的にエネルギー効率を向上させるための運用パフォーマンスのモデリングに至るまで、インフラのあらゆる側面にわたるエネルギー効率に重点を置いています。
【電力効率】
AWS Nitro Systemへの投資など様々な方法で電力効率を向上させるためにイノベーションを活用しています。
例えば、AWSが設計したGraviton3は、最も電力効率の高い汎用プロセッサです。Graviton3ベースのEC2インスタンスは、非Graviton EC2インスタンスよりも同じパフォーマンスを得るために使用するエネルギーが最大60%少なくなるそうです！
【冷却効率】
AWSはパートナーと協力して、データセンター冷却システムで使用される冷却媒体の寿命とエアフロー性能の最適化を実現しました。
新しい媒体は耐用年数が2倍になり、以前のバージョンよりも空気が通過しやすくなり、ファンのエネルギーが節約されます。これは建物のエネルギー性能に大きな影響を与え、冷却装置のエネルギー使用量を20％削減します。
https://sustainability.aboutamazon.com/environment/the-cloud?energyType=true
■CO2削減
451 Researchの調査によるとAWSは調査対象のエンタープライズ データセンターと比較して、顧客のワークロードのCO2排出量を80%近く削減でき、AWSが100%再生可能エネルギーで稼働すると最大96%削減できることもわかりました。
■水資源管理
AWSは2022年に「2030年までにウォーターポジティブになる！」という取り組みを発表しました。
https://sustainability.aboutamazon.com/environment/the-cloud/water-stewardship
（世界に数十か所ある）AWSデータセンターで利用/排出される水資源において、水の使用量を削減し、事業を展開しているコミュニティでの水資源の補給などのプロジェクトに投資しており、
現在の水資源プロジェクトがすべて完了すると、約24億リットル/年の水を地域社会や環境に戻すことになる！
水資源に関する取り組みには4つの柱があります。
【① 水の効率】
水の消費量を最適化するための取り組み。
IoTなどのクラウドテクノロジーを使用して、リアルタイムの水使用量を分析して、漏水箇所を特定しています。
【② 持続可能な資源】
可能な限りリサイクル水や雨水などの持続可能な水源を使用しています。
AWSではすでに、世界中の20のデータセンターの冷却にリサイクル水を使用しています。
そうすることで、地域社会と環境にとって貴重な飲料水を節約できます。
【③ 地域における水の再利用】
データセンターからの冷却水は最大96％が再利用可能であり、オレゴン州では地元の農家に無料で提供され、トウモロコシ、大豆、小麦などの作物の栽培に役立てられています。
【④ 水資源の補給】
AWSでは水補給プロジェクトを展開しており、水に困っている地域へきれいな水を提供する活動を行っています。
ウォーターポジティブとは？
消費する水より多くの水を供給することです。
世界中で淡水不足が課題となっている中、AmazonやGoogleなどの企業が水を確保するための様々な取り組みを行っています。
https://ideasforgood.jp/glossary/water-positive/
AWSユーザ側でできることは？
上記で解説したAWS側の取組みを見て、
「AWS側でだいぶ成果出してるからAWSユーザ側でやることないのでは？」
と思った方もいるのではないでしょうか？
否！！ 我々でもさらにサステナビリティを向上させることはできます
それは、AWS Well-Architected Frameworkに定義されています！
AWS Well-Architected Framework「サステナビリティの柱」
2021年にAWS Well-Architected Framework(以降、W-A)に新たに6つ目の柱「サステナビリティの柱」が誕生しました。
・運用上の優秀性の柱
・セキュリティの柱
・信頼性の柱
・パフォーマンス効率の柱
・コスト最適化の柱
・サステナビリティの柱 ★2021年追加
他の柱と同様にサステナビリティの柱でも、
ワークロードの設計、アーキテクチャ、実装
を評価対象としていますが、異なる点としては、エネルギー消費量を削減し、エネルギー効率を向上させることを目的とした内容が含まれていることです。
上記の【■CO2削減】でも解説したように、
AWSと一般的なオンプレ環境での構築を比較した際、CO2排出量が約80%削減できることがわかっています。
これは電力/冷却の効率化や、AWSデータセンターの設計など、AWS側の積極的な取組みにより実現しましたが、
我々AWSユーザ側でもこのW-Aを利用しアーキテクチャを意識/設計することでさらにサステナビリティを向上させることできます。
AWSでおなじみの「責任共有モデル」がサステナビリティ関連でも存在します。
我々ユーザ側は
ワークロードやリソースの利用効率を最適化し、リソース数を最小限にする
という役割が定義されています。
では、ユーザ側で具体的にどのようなことを考慮すればよいのか？
カテゴリーごとにべスプラ解説いたします！
中には、皆さんが今までコスト削減やパフォーマンス改善等でやってきたことがあるかもしれません
下記の各カテゴリにはそれぞれ複数のべスプラがありますが、情報量が多いため独断と偏見で内容を絞ってます
全べスプラ情報は下記ホワイトペーパーにありますので、ご興味あればご覧ください。
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sustainability-pillar/best-practices-for-sustainability-in-the-cloud.html
■ リージョンの選択
【べスプラ概要】
ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択すること（SUS01-BP01）
【べスプラ実装によるメリット】
Amazonの再生可能エネルギープロジェクトや公開されている炭素強度の低いリージョンの近くにワークロードを配置することで、ワークロードのカーボンフットプリントを削減できます
カーボンフットプリント(Carbon Footprint of Products)とは？
商品やサービスの原料調達から廃棄/リサイクルに至るまでのライフサイクル全体を通じて排出される温室効果ガスの排出量をCO2に換算したものです。
【べスプラ実装方法】
- SUS01-BP01
- ①ワークロードに適したリージョンを評価し、候補をリストアップする
- ・コンプライアンスに準拠したリージョンか？
- ・必要なサービスと機能が備わっているか？
- ・AWS Pricing Calculatorを使用して、各リージョンのワークロードのコストを計算する
- ・エンドユーザとリージョン間のネットワークレイテンシーをテストする
- ②再生可能エネルギープロジェクトに近いリージョンであり、電力マップ(※)を利用し炭素集約度が他リージョンより低いリージョンを選択する
【アンチパターン
】
- SUS01-BP01
- ・自分の場所に基づいてワークロードのリージョンを選択する
- ・すべてのワークロードリソースを 1 つの地理的場所に統合する
■ 需要に合わせた調整
【べスプラ概要】
・インフラを動的にスケールすること（SUS02-BP01）
・未使用アセットの整理/削除すること（SUS02-BP03）
・ワークロードをエンドユーザの近くに配置すること（SUS02-BP04）
【べスプラ実装によるメリット】
・需要の急増時や急増後に容量を自動スケールすることで、要件を満たすために必要な適切な数のリソースのみで運用できます（SUS02-BP01）
・不要なアセットを削除することで、リソースが解放されワークロード全体の効率が向上します（SUS02-BP03）
・ワークロードをエンドユーザの近くに配置することで、ネットワーク上のデータ量を減らし、環境負荷を削減しながら、最小限のレイテンシーを実現できる（SUS02-BP04）
【べスプラ実装方法】
- SUS02-BP01
- ①Auto Scalingを使用しリソースを自動的にスケールさせる
- ②需要に合わせ、DynamoDBのキャパシティユニットやKinesis Data Streamなど非コンピューティングサービスの設定/導入も検討する
- ③スケールインの導入の際にワークロードが期待通りに動作するかテストを実施する
- SUS02-BP03
- ①モニタリングツールを使用して、不要になった静的アセットを特定する
- ②削除によるアーキテクチャへの影響を評価し、不要アセットを削除する
- ③重複して作成されるアセットは統合し、冗長プロセスを排除する
- ④不要アセットがこれ以上生成/保存されないようにアプリケーションを更新する
- ⑤サードパーティ製品を利用している場合は、不要アセットの生成/保存を停止するように指示する
- ⑥サードパーティ製品を利用している場合は、冗長アセットを統合するように指示する
- ⑦ワークロードを定期的に見直して、未使用アセットを特定し削除する
- SUS02-BP04
- ①ワークロードのネットワークアクセスパターンを分析して、ユーザがアプリケーションをどのように使用しているか特定する
- ②ワークロードのデプロイに適切なリージョンを選択する
- ③AWSローカルゾーンを使用して、エンドユーザの近くにリソースを配置する
- ④オンプレに置く必要があり、かつAWSにあるワークロードとシームレスに連携させたい場合は、AWS Outpostsの使用を検討する
- ⑤ローカルキャッシュやCloudFront / ElastiCache / DynamoDB AcceleratorなどのAWSキャッシュソリューションを使用する
- ⑥エンドユーザの近くでコード実行できるLamdba@Edge / CloudFront関数 / IoT Greengrassを使用する
- ⑦コネクションプールを使用して、接続の再利用を可能にし、必要なリソースを削減する
- ⑧事前にプロビされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有する
【アンチパターン】
- SUS02-BP01
- ・ユーザーの負荷に合わせてインフラストラクチャをスケールしない
- ・常に手動でインフラストラクチャをスケールする
- ・スケーリングイベントの後、スケールダウンして元に戻さず、キャパシティーを増加させたままにする
- SUS02-BP03
- ・アプリケーションを分析して冗長または不要になったアセットを見つけていない
- ・冗長または不要になったアセットを削除していない
- SUS02-BP04
- ・自分の場所に基づいてワークロードのリージョンを選択する
- ・すべてのワークロードリソースを 1 つの地理的場所に統合する
- ・すべてのトラフィックが既存のデータセンターを通過する
■ ソフトウェアとアーキテクチャ
【べスプラ概要】
・使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする（SUS03-BP02）
・時間やリソースを最も多く消費するコード領域を最適化する（SUS03-BP03）
【べスプラ実装によるメリット】
・未使用のコンポーネントを削除すると、無駄が最小化され、クラウドワークロード全体の効率が向上する（SUS03-BP02）
・効率的なコードは、リソースの使用量を最小化し、パフォーマンスを向上させる（SUS03-BP03）
【べスプラ実装方法】
- SUS03-BP02
- ①ワークロードの重要なコンポーネントの使用率メトリクスをモニターしキャプチャする
- ②安定したワークロードの場合は、AWS Compute Optimizerなどのサイズ最適化ツールを定期的に確認して、アイドル/未使用/使用率の低いコンポーネントを特定する
- ※一次的なワークロードの場合は、使用率メトリクスを評価する
- ③不要になったコンポーネントや関連アセット(例：ECRイメージなど)を廃止する
- ④使用率の低いコンポーネントをリファクタリングまたは他のリソースと統合する
- SUS03-BP03
- ①ワークロードを開発する際に、自動化されたコードレビュープロセスを導入して、品質を向上させ、バグやアンチパターンを特定する
- ②ワークロードを実行しながら、リソースをモニターして、作業単位でリソースを多く必要とするコンポーネントを特定して、コードレビュー対象とする
- ③コードレビューでは、コードプロファイラーを使用して、時間またはリソースを最も多く使用するコードの領域を特定し最適化対象とする
- ④Rustなどのエネルギー効率の良いプログラム言語を使用する
- ⑤ソートや書式設定などの不要なコードを削除する
【アンチパターン】
- SUS03-BP02
- ・ワークロードの個別のコンポーネントの使用率レベルを定期的に確認していない
- ・AWS Compute Optimizer のような AWS サイズ最適化ツールからのレコメンデーションを確認し分析しない
- SUS03-BP03
- ・リソースの使用量のためにコードを最適化しない
- ・通常、パフォーマンスの問題にはリソースを増やすことで対処している
- ・コードの見直し及び開発プロセスで、パフォーマンスの変化を追跡していない
■ データ
【べスプラ概要】
・ポリシーを使用してデータセットのライフサイクルを管理する（SUS04-BP03）
・データは再作成が難しい場合にのみバックアップする（SUS04-BP08）
【べスプラ実装によるメリット】
・データライフサイクルポリシーを使用することで、ワークロードのデータアクセスと保持を効率的に行うことができる（SUS04-BP03）
・重要ではないデータのバックアップを避けると、ワークロードに必要なストレージリソースを削減し、環境への影響を減らすことができる（SUS04-BP08）
【べスプラ実装方法】
- SUS04-BP03
- ①ワークロード内のデータセットを分類する
- ②データクラスごとに処理手順を定義する
- ③ライフサイクルルールを適用するための自動ライフサイクルポリシーを設定する。（例：S3 ライフサイクル、Data Lifecycle Managerなど）
- ④未使用のボリューム、スナップショット、保持期間が過ぎたデータを削除する
- ※DynamoDBの有効期限やCloudWatchログ保持などのネイティブサービス機能が便利
- ⑤ライフサイクルルールに基づいて、該当する場合はデータを集約及び圧縮する
- SUS04-BP08
- ①ワークロード内のデータを重要度で分類する
- ②データ分類の重要度を使用し、RTO/RPOに基づいてバックアップ戦略を策定する。（重要でないデータのバックアップは避けること！）
- ・簡単に再作成できるデータを除外する
- ・バックアップから一時データを除外する
- ・共有の場所からデータを復元するために必要な時間がSLAを超過する場合を除き、データのローカルコピーを除外する
- ③自動化されたソリューションまたはマネージドサービスを使用してデータをバックアップする（例：AWS Backupなど）
【アンチパターン】
- SUS04-BP03
- ・データを手動で削除する
- ・ワークロードデータは削除しない
- ・データ保持やアクセス要件に基づいて、よりエネルギー効率の高いストレージ階層にデータを移動することがない
- SUS04-BP08
- ・データのバックアップ戦略がない
- ・簡単に再作成できるデータをバックアップしている
■ ハードウェアとサービス
【べスプラ概要】
・影響が最も少ないインスタンスタイプを使用する（SUS05-BP02）
【べスプラ実装によるメリット】
・エネルギー効率が高く、適切なサイズのインスタンスを使用することで、環境への影響とワークロードのコストを大幅に削減できる（SUS05-BP02）
【べスプラ実装方法】
- SUS05-BP02
- ①最新のAWSテクノロジーとインスタンスの情報を入手する（AWSの最新情報などを確認）
- ②ワークロードを計画し、最も影響の少ないインスタンスタイプに移行する
- ・ワークロードのパフォーマンス効率を向上させるため、なるべくGravitonベースのインスタンスへの移行を検討する
- ・機械学習のワークロードには、AWS Trainiumなどの専用ハードウェアを利用する
- ③ワークロードインスタンスを操作して最適化する
- ・一時的なワークロードの場合は、CloudWatchのCPUUtilizationなどのメトリクスを評価して、アイドル/低使用の状態になっていないか確認する
- ・安定したワークロードの場合は、Compute OptimizerなどのAWSサイズ最適化ツールを定期的に確認する
【アンチパターン】
- SUS05-BP02
- ・インスタンスの 1 つのファミリーのみを使用する
- ・x86 インスタンスのみを使用する
- ・Amazon EC2 Auto Scaling 設定で 1 つのインスタンスタイプを指定する
- ・AWS インスタンスが設計されていない方法で使用されている (たとえば、メモリ集中型のワークロードに計算用に最適化されたインスタンスを使用した場合)
- ・新しいインスタンスタイプを定期的に評価しない
- ・AWS Compute Optimizer のような AWS サイズ最適化ツールからのレコメンデーションを確認しない
■ プロセスと文化
【べスプラ概要】
・ワークロードを最新に保つ（SUS06-BP02）
【べスプラ実装によるメリット】
・ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決しワークロードの効率性を高めることができる（SUS06-BP02）
【べスプラ実装方法】
- SUS06-BP02
- ①ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを定義する。また新しい機能がワークロードをどのように改善するかを素早くテストする
- ・接続可能性への影響を削減する
- ・パフォーマンス効率を高める
- ・計画した改善にとっての障壁を取り除く
- ・接続可能性に対する影響の測定能力と管理能力を高める
- ②ソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する
- ③ワークロードのコンポーネント(マシンイメージ/コンテナイメージ/Lambda)を更新する方法を理解する
- ④更新プロセスにオートメーションを使用する（新しい機能をデプロイする工数を削減し、手動プロセスに起因するエラーを抑制できる）
【アンチパターン】
- SUS06-BP02
- ・現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている
- ・更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない
まとめ
今回の記事では
・AWSが見えないところで環境問題に取り組んでいたこと
・皆さんが今まで頑張ってきた改善活動が、知らない間に環境問題に貢献していたこと
・AWSユーザ側でさらにサステナビリティ向上に貢献できること
についてまとめてみました！
W-A「サステナビリティの柱」には、
・AutoScalingを使って、必要な分だけリソースを使う
・不要なリソースは定期的に消すこと
など、コスト削減活動で実施していそうなことが定義されており、
皆さんの改善活動に「サステナビリティ向上」という付加価値がついていることをご認識いただけたのではないでしょうか。
今後機会があれば、「皆さん、知らない間に〇〇」シリーズを記事にしていきたいと思います！
長文になってしまいましたが、最後まで読んでいただきありがとうございました