Google Cloud 二酸化炭素排出量を削減する

このドキュメントでは、環境のサステナビリティに対する Google Cloud のアプローチについて説明します。Google Cloud の二酸化炭素排出量を理解するために使用できる情報やその他のリソースと、フットプリントを小さくしたり最小限に抑えたりするための方法が含まれています。このドキュメントの対象者は次のとおりです。

  • 二酸化炭素排出量が最小限のアプリケーションを構築するデベロッパー。
  • 現在の二酸化炭素排出量を把握して、排出量を削減する機会を特定するインフラストラクチャ チームやその他の技術チーム。

このドキュメントは、Google Cloud と仮想マシン(VM)ワークロードの実行に精通されていることを前提としています。

クラウドの二酸化炭素排出量の把握

Google は2007 年からカーボン ニュートラルに配慮しており、2030 年までに 100% カーボンフリー エネルギーを 24 時間年中無休で活用するように取り組んでいます。 Google Cloud サービスを実行しているデータセンターを含む Google のデータセンターでは、通常のデータセンターよりもエネルギー消費量が大幅に少なくなっています。このため、Google Cloud を使用することで現在の IT の二酸化炭素排出量を削減できます。

Google は複数のクラウド リージョンを運用しており、データセンターのグローバル ネットワークを経由して提供されます。これらのデータセンターでは、クラウド サービスを実行するためにローカル グリッドで発電される電力を消費します。ローカル グリッドで発電される電力が環境に与える影響は、グリッド炭素強度によって測定されます。グリッド炭素強度は、グリッドの電力を発電する発電所から排出される二酸化炭素の量を示します。

さまざまなエネルギー源の組み合わせや生産効率などの要因があるため、データセンターのすべてのロケーションで環境の影響が均等なわけではありません。2017 年以降、Google は電力購入契約(PPA)を使用して、同じ年にグローバルで消費する電力と同等の再生可能エネルギーの調達も行っています。これらの PPA により Google に起因するカーボンフリー エネルギーの生産が実現し、Google のデータセンターが電力を消費する電力網に含まれます。

Google のデータセンターが消費する電力が環境に与える影響は、電力網の炭素強度と Google によるカーボンフリー エネルギーを組み合わせることで決定します。Google では、これら 2 つの要素から計算されたカーボンフリー エネルギー パーセンテージ(CFE%)の指標を導入しました。CFE% は、各リージョンの 1 時間あたりの平均カーボンフリー エネルギー消費を表し、お客様のアプリケーションがカーボンフリー エネルギーで稼働する平均時間の割合を表します。よりクリーンなエネルギー供給により、同じワークロードで CFE 率が高いリージョンは、CFE% が低いリージョンよりも二酸化炭素排出量が少なくなります。

二酸化炭素排出量を削減するには、クラウド ワークロードで二酸化炭素ベースの供給源から消費する電力量を削減する必要があります。二酸化炭素排出量を減らすには、次の主な戦略をおすすめします。

  1. 平均時間 CFE% が高く、電力網の炭素強度が低いクラウド リージョンを選択します。CFE% が同じリージョンの場合は、電力網の炭素強度を使用して、これらのリージョンの排出パフォーマンスをさらに比較します。
  2. クラウド ワークロードを最適化して、二酸化炭素排出量を削減します。たとえば、弾力性のあるクラウド サービスと自動スケーリング機能を使用して未使用のコンピューティング リソースを最小限に抑え、電力網の炭素強度が低いときにバッチ ワークロードを実行して、効率を高めます。
  3. 組織のポリシーを設定して、クラウド リソースのロケーションをよりクリーンなリージョンに制限します。

二酸化炭素排出量を把握する

Google Cloud には Google Cloud の使用状況から二酸化炭素の排出量を把握するのに役立つ Carbon Footprint ツールがあります。Carbon Footprint は、ローカル電力網の炭素強度に基づいた合計排出量を示しています。このレポートではさらに、お客様が所有する Google Cloud プロジェクトとお客様が使用するクラウド サービスへの排出量に基づいています。排出量データは、Google の二酸化炭素排出量のレポート手法に従って報告され、Google Cloud のお客様として温室効果ガス(GHG)プロトコル スコープ 3 標準のレポート要件で支援できます。Carbon Footprint データを BigQuery にエクスポートして、さらに分析を行うことができます。

