Open the door of Kubernetes elastic prediction

背景

クラウドレジリエンスに対するユーザーの期待はますます高まっており、主に 2 つの側面から来ています。1 つ目はクラウドネイティブコンセプトの台頭です。VM 時代からコンテナ時代へ、クラウドの活用モードは変化しています。2 つ目は新しいビジネスモデルの台頭です。これらの新しいビジネスモデルは設計段階からクラウドを基盤として構築され、柔軟性へのニーズを自然に持っています。

クラウドユーザーは物理サーバやデータセンターのインフラをゼロから構築する必要がなくなり、クラウドは非常に柔軟なインフラを提供しています。クラウドの最大の利点は柔軟なリソース供給であり、特にクラウドネイティブ時代においてユーザーの柔軟性への要望は強まっています。弾性需要の強度は、VM 時代の手動操作による分単位から、コンテナ時代には秒単位まで達しています。異なるビジネスシナリオに直面して、クラウドへの期待と要件も変化しています。

• 周期的なビジネスシナリオ：ライブ配信、オンライン教育、ゲームなどの新しいビジネスは、非常に明確な周期性を持つという大きな共通点があり、これが顧客に弾性ビジネスアーキテクチャについて考えさせています。クラウドネイティブコンセプトにより、必要に応じてサービスバッチを起動し、使用後にリリースするという考えが非常に自然に浮かびます。

• サーバーレスの到来：サーバーレスのコアコンセプトはオンデマンドで使用し、自動的な弾性化を実現することです。ユーザーはキャパシティプランニングを行う必要がありません。しかし、実際にサーバーレスを使用すると、弾性ラグやコールドスタートなどの問題が発生します。これはレスポンス遅延に敏感なサービスでは許容できません。

では、前述のシナリオでは、Kubernetes の既存の弾性ソリューションで解決できるでしょうか？

従来の柔軟なソリューションが直面する問題

一般的に、Kubernetes でアプリケーションインスタンス数を管理する方法は 3 つあります。固定インスタンス数、HPA、CronHPA です。固定インスタンス数が最もよく使用されています。固定インスタンス数の最大の問題は、ビジネスの低迷期における明らかなリソースの無駄です。リソースの無駄問題を解決するために HPA が導入されましたが、HPA の弾性トリガーには遅延があり、リソース供給のラグを招きます。速やかにリソースを供給できないと、ビジネスの安定性が低下する可能性があります。CronHPA は固定時間でスケーリングでき、弾性ラグの問題を解決できるように見えます。しかし、具体的なタイミング粒度をどの程度細かく設定すべきか、トラフィック量の変化に応じてタイミング弾性ポリシーを頻繁に手動調整する必要があるでしょうか？これを実行すると、運用保守の複雑性が増し、間違いも起こりやすくなります。

AHPA 弾性予測

AHPA 弾性予測の主な出発点は、検出された周期に基づいて「タイミングプランニング」を行い、プランニングを通じて早期拡張の目的を達成することです。ただし、プランニングには見落としがあるため、プランニングされたインスタンス数をリアルタイムで調整する機能が必要です。したがって、このソリューションにはアクティブ予測とパッシブ予測の 2 つの弾性戦略があります。アクティブ予測は DAMO アカデミーの robustPeriod アルゴリズム [1] に基づいて周期の長さを識別し、次に robustSTL アルゴリズム [2] を使用して周期的なトレンドを抽出し、次の周期で適用されるインスタンス数をアクティブに予測します。パッシブ予測はアプリケーションのリアルタイムデータに基づいてインスタンス数を設定し、急なトラフィックにうまく対応できます。さらに、AHPA には下限保護ポリシーも追加されており、ユーザーはインスタンス数の上限と下限を設定できます。AHPA アルゴリズムで最終的に有効になるインスタンス数は、アクティブ予測、パッシブ予測、ボトムアップ戦略の最大値です。

フレームワーク

弾性化はまず安定したビジネス条件の下で実施されます。弾性化の核心的な目的は、ユーザーのコスト削減を支援するだけでなく、ビジネス全体の安定性を強化し、運用保守機能を解放してコア競争力を構築することでもあります。AHPA アーキテクチャ設計の基本原理：

• 安定性：ユーザーサービスの安定性を保証した上での弾性スケーリング

• 運用保守不要：ユーザーに追加の運用保守負担を追加しない。以下の内容を含みます。ユーザー側に新しいコントローラを追加しない、Autoscaler 設定セマンティクスは HPA よりも明確

• サーバーレス指向：K8s ノードの利用率に関わらず、ユーザーアプリケーション中心かつアプリケーション指向の Pod 次元設計を提供します。ユーザーが ECI Pod を使用していると想定できます。サーバーレスシナリオ（ノードなし）での弾性ベストプラクティスを考慮し、ASK の LongRun 実行機能を強化

アーキテクチャは次のとおりです。

• 豊富なデータ指標：CPU、メモリ、QPS、RT、外部指標を含む

• 安定性保証：AHPA の弾性ロジックは、アクティブなウォームアップとパッシブなボトムアウトの戦略に基づき、デグレード保護と組み合わせてリソースの安定性を保証

• アクティブ予測：履歴に基づいて将来の一定期間のトレンド結果を予測し、周期的なアプリケーションに適用

• パッシブ予測：リアルタイム予測。急なトラフィックシナリオでは、パッシブ予測を通じてリアルタイムでリソースを準備

• デグレード保護：最大値と最小値の時間範囲を持つ複数のインスタンス設定をサポート

• 複数のスケーリング方法：AHPA は Knative、HPA、Deployment を含むスケーリング方法をサポート：

• Knative：サーバーレスアプリケーションシナリオでの同時実行数/QPS/RT に基づく弾性コールドスタート問題を解決

• HPA：HPA 弾性ポリシー設定を簡素化し、ユーザーの弾性しきい値を下げ、HPA 使用時のコールドスタート問題を解決

• Deployment：Deployment を直接使用して自動的に容量を拡張および縮小

適応シナリオ

AHPA 適応シナリオには以下が含まれます。

• 明確な周期があるシナリオ

• 固定インスタンス数 + 柔軟なパッケージシナリオ

• 推奨インスタンス数設定シナリオ

予測効果

AHPA 弾性を有効にすると、AHPA 効果を表示するビジュアルページが提供されます。以下は CPU 指標に基づく予測の例です（HPA と比較）。

説明：

• Predict CPU Oberserver：青は HPA の実際の CPU 使用量を示し、緑は予測 CPU 使用量を示します。緑の曲線が青より大きいことは、予測による容量が十分であることを示しています。

• Predict POD Oberserver：青は HPA を使用して実際に拡張された Pod 数を示し、緑は予測された拡張 Pod 数を示します。緑の曲線が青より小さいことは、予測弾性による Pod 数がより低いことを示しています。

• 周期性：7 日間の過去データに基づいて、予測アルゴリズムを通じてアプリケーションに周期性が検出されました。

結論：予測結果は、弾性予測トレンドが期待通りであることを示しています。