Well-Architected Framework: 持続可能性の柱

Last reviewed 2026-01-28 UTC

Google Cloud Well-Architected Framework の持続可能性の柱では、エネルギー効率と炭素排出量を意識した Google Cloudでワークロードを設計、構築、管理するための推奨事項について説明します。

このドキュメントの対象読者は、 Google Cloudでワークロードの設計、構築、デプロイ、保守を行う意思決定者、アーキテクト、管理者、デベロッパー、オペレーターです。

アーキテクチャと運用の決定は、クラウド内のワークロードによって発生するエネルギー使用量、水への影響、カーボン フットプリントに大きな影響を与えます。小規模なウェブサイトでも大規模な ML モデルでも、あらゆるワークロードはエネルギーを消費し、炭素排出量と水資源の集約度に影響します。持続可能性をクラウド アーキテクチャと設計プロセスに統合すると、効率的で費用対効果に優れ、環境的に持続可能なシステムを構築できます。持続可能なアーキテクチャは、復元力があり最適化されているため、効率の向上、コストの削減、環境への影響の軽減という正のフィードバック ループが生まれます。

設計による持続可能性: 包括的なビジネス成果

サステナビリティは、他のコア ビジネス目標とのトレードオフではありません。サステナビリティ プラクティスは、他のビジネス目標の達成を加速させるのに役立ちます。低炭素リソースとオペレーションを優先するアーキテクチャを選択すると、より高速で安価かつ安全なシステムを構築できます。このようなシステムは、設計による持続可能性が実現されていると見なされます。持続可能性を最適化することで、パフォーマンス、費用、セキュリティ、復元力、ユーザー エクスペリエンスの全体的な成果が向上します。

パフォーマンスの最適化

パフォーマンス向けに最適化されたシステムは、本質的に使用するリソースが少なくなります。タスクをより迅速に完了する効率的なアプリケーションでは、コンピューティング リソースの必要期間が短くなります。そのため、基盤となるハードウェアのエネルギー消費量（kWh）が少なくなります。パフォーマンスの最適化により、レイテンシが短縮され、ユーザー エクスペリエンスが向上します。非効率的なプロセスを待機するリソースによって時間とエネルギーが無駄になることはありません。専用ハードウェア（GPU や TPU など）を使用し、効率的なアルゴリズムを採用して、並列処理を最大化すると、パフォーマンスが向上し、クラウド ワークロードのカーボン フットプリントが削減されます。

費用の最適化

クラウドの運用費用はリソースの使用量によって異なります。この直接的な相関関係により、コストを継続的に最適化すると、エネルギー消費量と二酸化炭素排出量も削減されます。VM のサイズを適正化し、アグレッシブな自動スケーリングを実装し、古いデータをアーカイブして、アイドル状態のリソースを排除すると、リソース使用量とクラウド費用を削減できます。また、データセンターでワークロードの実行に必要なエネルギー消費量が減るため、システムの温室効果ガス排出量も削減できます。

セキュリティとレジリエンス

セキュリティと信頼性は、持続可能なクラウド環境の前提条件です。侵害されたシステム（サービス拒否（DoS）攻撃や不正なデータ漏洩の影響を受けたシステムなど）では、リソース消費量が大幅に増加する可能性があります。このようなインシデントが発生すると、トラフィックが急増し、緩和のためにコンピューティング サイクルが暴走し、フォレンジック分析、クリーンアップ、データ復元に長時間にわたる高エネルギーのオペレーションが必要になります。強力なセキュリティ対策は、リソース使用量の不要な急増を防ぎ、オペレーションを安定した予測可能なエネルギー効率の高い状態に保つうえで役立ちます。

ユーザー エクスペリエンス

効率性、パフォーマンス、アクセシビリティ、データ使用量の最小化を優先するシステムは、エンドユーザーのエネルギー使用量の削減に役立ちます。より小さなモデルを読み込むか、より少ないデータを処理して結果をより早く提供するアプリケーションは、ネットワーク デバイスとエンドユーザー デバイスで消費されるエネルギーを削減するのに役立ちます。このエネルギー使用量の削減は、帯域幅が限られているユーザーや古いデバイスを使用しているユーザーに特にメリットがあります。さらに、持続可能なアーキテクチャは、地球への悪影響を最小限に抑え、社会的責任を果たすテクノロジーへの取り組みを示すのに役立ちます。

クラウドへの移行によるサステナビリティの価値

オンプレミス ワークロードをクラウドに移行すると、組織の環境フットプリントを削減できます。クラウド インフラストラクチャへの移行により、一般的なオンプレミス環境と比較して、エネルギー使用量と関連する排出量を 1.4 ～ 2 倍削減できます。クラウド データセンターは、高い電力使用効率（PUE）を実現するために構築された、最新のカスタム設計の施設です。古いオンプレミス データセンターでは、高度な冷却システムや電力分配システムへの投資を正当化するのに必要な規模が不足していることがよくあります。

責任の共有と運命の共有

Google Cloudにおける責任と運命の共有では、クラウド ワークロードのセキュリティが Google とお客様の間の共有責任であることについて説明しています。この責任共有モデルは、持続可能性にも適用されます。

Google は Google Cloudの持続可能性に責任を負っています。これは、データセンター、インフラストラクチャ、コアサービスのエネルギー効率とウォーター スチュワードシップを意味します。Google は、再生可能エネルギー、気候変動に配慮した冷却、ハードウェアの最適化に継続的に投資しています。Google の持続可能性戦略と進捗状況について詳しくは、Google Sustainability 2025 環境報告書をご覧ください。

お客様は、クラウドの持続可能性に責任を負います。つまり、ワークロードを最適化してエネルギー効率を高める必要があります。たとえば、リソースの適切なサイジング、ゼロにスケーリングするサーバーレス サービスの使用、データ ライフサイクルの効果的な管理などを行うことができます。

また、Google は運命共同体モデルを提唱しています。持続可能性は単なるタスクの分担ではなく、エコシステム全体の環境フットプリントを削減するための Google との共同パートナーシップです。

ビジネス効果をもたらす AI の活用

Well-Architected Framework のサステナビリティの柱（このドキュメント）には、持続可能な AI システムの設計に役立つガイダンスが含まれています。ただし、包括的な持続可能性戦略は、AI ワークロードの環境への影響にとどまりません。この戦略には、AI を使用して業務を最適化し、新たなビジネス価値を創出する方法を含める必要があります。

AI は、膨大なデータセットを実用的な分析情報に変換することで、持続可能性の触媒として機能します。組織は、次のような分野で、事後対応型のコンプライアンスから事前対応型の最適化に移行できます。

  • 運用の効率化: 在庫管理の改善、サプライ チェーンの最適化、インテリジェントなエネルギー管理により、業務を効率化します。
  • 透明性とリスク: データを活用して、サプライ チェーンの透明性、規制遵守、気候リスクのモデリングを詳細に行います。
  • 価値と成長: サステナブル ファイナンスとリコマースで新たな収益源を開発します。

Google は、データから分析情報を取得し、持続可能な未来に向けた機能を構築するのに役立つ次のプロダクトと機能を提供しています。

  • Google Earth AI: 地球規模の地理空間データを使用して、環境の変化を分析し、サプライ チェーンへの影響をモニタリングします。
  • WeatherNext: 高度な天気予報と気候リスク分析を提供し、気候変動に対する復元力を高めます。
  • Google Earth の地理空間分析情報: 地理空間データを使用して、場所に関する豊富なコンテキスト データを追加し、よりスマートなサイト選定、リソース計画、運用を可能にします。
  • Google マップのルート最適化: 物流と配送ルートを最適化して、効率を高め、燃料消費量と輸送による排出量を削減します。

パートナーやお客様とのコラボレーション

Google Cloud と TELUS は、ワークロードを Google のカーボンニュートラルなインフラストラクチャに移行し、データ分析を活用してオペレーションを最適化することで、クラウドの持続可能性を推進するために提携しました。このコラボレーションは、スマートシティ技術などの取り組みを通じて、社会と環境にメリットをもたらします。スマートシティ技術では、リアルタイムのデータを使用して、カナダの自治体全体で交通渋滞と炭素排出量を削減します。このコラボレーションの詳細については、Google Cloud と TELUS が持続可能性に向けて協力をご覧ください。

基本原則

Well-Architected Framework の持続可能性の柱の推奨事項は、次の基本原則にマッピングされています。

寄稿者

著者: Brett Tackaberry | プリンシパル アーキテクト

その他の寄稿者:

  • Alex Stepney | リード プリンシパル アーキテクト
  • Daniel Lees | クラウド セキュリティ アーキテクト
  • Denise Pearl | サステナビリティ担当グローバル マーケティング リード
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Laura Hyatt | カスタマー エンジニア兼 FSI
  • Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
  • Radhika Kanakam | Google Cloud Well-Architected Framework プログラム リード

低炭素エネルギーを消費するリージョンを使用する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、 Google Cloudのワークロードに低炭素地域を選択するうえで役に立つ推奨事項が示されています。

原則の概要

Google Cloudにワークロードをデプロイする計画を立てる際に、重要なアーキテクチャ上の決定事項は、ワークロードの Google Cloud リージョンの選択です。この決定は、ワークロードのカーボン フットプリントに影響します。二酸化炭素排出量を最小限に抑えるには、リージョン選択戦略に次の要素を含める必要があります。

  • データに基づく選択: リージョンを特定して優先順位を付けるには、リーフアイコン CO2 排出量が少ない指標とカーボンフリー エネルギー（CFE）指標を考慮します。
  • ポリシーベースのガバナンス: 組織ポリシー サービスでリソース ロケーションの制約を使用して、環境に最適なロケーションにリソースの作成を制限します。
  • 運用の柔軟性: タイム シフティングや炭素認識スケジューリングなどの手法を使用して、電力網の二酸化炭素排出原単位が最も低い時間帯にバッチ ワークロードを実行します。

クラウドでアプリケーションとワークロードの実行に使用される電力は、 Google Cloud リージョンの選択に影響する重要な要素です。また、次の要素も考慮してください。

  • データ所在地とデータ主権: データを保存する必要がある場所は、 Google Cloudリージョンの選択を決定する基本的な要素です。この選択は、地域のデータ所在地要件の遵守に影響します。
  • エンドユーザーのレイテンシ: エンドユーザーとアプリケーションをデプロイするリージョン間の地理的な距離は、ユーザー エクスペリエンスとアプリケーションのパフォーマンスに影響します。
  • 費用: Google Cloud リソースの料金はリージョンによって異なる場合があります。

Google Cloud リージョン選択ツールを使用すると、温室効果ガス排出量、費用、レイテンシに関する要件に基づいて最適な Google Cloud リージョンを選択できます。Cloud Location Finder を使用して、近接性、カーボンフリー エネルギー（CFE）の使用量、その他のパラメータの要件に基づいて、 Google Cloud や他のプロバイダのクラウド ロケーションを見つけることもできます。

