Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

Last reviewed 2026-10-28 UTC

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

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

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

持続可能なクラウドコンピューティング戦略の一環として、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 の要件を満たすためにレプリケーションが必要な場合にのみ、リージョン間でデータとサービスを複製します。レプリカを追加するたびに、永続ストレージとネットワーク下り（外向き）のエネルギーコストが増加します。

サステナビリティのためにリソース使用量を最適化する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。