Carbon Footprint ダッシュボードと BigQuery Export を使用すると、Google Cloud サービスを使用することで位置情報を利用した排出量を把握できます。このデータを使用して、さまざまな Google Cloud サービスの二酸化炭素排出量を比較できます。たとえば、相対的な排出量を把握するために、同じクラウド リージョンで実行されている 2 つ以上のサービスの合計排出量を比較できます。

Carbon Footprint レポートに基づく、Google Cloud のお客様固有の温室効果ガスの総排出量データは、第三者による検証も保証もされていません。

最適なクラウド リージョンを選択する

よりクリーンなクラウド リージョンを選択してワークロードを実行することは、二酸化炭素排出量を削減するための最も簡単で効果的な方法の 1 つです。Google は地方の電力グリッドの CFE% とグリッド二酸化炭素排出原単位を含むすべてのクラウド リージョンの二酸化炭素データを公開しています。全体の排出量を削減するには、可能な場合は CFE% がより高いリージョンを選択することをおすすめします。よりクリーンなリージョンを選択するのに役立つように、Google Cloud では、コンソールのロケーション セレクタと Google Cloud ドキュメントの [ロケーション] ページの一部に Low CO2 インジケーターが含まれています。このインジケーターを受け取るためにリージョンが満たす必要がある基準については、Google Cloud リージョンのカーボンフリー エネルギーをご覧ください。

複数のリージョンで同様の CFE% がある場合、電力網の炭素強度を比較します。ロケーションに基づく排出量の削減に注力している場合は、さまざまなリージョンの電力網の炭素強度を比較することも重要です。たとえば、同様の CFE% スコアの場合、電力網は、石炭発電所またはガス発電所のいずれかから電力を供給できます。電力網の炭素強度は、この組み合わせを反映しており、最も低い炭素排出量の電力網を選択するのに役立ちます。

排出量を減らすことは、リージョンを選択する際にバランスを取る必要がある多くの要件の 1 つです。たとえば、特定の Google Cloud サービスの可用性、料金、データ ロケーションの要件、ユーザーへのサービス レイテンシなどを検討する必要があります。全体的に、CFE% が最も高いリージョンは、このユースケースに適していない場合があります。排出量を最小限に抑えるには、CFE% が高く、すべての要件を満たすリージョンを選択します。

リージョンの選択を簡素化するには、Google Cloud リージョン選択ツールを使用して、二酸化炭素排出量、料金、レイテンシに基づいて要件を満たす最適なクラウド リージョンを決定します。Google Cloud リージョン選択ツールの詳細については、最適な Google Cloud リージョンを選ぶをご覧ください。

組織でユーザーに使用するクラウド リージョンの選択肢を提供する場合は、ロケーションを制限する組織ポリシーを低 CO2 リージョンに設定することも検討できます。

最適なクラウド サービスを選択する

Google Cloud には、さまざまな IT ワークロードに適した幅広いクラウド サービスが用意されています。既存の二酸化炭素排出量を削減するには、VM ワークロードを、オンプレミスのデータセンターをはじめとするエネルギー効率の低いインフラストラクチャから Compute Engine に移行することを検討してください。オンプレミスのデータセンターとさまざまなクラウド環境から VM を Google Cloud に移行する方法については、Migrate to Virtual Machines を使用した VM の移行をご覧ください。

多くのワークロードは VM を必要としません。代わりに、VM をさまざまなワークロード タイプ向けの他のフルマネージド サービスにデプロイできます。これらのサービスには、多くの場合、パフォーマンスとリソースの使用量の最適化に役立つ自動スケーリングとサイズ適正化の機能が組み込まれています。たとえば、Cloud Run は完全なサーバーレス環境で、コンテナ化されたアプリケーションをすばやくスケーリングできます。また、VM で同等のアプリケーション スタックを実行する場合と比較して、アイドル状態のリソースを削減できます。アイドル状態のリソースを削減することで、コストが適正化され、二酸化炭素排出量が削減されます。