推奨事項

低炭素リージョンにクラウド ワークロードをデプロイするには、次のセクションの推奨事項を検討してください。これらの推奨事項は、 Google Cloud リージョンのカーボンフリー エネルギーのガイダンスに基づいています。

クラウド リージョンの炭素強度を理解する

リージョンのGoogle Cloud データセンターは、リージョンが配置されている電力網のエネルギーを使用します。Google は、1 時間ごとに計算される CFE 指標を使用して、地域のカーボン インパクトを測定しています。CFE は、1 時間あたりに消費される総エネルギーのうち、カーボンフリー エネルギーの割合を示します。CFE 指標は、次の 2 つの要因によって決まります。

  • 特定の期間にグリッドに電力を供給する発電所の種類。
  • その期間にグリッドに供給された Google 帰属のクリーン エネルギー。

各Google Cloud リージョンの 1 時間あたりの CFE% の集計平均については、 Google Cloud リージョンのカーボンフリー エネルギーをご覧ください。このデータは、GitHub の Carbon free energy for Google Cloud regions リポジトリと BigQuery 一般公開データセットから、マシンリーダブル形式で取得することもできます。

CFE をロケーション選択戦略に組み込む

以下の推奨事項を参考にしてください。

  • アプリケーションに最もクリーンなリージョンを選択します。アプリケーションを長期間実行する場合は、CFE% が最も高いリージョンで実行します。バッチ ワークロードでは、ワークロードの実行時期を予測できるため、リージョンをより柔軟に選択できます。
  • 低炭素リージョンを選択します。 Google Cloud ウェブサイトの特定のページと Google Cloud コンソールのロケーション セレクタには、カーボン フットプリントの影響が最も少ないリージョンに リーフアイコン 低 CO2 インジケーターが表示されます。
  • リソース ロケーションの組織のポリシーの制約を使用して、リソースの作成を特定の低炭素 Google Cloudリージョンに制限します。たとえば、米国の低炭素地域でのみリソースの作成を許可するには、in:us-low-carbon-locations 値グループを指定する制約を作成します。

Google Cloud リソースのロケーションを選択する場合は、データ所在地に関する要件、エンドユーザーへのレイテンシ、アプリケーションの冗長性、サービスの可用性、料金などの要素を含む、リージョン選択のベスト プラクティスも考慮してください。

時間帯別スケジューリングを使用する

電力網の二酸化炭素排出原単位は、1 日を通して大きく変動する可能性があります。変動は、グリッドに電力を供給するエネルギー源の組み合わせによって異なります。ワークロード（特に柔軟性のあるワークロードや緊急性のないワークロード）を、グリッドに供給される CFE の割合が高いときに実行するようにスケジュールできます。

たとえば、多くのグリッドでは、オフピーク時や、太陽光や風力などの再生可能エネルギー源からグリッドに供給される電力が多い時間帯に、CFE の割合が高くなります。モデルのトレーニングや大規模なバッチ推論などのコンピューティング負荷の高いタスクを CFE の高い時間帯にスケジュールすることで、パフォーマンスや費用に影響を与えることなく、関連する二酸化炭素排出量を大幅に削減できます。このアプローチはタイム シフティングと呼ばれます。グリッドの炭素強度の動的な性質を利用して、持続可能性のためにワークロードを最適化します。

エネルギー効率を高めるために AI と ML のワークロードを最適化する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、AI ワークロードと ML ワークロードを最適化してエネルギー使用量と温室効果ガス排出量を削減するための推奨事項が示されています。

原則の概要

持続可能性のために AI / ML ワークロードを最適化するには、ワークロードの設計、デプロイ、運用に包括的なアプローチを採用する必要があります。適切なモデルと Tensor Processing Unit（TPU）などの専用ハードウェアを選択し、低炭素リージョンでワークロードを実行し、リソース使用量を削減するように最適化し、運用のベスト プラクティスを適用します。

AI ワークロードと ML ワークロードの費用とパフォーマンスを最適化するアーキテクチャと運用のプラクティスは、エネルギー消費量の削減とカーボン フットプリントの削減につながります。Well-Architected Framework の AI と ML の視点では、運用、セキュリティ、信頼性、費用、パフォーマンスの目標を満たす AI ワークロードと ML ワークロードを設計、構築、管理するための原則と推奨事項について説明します。また、Cloud アーキテクチャ センターでは、 Google Cloudの AI ワークロードと ML ワークロードの詳細なリファレンス アーキテクチャと設計ガイドを提供しています。

推奨事項

AI / ML ワークロードのエネルギー効率を最適化するには、次のセクションの推奨事項を検討してください。

TPU を使用してエネルギー効率を重視したアーキテクチャを設計する

AI / ML ワークロードは計算負荷が高くなる可能性があります。AI ワークロードと ML ワークロードによるエネルギー消費は、持続可能性を考えるうえで重要な要素です。TPU を使用すると、AI ワークロードと ML ワークロードのエネルギー効率と持続可能性を大幅に向上させることができます。

TPU は、AI ワークロードと ML ワークロード専用に構築されたカスタム設計のアクセラレータです。TPU の特殊なアーキテクチャにより、ディープ ラーニングの基盤となる大規模な行列乗算に非常に効果的です。TPU は、CPU や GPU などの汎用プロセッサよりも効率的に複雑なタスクを大規模に実行できます。

TPU には、持続可能性に直接的なメリットがあります。

  • エネルギー消費量の削減: TPU は、エネルギー効率を最適化するように設計されています。消費電力あたりの計算量が増えます。この専用アーキテクチャにより、大規模なトレーニング タスクと推論タスクの電力需要が大幅に削減され、運用コストの削減とエネルギー消費量の削減につながります。
  • トレーニングと推論の高速化: TPU の優れたパフォーマンスにより、複雑な AI モデルを数日ではなく数時間でトレーニングできます。コンピューティング時間の合計が大幅に削減されるため、環境フットプリントの削減に直接貢献します。
  • 冷却の必要性の低減: TPU には高度な液体冷却が組み込まれており、効率的な熱管理を実現し、データセンターの冷却に使用されるエネルギーを大幅に削減します。
  • AI ライフサイクルの最適化: ハードウェアとソフトウェアを統合することで、TPU はデータ処理からモデル サービングまで、AI ライフサイクル全体にわたって最適化されたソリューションを提供します。

リソース選択に関する 4M のベスト プラクティスに従う

Google は、AI と ML のワークロードのエネルギー使用量と炭素排出量を大幅に削減するためのベスト プラクティスを推奨しています。これらのベスト プラクティスを 4Ms と呼びます。

  • モデル: 効率的な ML モデル アーキテクチャを選択します。たとえば、スパースモデルは、密モデルと比較して ML の品質を向上させ、コンピューティングを 3 ～ 10 倍削減します。
  • マシン: ML トレーニング用に最適化されたプロセッサとシステムを選択します。これらのプロセッサは、汎用プロセッサと比較して、パフォーマンスとエネルギー効率が 2 ～ 5 倍向上します。
  • 自動化: コンピューティング負荷の高いワークロードをクラウドにデプロイします。ワークロードのエネルギー使用量が減り、オンプレミス環境と比較して排出量が 1.4 ～ 2 倍削減されます。クラウド データセンターでは、エネルギー効率を重視して構築された新しいカスタム設計の倉庫が使用されており、電力使用効率（PUE）の比率が高くなっています。オンプレミスのデータセンターは古く、規模が小さいことが多いため、エネルギー効率の高い冷却システムや電力分配システムへの投資が経済的でないことがあります。
  • Map（マッピング）: 最もクリーンなエネルギーを使用する Google Cloud ロケーションを選択します。このアプローチにより、ワークロードの総二酸化炭素排出量を 5 ～ 10 倍削減できます。詳細については、 Google Cloud リージョンにおけるカーボンフリー エネルギーの利用状況をご覧ください。

4Ms のベスト プラクティスと効率指標の詳細については、次のリサーチ ペーパーをご覧ください。

トレーニングと推論用に AI モデルとアルゴリズムを最適化する

AI モデルのアーキテクチャと、トレーニングと推論に使用されるアルゴリズムは、エネルギー消費に大きな影響を与えます。以下の推奨事項を検討してください。

効率的な AI モデルを選択する

パフォーマンス要件を満たす、より小規模で効率的な AI モデルを選択します。使用可能な最大のモデルをデフォルトの選択肢として選択しないでください。たとえば、DistilBERT などの小規模な蒸留モデル バージョンは、BERT などの大規模なモデルよりも、コンピューティングのオーバーヘッドを大幅に削減し、推論を高速化しながら、同等のパフォーマンスを実現できます。

ドメイン固有の超効率的なソリューションを使用する

パフォーマンスが向上し、大規模な基盤モデルよりも大幅に少ないコンピューティング能力で済む、特殊な ML ソリューションを選択します。これらの特殊なソリューションは、多くの場合、事前トレーニングとハイパー最適化が行われています。トレーニング ワークロードと推論ワークロードの両方で、エネルギー消費量と研究開発の労力を大幅に削減できます。ドメイン固有の特殊なソリューションの例を次に示します。

  • Earth AI は、大量のグローバルな地理空間データを合成して、タイムリーで正確な、実用的な分析情報を提供するエネルギー効率の高いソリューションです。
  • WeatherNext は、従来の物理ベースの方法と比較して、より高速で効率的かつ高精度の世界天気予報を生成します。

適切なモデル圧縮手法を適用する

モデル圧縮に使用できる手法の例を次に示します。

  • プルーニング: ニューラル ネットワークから不要なパラメータを削除します。これらは、モデルのパフォーマンスに大きく影響しないパラメータです。この手法により、モデルのサイズと推論に必要なコンピューティング リソースが削減されます。
  • 量子化: モデル パラメータの精度を下げます。たとえば、精度を 32 ビット浮動小数点数から 8 ビット整数に下げます。この手法により、精度を大幅に低下させることなく、メモリ フットプリントと消費電力を大幅に削減できます。
  • 知識蒸留: 大規模で複雑な教師モデルの動作を模倣するように、小規模な生徒モデルをトレーニングします。生徒モデルは、パラメータの数を減らし、エネルギー消費量を抑えながら、高いパフォーマンスを実現できます。

専用のハードウェアを使用する

リソース選択の 4M ベスト プラクティスに従うで説明したように、ML トレーニング用に最適化されたプロセッサとシステムを選択します。これらのプロセッサは、汎用プロセッサと比較して、パフォーマンスとエネルギー効率が 2 ～ 5 倍向上します。

パラメータ エフィシエント ファインチューニングを使用する

