費用の最適化: コンピューティング、コンテナ、サーバーレス

Last reviewed 2023-07-12 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、Google Cloud の仮想マシン（VM）、コンテナ、サーバーレス リソースのコストを最適化するための推奨事項について説明します。

このセクションのガイダンスは、クラウド内のワークロードのコンピューティング リソースについてプロビジョニングと管理を担当するアーキテクト、デベロッパー、管理者を対象としています。

コンピューティング リソースは、クラウド インフラストラクチャの最も重要な部分です。ワークロードを Google Cloud に移行する場合、一般的に第 1 候補となるのが Compute Engine です。これにより、クラウド内で VM を効率的にプロビジョニングして管理できるようになります。Compute Engine にはさまざまなマシンタイプがあり、すべての Google Cloud リージョンでグローバルに利用できます。Compute Engine の事前定義されたカスタム マシンタイプを使用すると、オンプレミス インフラストラクチャと同様のコンピューティング容量を提供する VM をプロビジョニングして、移行プロセスを高速化できます。Compute Engine には、ご利用いただいたインフラストラクチャに対してのみ料金が発生します。また、継続利用割引によって、コンピューティング リソースの使用量が増えたときに費用を大幅に節約できます。

Google Cloud では、Compute Engine に加えてコンテナとサーバーレス コンピューティング サービスを提供しています。サーバーレス アプローチにより、常時実行されるわけではない新しいサービス（API、データ処理、イベント処理など）に対して費用対効果を向上させることができます。

このドキュメントでは、一般的な推奨事項とともに、次のプロダクトを使用する際にコンピューティング リソースの費用を最適化するためのガイダンスについても説明します。

  • Compute Engine
  • Google Kubernetes Engine（GKE）
  • Cloud Run
  • Cloud Functions
  • App Engine

一般的な推奨事項

以下の推奨事項は、このセクションで説明する Google Cloud のすべてのコンピューティング、コンテナ、サーバーレス サービスに適用できます。

使用状況と費用を追跡する

リソースの使用状況と費用をモニタリングするには、以下のツールと手法を使用します。

リソースのプロビジョニングを制御する

クラウドにプロビジョニングされるリソースの量とリソースが作成されるロケーションを制御するには、次の推奨事項を使用します。

  • リソースの消費量と費用が予測を超えないようにするために、リソースの割り当てを使用します。
  • ワークロードのレイテンシ要件を満たす最低費用のリージョンでリソースをプロビジョニングします。リソースをプロビジョニングする場所を制御するには、組織のポリシーの制約 gcp.resourceLocations を使用します。

確約利用割引を取得する

確約利用割引（CUD）は、必要なリソース量が予測可能なワークロードに最適です。ワークロードを Google Cloud に移行後、必要なリソースのベースラインを見つけて、確約利用の大幅な割引を取得します。たとえば、1 年間または 3 年間の確約利用を購入し、Compute Engine VM の料金の大幅な割引を取得します。

ラベルを使用して費用追跡を自動化する

一貫性のあるラベルの定義と割り当てを行います。ラベルを使用して費用の追跡を自動化する方法の例を次に示します。

  • デベロッパーが営業時間中にのみ使用する VM の場合は、ラベル env: development を割り当てます。Cloud Scheduler でサーバーレスの Cloud Functions の関数を設定すると、営業時間後にこうした VM をシャットダウンして、必要に応じて再起動できます。

  • 複数の Cloud Run サービスと Cloud Functions インスタンスを持つアプリケーションの場合は、すべての Cloud Run および Cloud Functions リソースに一貫したラベルを割り当てます。支出の多い領域を特定し、費用を削減するための措置を講じます。

請求レポートをカスタマイズする

Cloud Billing レポートを構成するには、必要なフィルタを設定し、必要に応じてデータをグループ化します（プロジェクト別、サービス別、ラベル別など）。

費用削減の文化を推進する

