GKE ワークロードのスケジューリング: リソースが不足している場合の戦略

※この投稿は米国時間 2025 年 6 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）をご利用のお客様は、自動アップグレードから手間のかからないノード管理まですべてをカバーする、高度なマネージド オペレーションを備えたコンテナ ランタイムを選択しています。この固有の効率性により、基盤となるインフラストラクチャよりも、アプリケーションに注力できるようになります。理想的な状況では、この合理化されたエクスペリエンスと GKE の堅牢な自動スケーリング機能が組み合わさることで、常に最適なワークロードのスケジューリングが実現します。アプリケーションはシームレスにスケールアップおよびスケールダウンされ、いつでも必要なリソースを必要なときに見つけることができます。

しかし残念ながら、現実の世界には、対処すべき課題がいくつか存在します。GKE には、ワークロードとインフラストラクチャのスケーラビリティのニーズに対応するための構成要素となる強力な 4 方向の自動スケーリング機能（HorizontalPodAutoscaler、VerticalPodAutoscaler、クラスタ オートスケーラー、ノード自動プロビジョニング）が備わっています。しかし、昨今の動的なワークロードに対応できる効率的なプラットフォームを運用するには、スケーラビリティの確保だけでは不十分です。費用の最適化、容量の可用性、リソースのスケーリング速度、全体的なパフォーマンス、インフラストラクチャの柔軟性などの要素はすべて、GKE でワークロードのスケジューリングを効果的に計画する方法に大きな影響を与え、制約となります。正直なところ、最適な戦略が何であるかや、これらのパラメータ間にどのようなトレードオフがあるかは、少しわかりにくい場合があります。

このブログ記事では、特に GKE スケジューラと、容量の制約がある場合にワークロードの配置に関する決定に影響を与える可能性がある要因に焦点を当てます。GKE のさまざまな機能とワークロード構成を使用して、これらのシナリオを計画および設計する方法について説明します。

これは（主に）制約最適化の問題である

GKE における効果的なワークロードのスケジューリングの核心となるのは、単一の最適なソリューションを見つけることではなく、多次元な制約最適化の問題を解決することです。多くのユースケースでは、厳しい制限を克服することより、相反する優先事項のトレードオフを見つけることが重要です。

• 費用: インフラストラクチャの全体的な費用を最小限に抑えて、利用率を最適化し、オーバープロビジョニングを回避して、費用対効果の高いソリューションを活用します。

• パフォーマンス: プラットフォームで実行されるワークロードが、ビジネスにおける相対的な重要度に応じて SLO を達成できるようにします。

• 柔軟性とアジリティ: 必要なときに必要な容量を提供することで、ワークロードの需要の変化に対応できるようにします。

これらの側面における個々の好みや許容範囲を理解することは、この制約空間をどのように乗り切るか、GKE 環境をどのように設計および構成するかを理解するうえで重要です。

主要な構成要素

自動スケーリングとその構成は、唯一の要因ではありませんが、ワークロードのスケジューリングにおいて重要な役割を果たします。スケーリングの構成は環境ごとに異なりますが、ベスト プラクティスがいくつか文書化されています。GKE は、次の 4 つの側面で自動スケーリングをサポートしています。

• HorizontalPodAutoscaler（HPA）- Pod のレプリカ数を調整します。

• VerticalPodAutoscaler（VPA）- 実際の使用状況に基づいて Pod のリソース リクエストを調整します。

• クラスタ オートスケーラー（CA）- ノード数を自動的に調整します。

• ノード自動プロビジョナー（NAP）- ワークロードの需要に基づいてノードプールのサイズを調整します。

容量が懸念される場合、ワークロードがリソースをどれだけリクエストし、消費するかを把握することが重要です。GKE スケジューラは、Pod の resource.request 値に基づいて最適なスケジューリングの決定を行います。これが設定されていないと、配置が不適切になり（容量が十分でないノードに配置されるなど）、プリエンプションが発生してワークロードが不安定になる可能性があります。リクエストの設定の重要性について詳しくは、こちらをご覧ください。

ワークロードのスケジューリングの制約シナリオ

容量が制限されているときに、効率的でパフォーマンスの高いプラットフォームを実行するための適切な選択肢について考えてみましょう。

一般的なシナリオの例をいくつか取り上げ、費用、パフォーマンス、柔軟性の面でワークロードから最適な結果を得るための選択肢について説明します。

容量が固定または制限されているが、優先度の高い一部のワークロードでは容量を保証する必要がある

このシナリオでは、利用可能なノード数は静的と見なされますが、ワークロードは需要に応じてスケールされます。そのため、重要なワークロードのリソースを保証し、優先順位を明示的に定義する必要があります。

ソリューション: ワークロードの優先度クラスと taint / toleration

• 優先度クラスでは、ワークロードの重要性の階層が実装され、優先度の高いワークロードが、スケジューリングの決定において優先度が低いワークロードよりも優先されます。上の図に示すように、容量の制約がある場合、スケジューラは優先度の低い（青）ワークロードを強制排除して、優先度の高い（赤）ワークロードを正常にスケジュールします。

• taint と toleration を使用すると、ワークロードが不適切なノードにスケジュールされないようにすることで、容量のターゲット設定が可能になります。特定の（taint が適用された）ノード（GPU や SSD を搭載しているなど）の容量全体が、特定のワークロードにのみ使用されるようになります。toleration が設定されているワークロードより優先度の高いワークロードであっても、taint が適用されたノードではスケジュールされません。

アプリケーションの需要が急増するが、パフォーマンスの低下やエラーなしでワークロードを迅速にスケールする必要がある