モデルの数十億ものパラメータすべてを調整する（フル ファインチューニング）のではなく、Low-Rank Adaptation（LoRA）などのパラメータ エフィシエント ファインチューニング（PEFT）手法を使用します。この手法では、元のモデルの重みを固定し、少数の新しい軽量レイヤのみをトレーニングします。このアプローチは、コストとエネルギー消費量の削減に役立ちます。

AI と ML の運用に関するベスト プラクティスに従う

運用方法が AI / ML ワークロードの持続可能性に大きな影響を与えます。以下の推奨事項を参考にしてください。

モデルのトレーニング プロセスを最適化する

モデル トレーニング プロセスを最適化するには、次の手法を使用します。

  • 早期停止: トレーニング プロセスをモニタリングし、検証セットに対するモデルのパフォーマンスの改善がこれ以上見られない場合に停止します。この手法は、不要な計算やエネルギー消費を防ぐのに役立ちます。
  • 効率的なデータ読み込み: 効率的なデータ パイプラインを使用して、GPU と TPU が常に使用され、データを待機しないようにします。この手法は、リソース使用率を最大化し、エネルギーの無駄を削減するのに役立ちます。
  • 最適化されたハイパーパラメータ調整: 最適なハイパーパラメータをより効率的に見つけるには、ベイズ最適化や強化学習などの手法を使用します。リソースを大量に消費する可能性がある徹底的なグリッド検索は避けてください。

推論の効率を向上させる

AI 推論タスクの効率を高めるには、次の手法を使用します。

  • バッチ処理: 複数の推論リクエストをバッチにグループ化し、GPU と TPU での並列処理を活用します。この手法は、予測あたりのエネルギー コストを削減するのに役立ちます。
  • 高度なキャッシュ保存: 自己回帰生成用の Key-Value（KV）キャッシュ保存とアプリケーション レスポンス用のセマンティック プロンプト キャッシュ保存を含む、多層キャッシュ保存戦略を実装します。この手法は、冗長なモデル計算を回避するのに役立ち、エネルギー使用量と炭素排出量を大幅に削減できます。

測定とモニタリング

次のパラメータをモニタリングして測定します。

  • 使用量と費用: 適切なツールを使用して、AI ワークロードのトークン使用量、エネルギー消費量、カーボン フットプリントを追跡します。このデータは、最適化の機会を特定し、持続可能性の目標に向けた進捗状況を報告するのに役立ちます。
  • パフォーマンス: 本番環境でモデルのパフォーマンスを継続的にモニタリングします。データドリフトなどの問題を特定します。これは、モデルを再度ファインチューニングする必要があることを示している可能性があります。モデルを再トレーニングする必要がある場合は、元のファインチューニング済みモデルを出発点として使用することで、更新にかかる時間、費用、エネルギーを大幅に節約できます。

継続的改善の運用化の詳細については、持続可能性を継続的に測定して改善するをご覧ください。

カーボン アウェア スケジューリングを実装する

最もクリーンなエネルギー ミックスのリージョンで実行するように ML パイプライン ジョブを設計します。Carbon Footprint レポートを使用して、炭素集約度が最も低いリージョンを特定します。ローカル電力網のカーボンフリー エネルギー（CFE）の割合が高い期間に、リソースを大量に消費するタスクをバッチジョブとしてスケジュールします。

データ パイプラインの最適化

ML オペレーションとファインチューニングには、クリーンで高品質なデータセットが必要です。ML ジョブを開始する前に、マネージド データ処理サービスを使用してデータを効率的に準備します。たとえば、ストリーミング処理とバッチ処理には Dataflow を使用し、マネージド Spark パイプラインと Hadoop パイプラインには Dataproc を使用します。最適化されたデータ パイプラインにより、ファインチューニング ワークロードがデータを待機しないようにします。これにより、リソース使用率を最大化し、エネルギーの無駄を削減できます。

MLOps を導入する

ML ライフサイクル全体を自動化して管理するには、ML オペレーション（MLOps）プラクティスを実装します。これらの手法により、モデルが継続的にモニタリング、検証、効率的に再デプロイされるため、不要なトレーニングやリソース割り当てを防ぐことができます。

マネージド サービスを使用する

独自のインフラストラクチャを管理するのではなく、Vertex AI などのマネージド クラウド サービスを使用します。クラウド プラットフォームは基盤となるリソース管理を処理するため、ユーザーはファインチューニング プロセスに集中できます。ハイパーパラメータ チューニング、モデル モニタリング、リソース管理用のツールが組み込まれたサービスを使用します。

次のステップ

サステナビリティのためにリソース使用量を最適化する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、 Google Cloudのワークロードによるリソース使用量を最適化するうえで役に立つ推奨事項が示されています。

原則の概要

リソースの使用量を最適化することは、クラウド環境の持続可能性を高めるうえで非常に重要です。プロビジョニングされるすべてのリソース（コンピューティング サイクルからデータ ストレージまで）は、エネルギー使用量、水使用量、炭素排出量に直接影響します。ワークロードの環境フットプリントを削減するには、クラウド リソースのプロビジョニング、管理、使用時に十分な情報に基づいて選択を行う必要があります。

推奨事項

リソース使用率を最適化するには、以下のセクションの推奨事項を検討してください。

自動スケーリングと動的スケーリングを実装する

自動的かつ動的なスケーリングにより、リソースの使用率が最適化され、アイドル状態や過剰なプロビジョニングによるインフラストラクチャのエネルギーの無駄を防止できます。エネルギーの無駄を減らすことで、コストと炭素排出量を削減できます。

自動的かつ動的なスケーラビリティを実装するには、次の手法を使用します。

水平スケーリングを使用する

水平スケーリングは、ほとんどのクラウド ファースト アプリケーションで推奨されるスケーリング手法です。垂直スケーリングと呼ばれる各インスタンスのサイズを増やす代わりに、インスタンスを追加して負荷を分散します。たとえば、マネージド インスタンス グループ（MIG）を使用して、Compute Engine VM のグループを自動的にスケールアウトできます。水平スケーリングされたインフラストラクチャは、インスタンスの障害がアプリケーションの可用性に影響しないため、復元力が向上します。水平スケーリングは、負荷レベルが変動するアプリケーションにとって、リソース効率の高い手法でもあります。

適切なスケーリング ポリシーを構成する

ワークロードの要件に基づいて自動スケーリング設定を構成します。アプリケーションの動作に固有のカスタム指標としきい値を定義します。CPU 使用率だけに頼るのではなく、非同期タスクのキューの深さ、リクエスト レイテンシ、カスタム アプリケーション指標などの指標を検討してください。頻繁な不要なスケーリングやフラッピングを防ぐには、明確なスケーリング ポリシーを定義します。たとえば、Google Kubernetes Engine（GKE）にデプロイするワークロードの場合は、適切なクラスタ自動スケーリング ポリシーを構成します。

事後対応型と予防型のスケーリングを組み合わせる

リアクティブ スケーリングでは、システムはリアルタイムの負荷の変化に応じてスケーリングします。この手法は、負荷の予測不可能な急増があるアプリケーションに適しています。

事前対応型スケーリングは、固定された毎日の営業時間や週次レポートの生成など、パターンが予測可能なワークロードに適しています。このようなワークロードの場合は、スケジュールされた自動スケーリングを使用してリソースを事前プロビジョニングし、予想される負荷レベルに対応できるようにします。この手法により、リソースの奪い合いを防ぎ、効率を高めてユーザー エクスペリエンスを向上させることができます。この手法は、大規模な販売イベントや集中的なマーケティング活動など、負荷の急増が予想される場合に、事前に計画を立てるうえでも役立ちます。

Google Cloud GKE Autopilot、Cloud Run、MIG などのマネージド サービスと機能は、ワークロード パターンから学習して、事前対応型スケーリングを自動的に管理します。デフォルトでは、Cloud Run サービスがトラフィックを受信しない場合、インスタンスの数がゼロにスケーリングされます。

ステートレス アプリケーションを設計する

アプリケーションを水平方向にスケーリングするには、コンポーネントがステートレスである必要があります。つまり、特定のユーザーのセッションやデータが単一のコンピューティング インスタンスに結び付けられることはありません。セッション状態を Memorystore for Redis などのコンピューティング インスタンスの外部に保存すると、任意のコンピューティング インスタンスが任意のユーザーからのリクエストを処理できます。この設計アプローチにより、シームレスで効率的な水平スケーリングが可能になります。

スケジューリングとバッチを使用する

バッチ処理は、大規模で緊急性の低いワークロードに最適です。バッチジョブは、エネルギー効率と費用を考慮してワークロードを最適化するのに役立ちます。

次の手法を使用して、スケジューリングとバッチジョブを実装します。

低炭素排出係数のスケジュール

バッチジョブを、炭素排出量の少ないリージョンで、地域の電力網のクリーン エネルギーの割合が高い時間帯に実行するようにスケジュールします。リージョンで二酸化炭素排出量が最も少ない時間帯を特定するには、Carbon Footprint レポートを使用します。

重要度の低いワークロードに Spot VM を使用する

Spot VM を使用すると、未使用の Compute Engine 容量を大幅な割引料金で利用できます。Spot VM はプリエンプトできますが、専用の常時オンのリソースを必要とせずに、大規模なデータセットを費用対効果の高い方法で処理できます。Spot VM は、重要度の低いフォールト トレラントなバッチジョブに最適です。

ジョブを統合して並列化する

個々のジョブの起動とシャットダウンのオーバーヘッドを削減するには、類似したジョブを 1 つの大きなバッチにグループ化します。これらの大容量ワークロードは、Batch などのサービスで実行します。このサービスは、必要なインフラストラクチャを自動的にプロビジョニングして管理するため、リソース使用率を最適化できます。

マネージド サービスを使用する

Batch や Dataflow などのマネージド サービスは、リソースのプロビジョニング、スケジューリング、モニタリングを自動的に処理します。クラウド プラットフォームがリソースの最適化を処理します。アプリケーション ロジックに集中できます。たとえば、Dataflow はパイプライン内のデータ量に基づいてワーカー数を自動的にスケーリングするため、アイドル状態のリソースに対して料金を支払う必要はありません。

VM マシン ファミリーをワークロードの要件に合わせる

Compute Engine VM に使用できるマシンタイプは、さまざまなワークロードに最適化されたマシン ファミリーにグループ化されています。ワークロードの要件に基づいて適切なマシン ファミリーを選択します。

