GKE での AI / ML ワークロード向けの簡素化された自動スケーリングの概念

このドキュメントでは、Google Kubernetes Engine（GKE）の AI/ML ワークロードの自動スケーリングのコンセプトの概要について説明します。

このドキュメントは、GKE を初めて使用する ML エンジニアを対象としています。AI/ML ワークロードに GKE を簡単に使用できるように、このシリーズの次のドキュメントを読むことをおすすめします。

  1. AI/ML 推論に GKE を使用する理由
  2. GKE での AI/ML モデル推論について
  3. GKE での AI/ML ワークロードの自動スケーリングのコンセプトの簡略化（このドキュメント）

始める前に

次のコンセプトについて基本的な知識が必要です。

課題: ピーク時の需要に対応する

架空のオンライン小売業者である Cymbal Shops は、年次セール イベントの準備を進めています。店舗の AI 搭載レコメンデーション エンジンは、大量のオンライン ショッパーにリアルタイムでパーソナライズされた提案を提供する必要があります。

レコメンデーション エンジンの速度が低下すると、ユーザー エクスペリエンスが低下し、販売機会を逃すことになります。ただし、通常のトラフィック期間中に過剰なサーバー容量をプロビジョニングすることは、費用対効果が低くなります。目標は、需要に応じてリソースを自動的にスケーリングし、コストを管理しながら優れたユーザー エクスペリエンスを確保することです。

解決策: オンデマンドの自動スケーリング

GKE の自動スケーリングは、セールラッシュに備える店舗マネージャーのようなものです。巨大な建物を常にフルスタッフで稼働させるのではなく、マネージャーは店舗の全容量（スタッフ、フロアスペース、設備）を、その時点での買い物客のニーズに合わせて動的に調整します。

GKE はこの原則を適用し、リアルタイムの需要に基づいてアプリケーションに割り当てられたリソース（ワークロードとインフラストラクチャの両方）を自動的にスケーリングします。

GKE 自動スケーリングのビジネス上のメリット

水平スケーリングと垂直スケーリングの戦略を組み合わせることで、GKE は 3 つの主なメリットを提供する堅牢なアプローチを提供します。

  • 費用の最適化: 使用したコンピューティング リソースに対してのみ料金が発生し、過剰なプロビジョニングによる費用を回避できます。GKE 自動スケーリングは、アプリケーションを実際の CPU とメモリの要件に合わせて自動的に適切なサイズに調整することで、無駄をなくします。また、高価な専用ハードウェア（GPU など）を必要なときにのみプロビジョニングし、ジョブが完了したら削除することもできます。
  • 信頼性とパフォーマンスの向上: アプリケーションは自動的にスケールアウト（コピーを追加）して、トラフィックの急増に対応し、ユーザーの安定性を確保できます。同時に、GKE の自動スケーリングは、アプリケーションをクラッシュさせる可能性のある一般的な「メモリ不足」（OOM）エラーを防ぐのに役立ちます。要求の厳しい AI/ML ジョブでは、必要な高性能ハードウェアが効率的に実行され、ジョブが時間どおりに完了するようにします。
  • 運用オーバーヘッドの削減: GKE の多次元自動スケーリング戦略により、リソース管理が大幅に簡素化されます。GKE は、リソース リクエストの調整や、さまざまなハードウェア用の専用ノードプールの管理などの複雑なタスクを自動化します。この自動化により、エンジニアリング チームはインフラストラクチャの調整ではなく、アプリケーション開発に集中できます。

ワークロードの自動スケーリング

ワークロードの自動スケーリングは、需要に合わせてアプリケーションの能力を自動的に調整します。GKE は、2 段階の自動スケーリング システムを使用して、アプリケーションのリソースを効率的に管理します。

Horizontal Pod Autoscaler（HPA）: リソースの追加

HorizontalPodAutoscaler（HPA）は、アプリケーションの Pod のリソース使用率をモニタリングします。この例では、Pod が「販売員」、HPA が「チーム マネージャー」で、販売員の忙しさを監視しています。

Pod の需要が増加すると、HPA は負荷を分散するために Pod を自動的にプロビジョニングします。需要が減少すると、HPA はアイドル状態の Pod を終了してリソースを節約します。

詳細については、水平 Pod 自動スケーリングをご覧ください。

Vertical Pod Autoscaler（VPA）: リソースの強化

水平方向のスケーリングはリソースの量を増やすことに重点を置いていますが、垂直方向のスケーリングは既存のリソースの能力を高めることに重点を置いた補完的な戦略です。オフラインの店舗に例えると、これはスタッフの増員ではなく、現在のチームの能力を高めて個々の効率を向上させることです。

