Google Cloud の温室効果ガス排出量を削減する

Last reviewed 2021-10-11 UTC

このドキュメントでは、環境のサステナビリティに対する Google Cloud のアプローチについて説明します。Google Cloud での温室効果ガス排出量を理解するために使用できる情報やリソースと、フットプリントを削減または最小化するための方法について説明します。このドキュメントの対象読者は次のとおりです。

  • 温室効果ガス排出量が最小限のアプリケーションを構築することを検討しているデベロッパー。
  • 現在の温室効果ガス排出量を把握して、排出量の削減機会を特定することを検討しているインフラストラクチャ チームやその他の技術チーム。

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

クラウドの温室効果ガス排出量の把握

Google は 2007 年からカーボン ニュートラルに配慮しており、2030 年までに 100% カーボンフリー エネルギーを 24 時間 365 日活用するように取り組んでいます。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 の Carbon Footprint の報告方法に従って報告されます。また、Google Cloud のお客様として温室効果ガス（GHG）プロトコル スコープ 3 標準のレポート要件を満たすことができます。Carbon Footprint データを BigQuery にエクスポートして、さらに分析を行えます。

Carbon Footprint ダッシュボードと BigQuery Export を使用して、Google Cloud サービスの利用によるロケーション ベースの排出量を把握できます。このデータを使用して、さまざまな Google Cloud サービスの温室効果ガス排出量を比較できます。たとえば、相対的な排出量を把握するには、同じクラウド リージョンで実行されている 2 つ以上のサービスの合計排出量を比較します。

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

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

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

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

排出量の削減は、リージョンを選択する際に兼ね合いを図る必要がある多くの要件の一つです。たとえば、特定の 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 をさまざまなワークロード タイプ向けの他のフルマネージド サービスにデプロイできます。これらのサービスには、多くの場合、パフォーマンスとリソースの使用量の最適化に役立つ自動スケーリングとサイズ適正化の機能が組み込まれています。たとえば、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 リソースの特定と削除: Google Cloud コンソールで未使用のディスクなどのアイドル状態のリソースの推奨事項を定期的にチェックします。gcloud CLI や API を使用して、アイドル状態のリソースの推奨事項を表示することもできます。アイドル状態のリソースが不要であることを確認したら、それらを削除して費用と排出量を節約できます。
  2. VM インスタンスのサイズ適正化: Google Cloud コンソールでサイズ適正化に関する推奨事項を定期的に確認し、リソース使用量に応じて VM のサイズを最適化します。サイズ適正化はオーバープロビジョニングによる無駄の対処に役立ちます。gcloud CLI または API を使用して、サイズ適正化の推奨事項を表示することもできます。
  3. アイドル状態の VM の特定と削除: アイドル状態の VM の推奨事項を使用して、使用されていない VM インスタンスを特定します。アイドル状態の VM は、不要であることを確認した後に削除できます。
  4. 放置されたプロジェクトを再利用または削除する: 放置されたプロジェクトの Recommender を使用して、使用頻度が低いか使用されておらず、手動操作を必要としないシャットダウン可能なプロジェクトを見つけます。
  5. 必要なときに実行するように VM をスケジュールする: VM が特定の時点でのみ必要な場合は、VM インスタンスを自動的に起動および停止するようにスケジューリングすることを検討してください。
  6. アイドル状態のプロビジョニングとオーバープロビジョニングされた Cloud SQL インスタンスを修正する: Active Assist を使用して、オーバープロビジョニング状態とアイドル状態の MySQL、PostgresSQL、SQL Server の Cloud SQL インスタンスを特定します。特定できたら、インスタンスのサイズを変更したり、削除したりできます。

最適ではないアーキテクチャは、クラウド リソースの使用効率低下につながります。クラウド用に構築されたアプリケーションでは、アーキテクチャの問題が発生する可能性がありますが、これらの問題はオンプレミスのワークロードでもよく発生します。たとえば、Google Cloud に移行され、最適化がまったく行われない（またはリフト＆シフトと呼ばれる）モノリシック アプリケーションなどです。次のことはアーキテクチャの最適化に役立ちます。

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

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

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

    • BigQuery: BigQuery は、サーバーレスでペタバイト規模の、サービスとしてのデータ ウェアハウスです。BigQuery は SQL に基づく分析ワークロードに使用できます。BigQuery 内のデータセット ストレージは、コンピューティング リソースから分離されます。この分離とは、BigQuery ストレージがスケーリングされ、リソースを効率的に使用する方法でストレージを仮想的に無制限に提供するということです。また、データを複製したり、新しいクラスタをスピンアップしたりすることなく、データセットを適切に共有できるということでもあります。
    • Dataproc: Dataproc は、Hadoop ワークロードと Spark ワークロード用のマネージド サービスです。オンプレミスの Hadoop と Spark のデプロイメントの多くは、使用量の特性に関係なく、常時稼働のコンピューティング クラスタを使用しています。Dataproc を使用して有効期間の長いクラスタを作成できますが、ジョブを実行する必要がある場合はエフェメラル クラスタを作成することをおすすめします。Dataproc ジョブによって読み書きされるデータは、Cloud Storage や Bigtable などの専用のストレージ サービスで個別に維持されます。ジョブが実行されていない場合でも Hadoop ストレージの環境を維持する必要がないため、運用の複雑さ、コスト、排出量が削減されます。
    • 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%）が、クラウド リージョンにおけるカーボンフリー エネルギーの消費をどのように説明しているかを理解します。

温室効果ガス排出量の削減に関する主な戦略を把握します。
温室効果ガス排出量を把握する Carbon Footprint ツールを使用して、Google Cloud の使用状況から温室効果ガス排出量を把握します。
最適なクラウド リージョンを選択する

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

CO2 が低いリージョンへの使用を制限する組織ポリシーを作成することを検討してください。
最適なクラウド サービスを選択する

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

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

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

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

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

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

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

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

既存の VM ワークロードをマネージド サービスに移行します。
バッチ ワークロードの排出量を削減する

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

電力網の二酸化炭素排出原単位が可能な限り低い時間帯にバッチ ワークロードを実行します。

次のステップ