マシン ファミリー ワークロード タイプ別の推奨事項 サステナビリティに関するガイダンス
汎用インスタンス（E2、N2、N4、Tau T2A/T2D）: CPU とメモリのバランスの取れた比率を提供します。 ウェブサーバー、マイクロサービス、中小規模のデータベース、開発環境。 E2 シリーズは、リソースの動的な割り当てにより、費用対効果とエネルギー効率に優れています。Tau T2A シリーズは Arm ベースのプロセッサを使用します。これは、大規模なワークロードでパフォーマンス単位あたりのエネルギー効率が高くなることがよくあります。
コンピューティング最適化インスタンス（C2、C3）: これらのインスタンスは、vCPU とメモリの比率が高く、コアあたりのパフォーマンスが高いインスタンスです。 ハイ パフォーマンス コンピューティング（HPC）、バッチ処理、ゲームサーバー、CPU ベースのデータ分析。 C シリーズ インスタンスを使用すると、CPU 使用率の高いタスクをより迅速に完了できるため、ジョブの合計コンピューティング時間とエネルギー消費量を削減できます。
メモリ最適化インスタンス（M3、M2）: 大量のメモリを必要とするワークロード向けに設計されたインスタンスです。 SAP HANA やインメモリ分析などの大規模なインメモリ データベースとデータ ウェアハウス。 メモリ最適化インスタンスを使用すると、メモリ使用量の多いワークロードをより少ない物理ノードに統合できます。この統合により、複数の小規模なインスタンスを使用する場合と比較して、必要なエネルギーの総量が削減されます。高性能メモリを使用すると、データアクセス レイテンシが短縮され、CPU がアクティブ状態になる合計時間を短縮できます。
ストレージ最適化インスタンス（Z3）: これらのインスタンスは、高スループットで低レイテンシのローカル SSD ストレージを提供します。 データ ウェアハウジング、ログ分析、SQL、NoSQL、ベクトル データベース。 ストレージ最適化インスタンスは、大規模なデータセットをローカルで処理するため、ロケーション間のネットワーク データの下り（外向き）に使用されるエネルギーを削減できます。高 IOPS タスクにローカル ストレージを使用すると、複数の標準インスタンスのオーバー プロビジョニングを回避できます。
アクセラレータ最適化インスタンス（A3、A2、G2）: これらのインスタンスは、AI、ML、HPC などの GPU と TPU で高速化されたワークロード用に構築されています。 ML モデルのトレーニングと推論、科学シミュレーション。

TPU は、エネルギー効率を最適化するように設計されています。ワットあたりの計算量が増加します。

NVIDIA H100 GPU を搭載した A3 シリーズなどの GPU アクセラレータ インスタンスは、大規模なモデルのトレーニングにおいて、CPU のみの代替手段よりも大幅にエネルギー効率が優れています。GPU アクセラレータ インスタンスは公称電力使用量が多いですが、タスクははるかに高速に完了します。

最新のマシンタイプにアップグレードする

最新のマシンタイプを使用すると、持続可能性の向上に役立つ可能性があります。マシンタイプが更新されると、多くの場合、エネルギー効率が向上し、ワットあたりのパフォーマンスが高くなるように設計されます。最新のマシンタイプを使用する VM は、同じ量の作業をより少ない電力消費で完了する可能性があります。

CPU、GPU、TPU は、多くの場合、次のようなチップ アーキテクチャの技術的進歩の恩恵を受けます。

  • 特殊なコア: プロセッサの進歩には、一般的なワークロード用の特殊なコアや命令が含まれることがよくあります。たとえば、CPU にはベクトル オペレーション専用のコアや統合 AI アクセラレータが搭載されている場合があります。これらのタスクをメイン CPU からオフロードすると、タスクがより効率的に完了し、消費電力が削減されます。
  • 電源管理の改善: チップ アーキテクチャの進歩には、ワークロードに基づく電圧と周波数の動的調整など、より高度な電源管理機能が含まれることがよくあります。これらの電源管理機能により、チップはピーク効率で動作し、アイドル状態になると低電力状態に移行するため、エネルギー消費を最小限に抑えることができます。

チップ アーキテクチャの技術的な改善により、持続可能性と費用に関して次のような直接的なメリットが得られます。

  • ワットあたりのパフォーマンスの向上: これは持続可能性の重要な指標です。たとえば、同じエネルギー消費量で C3 VM と比較すると、C4 VM のコスト パフォーマンスは 40% 高くなります。C4A プロセッサは、同等の x86 プロセッサよりもエネルギー効率が 60% 向上しています。これらのパフォーマンス機能により、タスクをより迅速に完了したり、同じ負荷に対して使用するインスタンスの数を減らしたりできます。
  • 総エネルギー消費量の削減: プロセッサの改善により、特定のタスクでコンピューティング リソースが使用される時間が短縮され、全体的なエネルギー使用量とカーボン フットプリントが削減されます。バッチジョブや ML モデルのトレーニングなど、短期間でコンピューティング負荷の高いワークロードでは、特に炭素排出量が多くなります。
  • 最適なリソース使用率: 最新のマシンタイプは、最新のソフトウェアに適しており、クラウド プラットフォームの高度な機能との互換性が高い傾向があります。これらのマシンタイプでは、通常、リソース使用率が向上するため、オーバー プロビジョニングの必要性が減り、電力のすべてのワットを生産的に使用できます。

コンテナ化されたアプリケーションをデプロイする

GKE や Cloud Run などのコンテナベースのフルマネージド サービスは、持続可能なクラウド コンピューティングの戦略の一部として使用できます。これらのサービスは、リソース使用率の最適化とリソース管理の自動化に役立ちます。

Cloud Run のスケールダウン機能を利用する

Cloud Run は、サービスへの受信トラフィックがない場合やジョブが完了した場合に、インスタンスを自動的にゼロにスケールするマネージド サーバーレス環境を提供します。自動スケーリングにより、アイドル状態のインフラストラクチャによるエネルギー消費を削減できます。リソースは、リクエストをアクティブに処理している場合にのみ電力が供給されます。この戦略は、断続的なワークロードやイベント ドリブン ワークロードに非常に効果的です。AI ワークロードでは、Cloud Run で GPU を使用できます。これにより、GPU が使用されている場合にのみ GPU を使用して料金を支払うことができます。

GKE を使用してリソースの最適化を自動化する

GKE はコンテナ オーケストレーション プラットフォームであり、アプリケーションが必要なリソースのみを使用するようにします。リソースの最適化を自動化するために、GKE は次の手法を提供します。

  • ビンパッキング: GKE Autopilot は、使用可能なノードに複数のコンテナをインテリジェントにパッキングします。ビンパッキングは、各ノードの使用率を最大化し、アイドル状態または使用率の低いノードの数を減らして、エネルギー消費量の削減に役立ちます。
  • 水平 Pod 自動スケーリング（HPA）: HPA を使用すると、CPU 使用率やカスタム アプリケーション固有の指標などの事前定義された指標に基づいて、コンテナ レプリカ（Pod）の数が自動的に調整されます。たとえば、アプリケーションでトラフィックの急増が発生した場合、GKE は需要を満たすために Pod を追加します。トラフィックが減少すると、GKE は Pod の数を減らします。この動的スケーリングにより、リソースの過剰なプロビジョニングが防止されるため、不要なコンピューティング容量の料金を支払ったり、電力を供給したりする必要がなくなります。
  • 垂直 Pod 自動スケーリング（VPA）: 個々のコンテナの CPU とメモリの割り当てと上限を自動的に調整するように GKE を構成できます。この構成により、コンテナに必要以上のリソースが割り当てられないため、リソースのオーバー プロビジョニングを防ぐことができます。
  • GKE 多次元 Pod 自動スケーリング: 複雑なワークロードの場合、HPA と VPA を同時に構成して、Pod の数と各 Pod のサイズの両方を最適化できます。この手法により、必要なパフォーマンスに対して可能な限り最小のエネルギー フットプリントを確保できます。
  • トポロジ認識スケジューリング（TAS）: TAS は、データセンター インフラストラクチャの物理構造に基づいて Pod を配置することで、GKE の AI ワークロードと ML ワークロードのネットワーク効率を高めます。TAS は、ネットワーク ホップを最小限に抑えるために、ワークロードを戦略的にコロケーションします。このコロケーションにより、通信レイテンシとエネルギー消費を削減できます。ノードと専用ハードウェアの物理的な配置を最適化することで、TAS はタスクの完了を高速化し、大規模な AI / ML ワークロードのエネルギー効率を最大化します。

カーボン アウェア スケジューリングを構成する

Google では、クリーンな電力を供給できる場所と時間帯にワークロードを継続的に移行しています。また、古い機器を別のユースケースに再利用（ハーベスティング）しています。このカーボン アウェア スケジューリング戦略を使用すると、コンテナ化されたワークロードでクリーン エネルギーを使用できます。

カーボン アウェア スケジューリングを実装するには、リージョンのデータセンターに電力を供給するエネルギー ミックスに関する情報をリアルタイムで取得する必要があります。この情報は、GitHub の Carbon free energy for Google Cloud regions リポジトリまたは BigQuery 一般公開データセットから、マシンリーダブル形式で取得できます。Google の年間二酸化炭素データセットの計算に使用される 1 時間ごとのグリッド ミックスと二酸化炭素排出原単位のデータは、Electricity Maps から取得されます。

カーボン アウェア スケジューリングを実装するには、次の手法をおすすめします。

  • 地理的シフト: 再生可能エネルギー源の使用率が高いリージョンでワークロードを実行するようにスケジュールします。このアプローチにより、よりクリーンな電力網を使用できます。
  • 時間シフト: バッチ処理などの柔軟な非クリティカル ワークロードの場合は、オフピーク時や再生可能エネルギーが最も豊富なときにワークロードを実行するように構成します。このアプローチは時間シフトと呼ばれ、クリーン エネルギー源が利用可能なときにそれを利用することで、全体的な二酸化炭素排出量の削減に役立ちます。

エネルギー効率の高い障害復旧を設計する

障害復旧（DR）の準備には、セカンダリ リージョンに冗長リソースを事前プロビジョニングすることがよくあります。ただし、アイドル状態または十分に活用されていないリソースは、エネルギーの無駄を大幅に引き起こす可能性があります。リソース使用率を最大化し、目標復旧時間（RTO）を損なうことなくカーボン フットプリントの影響を最小限に抑える DR 戦略を選択します。

コールド スタートの効率性を最適化する

次の方法を使用して、セカンダリ（DR）リージョンでアクティブなリソースを最小限に抑えるか、排除します。

  • コールド DR を優先する: DR リージョンのリソースをオフにするか、ゼロにスケーリングした状態にします。このアプローチは、アイドル状態のコンピューティング リソースの二酸化炭素排出量を削減するのに役立ちます。
  • サーバーレス フェイルオーバーを活用する: Cloud Run などのマネージド サーバーレス サービスを DR エンドポイントに使用します。Cloud Run は使用されていないときはゼロにスケーリングされるため、トラフィックが DR リージョンに転送されるまでエネルギーを消費しない DR トポロジを維持できます。
  • Infrastructure as Code（IaC）で復旧を自動化する: リソースを DR サイトで実行（ウォーム）状態に保つ代わりに、Terraform などの IaC ツールを使用して、必要な場合にのみ環境を迅速にプロビジョニングします。