Pod レベルの垂直スケーリングのこのアプローチは、垂直 Pod オートスケーラー（VPA）によって管理されます。VPA は、アプリケーションのリソース消費量を分析し、Pod の CPU とメモリのリクエストを実際の使用量に合わせて増減します。

VPA は、Pod のリソース リクエストと上限を調整できます。たとえば、Pod を再プロビジョニングして、1 CPU と 16 GB から 4 CPU と 64 GB にスケーリングします。このプロセスでは、ワークロードをより適切に処理するために、新しい高性能な構成で Pod を再起動します。

詳しくは、次のリソースをご覧ください。

HPA と VPA は相補的です。HPA はトラフィックの変化に応じて Pod の数を調整し、VPA はこれらの Pod のサイズがタスクに対して適切であることを確認します。これらのスケーリング戦略により、リソースの無駄をなくし、不要な費用を回避し、トラフィックの変動時でもアプリの応答性と可用性を維持できます。ただし、HPA と VPA を同じ指標（CPU とメモリ）で使用すると競合する可能性があるため、おすすめしません。詳細については、水平 Pod 自動スケーリングの制限事項をご覧ください。

インフラストラクチャの自動スケーリング

インフラストラクチャの自動スケーリングでは、ワークロードの需要に合わせてハードウェアが自動的に追加または削除されます。

クラスタ オートスケーラー: ビルディング マネージャー

クラスタ オートスケーラーは、Pod を収容するのに十分な基盤となるインフラストラクチャ（VM、または GKE のコンテキストではノード）があることを確認します。ノードは店舗の「フロア」、クラスタ オートスケーラーは「ビル管理者」に例えることができます。

HPA が Pod を追加する必要があるが、既存のノードで使用可能な容量が不足している場合、クラスタ オートスケーラーは新しいノードをプロビジョニングします。逆に、ノードの使用率が低下すると、クラスタ オートスケーラーはそのノードの Pod を他のノードに移動し、空になったノードを終了します。

詳細については、クラスタ オートスケーラーをご覧ください。

ノードプールの自動作成: 自動化のスペシャリスト

クラスタ オートスケーラーは既存のノードプールにノードを追加しますが、ノードプールの自動作成により、Pod の特定のニーズに一致する新しいノードプールを自動的に作成できるようになり、クラスタ オートスケーラーの機能が拡張されます。

特定の AI/ML ワークロードでは、汎用ノードプールで使用できない GPU や TPU などの専用の高性能ハードウェアが必要です。ノードプールの自動作成により、ワークロードでこの特殊なハードウェアが必要になったときに、このハードウェアのプロビジョニングが完全に自動化されます。これにより、計算負荷の高いタスクでも、必要なときに必要なハードウェアを確実に取得できます。

詳細については、ノードプールの自動作成についてをご覧ください。

GKE で使用可能なアクセラレータについては、以下をご覧ください。

ComputeClass: ノードプールの自動作成のトリガー

ノードプールの自動作成は、Pod が特定のハードウェア タイプ（nvidia-l4-vws など）をリクエストすることでトリガーできますが、ComputeClass を使用する方がより復元力があり、最新の方法です。ComputeClass は、定義する GKE リソースです。一連のルールに基づいて、ハードウェアの自動スケーリング方法を制御およびカスタマイズします。これはオートスケーラー自体ではありませんが、クラスタ オートスケーラーと連携します。

例を拡張すると、ComputeClass は店舗の備品の「スマートな請求書」と考えることができます。

販売員（Pod）が特定の固定されたハードウェア（「ブランド X モデル 500 のレジが必要です」など）を要求するのではなく、要求フォームを使用して機能（「高速チェックアウト ステーションが必要です」など）を要求します。フォーム（ComputeClass）には、購入チーム（GKE）がその注文を履行する方法に関する一連のルールが含まれています。

ComputeClass は、Pod のハードウェア リクエストを GKE のプロビジョニング アクションから分離します。Pod が特定のマシン（a3-highgpu-8g など）を要求する代わりに、ComputeClass をリクエストできます。ComputeClass 自体は、「スマート」ロジック、つまり GKE にリクエストの処理方法を指示する優先順位付きのルールのリストを定義します。

詳細については、GKE ComputeClass についてをご覧ください。

実際の例と YAML 構成を含む ComputeClass の詳細については、テクニカル ガイドの カスタム ComputeClass を使用して GKE ワークロードを最適化するをご覧ください。

