Kubernetes ネイティブのスケーリングは、本質的にリアクティブです。メトリックしきい値を超過した後にのみリソースがスケーリングされるため、トラフィックスパイクがすでに発生した後にPodが起動します。ACS は、Advanced Horizontal Pod Autoscaler (AHPA) に基づく予測スケーリングをサポートしており、過去のメトリックデータから学習して、ワークロードが必要とするPodの数を — 1分ごとに — 今後24時間予測し、需要のピーク前にそれらをプロビジョニングすることで、この問題を解決します。
既存のスケーリングアプローチの課題
| メソッド | 制限事項 |
|---|---|
| 手動Pod数 | オフピーク時にはアイドル状態のPodがリソースを浪費します |
| Horizontal Pod Autoscaler (HPA) | メトリックしきい値を超過した後にのみ反応します。リソース使用量がしきい値を超過した場合にのみスケールアウトがトリガーされ、下回った場合にのみスケールインがトリガーされるため、容量は常に需要に遅れます |
| CronHPA | 分単位の粒度で24時間をカバーするために、最大1,440エントリの各時間帯に個別のスケジュールが必要であり、トラフィックパターンが変更されるたびに手動更新が必要です |
AHPA は、予測スケーリングを通じてこれらの制限に対処します。需要に先立ってPodをプロビジョニングすることで、トラフィックスパイクと利用可能な容量との間のギャップを解消します。
以下の図は、2つのアプローチを対比しています。従来のHPAでは、ワークロードの急増後にPodが起動します。AHPAでは、急増前にPodがReady状態に達します。
仕組み
AHPA は、アプリケーションに十分なリソースを保証するために、プロアクティブ予測、パッシブ予測、およびサービス低下の3つのメカニズムを組み合わせます。
上記の図は、AHPAコントローラーがHPAおよびDeploymentsと連携して、需要に先立ってPodをスケジュールする方法を示しています。
| メカニズム | 動作 |
|---|---|
| プロアクティブ予測 | 履歴メトリックデータを分析してワークロードの傾向を予測し、Podを事前スケジュールします。定期的または予測可能な変動パターンを持つワークロードに最適です |
| パッシブ予測 | リアルタイムでワークロードの変動を検出して応答し、変動が発生したときにリソースをデプロイします |
| サービス低下 | 1つ以上の期間内でPodの最大数と最小数を指定でき、予測結果に関係なく、オペレーターに保証された下限と上限を提供します |
サポートされているメトリック: CPU、GPU、メモリ、秒間クエリ数 (QPS)、レスポンスタイム (RT)、および外部メトリック。
スケーリング実行: AHPA は、HPA — その構成を簡素化し、組み込みのスケーリング遅延を補償します — またはDeploymentsを直接通じて機能します。
パフォーマンス
| メトリック | 値 |
|---|---|
| ワークロード変動の検出 | ミリ秒以内 |
| リソースプロビジョニング | 秒以内 |
| 予測精度 | プロアクティブ予測とパッシブ予測を組み合わせることで95%以上 |
| スケジューリング粒度 | Pod数が分単位で指定される |
ユースケース
定期的なワークロード: 予測可能なトラフィックサイクルを持つアプリケーション — ライブストリーミング、オンライン教育、ゲーム — は、各ピーク前に容量を事前にウォームアップするプロアクティブ予測から最も恩恵を受けます。
バーストトラフィックを伴う固定ベースライン: デプロイメントが定常状態のトラフィックに対してすでに固定Pod数を実行している場合、AHPA は複数のスケーリングポリシーを管理する必要なく、予期せぬ急増に対処します。
カスタムオートスケーリング統合: プラットフォームチームがスケーリング推奨事項を内部ツールまたはCI/CD パイプラインに統合する必要がある場合、AHPA は標準Kubernetes APIを公開するため、予測結果を取得し、プログラムでそれらに基づいて処理できます。