冗長性と使用率のバランスを取る

リソースの冗長性は、エネルギーの無駄遣いの主な原因です。冗長性を減らすには、次の方法を使用します。

  • アクティブ / パッシブよりもアクティブ / アクティブを優先する: アクティブ / パッシブ設定では、パッシブ サイトのリソースがアイドル状態になり、エネルギーが無駄になります。最適にサイズ設定されたアクティブ / アクティブ アーキテクチャにより、両方のリージョンでプロビジョニングされたすべてのリソースがトラフィックをアクティブに処理します。このアプローチにより、インフラストラクチャのエネルギー効率を最大化できます。
  • 冗長性を適切に調整する: 高可用性または DR の要件を満たすためにレプリケーションが必要な場合にのみ、リージョン間でデータとサービスを複製します。レプリカを追加するたびに、永続ストレージとネットワーク下り（外向き）のエネルギー費用が増加します。

エネルギー効率に優れたソフトウェアを開発する

Google Cloud Well-Architected Framework の持続可能性の柱におけるこの原則では、エネルギー消費とサーバー負荷を最小限に抑えるソフトウェアを作成するための推奨事項が示されています。

原則の概要

ベスト プラクティスに沿ってクラウド アプリケーションを構築すると、クラウド インフラストラクチャ リソース（AI、コンピューティング、ストレージ、ネットワーク）で使用されるエネルギーを最適化できます。また、データセンターの水の必要量や、エンドユーザーのデバイスがアプリケーションにアクセスする際に消費するエネルギーを削減するのにも役立ちます。

エネルギー効率の高いソフトウェアを構築するには、設計と開発からデプロイ、メンテナンス、アーカイブまで、ソフトウェア ライフサイクル全体で持続可能性を考慮する必要があります。AI を使用してクラウド ワークロードの環境への影響を最小限に抑えるソフトウェアを構築する方法については、 Google Cloud 電子書籍『Build Software Sustainably』をご覧ください。

推奨事項

このセクションの推奨事項は、次の重点分野にグループ化されています。

計算作業を最小限に抑える

エネルギー効率の高いソフトウェアを作成するには、アプリケーションが実行する計算作業の合計量を最小限に抑える必要があります。不要な命令、冗長なループ、余分な機能は、エネルギー、時間、リソースを消費します。次の推奨事項に沿って、最小限の計算を行うソフトウェアを構築します。

簡潔で的を絞ったコードを記述する

必要な結果を得るために不可欠な最小限のコードを記述するには、次のアプローチを使用します。

  • 冗長なロジックと機能の肥大化を排除する: 必要な機能のみを実行するコードを記述します。計算オーバーヘッドと複雑さを増大させるものの、ユーザーに測定可能な価値を提供しない機能は避けてください。
  • リファクタリング: エネルギー効率を長期的に改善するには、アプリケーションを定期的に監査して、使用されていない機能を特定します。必要に応じて、このような機能を削除またはリファクタリングする措置を講じます。
  • 不要なオペレーションを回避する: 結果が必要になるまで、値を計算したりアクションを実行したりしないでください。遅延評価などの手法を使用して、アプリケーションの依存コンポーネントが出力を必要とするまで計算を遅延させます。
  • コードの読みやすさと再利用性を優先する: 読みやすく再利用可能なコードを記述します。このアプローチでは、重複が最小限に抑えられ、Don't Repeat Yourself（DRY）の原則に従います。これにより、ソフトウェア開発とメンテナンスによる二酸化炭素排出量を削減できます。

バックエンド キャッシュ保存を使用する

バックエンド キャッシュ保存により、アプリケーションが同じ作業を繰り返し実行しないようにします。キャッシュ ヒット率が高いと、リクエストあたりのエネルギー消費量がほぼ線形に減少します。バックエンド キャッシュを実装するには、次の手法を使用します。

  • 頻繁に使用されるデータをキャッシュに保存する: 頻繁にアクセスされるデータを一時的な高パフォーマンスのストレージ ロケーションに保存します。たとえば、Memorystore などのメモリ内キャッシュ保存サービスを使用します。アプリケーションがキャッシュからデータを取得すると、データベース クエリとディスク I/O オペレーションの量が減ります。その結果、バックエンドのデータベースとサーバーの負荷が軽減されます。
  • API レスポンスをキャッシュに保存する: 冗長でコストのかかるネットワーク呼び出しを回避するため、頻繁な API リクエストの結果をキャッシュに保存します。
  • インメモリ キャッシュ保存を優先する: 低速なディスク I/O オペレーションと複雑なデータベース クエリを排除するには、高速メモリ（RAM）にデータを保存します。
  • 適切なキャッシュ書き込み戦略を選択します。
    • ライトスルー戦略では、データがキャッシュと永続ストアの両方に同期的に書き込まれます。この戦略により、キャッシュ ヒットの可能性が高まるため、永続ストアに送信されるエネルギー消費量の多い読み取りリクエストが少なくなります。
    • ライトバック（ライトビハインド）戦略により、書き込み負荷の高いアプリケーションのパフォーマンスが向上します。データは最初にキャッシュに書き込まれ、データベースは後で非同期的に更新されます。この戦略により、低速のデータベースに対する書き込み負荷が軽減されます。
  • スマートな削除ポリシーを使用する: キャッシュを効率的に維持します。古いデータや有用性の低いデータを削除し、頻繁にリクエストされるデータに使用できるスペースを最大化するには、有効期間（TTL）、Least Recently Used（LRU）、Least Frequently Used（LFU）などのポリシーを使用します。

効率的なアルゴリズムとデータ構造を使用する

選択するアルゴリズムとデータ構造によって、ソフトウェアの計算複雑度が決まります。適切なアルゴリズムとデータ構造を選択すると、タスクの完了に必要な CPU サイクル数とメモリ オペレーションの数を最小限に抑えることができます。CPU サイクルとメモリ オペレーションが少ないほど、エネルギー消費量が少なくなります。

最適な時間計算量のアルゴリズムを選択する

必要な結果を最短時間で達成するアルゴリズムを優先します。このアプローチは、リソース使用時間の短縮に役立ちます。リソース使用量を最適化するアルゴリズムを選択するには、次の方法を使用します。

  • 複雑さの軽減に重点を置く: 複雑さを評価するには、ランタイム指標だけでなく、アルゴリズムの理論上の複雑さも考慮します。たとえば、バブルソートと比較して、マージソートでは、大規模なデータセットの計算負荷とエネルギー消費量が大幅に削減されます。
  • 冗長な作業を避ける: 選択したプログラミング言語またはフレームワークの組み込みの最適化された関数を使用します。これらの関数は、C や C++ などの下位レベルでエネルギー効率の高い言語で実装されることが多いため、カスタムコードの関数と比較して、基盤となるハードウェア向けに最適化されています。

効率性を考慮してデータ構造を選択する

選択するデータ構造によって、データの取得、挿入、処理の速度が決まります。この速度は CPU とメモリの使用率に影響します。効率的なデータ構造を選択するには、次のアプローチを使用します。

  • 検索と取得用に最適化する: アイテムが存在するかどうかの確認や特定の値の取得などの一般的なオペレーションでは、速度用に最適化されたデータ構造を優先します。たとえば、ハッシュマップやハッシュセットを使用すると、ほぼ一定の時間でルックアップを実行できます。これは、配列を線形検索するよりもエネルギー効率の高いアプローチです。
  • メモリ フットプリントを最小限に抑える: 効率的なデータ構造は、アプリケーションの全体的なメモリ フットプリントの削減に役立ちます。メモリ アクセスと管理が削減されるため、消費電力が削減されます。また、メモリ プロファイルが軽量化されることで、プロセスをより効率的に実行できるようになり、リソースのアップグレードを延期できます。
  • 専用の構造を使用する: 特定の問題専用に構築されたデータ構造を使用します。たとえば、文字列プレフィックスの高速検索には trie データ構造を使用し、最大値または最小値のみに効率的にアクセスする必要がある場合は優先度キューを使用します。

コンピューティングとデータ オペレーションを最適化する

ソフトウェアを開発する際は、テクノロジー スタック全体でリソースを効率的かつ比例的に使用することに重点を置きます。CPU、メモリ、ディスク、ネットワークは、制限された共有リソースとして扱います。リソースを効率的に使用すると、コストとエネルギー消費量を大幅に削減できることを認識します。

CPU 使用率とアイドル時間を最適化する

CPU が有意義な作業を行わずにアクティブな状態を維持する時間を最小限に抑えるには、次の方法を使用します。

  • ポーリングよりもイベント ドリブン ロジックを優先する: リソースを大量に消費するビジー ループや定数チェック（ポーリング）をイベント ドリブン ロジックに置き換えます。イベント ドリブン アーキテクチャでは、アプリケーションのコンポーネントは関連するイベントによってトリガーされた場合にのみ動作します。このアプローチにより、オンデマンド処理が可能になり、リソースを大量に消費するポーリングが不要になります。
  • 高頻度の継続を回避する: CPU が常に最高頻度で動作することを強制しないコードを記述します。消費電力を最小限に抑えるため、アイドル状態のシステムは低電力状態またはスリープモードに移行できる必要があります。
  • 非同期処理を使用する: アイドル待機中にスレッドがロックされないようにするには、非同期処理を使用します。このアプローチにより、リソースが解放され、全体的なリソース使用率が向上します。

メモリとディスク I/O を効率的に管理する

メモリとディスクの使用率が低いと、不要な処理が発生し、消費電力が増加します。メモリと I/O を効率的に管理するには、次の手法を使用します。

  • 厳格なメモリ管理: 未使用のメモリリソースを積極的に解放するアクションを実行します。必要以上に長い期間、大きなオブジェクトをメモリに保持しないようにします。このアプローチにより、パフォーマンスのボトルネックが回避され、メモリ アクセスに使用される電力が削減されます。
  • ディスク I/O を最適化する: 永続ストレージ リソースに対するアプリケーションの読み取り / 書き込みインタラクションの頻度を減らします。たとえば、中間メモリバッファを使用してデータを保存します。固定間隔で、またはバッファが一定のサイズに達したときに、データを永続ストレージに書き込みます。
  • バッチ オペレーション: 頻繁に実行される小さなディスク オペレーションを、より大きなバッチ オペレーションに統合します。バッチ オペレーションは、多くの個別の小規模なトランザクションよりもエネルギー消費量が少なくなります。
  • 圧縮を使用する: 適切なデータ圧縮手法を適用して、ディスクに書き込まれるデータ量またはディスクから読み取られるデータ量を減らします。たとえば、Cloud Storage に保存するデータを圧縮するには、非圧縮トランスコーディングを使用します。

ネットワーク トラフィックを最小限に抑える