クラウド インフラストラクチャに関して開発者や運用担当者をトレーニングします。従来のクラスやオンライン クラス、ディスカッション グループ、ピアレビュー、ペア プログラミング、コスト削減ゲームを使用して、学習プログラムを作成し、プロモーションします。Google の DORA の調査で示されているように、組織文化は、パフォーマンスの改善、後戻り作業と燃え尽き症候群の削減、費用の最適化の重要な推進要因です。従業員がリソースの費用を把握できるようにすることで、従業員は優先事項とアクティビティをビジネス目標や制約に合わせることができます。

Compute Engine

このセクションでは、Compute Engine リソースの費用の最適化に役立つガイダンスを示します。このガイダンスに加えて、前述の一般的な推奨事項を適用することをおすすめします。

請求モデルを理解する

Compute Engine の請求オプションについては、料金をご覧ください。

リソース使用量を分析する

Compute Engine でのリソース使用量を把握するには、使用状況データを BigQuery にエクスポートします。BigQuery データストアにクエリを実行して、プロジェクトの仮想 CPU（vCPU）の使用傾向を分析し、再利用できる vCPU の数を決定します。プロジェクトあたりのコア数のしきい値を定義している場合は、使用傾向を分析して異常を特定し、是正措置を取ります。

アイドル状態のリソースを再利用する

降格された概念実証プロジェクトの VM など、未使用の VM とディスクを特定して再利用するには、次の推奨事項を使用してください。

  • アイドル状態の VM Recommender を使用して、使用状況の指標に基づき、非アクティブな VM と永続ディスクを識別できます。
  • リソースを削除する前に、削除によって生じる可能性のある影響を評価し、必要な場合にはリソースの再作成を計画してください。
  • VM を削除する前に、スナップショットの取得を検討してください。VM を削除する際、[ディスクを維持] オプションを選択しない限り、アタッチされたディスクが削除されます。
  • 可能であれば、VM を削除するのではなく停止することを検討してください。VM を停止するとインスタンスは終了しますが、ディスクと IP アドレスは切断または削除するまで保持されます。

需要に合わせて容量を調整する

VM の起動と停止が自動的に行われるようにスケジュール設定します。たとえば、VM を 1 日 8 時間、週 5 日（週 40 時間）使用する場合、VM を使用していない間（週 128 時間）VM を停止することで、コストを 75% 削減できます。

マネージド インスタンス グループを使用して、需要に基づいてコンピューティング容量を自動スケーリングします。ビジネスにとって重要なパラメータ（CPU 使用率やロード バランシング容量など）に基づいて容量を自動スケーリングできます。

適切なマシンタイプを選択する

VM マシンタイプ Recommender を使用して、ワークロードのコンピューティング要件に合わせて VM のサイズを調整します。

リソースの要件が予測可能なワークロードの場合は、マシンタイプをニーズに合わせて、カスタム VM を使用すると費用を節約できます。

フォールト トレラントなバッチ処理のワークロードの場合は、Spot VM の使用を検討してください。ハイ パフォーマンス コンピューティング（HPC）、ビッグデータ、メディアのコード変換、継続的インテグレーションと継続的デリバリー（CI / CD）パイプライン、ステートレス ウェブ アプリケーションなどが、Spot VM にデプロイ可能なワークロードの例です。プリエンプティブル VM（古いバージョンの Spot VM）を使用して衛星画像を処理することで、Descartes Labs が分析コストを削減した例については、Descartes Labs の事例紹介をご覧ください。

ライセンス オプションを評価する

サードパーティのワークロードを Google Cloud に移行する場合は、お客様所有ライセンスの使用（BYOL）で費用を削減できる可能性があります。たとえば、Microsoft Windows Server VM をデプロイする場合、サードパーティ ライセンスの追加費用が発生するプレミアム イメージを使用する代わりに、カスタム Windows BYOL イメージを作成して使用できます。この場合、料金は Google Cloud で使用する VM インフラストラクチャにしか発生しません。この戦略により、サードパーティ ライセンスに対するこれまでの投資の価値を継続的に現金化できます。

