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

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

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

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

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

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

バッチジョブを、炭素排出量の少ないリージョンで、地域の電力網のクリーンエネルギーの割合が高い時間帯に実行するようにスケジュールします。リージョンで二酸化炭素排出量が最も少ない時間帯を特定するには、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 アクセラレータインスタンスは公称電力使用量が多いですが、タスクははるかに高速に完了します。

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

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 の要件を満たすためにレプリケーションが必要な場合にのみ、リージョン間でデータとサービスを複製します。レプリカを追加するたびに、永続ストレージとネットワーク下り（外向き）のエネルギー費用が増加します。

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