一般的なワークロードの種類には、次のサービスを検討してください。このサービスのリストはすべてを網羅しているわけではありませんが、さまざまなマネージド サービスで(多くの場合自動的に)クラウド リソースの使用量を最適化し、クラウド費用と二酸化炭素排出量を削減する方法について説明しています。

  • Cloud Run: 選択した言語で書かれた、コンテナ化されたアプリケーションを実行するためのサーバーレスのサービス。トラフィックに応じてゼロから N 個のコンテナ インスタンスにすばやく自動スケーリングする機能があります。トラフィックがない場合、アプリケーションはサービスの提供にコンピューティング リソースを使用しません。サービスは、突発的なトラフィック パターンを処理し、それに応じてコンピューティング リソースの使用を最適化するように設計されています。
  • Cloud Functions: サーバーレスの Functions as a Service(FaaS)サービスです。Cloud Run や App Engine と同じインフラストラクチャで動作し、同様のゼロから高速の自動スケーリング機能を Cloud Functions に拡張します。
  • Google Kubernetes Engine(GKE): マネージド Kubernetes 環境を提供するクラウド サービスです。VM を直接使用する場合と比較して、GKE で Kubernetes 環境を使用してコンテナ化されたワークロードを実行すると、未使用のクラウド リソースが最小限に抑えられ、ワークロードのクラウドコストの削減と二酸化炭素排出量の低下を実現できます。
  • BigQuery: 大規模なペタバイト規模のデータセットのクエリをサポートする、サーバーレスのクラウド データ ウェアハウス。大規模なマルチテナント インフラストラクチャで多くのユーザーをサポートすることで、BigQuery は膨大なスケール メリットによるコンピューティング リソースを効率的に活用します。BigQuery のアーキテクチャではストレージとコンピューティングが分離されます。これにより、クエリ実行とは別にデータ ストレージをスケーリングするためにコンピューティング リソースが効率的に割り当てられます。BigQuery は、クエリの実行に必要なコンピューティング リソース(スロットと呼ばれます)を動的に割り当てます。フェア スケジューリングは、プロジェクト間でスロットの容量を自動的に割り当て、必要に応じてクエリを実行します。

他にもまだ VM を必要とするワークロードがある場合があります。VM が必要な場合は、コストと排出量が増加する可能性があるため、必要以上のオーバー プロビジョニングを避け、未使用のリソースを実行したままにしないでください。

アイドル状態のクラウド リソースを最小限に抑える

アイドル状態(または非効率的な使用の)クラウド リソースを減らすコスト最適化の手法も、二酸化炭素排出量の削減につながる可能性があります。アイドル状態のリソースでは、不要な費用や排出量を発生させることによって無駄が発生します。次の形式の未使用のリソースについて考えてみましょう。

  1. 未使用のアクティブなクラウド リソース(たとえば、ワークロードの完了時に終了しない VM インスタンス)。
  2. オーバープロビジョニングされたリソース(ワークロードに必要以上の VM やより大きな VM マシンタイプを使用するなど)。
  3. 最適化されていないアーキテクチャまたはワークフロー。たとえば、クラウドに移行された(ただし、最適化されていない)リフト&シフト アプリケーション、またはデータ処理と分析ワークロードのために分離されていないストレージとコンピューティング インフラストラクチャ。

未使用の VM リソースが過剰にプロビジョニングされると、通常、不要なコストやカーボン フットプリントの増加に重大な影響を及ぼします。カーボン フットプリントを最小限に抑えるには、ワークロードの自動化、モニタリング、最適化プロセスを通じて、アイドル状態の VM 容量やその他の未使用のクラウド リソースを最小限に抑える方法を検討してください。以下のトピックは、このドキュメントの対象外ですが、コストとカーボン フットプリントに大きな影響を与える可能性のある単純な手法があります。これらの手法の一部は、Active Assist で有効にされます。これは、クラウド使用量を最適化する次の種類の自動推奨事項を提供するソリューションです。

  1. アイドル状態の VM リソースの特定と削除: コンソールで未使用のディスクなどのアイドル状態のリソースの最適化案を定期的にチェックしてください。gcloud CLI または API を使用して、アイドル状態のリソースの最適化案を表示することもできます。アイドル状態のリソースが不要であることを確認したら、それらを削除して費用と排出量を節約できます。
  2. VM インスタンスのサイズ適正化: コンソールサイズ適正化に関する最適化案を定期的に確認して、リソース使用量に応じて VM のサイズを最適化します。サイズ適正化はオーバープロビジョニングによる無駄の対処に役立ちます。gcloud CLI または API を使用して、サイズ適正化の最適化案を表示することもできます。
  3. アイドル状態の VM の特定と削除: アイドル状態の VM Recommender を使用して、使用されていない VM インスタンスを特定します。アイドル状態の VM は、不要であることを確認した後に削除できます。
  4. 手動操作を必要としないプロジェクトを再利用または削除する: 手動操作を必要としないプロジェクトの Recommender を使用して、使用頻度が低いか使用されていない、シャットダウンできる、手動操作を必要としないプロジェクトを見つけます。
  5. 必要なときに実行するように VM をスケジュールする: VM が特定の時点でのみ必要な場合は、VM インスタンスを自動的に起動および停止するようにスケジューリングすることを検討してください。
  6. アイドル状態のプロビジョニングと過剰にプロビジョニングされた Cloud SQL インスタンスを修正する: Active Assist を使用して、Cloud SQL の過剰なプロビジョニングアイドル状態の Cloud SQL for MySQL と SQL Server インスタンスを特定します。特定できたら、インスタンスのサイズを変更したり、削除したりできます。

