このドキュメントは、Google Kubernetes Engine（GKE）のドキュメントで、費用の最適化に関するガイドラインと推奨事項を見つけるのに役立ちます。GKE には、アプリケーションの安定性を維持しながらクラスタの費用を最小限に抑えるために使用できる、広範な自動スケーリング機能とスケジューリング機能が用意されています。
すべての GKE ベスト プラクティスの概要については、GKE のベスト プラクティスをご覧ください。次のことに精通している必要があります。
概要
GKE を実装する場合は、アプリケーションとビジネスの要件に合わせて、さまざまな技術的な側面を考慮する必要があります。ネットワーキング、セキュリティ、ストレージなどの技術的な側面を定義するだけでなく、ビジネスニーズを満たすために費用とパフォーマンスの両方を評価する必要があります。費用とパフォーマンスを別個のエンティティとして扱うのではなく、インフラストラクチャ計画の初期段階から統合して、信頼性とクラウド費用を決定する統一された関係を定義する必要があります。低コストと高信頼性が期待されますが、スケーリングするにつれて、このトレードオフの管理の複雑さが増します。
低コストで安定したアプリケーションを実現するには、次の GKE 機能を設定または調整します。
- GKE の構成
- ワークロードの構成
- 費用のベースラインと可視性
Compute Advisor（プレビュー版）を使用して、費用の最適化のベスト プラクティスを見つけて実装することもできます。詳細については、Compute Advisor を使用するをご覧ください。
GKE Autopilot を使用する
小規模なサンドボックス環境または開発環境の場合は、Autopilot クラスタを選択します。Autopilot では、GKE がノードを動的に管理し、リクエストされた Pod 容量に対してのみ課金されるため、VM、ノード オペレーティング システム、システム オーバーヘッドの料金を回避できます。
詳細については、GKE Autopilot の概要をご覧ください。
自動スケーリングの仕組みを理解する
GKE 自動スケーリング コントローラは、トラフィック リクエストの変化に応じてリソースを動的に調整します。
使用率指標に基づいて Pod を追加および削除する
HorizontalPodAutoscaler（HPA）は、CPU またはカスタム指標に基づいて Pod を追加または削除します。
水平 Pod 自動スケーリングを理解して構成するには、次の GKE ドキュメントをご覧ください。
- 水平 Pod 自動スケーリングのコンセプト
- 水平 Pod 自動スケーリングを構成する
- HorizontalPodAutoscaler イベントを表示する
- 自動スケーリング用のカスタム アプリケーション指標を公開する
ターゲット使用率のしきい値（70% や 80% など）を構成して、追加のレプリカ Pod の起動中にトラフィックの急増を処理するバッファを維持します。
使用率指標に基づいて Pod をスケーリングする
水平 Pod 自動スケーリングを使用しないワークロードや、ピーク時のワークロードが不明な場合は、VerticalPodAutoscaler（VPA）を使用して、コンテナの CPU リクエストとメモリ リクエストのサイズを動的に変更します。
垂直 Pod 自動スケーリングを理解して構成するには、次の GKE ドキュメントをご覧ください。
本番環境のような環境で VPA を Off（推奨のみ）モードで少なくとも 24 時間（理想的には 1 週間）保持し、代表的なトラフィック パターンをキャプチャします。サイズ調整の不安定さを防ぐには、Initial モードまたは Auto モードを有効にする前に、VerticalPodAutoscaler オブジェクトで明示的な最小値と最大値を指定します。
クラスタ オートスケーラーを使用してインフラストラクチャのスケーリングを自動化する
指標の負荷ではなく、アクティブなスケジューリング シミュレーションに基づいて基盤となるコンピューティング ノードをスケーリングするには、GKE Standard ノードプールでクラスタ オートスケーラーを有効にします。夜間のベースライン容量をサポートする最小ノード パラメータを指定します。
システム Pod とアプリケーション Pod には、常に PodDisruptionBudget（PDB）オブジェクトを構成します。この構成により、使用率の低いノードプールを統合またはスケールダウンする際に、クラスタ オートスケーラーが誤ってサービスの中断を引き起こすことがなくなります。
クラスタ オートスケーラーを理解して構成するには、次の GKE ドキュメントをご覧ください。
ノードプールの自動作成を使用して動的ノードプールをデプロイする
ノードプールの自動作成を有効にすると、保留中の Pod のスケジューリング パラメータに正確に適合するシェイプ、CPU 数、メモリ上限を持つカスタム GKE ノードプールが自動的に生成されます。この機能により、サイズが大きすぎるノードに残るリソースを最小限に抑えることができます。
ノードプールの自動作成について理解し、構成するには、次の GKE ドキュメントをご覧ください。
自動スケーリングのチェックリスト
インフラストラクチャの特性
クラスタのハードウェア、ロケーション、ノード ネットワーク ルールを費用最適化の優先度に合わせて調整します。
適切なマシンタイプを選択する
ユーザーのロケーションと、クラスタがアクセスする必要があるデータのロケーションに基づいて、クラスタに適したマシンタイプを選択します。
詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。
Spot VM にフォールト トレラントなワークロードをデプロイする
Spot VM を使用して、ステートレス、フォールト トレラント、またはバッチ ワークロードを実行します。オンデマンド VM インスタンスと比較して最大 91% の割引が適用されます。
詳細については、次の GKE ドキュメントをご覧ください。
効率的なマシン ファミリーと OS システム設定をマッピングする
費用対効果の高いインスタンス プロファイル（E2 VM アーキテクチャなど）を使用して、ノードプールのマシン設定をカスタマイズします。
ノードのサイズ設定、Spot VM のプリエンプション タイミングの構成、カーネル構成の構成の詳細については、ノードプールについてをご覧ください。
適切なリージョンを選択する
レイテンシがユーザーに影響しない場合は、運用コストが低い Compute Engine リージョンでクラスタ ワークロードを実行します。
詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
CUD に登録する
確約利用割引（CUD）を購入して、1 年間または 3 年間のベースライン コンピューティング リソースの割引料金（最大 70%）を確保します。
詳細については、リソースベースの確約利用割引をご覧ください。
ネットワーク費用を考慮する
リージョン GKE クラスタとマルチゾーン GKE クラスタは、アプリケーションの信頼性を向上させますが、内部クロスゾーン ネットワーク下り（外向き）費用が発生する可能性があります。
ネットワーク費用を最小限に抑えて制御するには、次の点を考慮してください。
- ゾーン間のデータ転送: リージョン クラスタでは、ワークロードをゾーン間で分散することで可用性が向上しますが、これらのゾーン間で転送されるデータには費用が発生します。
詳しくは、ネットワーキングのすべての料金をご覧ください。
非本番環境にシングルゾーン クラスタをデプロイする
非本番環境では、ゾーン間のネットワーク料金を回避し、VM のオーバーヘッドを削減するために、リージョン クラスタまたはマルチゾーン クラスタではなく、シングルゾーン クラスタをデプロイします。
詳細については、クラスタ構成の選択についてをご覧ください。
クラスタの DNS の解決パスと上り（内向き）トラフィックを最適化する
クラスタの DNS の解決と内向きトラフィックを最適化するには、NodeLocal DNSCache とネットワーク エンドポイント グループ（NEG）をデプロイします。
DNS を多用するワークロードを実行すると、NodeLocal DNSCache は各ノードでローカル DNS デーモンを実行します。この構成により、クエリ負荷が高くなっても CoreDNS が枯渇しないため、CoreDNS をスケーリングする必要がなくなり、GKE の全体的な費用を削減できます。
上り（内向き）トラフィックの場合、NEG を介したコンテナ ネイティブのロード バランシングにより、トラフィックはインスタンス グループではなく Pod IP アドレスに直接ルーティングされます。この直接ルーティングにより、Pod のスケーリング アクション中にトラフィックを適切にリダイレクトできます。
詳しくは以下をご覧ください。
Namespace ごとにリソース割り当てを適用する
マルチテナント クラスタの Namespace ごとに標準の Kubernetes ResourceQuota オブジェクトをデプロイして、CPU とメモリの形状のしきい値をロックダウンし、個々のチームが予期しないコンピューティング料金が発生する非準拠のワークロードをスケジュールしないようにします。
詳細については、Kubernetes ドキュメントの Namespace をご覧ください。
Policy Controller の監査を実装する
Policy Controller をデプロイして、企業標準へのクラスタの準拠を動的に監査し、適用します。Policy Controller は、アドミッション コントロールを使用して構成が誤っているリソースを拒否します。
詳しくは以下をご覧ください。
CI/CD パイプラインで非準拠のマニフェストをゲートする
開発ライフサイクルの早い段階で、費用ポリシーのコンプライアンスを検証します。検証スクリプト（kpt 解析など）をコミット前またはプルリクエストのチェックに統合して、クラスタに到達する前に非準拠のマニフェストを監査してブロックします。
詳細については、CI パイプラインで会社のポリシーに照らしてアプリの状態を検証するをご覧ください。
インフラストラクチャのチェックリスト
アプリケーションとワークロードの最適化
リソースを効率的に使用し、運用オーバーヘッドを削減するようにワークロードを構成します。
一致するメモリ リクエストと上限を指定する
デプロイ前にコンテナの CPU とメモリのリクエストを正確に指定します。CPU の場合は、サービスレベル目標（SLO）を満たすようにリクエストを構成しますが、上限は制限しないままにします。メモリの場合は、リクエストされた割り当てがメモリ上限と一致していることを確認します。
詳細については、Kubernetes ドキュメントのコンテナに割り当てられた CPU とメモリリソースのサイズを変更するをご覧ください。
コンテナの起動時間を短縮する
コンテナ イメージを可能な限り小さくして、イメージのダウンロード時間を最小限に抑えます。
PDB を構成する
アプリケーション レプリカの PodDisruptionBudget（PDB）オブジェクトを指定して、GKE のスケールダウン時やノードのアップグレード時に自発的な中断を制限し、安定性を確保します。
詳細については、アプリケーションの停止予算を指定するをご覧ください。
意味のある readinessProbe と livenessProbe を設定する
すべてのコンテナの readiness プローブと liveness プローブを構成して、GKE がトラフィックを準備完了の Pod にのみ転送し、障害が発生したインスタンスを再起動して、自動スケーリング中のトラフィック損失を防ぐようにします。
詳細については、liveness プローブ、readiness プローブ、startup プローブを構成するをご覧ください。
アプリケーションの正常なシャットダウンを構成する
SIGTERM シグナルをリッスンする、終了前に進行中のリクエストを完了する、preStop フックを構成するなどして、正常終了のコンテナを準備します。
詳細については、プリエンプティブル VM の終了と正常なシャットダウンをご覧ください。
指数バックオフを使用して再試行を実装する
アプリケーション レベルまたはサービス メッシュレベルで指数バックオフ再試行を実装して、一時的な障害や Spot VM のプリエンプションの可能性に対処します。
詳細については、Istio ドキュメントの再試行をご覧ください。
アプリケーションとワークロードの最適化チェックリスト
費用のベースラインと可視性
費用を最適化するには、まず GKE の費用とその割り当て方法を把握する必要があります。この可視性により、費用が発生したチームとビジネス ユニットに費用を割り当てることができます。
次の GKE ドキュメントでは、GKE の課金、リソース消費、ベースライン指標を詳細に可視化する方法について説明します。
GKE の費用の割り当てを有効にする
GKE の費用の割り当てを有効にすると、ワークロードのリソース リクエストと関連する費用を把握できます。費用の割り当てでは、クラスタの費用がワークロードの Namespace と Kubernetes ラベルに割り当てられます。
これらの詳細を BigQuery にエクスポートして、Cloud Billing のデータを分析します。この分析を使用して、課金ピークの原因となっているワークロードを特定し、チャージバックを実行して、リソース リクエストを最適化します。
詳細については、GKE のリソース割り当てとクラスタの費用に関する主要な支出に関する情報を取得するをご覧ください。
ログと指標の取り込み量を確認する
クラスタで Cloud Logging と Cloud Monitoring を有効にすると、費用が発生します。ログとカスタム指標の取り込み量が多いと、予期しない料金が発生する可能性があります。取り込まれるログレベルとカスタム指標を一元的に監査します。
Logging API の使用量が多い場合や、ログ書き込み上限のタイムアウトのトラブルシューティングの詳細については、以下をご覧ください。
Metrics Server の健全性をモニタリングする
GKE の組み込み自動スケーリング コントローラは、CPU とメモリの指標を取得するために Metrics Server に依存しているため、Metrics Server Deployment の健全性をモニタリングします。
詳細については、水平 Pod 自動スケーリングのトラブルシューティングをご覧ください。
費用削減の文化を育む
デベロッパーがクラウドの支出ダッシュボードにアクセスできるようにし、FinOps トレーニングを確立して、アーキテクチャの決定をビジネス費用の予算に合わせます。
組織の費用対効果の文化の詳細については、費用削減の文化を広げるをご覧ください。
費用のベースラインと可視性のチェックリスト
Compute Advisor を使用する
Compute Advisor は、Gemini を搭載したGoogle Cloud コンソールの AI 搭載インターフェースです。GKE の復元力と費用対効果の高いアーキテクチャの設計に役立ちます。
Compute Advisor は、Flex Start VM と Spot VM の準リアルタイムの可用性ガイダンスを提供し、デプロイ前に組織のポリシーとリソース割り当てを検証します。Compute Advisor は、オンデマンド リソースを必要とするワークロードの可用性に関するガイダンスを提供しません。
Google Cloud コンソールで Gemini にアクセスする手順は次のとおりです。
-
Google Cloud コンソールで、[概要] ページに移動します。
-
[Compute Advisor でインフラストラクチャを設計] セクションで、プロンプトを送信します。Gemini がレスポンスの生成を開始します。
-
アーキテクチャの推奨事項を生成するには、Compute Advisor で次のいずれかのプロンプト例を実行します。[Compute Advisor でプロンプトを実行] ボタンをクリックすると、 Google Cloud コンソールの読み込みに 15 秒以上かかることがあります。
自動スケーリングとビンパッキング:
ユースケース: ビンパッキングを最大化し、アイドル状態の CPU オーバーヘッドを最小化するには、このプロンプトを使用して、GKE クラスタの自動スケーリングとノードプールの戦略を構成します。
Configure a GKE cluster to use autoscaler and node pool strategy to maximize bin packing and minimize idle CPU overhead.マルチテナンシー ガバナンス:
ユースケース: 開発用 Namespace を予算の範囲内に維持するには、このプロンプトを使用して、マルチテナント GKE クラスタの ResourceQuota ポリシーのドラフトを作成します。
Draft a ResourceQuota policy for a multi-tenant GKE cluster to keep development namespaces within budget bounds.ワークロードの最適化:
ユースケース: リソース需要の変動が大きいバッチ ワークロードに GKE Autopilot モードと Standard モードのどちらを使用するかを判断するには、次のプロンプトを使用して推奨事項を取得します。
Recommend whether to use GKE Autopilot or Standard mode for a batch processing workload with highly variable resource demands.
次のステップ
費用対効果を高めるために必要なアーキテクチャの原則と組織文化について詳しくは、GKE で費用が最適化された Kubernetes アプリケーションを実行するためのベスト プラクティスをご覧ください。