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 の協力関係により、エコシステム全体の環境フットプリントを削減することです。

AI を活用してビジネス効果を高める

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

AI は、膨大なデータセットを行動につながるインサイトに変換することで、サステナビリティの触媒として機能します。これにより、組織は事後対応型のコンプライアンスから、次のような分野でのプロアクティブな最適化に移行できます。

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

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

  • Google Earth AI: 地球規模の地理空間データを使用して、環境の変化を分析し、サプライ チェーンへの影響をモニタリングします。
  • WeatherNext: 高度な天気予報と気候リスク分析を提供し、気候変動に対するレジリエンスを構築できるようにします。
  • Google Earth を使用した地理空間分析情報: 地理空間データを使用して、ロケーションに豊富なコンテキスト データを追加します。これにより、よりスマートなサイト選択、リソース計画、運用が可能になります。
  • Google マップのルートの最適化: 物流と配送ルートを最適化して、効率を高め、燃料消費量と交通による排出量を削減します。

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

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

エージェント スキルを使用してワークロードを評価する

AI エージェントがこの柱の原則と推奨事項に照らしてクラウド ワークロードを評価できるようにするには、GitHub の Google Agent Skills リポジトリにある google-cloud-waf-sustainability スキルを使用します。

スキルをインストールするには、エージェントのクライアントまたはターミナルで次のコマンドを実行します。

npx skills add google/skills --skill google-cloud-waf-sustainability

プロンプトが表示されたら、スキルをインストールする AI エージェントを指定し、インストール スコープ（プロジェクトまたはグローバル）を設定します。

スキルがすでにインストールされている場合は、次のコマンドを実行して最新バージョンに更新できます。

npx skills update

基本原則

Well-Architected Framework のサステナビリティの柱の推奨事項は、次の基本原則にマッピングされています。

寄稿者

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

その他の寄稿者:

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

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

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

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

4M のベスト プラクティスと効率指標の詳細については、次の研究論文をご覧ください。

トレーニングと推論のために 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 パイプラインには Managed Service for Apache Spark を使用します。最適化されたデータ パイプラインにより、ファインチューニング ワークロードがデータを待機することがなくなり、リソースの使用率を最大化してエネルギーの無駄を削減できます。

MLOps を導入する

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

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

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

次のステップ

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

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 など）に保存すると、任意のコンピューティング インスタンスが任意のユーザーからのリクエストを処理できます。この設計アプローチにより、シームレスで効率的な水平スケーリングが可能になります。

スケジュール設定とバッチを使用する

バッチ処理は、大規模で緊急性の低いワークロードに最適です。バッチジョブは、エネルギー効率に優れた費用対効果の高いワークロードの最適化に役立ちます。

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

二酸化炭素排出原単位が低い時間帯にスケジュールする

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

重要でないワークロードに 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 アクセラレーション インスタンスは公称電力使用量が高くなりますが、タスクははるかに高速に完了します。

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

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

CPU、GPU、TPU は、次のようなチップ アーキテクチャの技術的な進歩の恩恵を受けることがよくあります。

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

チップ アーキテクチャの技術的な改善により、サステナビリティと費用に次のような直接的なメリットがもたらされます。

  • ワットあたりのパフォーマンスの向上: これはサステナビリティの重要な指標です。たとえば、C4 VM は、同じエネルギー消費量で C3 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 の Google Cloud リージョンのカーボンフリー エネルギー リポジトリまたは BigQuery の一般公開データセットから、機械で読み取り可能な形式で取得できます。Google の年間炭素データセットの計算に使用される 1 時間ごとのグリッド ミックスと二酸化炭素排出原単位のデータは、Electricity Maps から取得されます。

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

  • 地理的なシフト: 再生可能エネルギー源の使用率が高いリージョンで実行されるようにワークロードをスケジュールします。このアプローチにより、よりクリーンな電力網を使用できます。
  • 時間シフト: バッチ処理などの重要度が低く、柔軟なワークロードの場合は、オフピーク時間や再生可能エネルギーが最も豊富な時間帯に実行されるようにワークロードを構成します。このアプローチは時間シフトと呼ばれ、クリーン エネルギー源が利用可能なときにそれを利用することで、全体的な温室効果ガス排出量を削減できます。

エネルギー効率に優れた障害復旧を設計する

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

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

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

  • コールド DR を優先する: DR リージョンのリソースをオフにするか、ゼロへのスケーリングされた状態にします。このアプローチにより、アイドル状態のコンピューティング リソースの二酸化炭素排出量を削減できます。
  • サーバーレス フェイルオーバーを活用する: DR エンドポイントに Cloud Run などのマネージド サーバーレス サービスを使用します。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）、最も長い間使われていないデータが削除される（LRU）、最も使用頻度の低いデータが削除される（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 を提供するフロントエンド インターフェースを構築するには、次の手法を使用します。

  • 効率的なレンダリング: リソースを大量に消費する頻繁なドキュメント オブジェクト モデル（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 バケットなどの中央データ リポジトリを信頼できる唯一の情報源として使用し、これらのリポジトリに適切なアクセス権を付与します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用されるデータソース、スコープ 3 の包含、お客様の割り当てモデルなど、カーボン フットプリント レポートの作成方法の詳細については、カーボン フットプリントの報告方法をご覧ください。

推奨事項

継続的な改善のために炭素測定を使用するには、以下のセクションの推奨事項を検討してください。推奨事項は、サステナブル バイ デザインのクラウド オペレーションを実装するための成熟度のフェーズとして構成されています。

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

このフェーズでは、必要なツールを設定し、データにアクセス可能で、正しく統合されていることを確認します。

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