アーキテクチャが最適でないと、クラウド リソースの使用効率が低下します。アーキテクチャの問題は、クラウド用に構築されたアプリケーションでも発生しますが、通常はオンプレミス ワークロードで発生します。たとえば、Google Cloud に移行され、最適化がまったく、または最低限しか行われていない(通常リフト&シフトと呼ばれる)モノリシック アプリケーションなど。次の方法により、アーキテクチャを最適化できます。

  1. 必要なときにリソースを作成する: クラウド リソースには弾力性がありますが、実際の使用量に関係なく、継続的に実行される固定リソースにワークロードをデプロイすると、効率性のメリットが制限されます。VM スケジューリングやクラウド サービス内の弾力性のある機能の使用など、必要に応じてリソースを作成(および削除)する機会を特定します。弾力性のある機能の使用には、Compute Engine を使用したステートレス ウェブサーバーを実行する VM の自動スケーリングや、Dataflow を使用したストリーミング データ パイプライン用のワーカーの自動スケーリングが含まれます。
  2. ワークロードのコンテナ化: ワークロードをコンテナにパッケージ化し、Google Kubernetes Engine(GKE)などのコンテナ オーケストレーターを使用してコンテナを効率的に実行することを検討してください。GKE を使用すると、リソース要件に基づいて VM のクラスタにわたってコンテナを効率的にスケジューリングできます。リソースの要件が許容する場合、複数のコンテナが単一の VM のリソースを共有することもできます。

Migrate for GKE and Anthos を使用すると、VM からコンテナへのワークロードの移行を簡略化できます。VM をコンテナに移行することは、アプリケーションのモダナイゼーションへの第一歩です。以降の手順では、費用の最適化の手法を用いることができ、それによって排出量の削減と、マイクロサービスへのアプリケーションのリファクタリングを行うことも可能です。