BYOL の手法を使用する場合は、次のことをおすすめします。

  • カスタム マシンタイプを使用して、必要な数のコンピューティング CPU コアをメモリとは独立してプロビジョニングし、サードパーティのライセンスの費用を必要な CPU コアの数に制限します。
  • 同時マルチスレッディング（SMT）を無効にして、コアあたりの vCPU 数を 2 から 1 に減らし、ライセンス費用を 50% 削減します。

サードパーティ ワークロードが、セキュリティまたはコンプライアンスの要件を満たすために専用のハードウェアを必要とする場合は、単一テナントノードでお客様所有ライセンス（BYOL）を使用できます。

Google Kubernetes Engine

このセクションでは、GKE リソースの費用を最適化するためのガイダンスについて説明します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

  • GKE Autopilot を使用すると、GKE でクラスタのインフラストラクチャの効率が最大化されます。ノードの健全性のモニタリング、ビンパッキングの処理、ワークロードに必要な容量の計算は必要ありません。
  • ワークロードの要件に応じて、HorizontalPodAutoscaler（HPA）、VerticalPodAutoscaler（VPA）、クラスタ オートスケーラー（CA）、またはノードの自動プロビジョニングを使用して、GKE 自動スケーリングをファインチューニングできます。
  • 起動レイテンシに影響されないバッチ ワークロードの場合は、optimization-utilization 自動スケーリング プロファイルを使用してクラスタの使用率を向上させます。
  • ノードの自動プロビジョニングを使用して GKE クラスタ オートスケーラーを拡張し、オーバープロビジョニングすることなく、保留中の Pod の仕様に基づいて効率的にノードプールの作成や削除を行います。
  • 別々のノードプールを使用します。静的読み込みには静的ノードプールを、動的読み込みにはクラスタ自動スケーリング グループがある動的ノードプールを使用します。
  • Pod がフォールト トレラントで、25 秒未満で正常に終了できる場合は、Kubernetes ノードプールに Spot VM を使用します。この戦略を GKE クラスタ オートスケーラーと組み合わせると、低コストの VM（この場合は Spot VM を含むノードプール）を搭載したノードプールを最初にスケーリングできるようになります。
  • 費用対効果の高いマシンタイプ（例: E2、N2D、T2D）を選択すると、価格性能比が 20～40% 向上します。
  • GKE 使用状況測定を使用して、名前空間とラベルでクラスタの使用状況プロファイルを分析します。最も支出の大きいチームやアプリケーション、使用量や費用の急増を引き起こした環境やコンポーネント、リソースを浪費しているチームを特定します。
  • マルチテナント クラスタでリソースの割り当てを使用して、各テナントで使用されるクラスタ リソースがそれぞれの割り当て量を超えないようにします。
  • 営業時間後に開発環境とテスト環境の自動ダウン スケーリングをスケジュール設定します。
  • GKE でコスト最適化 Kubernetes アプリケーションを実行するためのベスト プラクティスに沿って実施します。

Cloud Run

このセクションでは、Cloud Run リソースの費用を最適化するためのガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

  • 同時実行の設定（デフォルトは 80）を調整して費用を削減します。Cloud Run では、CPU とメモリの使用量に基づいて、インスタンスに送信されるリクエストの数が決定されます。リクエストの同時実行を増やすと、必要となるインスタンス数を削減できます。
  • デプロイ可能なインスタンス数の上限を設定します。
  • 課金対象インスタンス時間指標を使用して、必要なインスタンス数を推定します。たとえば、指標に 100s/s と示されている場合、約 100 個のインスタンスがスケジュールされています。パフォーマンスを維持するために 30% のバッファを追加します。つまり 100 個/秒のトラフィックに対して 130 個のインスタンスにします。
  • コールド スタートの影響を軽減するには、最小のインスタンス数を構成します。こうしたインスタンスがアイドル状態の場合、10 分の 1 の料金が請求されます。
  • CPU 使用率を追跡し、それに応じて CPU の上限を調整します。
  • トラフィック管理を使用して、コスト最適化された構成を決定します。
  • 静的アセットの提供には、Cloud CDN または Firebase Hosting の使用を検討してください。
  • リクエストをグローバルに処理する Cloud Run アプリの場合、大陸間のデータ転送が高コストになる可能性があるため、複数のリージョンにアプリをデプロイすることを検討してください。この設計は、ロードバランサと CDN を使用する場合におすすめします。
  • 起動時間も課金対象になるため、インスタンスの起動時間を短縮します。
  • 確約利用割引を購入すると、1 年間の確約利用の場合、オンデマンド料金が最大で 17% の割引となります。