フェーズ 2: 二酸化炭素排出量のホットスポットを特定する

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

  • スコープ別に優先順位を付ける: 二酸化炭素排出量が最も多いプロジェクト、リージョン、サービスを迅速に特定するには、ダッシュボードのデータを分析します。
  • 二重会計を使用する: リージョンのカーボン フットプリントを評価する場合は、ロケーション ベースの排出量（地域の電力網の環境への影響）と市場ベースの排出量（Google の CFE 投資のメリット）の両方を考慮します。
  • 費用との相関関係を把握する: BigQuery の炭素データを課金データと結合し、最適化アクションがサステナビリティと費用に与える影響を評価します。費用と二酸化炭素排出量は多くの場合、同じ傾向を示しますが、費用は初期の指標としてのみ使用できます。たとえば、カーボンフリー エネルギー（CFE）スコアが高い高コストのリージョンでは、ワークロードのコストは高くなりますが、市場ベースの排出量は少なくなります。最適化の前提条件は、常に実際のロケーションベースの指標と市場ベースの指標に照らして検証してください。
  • データにアノテーションを付けて、努力に対するリターン（ROE）を測定する: BigQuery の炭素データに、リソースのサイズ適正化や大規模なサービスのデコミッションなどの特定のイベントのアノテーションを付けます。アノテーションを使用すると、二酸化炭素排出量と費用の削減を特定の最適化イニシアチブに関連付けることができるため、各イニシアチブの結果を測定して実証できます。

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

これは、設計段階からサステナビリティを考慮したクラウド運用を実装するための実行フェーズです。次の戦略を使用して、費用と二酸化炭素排出量の主な要因として特定した特定のリソースを最適化します。

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

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

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

このフェーズでは、炭素測定をガバナンス フレームワークに組み込みます。このアプローチにより、組織はサステナビリティの継続的な改善と検証可能なレポート作成に必要な機能と管理を確保できます。

  • GreenOps ガバナンスを実装する: 正式な GreenOps 機能またはワーキング グループを確立して、Carbon Footprint データを Cloud Billing データと統合します。毎月の BigQuery カーボン エクスポートを、Looker などの既存の FinOps ダッシュボードに直接統合します。二酸化炭素と費用のデータを 1 つのインターフェースに表示することで、サステナビリティを標準の運用レビュー サイクルに組み込むことができます。この機能では、プロジェクト全体の二酸化炭素削減目標に対する説明責任を定義し、費用最適化をサステナビリティ目標に合わせ、支出に対する二酸化炭素効率を追跡するレポートを実装する必要があります。
  • レポートとコンプライアンスに 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 リーフアイコン 低 CO2 リージョンに移行し、クラスタを C4A Axion ベースのインスタンスにアップグレードしたことで、カーボン プロファイルが根本的に変わりました。この移行により、データ分析エンジンの二酸化炭素排出原単位が 75% 削減されました。これは、今四半期に 12 メートルトンの CO2 換算の削減に相当します。この移行は当社のビジネス目標に大きな影響を与え、取締役会向けの第 4 四半期のニュースレターにも掲載されました。」

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

透明性は、サステナビリティの実践を目標に合わせるために不可欠です。可能な限り、サステナビリティの目標と進捗状況を組織全体で広く共有します。年次財務諸表でサステナビリティの進捗状況を強調する。このようなコミュニケーションにより、技術チームは、組織の公約と財務の健全性の重要な部分として、自分たちの仕事を見ることができます。

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

クラウドのサステナビリティの協調的な性質についてチームを教育します。Google は、インフラストラクチャとデータセンターの効率性など、クラウドのサステナビリティに責任を負います。お客様は、クラウド「内」のリソースとワークロードのサステナビリティに責任を負います。このコラボレーションを運命を共有するパートナーシップとして位置付けることで、組織と Google が協力して最適な環境成果を達成するという理解を強化できます。

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

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

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

サステナビリティを提唱し、成功を評価する

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

マネージャーがサステナビリティを推進できるようにする

市場投入までの時間やコストなどの他のビジネス指標と同様に、環境への影響を優先するために必要なデータと権限をマネージャーに提供します。このデータを入手したマネージャーは、サステナビリティを、生産を遅らせる「あればよい」機能ではなく、品質と効率の基準として捉えるようになります。また、より詳細な二酸化炭素排出量データや、特定のリージョンにおける新しい環境に優しいプロセッサなど、クラウド プロバイダの新機能を積極的に提唱しています。

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

サステナビリティへの取り組みが信頼でき、測定可能であることを確認するには、内部の慣行を、認められたグローバルおよび地域の基準に合わせます。詳細については、サステナビリティの実践を業界ガイドラインに合わせるをご覧ください。

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

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

炭素 KPI と NFR を定義する

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

労力対効果を測定する

バッチジョブを別のリージョンに移行するなど、影響が大きく、労力が少ないサステナビリティの成果を特定できるようにチームを支援します。これに対して、複雑なコード リファクタリング演習では、最小限の成果しか得られない可能性があります。取り組みに対するリターン（ROE）を可視化します。チームがより効率的なプロセッサ ファミリーを選択する場合、新しいプロセッサへの移行に必要な時間と労力に対して、回避した二酸化炭素排出量を正確に把握する必要があります。

二酸化炭素削減を認識して称える

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

サステナビリティの実践を業界ガイドラインに合わせる

Google Cloud Well-Architected Framework のサステナビリティの柱におけるこの原則では、サステナビリティの取り組みを整合させるべき業界ガイドラインとフレームワークの概要について説明します。

原則の概要

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

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

W3C ウェブ サステナビリティ ガイドライン

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

Green Software Foundation

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

温室効果ガスプロトコル

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

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