完全な構成の柔軟性とコンテナ オーケストレーションの制御が必要な場合は、GKE の使用を検討してください。コンテナ化されたウェブ アプリケーションまたはマイクロサービスを実行する必要があり、完全な Kubernetes 環境が不要な場合は、Cloud Run の使用を検討してください。Cloud Run はコンテナ実行の複雑さを抽象化し、デベロッパーの拡張体験の提供に重点を置いています。詳細な比較については、Google Kubernetes Engine と Cloud Run をご覧ください。

  1. モノリシック アプリケーションをマイクロサービスにリファクタリングする: モノリシック アプリケーションは、すべてのモジュールを 1 つのプログラムに結合するため、リソースを割り当てて特定のモジュールを実行することが困難になります。そのため、モノリシック アプリケーションを効率的に実行してスケーリングすることは困難である可能性があるため、マイクロサービスに基づく実装と比較して温室効果ガス排出量がより大きくなる場合があります。

    ショッピング カートサービスと支払いサービスがあるモノリシック e コマース ウェブサイトがあるとします。ユーザーはセッション内でショッピング カートサービスと複数回やり取りし、セッション終了時にのみ支払いサービスとやり取りする場合があります。2 つのサービスでは、トラフィックと負荷の特性が異なるためリソース要件は異なりますが、どちらも同じモノリシック アプリケーションの一部であるため、別々に実行できません。モノリスを VM 上で実行する場合、たとえ 1 つのサービスのみサービス能力を増やす必要がある場合でも、追加の VM ごとに両方のサービスを実行するためのコンピューティング リソースを追加します。

    モノリスとは対照的に、マイクロサービスは、ネットワーク呼び出しを使用して統合される独自の軽量プログラムにアプリケーション モジュールを分離します。マイクロサービスは互いに独立してスケーリングでき、サービスの実行に適したさまざまなリソース形態(VM マシンタイプ、Cloud Run vCPU とメモリ割り当て、App Engine インスタンス タイプなど)を使用します。マイクロサービスのスケーリングでは、きめ細かいスケーリングによってクラウド リソースをより効率的に使用し、オーバープロビジョニングを削減するため、費用と排出量が削減されます。詳細については、モノリスのマイクロサービスへのリファクタリングをご覧ください。

  2. ストレージ リソースとコンピューティング リソースを分離するクラウド サービスを使用する: Apache HadoopApache Spark などの一部のオンプレミス(およびクラウドベースの)データ処理および分析ワークロードは、多くの場合、データ ストレージおよびコンピューティングのために同じインフラストラクチャを共有します。データを保存するために大規模なインフラストラクチャのフットプリントを維持しながら、ピーク コンピューティング要件のために同じフットプリントのサイズを指定する必要がある場合、コンピューティング リソースの使用率は低くなります。使用率が低いと、アイドル状態のリソースが増え、それによって費用と不必要な排出量が増加します。

    これらのワークロードを Google Cloud に移行する場合は、次のようなストレージとコンピューティングのインフラストラクチャを分離するマネージド サービスを使用することをおすすめします。

    • BigQuery: BigQuery は、サーバーレスでペタバイト規模の、サービスとしてのデータ ウェアハウスです。BigQuery は SQLに基づく分析のワークロードに使用できます。BigQuery 内のデータセット ストレージは、コンピューティング リソースから分離されます。この分離とは、BigQuery ストレージがスケーリングされ、リソースを効率的に使用する方法でストレージを仮想的に無制限に提供するということです。また、データを複製したり、新しいクラスタをスピンアップしたりすることなく、データセットを適切に共有できるということでもあります。
    • Dataproc: Dataproc は、Hadoop ワークロードと Spark ワークロード用のマネージド サービスです。多くのオンプレミス Hadoop デプロイメントと Spark デプロイメントでは、使用状況の特性に関係なく、常時稼働のコンピューティング クラスタが使用されています。有効期間が長いクラスタは Dataproc を使用して作成できますが、ジョブを実行する必要がある場合はエフェメラル クラスタを作成することをおすすめします。Dataproc ジョブによって読み書きされるデータは、Cloud Storage や Bigtable などの専用のストレージ サービスで個別に管理されます。Hadoop ストレージ用の環境を維持する必要がないため、ジョブが実行されていなくても、運用の複雑さ、コスト、排出量は削減されます。
    • Cloud Spanner: Spanner は、分散型でグローバルにスケーラブルな SQL データベース サービスで、これらのリソースを別々にスケーリングできるようにします。オートスケーラー ツールを使用して、Spanner インスタンス用のコンピューティング リソースノードの数を自動的にスケーリングすることもできます。Spanner デプロイの自動スケーリングを使用すると、インフラストラクチャが自動的に調整とスケーリングを行って負荷要件を満たすことができ、負荷が低い場合は費用と二酸化炭素排出量を削減できます。
  3. ワークロードをマネージド サービスに移行する: マネージド サービスでは、ワークロードを自動的にスケーリングすることで、未使用のリソースを最小化でき、インフラストラクチャの要件を軽減できるその他の機能も提供できます。詳細については、この文書で前述の最適なクラウド サービスの選択をご覧ください。

バッチ ワークロードの排出量を削減する

多くのオンライン サービス ワークロードとは異なり、バッチ ワークロードには多くの場合、実行される場所とタイミングの点で柔軟性があります。バッチ ワークロードの例としては、科学計算のためのハイ パフォーマンス コンピューティング(HPC)ジョブ、毎日のアカウント調整の実行、マーケティング メールの商品のレコメンデーションの生成などがあります。

他のワークロードと同様に、バッチ ワークロードを CFE% が高いリージョンで実行して、全体的な二酸化炭素排出量を削減することをおすすめします。バッチジョブの実行を柔軟に行うことができる場合は、グリッド炭素強度の低下に合わせてジョブを実行すると、二酸化炭素排出量をさらに削減できる可能性があります。Google Cloud リージョンが配置されているさまざまなグローバル ロケーションのグリッド ミックス、炭素強度のデータを 1 時間ごとに表示するには、Tomorrow がメンテナンスしている electricityMap ウェブサイトを使用します。

