COLA: クラウドマイクロサービス向け集団的オートスケーリング

1. はじめに

クラウドアプリケーションにおけるモノリシックアーキテクチャから疎結合なマイクロサービスへの移行は、リソース管理に大きな複雑さをもたらします。開発者は各マイクロサービスに割り当てる計算リソース（コンテナレプリカ、VMなど）の数を決定しなければなりません。この決定は、開発者の運用コストとアプリケーションユーザーが経験するエンドツーエンドのレイテンシの両方に重大な影響を及ぼします。Horizontal Pod Autoscaling (HPA) のような従来のオートスケーリング手法は、CPU使用率などのローカルメトリクスに基づいて各マイクロサービスを独立してスケールします。しかし、このアプローチは、アプリケーションのワークフロー内におけるマイクロサービスの相互依存性を無視しているため、最適とは言えません。COLA (Collective Autoscaler) は、すべてのマイクロサービスにわたってリソースを集団的に割り当て、グローバルな目的（アプリケーションのエンドツーエンドレイテンシを指定された目標以下に保ちつつ、コストを最小化する）を達成するソリューションとして提案されています。

2. 独立型オートスケーリングの問題点

現在の業界標準のオートスケーリングは、分散型のマイクロサービス単位で動作します。各サービスは、自身のリソース使用率（CPU、メモリ）が閾値を超えたときに、スケーリングアクション（VMやPodの追加/削除）をトリガーします。根本的な欠陥は、このローカルな視点がアプリケーション全体のパフォーマンスを考慮していない点です。チェーン内の別のサービスがボトルネックのままである場合、1つのマイクロサービスのレイテンシを改善しても、ユーザーが認識する全体のレイテンシへの影響は無視できる可能性があります。これにより、リソース割り当てが非効率になります。つまり、一部のサービスは過剰にプロビジョニングされ、重要なボトルネックは過少にプロビジョニングされ、望ましいレイテンシサービスレベル目標 (SLO) を達成できないままコストが高くなってしまいます。

3. COLA: 集団的オートスケーリング手法

COLAは、オートスケーリング問題を制約付き最適化問題として再定義します。複数の独立したオートスケーラーを、アプリケーションのマイクロサービス・トポロジーとパフォーマンスをグローバルに把握できる単一の集中型コントローラーに置き換えます。

3.1. コア最適化フレームワーク

目標は以下のように形式化されます：

目的関数: 総計算コストの最小化。
制約条件: アプリケーションのエンドツーエンド平均またはテールレイテンシ ≤ 目標レイテンシ。
決定変数: 各マイクロサービス $i$ に割り当てるVM（またはレプリカ）の数 $n_i$。

$n_i$ とエンドツーエンドレイテンシの関係は単純ではなく、ワークロードパターンやサービス間通信に依存するため、これは複雑な非線形最適化問題です。

3.2. オフライン探索プロセス

プロビジョニングとパフォーマンス安定化に時間がかかるため、この最適化をオンラインで解くことは非現実的です。したがって、COLAはオフライン探索プロセスを採用します：

ワークロード適用: アプリケーションに代表的なワークロードを適用する。
ボトルネック特定: 最も混雑しているマイクロサービス（負荷下でCPU使用率の増加が最も大きい）を特定する。
バンディット問題によるリソース割り当て: ボトルネックサービスに対して、マルチアームバンディット問題の定式化を用いて最適なVM数を決定する。「報酬」関数は、レイテンシ改善とコスト増加のバランスを取る。
反復: グローバルなレイテンシ目標が達成されるまで、次に混雑しているマイクロサービスに対してステップ2-3を繰り返す。
ポリシー生成: 結果は、オンラインでデプロイ可能なスケーリングポリシー（ワークロード特性からリソース割り当てへのマッピング）となる。

COLAは、既知のワークロード間を補間でき、未知のワークロードパターンに直面した場合はデフォルトのオートスケーラーにフォールバックします。

