費用の最適化のために GKE クラスタを設計して構成する

このドキュメントでは、Google Kubernetes Engine（GKE）のドキュメントを参照して、費用の最適化に関するガイドラインと推奨事項を見つける方法について説明します。GKE には、アプリケーションの安定性を維持しながらクラスタの費用を最小限に抑えるために使用できる、広範な自動スケーリング機能とスケジューリング機能が用意されています。

すべての GKE ベスト プラクティスの概要については、 GKE のベスト プラクティスをご覧ください。

次のことに精通している必要があります。

概要

GKE を実装する場合は、アプリケーションとビジネスの要件に沿って、さまざまな技術的な側面を考慮する必要があります。ネットワーキング、セキュリティ、ストレージなどの技術的な側面を定義するだけでなく、ビジネスニーズを満たすために費用とパフォーマンスの両方を評価する必要があります。費用とパフォーマンスを別個のエンティティとして扱うのではなく、インフラストラクチャ計画の初期段階から統合して、信頼性とクラウド支出の両方を決定する統一された関係を定義する必要があります。低コストと高信頼性が期待されますが、スケーリングするにつれて、このトレードオフの管理の複雑さが増します。

低コストとアプリケーションの安定性を実現するには、次の GKE 機能を設定または調整します。

  • GKE の構成
  • ワークロードの構成
  • 費用のベースラインと可視性

GKE Autopilot を使用する

小規模なサンドボックス環境または開発環境の場合は、Autopilot クラスタを選択します。Autopilot では、GKE がノードを動的に管理し、リクエストされた Pod 容量に対してのみ課金されるため、VM、ノード オペレーティング システム、システム オーバーヘッドの料金を回避できます。

詳細については、GKE Autopilot の概要をご覧ください。

自動スケーリングの仕組みを理解する

GKE 自動スケーリング コントローラは、トラフィック リクエストの変化に応じてリソースを動的に調整します。

使用率の指標に基づいて Pod を追加または削除する

HorizontalPodAutoscaler（HPA）は、CPU またはカスタム指標に基づいて Pod を追加または削除します。

水平 Pod 自動スケーリングを理解して構成するには、次の GKE ドキュメントをご覧ください。

追加のレプリカ Pod の起動中にトラフィックの急増を処理するバッファを維持するために、ターゲット使用率のしきい値（70% または 80% など）を構成します。

使用率の指標に基づいて Pod をスケーリングする

HorizontalPodAutoscaler を使用しないワークロードや、ピーク時のワークロードが不明な場合は、VerticalPodAutoscaler（VPA）を使用して、コンテナの CPU リクエストとメモリ リクエストのサイズを動的に調整します。

垂直 Pod 自動スケーリングを理解して構成するには、次の GKE ドキュメントをご覧ください。

代表的なトラフィック パターンをキャプチャするには、本番環境と同様の環境で VPA を少なくとも 24 時間（理想的には 1 週間）Off （推奨のみ）モードのままにします。サイズ調整の誤りを防ぐため、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 を設定する

すべてのコンテナに readinessProbe と livenessProbe を構成して、GKE が準備完了の Pod にのみトラフィックをルーティングし、障害が発生したインスタンスを再起動して、自動スケーリング中のトラフィック損失を防ぐようにします。

詳細については、livenessProbe、readinessProbe、startup Probe を構成するをご覧ください。

アプリケーションの正常なシャットダウンを構成する

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 Deployment に依存しているため、Metrics Server Deployment の健全性をモニタリングします。

詳細については、 水平 Pod 自動スケーリングのトラブルシューティングをご覧ください。

費用削減の文化を育む

デベロッパーにクラウド支出ダッシュボードへのアクセス権を付与し、FinOps トレーニングを実施して、アーキテクチャの決定をビジネス コスト予算に合わせます。

組織の費用対効果の高い文化の詳細については、 費用削減の文化を広めるをご覧ください。

費用のベースラインと可視性のチェックリスト

次のステップ

費用対効果に必要なアーキテクチャの原則と組織 文化の詳細については、GKE で費用を最適化した Kubernetes アプリケーションを実行するための ベスト プラクティスをご覧ください。