バッチ ワークロードは、当然のことながらレイテンシの影響は受けません。ただし、関連するシステム(データソースやシンクなど)に依存関係がある場合は、望ましくないネットワーク オーバーヘッドが生じる可能性があります。このような依存関係は、大規模なアプリケーションやワークフローの一部であるジョブの場合に存在する可能性があります。たとえば、1 つ以上のソースシステムからデータを読み取り、変換されたデータをデータ ウェアハウスに書き込む抽出、変換、格納(ETL)ジョブなどです。ETL ジョブがクラウド リージョン間で大量のデータを処理して転送する場合、ネットワーク パフォーマンスへの影響とリージョン間の下り(外向き)コストが増加するため、ジョブを個別に実行するのが非現実的であったり、コストがかかったりする場合があります。

CO2 が低いリージョンでは、次のタイプのバッチ ワークロードを実行することをおすすめします。

  1. スタンドアロンのバッチ ワークロード: ニーズに最適な価格と排出量の特性を備えたリージョンを選択し、そのリージョンでストレージ サービスとコンピューティング サービスを使用し、分析結果を直接ダウンロードするスタンドアロンの HPC ワークロードを検討してください。このシナリオでは、分析結果の取得を超える、ネットワーク パフォーマンスの低下や下り(外向き)ネットワーク コストを引き起こす可能性のあるリージョン間トラフィックはありません。
  2. 他のクラウド リージョンとのデータ転送の最小化が必要なバッチ ワークロード: 機械学習(ML)モデルからプロダクトのレコメンデーションを提供する API を検討します。API は、低レイテンシでユーザーにサービスを提供するために、複数のクラウド リージョンにホストされる場合があります。ML モデルは、一元化されたバッチ処理としてブラウザからのクリックストリーム データから定期的にトレーニングされ、API がホストされている各クラウド リージョンにコピーされる場合があります。このシナリオでは、トレーニング ジョブからの出力モデルのアーティファクトは小さく、サイズはおよそ数 10 MB です。

    このシナリオでは、ML モデルのトレーニング用のクリックストリーム データが、ブラウザから ML バックエンドをホストするクラウド リージョンに直接送信されます。ML バックエンドが新しいモデルセットをトレーニングする場合、モデルを他のクラウド リージョンにコピーするためのデータ転送は比較的少量です(10 個のモデルをコピーする必要がある場合、おそらく数百メガバイト程度)。

推奨事項

次の表に、Google Cloud 二酸化炭素排出量の削減に関する最適化案の概要を示します。

トピック 推奨事項
クラウドの二酸化炭素排出量の把握

カーボンフリー エネルギーの割合(CFE%)が、クラウド リージョンにおけるカーボンフリー エネルギーの消費をどのように説明しているかを理解します。

二酸化炭素排出量の削減に関する主な戦略を把握します。

二酸化炭素排出量を把握する Google Cloud の使用状況から二酸化炭素の排出量を把握するのに役立つ Carbon Footprint ツールを使用します。
最適なクラウド リージョンを選択する

Google Cloud リージョン選択ツールを使用して、関連する考慮すべき事項である二酸化炭素排出量、料金、レイテンシに応じて最適なクラウド リージョンを決定します。

CO2 が低いリージョンへの使用を制限する組織ポリシーを作成することを検討してください。

最適なクラウド サービスを選択する

より効率の低いオンプレミス データセンターから Compute Engine に VM を移行します。

セルフマネージド VM ではなく、特定のワークロード用に最適化されたクラウド マネージド サービスを使用します。

未使用のクラウド リソースを最小化する

Active Assist 機能を使用して、未使用の VM の削除、VM シェイプの最適化、放置プロジェクトのシャットダウンを行います。

クラウド リソースを永続的に保持するのではなく、必要に応じて作成(および削除)する機会を特定します。

VM をスケジュールし、必要なときに起動と停止を行います。

ワークロードをコンテナに移行し、Cloud Run や GKE などのマネージド サービスを使用して、それらを効率的に実行します。

モノリシック アプリケーションをマイクロサービスにリファクタリングして、効率性を高めます。

データ処理と分析のためにコンピューティングとストレージを分離するサービスを使用します。

既存の VM ワークロードをマネージド サービスに移行します。

バッチ ワークロードの排出量を削減する

低 CO2 リージョンでリージョン間の下り(外向き)が最小またはゼロのバッチ ワークロードを実行します。

電力網の炭素強度が可能な限り低い時間帯にバッチ ワークロードを実行します。

次のステップ