ネットワーク リソースは、データ転送オペレーション中に大量のエネルギーを消費します。ネットワーク通信を最適化するには、次の手法を使用します。

  • ペイロード サイズを最小限に抑える: リクエストに必要なデータのみを転送するように API とアプリケーションを設計します。少数のフィールドのみが必要な場合は、大きな JSON 構造や XML 構造の取得や返却を避けます。返されるデータ構造が簡潔であることを確認します。
  • ラウンドトリップを減らす: ユーザー アクションを完了するために必要なネットワーク ラウンドトリップの数を減らすには、よりスマートなプロトコルを使用します。たとえば、HTTP/1.1 よりも HTTP/3 を優先し、REST よりも GraphQL を選択し、バイナリ プロトコルを使用し、API 呼び出しを統合します。ネットワーク呼び出しの量を減らすと、サーバーとエンドユーザー デバイスの両方のエネルギー消費量を減らすことができます。

フロントエンドの最適化を実装する

フロントエンドの最適化により、エンドユーザーがダウンロードして処理する必要があるデータが最小限に抑えられ、エンドユーザー デバイスのリソースの負荷を軽減できます。

コードとアセットを最小限に抑える

エンドユーザーがより小さく、より効率的に構造化されたリソースをダウンロードして処理する必要がある場合、デバイスの消費電力が少なくなります。エンドユーザーのデバイスでのダウンロード量と処理負荷を最小限に抑えるには、次の手法を使用します。

  • 最小化と圧縮: JavaScript、CSS、HTML ファイルについては、適切な最小化ツールを使用して、空白文字やコメントなどの不要な文字を削除します。画像などのファイルが圧縮され、最適化されていることを確認します。CI/CD パイプラインを使用すると、ウェブ アセットの最小化と圧縮を自動化できます。
  • 遅延読み込み: 画像、動画、重要でないアセットは、実際に必要になったとき（ウェブページのビューポートにスクロールされたときなど）にのみ読み込みます。このアプローチにより、初期データ転送の量とエンドユーザー デバイスの処理負荷が軽減されます。
  • JavaScript バンドルのサイズを小さくする: 最新のモジュール バンドラと、ツリー シェイキングなどの手法を使用して、JavaScript バンドルから未使用のコードを削除します。このアプローチにより、ファイルが小さくなり、読み込みが速くなり、サーバー リソースの使用量が少なくなります。
  • ブラウザ キャッシュ: HTTP キャッシュ ヘッダーを使用して、静的アセットをローカルに保存するようユーザーのブラウザに指示します。ブラウザ キャッシュを使用すると、その後のアクセスでダウンロードが繰り返されたり、不要なネットワーク トラフィックが発生したりするのを防ぐことができます。

軽量なユーザー エクスペリエンス（UX）を優先する

ユーザー インターフェースの設計は、フロントエンド コンテンツのレンダリングの計算複雑性に大きな影響を与える可能性があります。軽量な UX を提供するフロントエンド インターフェースを構築するには、次の手法を使用します。

  • 効率的なレンダリング: リソースを大量に消費する Document Object Model（DOM）の操作を頻繁に行わないようにします。レンダリングの複雑さを最小限に抑え、不要な再レンダリングを排除するコードを記述します。
  • 軽量設計パターン: 適切な場合は、静的サイトまたはプログレッシブ ウェブアプリ（PWA）を優先します。このようなサイトやアプリは読み込みが速く、必要なサーバー リソースも少なくなります。
  • アクセシビリティとパフォーマンス: 応答性が高く、読み込みの速いサイトは、持続可能性とアクセシビリティが高い傾向があります。最適化されたすっきりとしたデザインにより、コンテンツのレンダリング時に消費されるリソースが削減されます。パフォーマンスと速度が最適化されたウェブサイトは、収益の増加に役立ちます。Deloitte と Google の調査研究「Milliseconds Make Millions」によると、サイトの速度が 0.1 秒（100 ミリ秒）速くなると、小売サイトのコンバージョン率が 8.4% 向上し、平均注文額が 9.2% 増加します。

持続可能性のためにデータとストレージを最適化する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、 Google Cloudのストレージ リソースのエネルギー効率と二酸化炭素排出量を最適化するうえで役に立つ推奨事項が示されています。

原則の概要

保存されたデータは受動的なリソースではありません。データのライフサイクル全体でエネルギーが消費され、二酸化炭素が排出されます。保存されたデータの 1 ギガバイトごとに、継続的に電源が供給され、冷却され、管理される物理インフラストラクチャが必要です。持続可能なクラウド アーキテクチャを実現するには、データを価値があるが環境コストの高い資産として扱い、事前対応型のデータ ガバナンスを優先します。

データの保持、品質、ロケーションに関する決定は、クラウド費用とエネルギー消費量を大幅に削減するのに役立ちます。保存するデータを最小限に抑え、データの保存場所と保存方法を最適化し、自動削除とアーカイブ戦略を実装します。データ クラッターを減らすと、システム パフォーマンスが向上し、データの長期的な環境フットプリントが根本的に削減されます。

推奨事項

持続可能性を高めるためにデータ ライフサイクルとストレージ リソースを最適化するには、次のセクションの推奨事項を検討してください。

価値の高いデータを優先する

未使用、重複、または廃止された保存データは、基盤となるインフラストラクチャの電力を消費し続けます。ストレージ関連のカーボン フットプリントを削減するには、次の手法を使用します。

重複を特定して排除する

複数の Google Cloud プロジェクトまたはサービス間でデータセットが不必要に複製されないようにするポリシーを確立します。BigQuery データセットや Cloud Storage バケットなどの一元化されたデータ リポジトリを唯一の信頼できる情報源として使用し、これらのリポジトリへの適切なアクセス権を付与します。

シャドー データとダークデータを削除する

ダークデータとは、有用性や所有者が不明なデータです。シャドーデータとは、データの不正なコピーを意味します。Dataplex Universal Catalog などのデータ検出とカタログ化ソリューションを使用して、ストレージ システムをスキャンし、ダークデータとシャドーデータを見つけます。これらの結果を定期的に監査し、必要に応じてダークデータとシャドーデータのアーカイブまたは削除のプロセスを実装します。

AI ワークロードのデータ量を最小限に抑える

モデルのトレーニングとサービングに必要な特徴量と処理済みデータのみを保存します。可能な場合は、データ サンプリング、集計、合成データ生成などの手法を使用して、大規模な元データセットに依存せずにモデルのパフォーマンスを実現します。

データ品質チェックを統合する

データ取り込み時に、Dataproc、Dataflow、Dataplex Universal Catalog などのサービスを使用して、自動データ検証とデータ クリーニングのパイプラインを実装します。低品質のデータは、ストレージ容量の無駄につながります。また、後でデータが分析や AI トレーニングに使用されるときに、不必要なエネルギー消費につながります。

データの値密度を確認する

ログや IoT ストリームなどの大容量データセットを定期的に確認します。必要な情報密度を維持し、物理ストレージの容量を削減するために、データを要約、集計、ダウンサンプリングできるかどうかを判断します。

バックアップの必要性を批判的に評価する

最小限の労力で再生成できるデータのバックアップの必要性を評価します。このようなデータの例としては、中間 ETL 結果、エフェメラル キャッシュ、安定した永続的なソースから派生したトレーニング データなどがあります。バックアップは、一意のデータまたは再作成にコストがかかるデータのみを保持します。

ストレージ ライフサイクル管理を最適化する

データの有用性が低下したときに、データがエネルギー効率の高いストレージ クラスに移動されるか、適切に廃止されるように、ストレージのライフサイクルを自動化します。次の手法を使用します。

適切な Cloud Storage クラスを選択する

オブジェクトのライフサイクル管理を使用して、Cloud Storage 内のデータをアクセス頻度に基づいて低炭素ストレージ クラスに自動的に移行します。

  • Standard ストレージは、現在の本番環境モデルなど、アクティブに使用されているデータセットにのみ使用します。
  • 古い AI トレーニング データセットやアクセス頻度の低いバックアップなどのデータを Nearline ストレージまたは Coldline ストレージに移行します。
  • 長期保存には、大規模なエネルギー効率に最適化された Archive ストレージを使用します。

積極的なデータ ライフサイクル ポリシーを実装する

ログファイル、一時モデル アーティファクト、古い中間結果など、重要でないデータに対して明確で自動化された有効期間（TTL）ポリシーを定義します。ライフサイクル ルールを使用して、定義された期間の経過後にこのようなデータを自動的に削除します。

リソースのタグ付けを義務付ける

すべての Cloud Storage バケット、BigQuery データセット、永続ディスクで一貫したリソースタグとラベルの使用を義務付けます。データの所有者、データの目的、保持期間を示すタグを作成します。組織のポリシー サービスの制約を使用して、保持期間などの必要なタグがリソースに適用されていることを確認します。タグを使用すると、ライフサイクル管理の自動化、詳細な FinOps レポートの作成、炭素排出量レポートの作成を行うことができます。

コンピューティング ストレージのサイズを適正化してプロビジョニング解除する

Compute Engine インスタンスにアタッチされている永続ディスクを定期的に監査し、ディスクがオーバー プロビジョニングされていないことを確認します。スナップショットは、バックアップに必要な場合にのみ使用してください。古い未使用のスナップショットを削除します。データベースの場合は、データ保持ポリシーを使用して、基盤となる永続ディスクのサイズを削減します。

ストレージ形式を最適化する

分析ワークロードに使用するストレージには、JSON や CSV などの行ベースの形式よりも、Parquet や最適化された Avro などの圧縮された列形式を使用することをおすすめします。列形式のストレージは、物理ディスク容量の要件を大幅に削減し、読み取り効率を向上させます。この最適化により、関連するコンピューティング オペレーションと I/O オペレーションのエネルギー消費量を削減できます。

地域性とデータ移動を最適化する

データの物理的なロケーションと移動は、ネットワーク リソースの使用量とストレージに必要なエネルギーに影響します。次の手法を使用して、データの地域性を最適化します。

低炭素ストレージ リージョンを選択する

コンプライアンス要件に応じて、カーボンフリー エネルギー（CFE）の割合が高いリージョン、またはグリッドの二酸化炭素排出原単位が低いリージョンにデータを保存します。 Google Cloud リソース ロケーションの組織のポリシーの制約を使用して、高炭素排出地域のストレージ バケットの作成を制限します。 Google Cloud リージョンの CFE と二酸化炭素排出原単位のデータについては、 Google Cloud リージョンのカーボンフリー エネルギーをご覧ください。

レプリケーションを最小限に抑える

必須の障害復旧（DR）または高可用性（HA）の要件を満たす場合にのみ、リージョン間でデータを複製します。クロスリージョンとマルチリージョンのレプリケーション オペレーションは、データのエネルギー コストとカーボン フットプリントを大幅に増加させます。