Cloud Functions

このセクションでは、Cloud Functions リソースの費用を最適化するためのガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

  • 関数の実行時間を確認します。テストやベンチマークを行い、必要な性能を満たす最小の関数を設計します。
  • Cloud Functions のワークロードが常に実行されている場合は、GKE または Compute Engine を使用してワークロードを処理することを検討してください。常時実行されるワークロードの場合、コンテナまたは VM が低コストなオプションになる場合があります。
  • 共存できる関数インスタンスの数の上限を設定します。
  • Cloud Functions プログラミング言語のランタイムのパフォーマンスを関数のワークロードに対してベンチマークします。コンパイル済み言語のプログラムでは、コールド スタートの時間が長くなりますが、実行速度は速くなります。インタプリタ言語のプログラムでは実行速度は遅くなりますが、コールド スタートのオーバーヘッドが少なくなります。頻繁に実行される短く簡単な関数は、インタプリタ言語では費用が抑えられる可能性があります。
  • メモリ内のファイル システムであるローカル ディスクに書き込まれた一時ファイルを削除します。一時ファイルは関数に割り当てられたメモリを消費し、次に呼び出されるまでそのまま残る場合もあります。こうしたファイルを削除しなければ、メモリ不足エラーが発生してコールド スタートがトリガーされ、実行時間が長くなって費用が増加する可能性があります。

App Engine

このセクションでは、App Engine リソースの費用の最適化に役立つガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

  • トラフィックとリクエストのレイテンシに基づいてインスタンス数の最大値を設定します。App Engine では通常、アプリケーションが受信するトラフィックに基づいて容量がスケーリングされます。App Engine で作成できるインスタンスの数を制限することで費用を制御できます。
  • アプリケーションで使用できるメモリまたは CPU を制限するには、インスタンス クラスを設定します。CPU 使用率が高いアプリケーションの場合は、より多くの CPU を割り当てます。いくつかの構成をテストして、最適なサイズを決定します。
  • 複数のプログラミング言語で App Engine ワークロードのベンチマークを行います。たとえば、ある言語で実装されたワークロードは、別の言語でプログラムされた同じワークロードよりも、所定の時間でタスクを完了するために必要なインスタンス数とコストが低くなります。
  • コールド スタートが少なくなるように最適化します。可能であれば、グローバル スコープで発生する CPU を集中的に使用するタスクや実行時間の長いタスクを減らします。タスクを、リクエストのコンテキストに「遅延読み込み」できる小さなオペレーションに分割してみます。
  • トラフィックが急増することが予想される場合は、あらかじめ起動されておくアイドル状態のインスタンスの最小数を構成します。トラフィックが予想されない場合は、アイドル状態のインスタンスの最小数をゼロに構成できます。
  • パフォーマンスと費用のバランスをとるには、異なる構成の 2 つのバージョン間でトラフィックを分割して、A/B テストを実行します。各バージョンのパフォーマンスと費用をモニタリングし、必要に応じてチューニングして、トラフィックを送信する構成を決定します。
  • リクエストの同時実行を構成し、最大同時リクエスト数をデフォルトよりも高く設定します。各インスタンスが同時に処理できるリクエストが多いほど、既存のインスタンスを使用してトラフィックをより効率的に処理できます。

次のステップ