4. 技術詳細と数式定式化

コアとなる最適化問題は、抽象的に以下のように表現できます：

$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{subject to: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ ここで：

$M$: マイクロサービスの数。
$n_i$: マイクロサービス $i$ に割り当てるリソース単位（例：VM）の数。
$C_i(n_i)$: $n_i$ 単位のマイクロサービス $i$ のコスト関数。
$L_{e2e}$: すべての $n_i$ とワークロード強度 $\lambda$ に依存するエンドツーエンドレイテンシ関数。
$L_{target}$: 望ましいレイテンシSLO。

COLAの探索におけるステップ3の「バンディット問題」では、ボトルネックサービスに対する各可能なVM割り当てを「アーム」として扱います。アームを引くことは、その構成をプロビジョニングし、結果として生じるコストとレイテンシのトレードオフを測定することに対応します。Upper Confidence Bound (UCB) のようなアルゴリズムを使用して、構成空間を効率的に探索・活用することができます。

5. 実験結果と評価

COLAは、Google Kubernetes Engine (GKE) 上で、いくつかのベースラインオートスケーラー（使用率ベースおよびMLベース）に対して厳密に評価されました。

5.1. 実験環境

アプリケーション: 5つのオープンソースマイクロサービスアプリケーション（例：Simple WebServer, BookInfo, Online Boutique）。
プラットフォーム: GKE Standard（ユーザー管理ノード）および GKE Autopilot（プロバイダー管理インフラ）。
ベースライン: 標準HPA（CPUベース）、高度なMLベースオートスケーラー。
ワークロード: 63種類の異なるワークロードパターン。
目標: 指定された中央値またはテール（例：p95）レイテンシSLOを満たす。

5.2. 主要パフォーマンス指標

SLO達成率

53/63

COLAがレイテンシ目標を達成したワークロード数。

平均コスト削減率

19.3%

次に安価なオートスケーラーとの比較。

最もコスト効率の高いポリシー

48/53

成功した53のワークロードのうち、48のワークロードでCOLAが最も安価でした。

小規模アプリでの最適性

~90%

網羅的探索が可能な小規模アプリケーションでは、約90%のケースでCOLAが最適な構成を見つけました。

5.3. 結果の概要

結果は、COLAの顕著な優位性を示しています。COLAは、他の手法が失敗した場合でも一貫して望ましいレイテンシSLOを達成し、それを大幅に低いコストで実現しました。コスト削減効果は非常に顕著で、COLAのオフライン探索を実行する「トレーニングコスト」は、運用開始数日以内に回収されました。GKE Autopilotでは、プロバイダー管理の抽象化を効果的にナビゲートしてコストを最小化するため、COLAの利点はさらに明白でした。

（想定される）チャートの説明: 棒グラフでは、Y軸に「成功リクエストあたりのコスト」または「クラスター総コスト」、X軸に異なるオートスケーラー（COLA、HPA、ML-A）が表示され、COLAの棒は他よりも大幅に低くなると考えられます。2番目のグラフでは「レイテンシSLO違反率」が示され、COLAの棒はゼロに近く、他の手法はより高い違反率を示すでしょう。

6. 分析フレームワークと事例

アナリストの視点：4段階の分解

核心的洞察: 本論文の根本的なブレークスルーは、洗練された新しいアルゴリズムではなく、視点の重要な転換にあります。それは、マイクロサービスアプリケーション全体を、独立した部品の集合ではなく、最適化すべき単一のシステムとして扱うことです。これは、CycleGAN (Zhu et al., 2017) のようなモデルがもたらしたコンピュータビジョンの転換（ペア画像変換を超え、変換領域全体のサイクル一貫性を考慮すること）に類似しています。COLAは、リソース管理に同様の「グローバル一貫性」の原則を適用します。

論理的流れ: 議論は説得力がありシンプルです：1) 局所最適（サービス単位のスケーリング）は、全体として非効率を生む。2) したがって、グローバルな制約（エンドツーエンドレイテンシ）付きのグローバルな目的（コスト）を使用する。3) これをオンラインで解くには遅すぎるため、探索によってオフラインで解き、ポリシーをデプロイする。優雅さは、ボトルネックの最適割り当ての探索を効率化するためにバンディット問題を使用する点にあり、この技術はシステム最適化のための強化学習に関する広範な研究（例：UC BerkeleyのRISELabの研究）によって支持されています。