データ処理のロケーションを最適化する

ネットワーク データ転送のエネルギー消費量を削減するには、AI トレーニングや BigQuery 処理などのコンピューティング負荷の高いワークロードをデータソースと同じリージョンにデプロイします。

パートナーと顧客のデータ移動を最適化する

クラウド サービス、ロケーション、プロバイダ間で大量のデータを移動するには、パートナーとお客様に Storage Transfer Service またはデータ共有 API の使用を推奨します。大量のデータダンプは避けてください。一般公開データセットの場合は、リクエスト元の支払バケットを使用して、データ転送と処理の費用と環境への影響をエンドユーザーに転嫁します。

サステナビリティを継続的に測定して改善する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、 Google Cloudでワークロードのサステナビリティを測定して継続的に改善するうえで役に立つ推奨事項が示されています。

原則の概要

クラウド ワークロードの持続可能性を確保するには、正確で透明性の高い指標が必要です。検証可能な指標を使用すると、サステナビリティの目標をアクションに変換できます。クラウドで作成するすべてのリソースには、関連付けられたカーボン フットプリントがあります。持続可能なクラウド アーキテクチャを構築して維持するには、炭素データの測定を運用フィードバック ループに統合する必要があります。

このセクションの推奨事項は、カーボン フットプリントを使用して、炭素排出量の定量化、炭素ホットスポットの特定、対象を絞ったワークロードの最適化の実装、最適化の取り組みの結果の検証を行うためのフレームワークを提供します。このフレームワークを使用すると、費用最適化の目標と検証可能な炭素削減目標を効率的に調整できます。

Carbon Footprint の報告方法

Carbon Footprint は、クラウド関連の排出量に関する透明性、監査可能性、グローバルな整合性を備えたレポートを提供します。このレポートは、主に二酸化炭素排出量の報告と会計に関する温室効果ガス（GHG）プロトコルなどの国際基準に準拠しています。Carbon Footprint レポートでは、ロケーション ベースと市場ベースの算定方法を使用します。ロケーション ベースのアカウンティングは、地域の電力網の排出係数に基づいています。市場ベースの会計では、Google によるカーボンフリー エネルギー（CFE）の購入が考慮されます。このデュアル アプローチにより、 Google Cloudでのワークロードの物理グリッドへの影響と炭素排出量の削減効果の両方を把握できます。

使用されるデータソース、Scope 3 の対象、顧客割り当てモデルなど、Carbon Footprint レポートの作成方法について詳しくは、Carbon Footprint の報告方法をご覧ください。

推奨事項

継続的な改善に炭素排出量の測定を使用するには、次のセクションの推奨事項を検討してください。推奨事項は、設計による持続可能なクラウド オペレーションを実装するための成熟度のフェーズとして構成されています。

フェーズ 1: ベースラインを確立する

このフェーズでは、必要なツールを設定し、データにアクセスして正しく統合できるようにします。

  1. 権限を付与する: FinOps、SecOps、プラットフォーム エンジニアリングなどのチームに権限を付与して、 Google Cloud コンソールでカーボン フットプリント ダッシュボードにアクセスできるようにします。Identity and Access Management（IAM）で、適切な請求先アカウントにカーボン フットプリント閲覧者ロール（roles/billing.carbonViewer）を付与します。
  2. データ エクスポートを自動化する: BigQuery へのCarbon Footprint データの自動エクスポートを構成します。エクスポートされたデータを使用すると、詳細な分析を実行し、炭素データを費用データや使用量データと関連付け、カスタム レポートを作成できます。
  3. 炭素関連の重要業績評価指標（KPI）を定義する: 炭素排出量をビジネス価値に関連付ける指標を確立します。たとえば、炭素排出原単位は、顧客、取引、収益単位あたりの CO2 換算のキログラム数を測定する指標です。

フェーズ 2: 炭素排出量の多い場所を特定する

カーボン フットプリント レポートの詳細なデータを分析して、環境への影響が最も大きい領域を特定します。この分析には、次の手法を使用します。

  • スコープ別に優先順位付けする: 総炭素排出量が最も多い排出元をすばやく特定するには、プロジェクト、リージョン、サービス別にダッシュボードのデータを分析します。
  • 二重会計を使用する: ある地域の炭素排出量を評価する際は、ロケーション ベースの排出量（地域の電力網の環境への影響）と市場ベースの排出量（Google の CFE 投資のメリット）の両方を考慮します。
  • 費用との関連付け: BigQuery のカーボンデータを課金データと結合し、最適化アクションが持続可能性と費用に与える影響を評価します。多くの場合、コストが高いと炭素排出量も多くなります。
  • データをアノテーションして、労力に対する収益率（ROE）を測定する: BigQuery の炭素データに、リソースの適正化や大規模なサービスの廃止などの特定のイベントをアノテーションします。アノテーションを使用すると、二酸化炭素排出量と費用の削減を特定の最適化イニシアチブに帰属させることができるため、各イニシアチブの結果を測定して示すことができます。

フェーズ 3: ターゲットを絞った最適化を実装する

これは、設計による持続可能なクラウド オペレーションを実装するための実行フェーズです。費用と炭素排出量の大きな要因として特定した特定のリソースを最適化するには、次の戦略を使用します。

  • 放置されたプロジェクトを廃止する: 二酸化炭素排出量データと統合されている放置されたプロジェクトの Recommender を定期的に確認します。炭素排出量とコストを直ちに削減し、その効果を確認するには、未使用のプロジェクトのレビューと最終的な削除を自動化します。
  • リソースのサイズを適正化する: Active Assist のサイズ適正化のRecommender（Compute Engine VM のマシンタイプに関する推奨事項など）を使用して、プロビジョニングされたリソース容量を実際の使用率に合わせます。コンピューティングを多用するタスクや AI ワークロードには、最も効率的なマシンタイプと AI モデルを使用します。
  • カーボン アウェア スケジューリングを採用する: 時間が重要でないバッチ ワークロードの場合は、リージョン CFE データをスケジューリング ロジックに統合します。可能な場合は、組織のポリシー サービスのリソース ロケーションの制約を使用して、新しいリソースの作成を低炭素リージョンに制限します。
  • データ スプロールを削減する: データ ガバナンス ポリシーを実装して、アクセス頻度の低いデータが適切なコールド ストレージ クラス（Nearline、Coldline、Archive）に移行されるか、完全に削除されるようにします。この戦略は、ストレージ リソースのエネルギー費用を削減するのに役立ちます。
  • アプリケーション コードを改善する: リソースの過剰な使用や不要な計算の原因となるコードレベルの非効率性を修正します。

詳しくは以下をご覧ください。

フェーズ 4: サステナビリティの取り組みとレポート作成を制度化する

このフェーズでは、炭素排出量の測定をガバナンス フレームワークに組み込みます。このアプローチにより、組織が継続的な持続可能性の改善と検証可能なレポート作成に必要な機能と制御を確実に備えることができます。

  • GreenOps ガバナンスを実装する: GreenOps の正式な機能またはワーキング グループを確立して、カーボン フットプリント データを Cloud Billing データと統合します。この機能では、プロジェクト全体の炭素削減目標に対する説明責任を定義し、費用最適化と持続可能性の目標を調整し、費用に対する炭素効率を追跡するレポートを実装する必要があります。
  • レポートとコンプライアンスに Carbon Footprint データを使用する: BigQuery の検証済みで監査可能な Carbon Footprint データを使用して、環境、社会、ガバナンス（ESG）に関する正式な開示を作成します。このアプローチにより、透明性に対するステークホルダーの要求を満たし、義務的および自主的な規制の遵守を確保できます。
  • トレーニングと意識向上に投資する: 関連する技術チームと非技術チームに、持続可能性に関する必修のトレーニングを実施します。チームは、Carbon Footprint データにアクセスして解釈する方法と、最適化の推奨事項を日々のワークフローと設計上の選択に適用する方法を理解する必要があります。詳細については、ロールベースのサステナビリティ トレーニングを提供するをご覧ください。
  • 炭素要件を定義する: 新しいデプロイのアプリケーションの受け入れ基準に、炭素排出量指標を非機能要件（NFR）として組み込みます。このプラクティスは、アーキテクトとデベロッパーがアプリケーション開発ライフサイクルの開始時から低炭素設計オプションを優先できるようにするのに役立ちます。
  • GreenOps を自動化する: スクリプト、テンプレート、Infrastructure as Code（IaC）パイプラインを使用して、Active Assist の推奨事項の実装を自動化します。このプラクティスにより、チームは推奨事項を組織全体で一貫して迅速に適用できます。

持続可能性の文化を推進する

Google Cloud Well-Architected Framework の持続可能性の柱におけるこの原則では、組織全体のチームが持続可能性のプラクティスを認識し、習熟している文化を構築するうえで役に立つ推奨事項が示されています。

原則の概要

持続可能性のプラクティスを適用するには、ツールや手法だけでは不十分です。教育とアカウンタビリティによって推進される文化の変革が必要です。チームは、持続可能性に関する懸念事項を認識し、持続可能性に関する取り組みの実践的な熟練度を備えている必要があります。

  • 持続可能性の認識とは、すべてのアーキテクチャと運用の意思決定が持続可能性に具体的な影響を与えるというコンテキスト知識です。クラウドは仮想リソースの抽象的な集合体ではなく、エネルギーを消費して炭素排出量を生成する物理リソースによって駆動されることを認識する必要があります。
  • 持続可能性の実践に関する熟練度には、炭素排出量データを解釈する知識、クラウドの持続可能性ガバナンスを実装した経験、エネルギー効率を高めるためにコードをリファクタリングする技術スキルが含まれます。

持続可能性の取り組みを組織の目標に合わせるには、クラウド インフラストラクチャとソフトウェアによるエネルギー使用量が組織のカーボン フットプリントにどのように影響するかをチームが理解する必要があります。適切に計画されたトレーニングは、開発者やアーキテクトから財務担当者や運用エンジニアまで、すべての関係者が日々の業務の持続可能性のコンテキストを理解するのに役立ちます。この共通認識により、チームは受動的なコンプライアンスから積極的な最適化へと移行し、クラウド ワークロードを設計段階から持続可能なものにすることができます。サステナビリティは、セキュリティ、費用、パフォーマンス、信頼性に関する他の要件と同様に、重要な非機能要件（NFR）になります。

推奨事項

持続可能性に関する懸念事項と持続可能性の実践に関する熟練度を高めるには、以下のセクションの推奨事項を検討してください。

ビジネスのコンテキストと組織の目標との整合性を提供する

持続可能性は単なる技術的な取り組みではなく、個々の行動を組織の環境ミッションに沿ったものにする文化的な変化が必要です。チームがサステナビリティに関する取り組みの理由を理解すると、その取り組みをオプションのタスクではなく、基本原則として採用する可能性が高くなります。