自動スケーリングの主な指標とトリガー

自動スケーリング コンポーネントは、スケーリングに関する十分な情報に基づいて判断を下すために、さまざまなシグナルをモニタリングします。次の表に、指標ベースの自動スケーリング トリガーの比較を示します。

コンポーネント 次のイベントに反応します シグナルのソース 思考プロセス GKE のアクション
HPA 現在の負荷 リアルタイムの使用量（CPU が現在 90% など）。 「現在の Pod が過負荷状態です。このトラフィックをすぐに分散する必要があります。」 スケールアウトまたはスケールイン: 需要に合わせて Pod レプリカの数を変更します。
VPA サイズ設定の効率 過去の使用量（過去 24 時間の平均 RAM 使用量など）。 「この Pod のリソース要件が変更されたか、最初の見積もりが正しくありませんでした。実際の使用量に合わせてリソース割り当てを調整する必要があります。」 スケールアップまたはスケールダウン: Pod のサイズ（CPU または RAM の上限）を変更して、適切なサイズにします。
ノードプールの自動作成 ハードウェアの可用性 満たされていないリクエスト（GPU ノードが存在しないため、Pod が「保留中」ステータスになっているなど）。 「要求された物理ハードウェアがないため、この Pod を起動できません。」 インフラストラクチャをプロビジョニングする: 特定のハードウェアを使用して新しいノードプールを作成します。

Horizontal Pod Autoscaler（HPA）トリガー: 負荷への対応

HPA は、リアルタイムのパフォーマンス指標を監視して、Pod の数をスケーリング（スケールインまたはスケールアウト）します。たとえば、Pod の処理負荷を示す基本的な指標である CPU とメモリの使用率は、HPA でそのまま使用できます。

ただし、一部の指標では、次のような明示的な構成が必要です。

  • ロードバランサの指標（リクエスト数/秒（RPS））: アプリケーション トラフィックを直接測定し、スケーリングの応答を迅速化します。この指標を使用するには、使用率ベースのロード バランシングとパフォーマンス HPA プロファイルを有効にするをご覧ください。
  • カスタム指標: 「アクティブ ユーザー数」などのカスタム ビジネス指標に基づいて自動スケーリングを構成し、予測される需要に基づいてリソースを事前に管理します。カスタム指標を使用するには、指標パイプラインを設定して HPA に公開する必要があります。詳細については、Google Cloud Managed Service for Prometheus をご覧ください。

垂直 Pod 自動スケーラー（VPA）トリガー: リソースのニーズに対応する

VPA は、過去のリソース消費量をモニタリングして、Pod のサイズをスケーリング（スケールアップまたはスケールダウン）します。

  • CPU とメモリの使用率: VPA は Pod の過去の使用状況を分析して、リソースのリクエストが正しいかどうかを判断します。VPA の主な目的は、Pod のメモリと CPU のリクエストを実際のニーズに合わせて増減させることで、リソースの競合を防ぐことです。

ノードプールの自動作成のトリガー: ハードウェア リクエストへの対応

ノードプールの自動作成では、特殊なハードウェアを使用して新しいノードプールがプロビジョニングされます。CPU 負荷などのパフォーマンス指標によってトリガーされることはありません。代わりに、Pod のリソース リクエストによってトリガーされます。

  • スケジュールできないリソース リクエスト: 主要なトリガー。Pod が作成されると、特定のハードウェアがリクエストされます。既存のノードにそのハードウェアがないため、クラスタがこのリクエストを満たせない場合、ノードプールの自動作成が実行されます。
  • ComputeClass リクエスト: Pod が ComputeClass（cloud.google.com/compute-class: premium-gpu など）をリクエストします。クラスタ内のどのノードも「premium-gpu」機能を提供できない場合、ノードプールの自動作成によって、これらの機能を提供できる新しいノードプールが自動的に作成されます。

カスタム指標、Prometheus 指標、外部指標を使用して自動スケーリングを実現する方法については、指標に基づくワークロードの自動スケーリングについてをご覧ください。

まとめ

これらの自動スケーリング戦略を適用することで、変動する AI/ML ワークロードを効果的に管理できます。Cymbal Shops の店長がリソースを柔軟に管理してピーク時の販売イベントを乗り切ったように、GKE 自動スケーリングを使用してインフラストラクチャとワークロードのリソースを自動的に拡張および縮小できます。これにより、トラフィックの急増時にはモデルのパフォーマンスを維持し、トラフィックの少ない期間には費用対効果を高め、環境のサイズを適切に保つことができます。

次のステップ