GPUワークロードにおけるオートスケーリングの問題は、Kubernetesが判断を下せないことではなく、判断が手遅れになってから届くことかもしれない。AdobeのRamkumar Nagaraj氏とBingi Narasimha Karthik氏は、重要な本番サービスが需要の波にさらされ、Horizontal Pod Autoscalerがスケーリングを開始したにもかかわらず、ユーザーのエラー率が15～20%に達した事例を説明している。原因は、数百のコンテナが待機状態にとどまり、新しいGPUノードが利用可能になるまでに長い時間を要したことだった。
著者らが記録したタイムラインでは、需要の波が06:00に到来し、HPAの指標が06:05にしきい値を超え、コンテナのスケジューリングが06:15に始まった。しかし、最初のGPUノードの準備が完了したのは06:45で、急増が終わった後だった。GPUノードの準備には通常、ファームウェアの読み込み、ドライバーの設定、CUDAの準備が必要なため、CPUに依存するサービスの準備時間の3～5倍を要する。
需要への反応から、需要への備えへ
チームは、Kubernetes内で60秒ごとに動作するコントローラーを稼働させ、過去1時間の指標を読み取り、10分後の需要を予測することを提案した。目的は完璧な予測ではなく、波が到来する前に、必要な時点でノードとコンテナが準備できるだけの余裕をもって容量の準備を始めることだ。
この設計では、Prometheusが収集するデータとして、CPUとメモリの使用率、応答時間、リクエスト率、GPU使用率などを利用した。チームはARIMA、指数平滑法、Prophetライブラリ、LSTMを検証した後、64ユニット、続いて32ユニットの2層で構成されるBi-LSTMモデルを選択した。記事によれば、この選択は、短い急増、回復期間、異常な一定値を含むデータパターンに対応するためであり、あらゆるケースで理論上最良の選択だったからではない。
モデルは毎週再学習される一方、デプロイされたモデルは、TensorFlow Liteを使用するGo製コントローラーのバイナリ内で、推論専用モードで動作する。これにより、この設計は外部の機械学習プラットフォームやモデルサービング層を必要としない。
スケーリングを制御する3つの層
この設計は、予測、準備、吸収という相互に連携する3つの機能を基盤としている。モデルが需要を予測し、コントローラーがレプリカを段階的に増やし、事前に準備された容量が実際の波を受け止める余地を提供する。
予測ではあらゆる突発事象に対応できないため、チームは並行して動作する急増検出器を追加した。このコンポーネントは、移動標準偏差に基づく適応型しきい値を用いて、実際の需要と予測を比較する。需要が予測を上回り、設定された信頼水準を満たす差が生じた場合、検出器はスケーリングの速度を上げる。著者らはこのコンポーネントを、2つ目の予測モデルではなく、推論に基づく安全網と説明している。
一方、段階的スケーラーは増加を1分あたり20コンテナに制限する。これは、大規模なスケジューリングの波がスケジューラーとetcdに負荷をかけ、イメージのプル、コンテナの起動、初期コンテナの初期化、サイドカーの注入が競合するのを防ぐことを目的としている。また、目標使用率は100%ではなく70%に設定され、急増を吸収し、モデルが時折不正確でもエラーが一連の障害に発展しないよう余裕を残している。
テストで何が実証されたのか？
チームはまずシャドーモードでシステムを稼働させ、実際のスケーリングを実行せずに予測を記録し、500時間を超えるデータを収集した。結果は、10分後の需要予測が実際の需要の±10%以内に収まった場合、85%の精度を示した。また、急増検出器は10回中9回の波を検出し、誤警報は2回だった。段階的スケーラーのテストでは、連鎖的な障害やスケーリングの振動は発生しなかった。
このシステムはHPA v2と並行して動作し、競合も発生しなかった。制御された開発環境で1週間の検証を行った結果、23件中23件のテストに合格した。元のインシデントを引き起こした急増パターンのシミュレーションでは、システムは約11分前に波を検出できた。
このアプローチはいつ適しているのか？
予測的スケーリングの価値が現れるのは、ノードの準備に2～3分以上かかり、日次・週次パターンや既知のイベントなど、需要が部分的に予測可能な場合だ。また、少なくとも1週間分のPrometheus指標を含む、良質な監視データも必要になる。一方、ノードが30秒以内に準備される場合、需要が完全にランダムな場合、またはチームの最優先事項が何よりもコスト削減である場合、この考え方の有効性は低くなる。ウォームなノードを維持することは、予備容量のコストを支払うことを意味するためだ。
編集部の見解：ここでの実務的な変化はHPAを置き換えることではなく、通常は需要が現れてから対応するシステムに予測時間を追加することだ。その重要性は特にGPUワークロードで顕著であり、インフラストラクチャがコンテナの起動までに数十分を必要とする場合、スケーリングの判断が速いだけでは不十分である。ただし、提示された証拠は依然として統制された検証の結果であり、複数の本番環境を対象とした大規模な独立測定ではない。
チーム自身の経験も重要な制約を示している。調整されたARIMAモデルなら、より単純な構成で近い結果を達成できる可能性があり、需要パターンが変化すれば、モデルは数日で古くなる可能性がある。また、なぜ特定のレプリカ数を予測したのかを説明することは依然として難しく、最適なデータ量、再学習の周期、推論型の急増検出器が前例のないイベントを検出できる能力についても、まだ結論は出ていない。
そのため記事では、まず1週間分の指標を収集し、単純なモデルを訓練してシャドーモードで稼働させ、スケーリングを有効にする前に精度を測定することを提案している。本番へ移行する際には、レプリカ数の上限を設け、明確な無効化手順を用意し、できれば全面的に開放する前に制限付きスケーリングの段階を設けるべきだ。著者らが繰り返す結論は実践的である。モデルの複雑さ自体は利点ではなく、より単純なソリューションが成功するなら、それを稼働させる方がよい。