全体像を把握する

低炭素地域を選択したり、データ パイプラインを最適化したりするなど、個々のアーキテクチャの選択が組織の全体的な持続可能性の取り組みにどのように貢献するかをチームが理解できるようにします。これらの選択が地域社会や業界にどのような影響を与えるかを明確に伝えます。抽象的な炭素指標を、企業の社会的責任（CSR）目標の達成に向けた進捗状況を示す具体的な指標に変換します。

たとえば、次のようなメッセージは、ワークロードを低炭素リージョンに移行し、電力効率の高いマシンタイプを使用するという決定の肯定的な結果と、経営陣の認識をチームに伝えます。このメッセージでは、CO2 換算値が参照されます。これにより、チームは炭素削減対策の影響を把握できます。

「データ分析エンジンを us-central1 リーフアイコン Low CO2 リージョンに移行し、クラスタを C4A Axion ベースのインスタンスにアップグレードすることで、カーボン プロファイルを根本的に変更しました。この移行により、データ分析エンジンの炭素集約度が 75% 削減され、今四半期には 12 メートルトンの CO2 換算量が削減されました。この移行はビジネス目標に大きな影響を与えたため、第 4 四半期の取締役会向けニュースレターに記載されました。」

財務目標とサステナビリティ目標を伝える

透明性は、持続可能性に関する取り組みを目標に沿って進めるうえで重要です。可能な範囲で、持続可能性に関する目標と進捗状況を組織全体で広く共有します。年次財務諸表で持続可能性の進捗状況をハイライトします。このようなコミュニケーションにより、技術チームは自らの仕事を組織の一般向けコミットメントと財務の健全性の重要な一部と見なすようになります。

運命共有の考え方を取り入れる

クラウドの持続可能性の共同作業の性質についてチームに説明します。Google は、インフラストラクチャとデータセンターの効率性など、クラウドの持続可能性に責任を負っています。お客様は、クラウド内のリソースとワークロードの持続可能性に責任を負います。このコラボレーションを運命を共有するパートナーシップとして捉えることで、組織と Google が協力して最適な環境成果を達成するという認識を強化できます。

役割に応じたサステナビリティ トレーニングを提供する

持続可能性が理論的な概念ではなく実践的なスキルとなるように、持続可能性に関するトレーニングを特定の職務に合わせて調整します。データ サイエンティストが使用できるサステナビリティ ツールと手法は、次の表に示すように、FinOps アナリストが使用できるものとは大きく異なります。

ロール トレーニングの焦点
データ サイエンティストと ML エンジニア コンピューティングの炭素強度: レガシー システムで AI トレーニング ジョブを実行する場合と、専用の AI アクセラレータで実行する場合の違いを示します。パラメータの少ないモデルで、必要な精度を大幅に低いエネルギー消費で実現できることを強調します。
デベロッパー コードの効率とリソース消費量: レイテンシの高いコードや非効率なループが、CPU の実行時間の延長やエネルギー消費量の増加に直接つながることを説明します。軽量コンテナの重要性と、ソフトウェアの環境フットプリントを削減するためにアプリケーションのパフォーマンスを最適化する必要性を強調します。
アーキテクト 設計による持続可能性: リージョンの選択とワークロードの配置に重点を置きます。リーフアイコン CO2 排出量が少なく、再生可能エネルギーの割合が高いリージョン（northamerica-northeast1 など）を選択すると、コードを 1 行も記述する前に、アプリケーション スタック全体のカーボン プロファイルが根本的に変わることを示します。
プラットフォーム エンジニアと運用エンジニア 使用率の最大化: アイドル状態のリソースと過剰なプロビジョニングの環境コストを強調します。クラウド リソースを効率的に使用するために、自動スケーリングと適切なサイジングのシナリオを提示します。使用率などの持続可能性に関連する指標を作成して追跡する方法と、コンピューティング時間などの指標を二酸化炭素排出量の同等の指標に変換する方法について説明します。
FinOps 炭素の単位経済性: 財務支出と環境への影響の関係に焦点を当てます。GreenOps のプラクティスにより、組織がトランザクションあたりの炭素排出量を追跡し、持続可能性を費用や使用率などの従来の KPI と同程度に重要な重要業績評価指標（KPI）にできることを説明します。
プロダクト マネージャー 機能としてのサステナビリティ: 炭素排出量削減の目標をプロダクト ロードマップに統合する方法を説明します。簡素化されたユーザー ジャーニーが、クラウド リソースとエンドユーザー デバイスの両方のエネルギー消費量を削減するのにどのように役立つかを示します。
ビジネス リーダー 戦略的整合性とレポート: クラウドの持続可能性が環境、社会、ガバナンス（ESG）のスコアと一般の評判にどのように影響するかを重視します。サステナビリティに関する選択が、規制リスクの軽減と、コミュニティや業界に対するコミットメントの履行にどのように役立つかを説明します。

持続可能性を推進し、成功を認識する

長期的な進歩を維持するには、内部の技術的な修正にとどまらず、パートナーや業界に影響を与え始める必要があります。

サステナビリティを推進するよう管理者を支援する

環境への影響を、市場投入までの時間やコストなどの他のビジネス指標と同様に優先順位付けするために必要なデータと権限を管理者に提供します。このデータを取得すると、管理者は持続可能性を、生産性を低下させる望ましい機能ではなく、品質と効率の基準として捉え始めます。より詳細な炭素データや特定のリージョンでのより新しい環境に優しいプロセッサなど、新しいクラウド プロバイダの機能を積極的に提唱しています。

業界標準とフレームワークに準拠する

サステナビリティへの取り組みの信頼性と測定可能性を確保するため、社内慣行をグローバルおよび地域の認定基準に合わせます。詳細については、持続可能性に関するプラクティスを業界ガイドラインに沿って調整するをご覧ください。

サステナビリティへの取り組みを奨励する

持続可能性をエンジニアリング文化の永続的な一部にするには、チームが持続可能性を優先することの価値を認識する必要があります。上位の目標から、改善と効率性を評価する具体的で測定可能な KPI に移行します。

炭素 KPI と NFR を定義する

持続可能性を中核的な技術要件として扱います。100 万リクエストあたりの CO2 換算グラム数や、AI トレーニング実行あたりの炭素強度などの炭素 KPI を定義すると、持続可能性への影響を可視化して、対策を講じることができます。たとえば、すべての新しいプロジェクトの NFR に持続可能性を統合します。つまり、システムが特定のレイテンシや可用性の目標を満たす必要があるのと同様に、定義された炭素排出量の予算内に収まる必要もあります。

労力対効果を測定する

チームが、バッチジョブを別のリージョンに移行するなど、効果が高く労力が少ない持続可能性の向上策と、効果が最小限にとどまる可能性のある複雑なコードのリファクタリング作業とを区別できるようにします。労力に対するリターン（ROE）を可視化します。チームがより効率的なプロセッサ ファミリーを選択する場合は、新しいプロセッサへの移行に必要な時間と労力に対して、どの程度の炭素排出量を削減できるかを正確に把握する必要があります。

二酸化炭素排出量の削減を認識して祝う

持続可能性への影響は、インフラストラクチャのバックグラウンドに隠れていることがよくあります。持続可能性の進捗を加速させるには、成功事例を組織全体に公開します。たとえば、モニタリング ダッシュボードでアノテーションを使用して、チームが特定の持続可能性最適化をデプロイした日時をマークします。この可視性により、チームはダッシュボードのデータを参照して、成功を主張できます。

サステナビリティに関する取り組みを業界のガイドラインに沿って実施する

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、サステナビリティの取り組みを調整する必要がある業界のガイドラインとフレームワークの概要が示されています。

原則の概要

サステナビリティ イニシアチブが、測定、レポート、検証に関する世界的に認められた方法に基づいて構築されるように、次の業界ガイドラインに沿ってイニシアチブを調整することをおすすめします。

サステナビリティ イニシアチブをこれらの共通の外部ガイドラインに沿って実施すると、投資家、規制機関、その他の外部関係者が求める信頼性と監査可能性がイニシアチブに付与されます。また、エンジニアリング チーム全体で説明責任を促進し、従業員トレーニングに持続可能性を組み込み、クラウド オペレーションを環境、社会、ガバナンス（ESG）に関する報告のための全社的な取り組みに統合することにも成功しています。

W3C Web Sustainability Guidelines

W3C Web Sustainability Guidelines（WSG）は、デジタル プロダクトとサービスの環境への影響に対処するために W3C ワーキング グループが開発した、ベスト プラクティスの新しいフレームワークです。このガイドラインは、ビジネス戦略とプロダクト戦略、ユーザー エクスペリエンス（UX）デザイン、ウェブ開発、ホスティング、インフラストラクチャ、システムなど、デジタル ソリューションのライフサイクル全体を対象としています。WSG の主な目標は、デベロッパーやアーキテクトが、エネルギー効率が高く、ネットワーク トラフィック、クライアントサイドの処理、サーバーサイドのリソース消費を削減するウェブサイトやウェブ アプリケーションを構築できるようにすることです。これらのガイドラインは、アプリケーション レベルの持続可能性をクラウド レベルのアーキテクチャ上の決定と整合させるための重要な基準点となります。

Green Software Foundation

Green Software Foundation（GSF）は、持続可能なソフトウェアを中心とした業界エコシステムの構築に注力しています。その使命は、二酸化炭素排出量を最小限に抑えるように設計、構築、運用されるソフトウェアの作成を推進することです。GSF は、あらゆるソフトウェアの炭素排出率を測定するための共通の標準を提供するソフトウェア炭素強度（SCI）仕様を開発しました。GSF に準拠することで、デベロッパーはアプリケーションの効率をクラウド環境の炭素排出量に直接関連付けることができます。

温室効果ガス プロトコル

温室効果ガス（GHG）プロトコルは、温室効果ガス排出量の測定、管理、公的報告に関する基準として広く使用されています。このプロトコルは、世界資源研究所（WRI）と持続可能な開発のための世界経済人会議（WBCSD）のパートナーシップを通じて開発されました。GHG プロトコルは、企業の気候変動会計の基本的なフレームワークを提供します。Carbon Footprint レポートには、クラウドの使用に関連する排出量スコープのデータが提供されます。詳細については、Carbon Footprint の報告方法をご覧ください。

GHG プロトコルに準拠することで、サステナビリティ イニシアチブの信頼性を確保し、外部の当事者が炭素排出量データを監査できるようになります。また、グリーンウォッシュと見なされるのを防ぎ、投資家、規制当局、外部の利害関係者のデュー デリジェンス要件を満たすこともできます。検証および監査済みのデータは、組織がアカウンタビリティを証明し、一般向けの持続可能性への取り組みに対する信頼を築くのに役立ちます。