このシナリオでは、水平方向にスケーラブルなクラスタでワークロードを迅速にスケジュールする必要があります。GKE には、新しいノードのプロビジョニング時間を大幅に短縮できるコンテナ最適化コンピューティングやイメージ ストリーミングなどの機能がありますが、Pod のスケジューリングはノードのスケーリングよりもはるかに高速です。このため、リソースのボトルネックが発生し、SLO が低下する可能性があります。

ソリューション: プレースホルダ Pod とスケーリング プロファイル

• プレースホルダ Pod（「バルーン」Pod）には、クラスタ内の予備の実行容量を確保または予約する効果があります。急激な需要の増加により新しい Pod をスケジュールする必要が生じたら、これらのバルーン Pod は強制排除されて、容量が解放され、すぐに新しい Pod を代わりにスケールできるようになります。新しいノードは、強制排除されるプレースホルダ Pod を収容するように、クラスタ オートスケーラーによってプロビジョニングされ、必要に応じて追加の容量を提供します。

• 自動スケーリング プロファイルは、費用またはパフォーマンスに基づいてノードのスケールダウン動作を構成します。GKE には、クラスタベースのプロファイルとして、バランスと使用率最適化の 2 つがあります。バランス プロファイルでは、使用率最適化プロファイルに比べてノードがより穏やかにスケールダウンされるため、ノードがより長時間利用可能になります。したがって、需要がさらに急増した場合の対応が、新しいノードのプロビジョニング時間によって遅れることがありません。

ワークロード固有のノード スケールダウンは、コンピューティング クラスを使用することでも行えます（後で詳しく説明します）。これにより、使用率や時間遅延などのノード統合トリガーを使用し、さまざまな条件に合わせてノードの有効期間をカスタマイズできます。

クラスタにノードを追加でプロビジョニングする必要があるが、優先されるノードタイプが利用できない

このシナリオでは、特定のハードウェア アクセラレータやスポット インスタンスなど、必要なノードタイプまたは優先されるノードタイプが利用可能かどうかを把握せずにクラスタをスケールアウトする必要があるケースに対処します。

ソリューション: GKE カスタム コンピューティング クラス。

これにより、クラスタのスケールアウトに使用できる優先ノードとフォールバック ノードを指定できます。CPU やアクセラレータなどの特定のノード プロパティ、ノード特性（VM ファミリー、最小 CPU / メモリ、スポット）、または特定のインスタンス タイプ（n4-standard-16）に対して優先度を定義できます。コンピューティング クラスでは、優先度の高いものへのアクティブな移行も採用されます。つまり、優先度の最も高いオプション（スポット インスタンスなど）がデプロイ時に利用できなかった場合、利用可能になると、ワークロードは常にそのオプションを使用するように調整されます。リソースベースの確約利用割引（CUD）を利用しているユーザーの場合、他のリソースに移行する前に、確約されたリソースを優先するようにコンピューティング クラスを構成できます。マシン ファミリー、リージョン、さらにはコンピューティング プラットフォーム間での完全な柔軟性を確保するため、将来的にはフレキシブル CUD への移行も検討してください。

優先されるリソースが特定のリージョンで利用できない

このシナリオでは、ワークロードに必要な容量が非常に特殊で、需要も高くなります。コンピューティング クラスを使用しても、リージョンでリソースを取得できない可能性さえあります。これは、高パフォーマンス インフラストラクチャと GPU または TPU アクセラレータを必要とする AI ベースのワークロードでは特に重要です。

ソリューション: マルチクラスタ オーケストレーターとマルチクラスタ ゲートウェイ

• マルチクラスタ オーケストレーターは、オープンソース プロジェクトであり、その主な目標は「マルチクラスタ デプロイの簡素化、リソースの使用率と費用の最適化、ワークロードの信頼性、スケーラビリティ、パフォーマンスの向上」です。GKE でこのテクノロジーを使用すると、プラットフォーム エンジニアは、ワークロードの容量要件が、その容量が利用可能なリージョンと一致している場合、Google Cloud リージョン間で、事実上「容量追跡」を行うことができます。マルチクラスタ オーケストレーターは、そのリージョンでクラスタのプロビジョニングを開始してワークロードを実行します。

• マルチクラスタ ゲートウェイは、GKE 向けのネットワーキング ソリューションです。Kubernetes Gateway API を活用して、複数の GKE クラスタ（異なるリージョンにまたがる可能性がある）間でアプリケーション トラフィックを管理します。地理的に分散した GKE 環境で、サービスの公開とワークロードのバランス調整という複雑なタスクが簡素化されます。

まとめと次のステップ 

GKE は、容量の制約に直面してもリソース割り当てを最適化できる堅牢なツールセットをプラットフォーム エンジニアに提供します。効果的かつ包括的な容量計画を行うには、ワークロードの重要度、使用状況プロファイル、容量要件など、ワークロードを明確に理解する必要があります。制約のある容量を管理することは、費用を抑える戦略的な手段であり、そのような状況下でパフォーマンスを最適化することが重要になります。

容量計画をさらに強化するには、次のリソースをご覧ください。

• 使用率とサイズ適正化など、GKE クラスタとワークロードのシグナルについて理解し、それらが容量計画においてどの程度重要であるかを理解します。

• スケジュール不可の Pod ダッシュボード テンプレートで、Pod スケジューリングの失敗イベントやノード / Pod 数の変更などのスケーリング イベントをモニタリングします。

最近リリースされた機能である GKE 水平 Pod 自動スケーリングのオブザーバビリティ イベントをご覧ください。この機能を使用すると、HPA オートスケーラーの決定イベントをログで確認できます。これは、プラットフォーム設計に影響する可能性があるスケーリング イベントの決定を追跡して理解するのに役立ちます。

ー アプリケーション モダナイゼーション担当 EMEA ソリューション リード、Olive Power

ー アプリケーション モダナイゼーション担当 EMEA ソリューション リード、Daniel Strebel