強みと欠点: 強み: 実証結果は素晴らしいものです。19.3%のコスト削減は、経営会議レベルの数字です。オフラインアプローチは実用的で、ランタイムの不安定性を回避します。フレームワークはプラットフォームに依存しません。欠点: アキレス腱は、代表的なオフラインワークロードへの依存性です。急速に進化するアプリケーションや「ブラックスワン」的なトラフィックイベントでは、事前計算されたポリシーは時代遅れになったり、壊滅的な結果をもたらしたりする可能性があります。本論文でデフォルトのオートスケーラーへのフォールバックを提案していますが、これは堅牢性の問題に対する応急処置であり、根本的な解決策ではありません。さらに、探索の複雑さはマイクロサービスの数に対してスケールしにくい可能性があり、非常に大規模で複雑なアプリケーションでの使用が制限されるかもしれません。

実践的示唆: クラウドアーキテクトにとって、メッセージは明確です：CPU閾値を孤立して設定するのをやめること。グローバルなパフォーマンス可観測性と集中型意思決定エンジンの構築または導入に投資すること。ハイブリッドアプローチから始めること：COLAの哲学を使用して重要なサービスチェーンを定義し、そこに集団的スケーリングを適用し、重要度の低い独立したサービスは従来のHPAに任せること。示されたように、投資収益率 (ROI) は迅速です。クラウドプロバイダーは注目すべきです。GKE Autopilotのようなツールは、「マネージド」インフラの約束を真に実現するために、このようなインテリジェントなオーケストレーション層を必要としています。

7. 応用の展望と将来の方向性

COLAの背後にある原則は、基本的なVMスケーリングを超えて広範な適用可能性を持っています：

マルチリソースおよび異種スケーリング: 将来のバージョンでは、VMサイズ（メモリ最適化 vs コンピュート最適化）、GPU割り当て、さらにはコストと回復力のためにアベイラビリティゾーンやクラウドプロバイダー間での配置を集団的に決定できる可能性があります。
サービスメッシュとの統合: COLAをIstioのようなサービスメッシュと連携させることで、より豊富なテレメトリ（リクエストレベルのトレーシング、依存関係グラフ）が提供され、最適化の一部としてトラフィックルーティングやサーキットブレーカーを直接制御することも可能になります。
オンライン適応とメタ学習: 主要な研究フロンティアは、オフラインの制限を克服することです。メタ学習からの技術により、COLAはリアルタイムフィードバックに基づいてポリシーをオンラインで迅速に適応させたり、低トラフィック期間中に新しい構成を安全に探索したりできる可能性があります。
グリーンコンピューティング目標: 最適化目標を、Cloud Carbon Footprintプロジェクトなどのソースからのデータを組み込むことで、カーボンフットプリントやエネルギー消費の最小化に拡張し、持続可能なコンピューティングの取り組みと連携させることができます。
ポリシーのマーケットプレイス: 一般的なアプリケーションパターン（例：eコマース、メディアストリーミング）向けに、事前に最適化されたCOLAポリシーを共有または販売することで、個別のトレーニング実行の必要性を減らすことができます。

8. 参考文献

Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (オンライン適応に関連する高度なRLの例)。
Cloud Carbon Footprint. (n.d.). An open source tool to measure and visualize the carbon footprint of cloud usage. Retrieved from https://www.cloudcarbonfootprint.org/.
Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).