AI-RANを実現するAITRASオーケストレーターの仕組み: Dynamic Scoring Frameworkを用いたリソース最適化

1. AI-RANオーケストレーターに求められる機能

AI-RANでは、RANやAIワークロードを実行する計算リソースをエッジ拠点やデータセンターに配置し、それぞれをクラスターとして構成し、全国のクラスターを束ねたマルチクラスター環境を扱います。

このとき、AI-RANオーケストレーターは次の役割を担います。

・AIやRANドメインのオーケストレーター（DSO, Domain Specific Orchestrator）に対して利用可能なリソースの配分を行う。（各ドメインに特化したオーケストレーターが最大限能力を発揮できるように全体からリソース配分）[2][3]

・ワークロードをAI-RANオーケストレーター自身が受け付け、適切なリソースを割り当て実行する。

以下の図1はこれらを実現するオーケストレーターの参照システムアーキテクチャーを表しています[4]。

図1. AI-RANオーケストレーターの参照システムアーキテクチャー

システムアーキテクチャーは以下の機能ブロックから構成されます。

1. Multi-Cluster Management: ワークロードを実行するクラスターの登録や更新など、管理したいクラスターのライフサイクルマネジメント。
2. Metrics Collection: 管理対象クラスター群の横断的なリソース状況収集。
3. Dynamic Scoring: 収集したリソース状況をもとに分析・評価する機能。
4. Multi-Cluster Scheduling: 評価結果に基づき、最適なリソース割り当て計画を策定する機能。
5. Resource Arrangement: 割当計画に基づくクラスター設定変更とアプリケーションのライフサイクルマネジメント。

先端技術研究所が現在開発しているAITRASオーケストレーターでは、これらの機能ブロックにRed Hat OpenShift上の各種コンポーネントを活用しつつ、必要な部分は個別に開発を進めています。
例えば、Multi-Cluster ManagementやMetrics CollectionにはRed Hat Advanced Cluster Management for Kubernetesを活用しています。
Red Hat Advanced Cluster Management for Kubernetesはマルチクラスター環境におけるリソース管理を効率化するためのツールです。この中にはOSSであるOpen Cluster Management (OCM)の機能が含まれており、これを利用することでマルチクラスター環境の管理が容易になります。

2. AI-RANオーケストレーターにおける課題

OCMを活用することでマルチクラスター管理の基盤は整いますが、AI-RANオーケストレーターの実現には、Dynamic Scoring、Multi-Cluster Scheduling、Resource Arrangementのスムーズな連携が必要です。
例えば複数のAIモデルをAI-RANインフラにデプロイする場合のオーケストレーションを考えると、

・マルチクラスター環境の状況に応じて異なる観点で最適化されたリソース計画を行いたい。つまり、
- リソースが十分に存在する場合、性能を最大限に出せるようにデプロイしたい。
- 逆に電力が逼迫している場合、リソースの使用を制限しつつも必要な処理を行いたい。

・リソース計画には各クラスターの動的なリソース状況を柔軟に反映する必要がある。つまり、
- 現在のリソース状況だけでなく、将来のリソース状況予測を用いたい。
- 必要な評価は最適化ロジックに依存するため、多様な評価ロジックを用意・実施したい。
- 評価には各クラスターから収集されたメトリクスを用いつつ、評価結果は中央に集約して全体最適な意思決定を行いたい。

・策定したリソース計画を実現する際には、手順の順序性も考慮する必要がある。つまり、
- アプリケーションのデプロイにインフラの設定変更が伴う場合、インフラ設定変更が行われて正常に動作しているノードにアプリデプロイを行うなど、望ましい状態への遷移の仕方も考慮する必要がある。

といった様々な要件が挙げられます。
これに対して、私たちはOCMへの追加機能(Addon)としてDynamic Scoring Frameworkを実装しました。本フレームワークに自社開発の評価ロジックや最適化ロジックによるMulti-Cluster Schedulingや、他のOCMコンポーネントと連携したResource Arrangementの実現が可能になる仕組みを作り、コミュニティへの貢献として公開しました[5]。 このDynamic Scoring Frameworkにより、マルチクラスター環境におけるリソース最適化がより簡単に実現され、AIワークロードとRANワークロードの効率的なリソース配分が可能になります。

3. Dynamic Scoring Frameworkの仕組み

Dynamic Scoring Frameworkは、マルチクラスターにおけるリソース評価を効率的に行うための仕組みです。
この仕組みを設計・実装にあたって、主に以下のコンセプトを重視しました。

・評価ロジック開発者がロジック開発そのものに注力するためのモジュール分離構造
- 評価ロジックの共通インターフェース定義とモジュール分離。
- 「どう評価ロジックを使ってほしいか」設定を宣言するインターフェース定義。
- アプリ性能/電力/リソース使用率などの多様な評価管理に向けて汎化されたインターフェース定義。

・評価実行を行うエージェントの配布とリソース最適化のための中央集約
- 各クラスターに配置されるエージェントによる、クラスター内のリソース状況を用いた評価ロジック実行。
- ハブクラスターで利用しやすい形での評価結果の集約。

・評価ロジック自体のリソース消費がワークロードの妨げにならないための設計
- モジュール分離による評価実行リソースの柔軟性確保。
- 評価実行時のレイテンシを集約し、評価ロジック自体のパフォーマンスをモニタリングする仕組み。

これらを踏まえて実装したDynamic Scoring Frameworkの大きな流れを以下図2に示します。分散的に設定をマネージドクラスターに配布することでマネージドクラスター自身のメトリクスを用いて評価ロジックを実行し、その結果であるスコアをハブクラスターに集約し、リソース割り当てに活用することができます。

図2. Dynamic Scoring Frameworkの動作イメージ

以降では、具体的なDynamic Scoring Frameworkの中身について説明します。

3.1. Dynamic Scoring Frameworkの全体アーキテクチャー

Dynamic Scoring Frameworkの全体アーキテクチャーは以下の図3で表されます。

図3. Dynamic Scoring Frameworkの全体アーキテクチャー

キーとなるコンポーネントは、

・Scoring API
・DynamicScorer
・DynamicScoringConfig
・DynamicScoringAgent

の4つです。詳細はGitHubのリポジトリに記載されていますが、ここでは各コンポーネントの役割について簡単に説明します。

3.2. Scoring API

Scoring APIは、任意の評価を行うロジックの実体であり、これをWeb APIとして提供するコンポーネントです。

クラスターの状態を動的に評価することはオーケストレーションにおいてなくてはならない処理であり、例えばクラスター全体の消費電力から推測される予測結果を評価としたり、アクセラレーターの消費電力とアプリケーションのスループットからリソースに対する費用対効果を評価するなど、評価があって初めて最適化を試みることができます。

このような「メトリクスを受け取って良し悪しを計算する評価機構」のインターフェースを汎化して定義したものが、Dynamic Scoring FrameworkにおけるScoring APIです。
Scoring APIは、メトリクスの時系列を入力として受け取り、スコアリング結果を出力する評価モジュールのインターフェースを定義します。これにより、評価機構をモジュール分離して扱うことが出来ます。

モジュール分離されたScoring APIを有効に利用するためには、

・入力される時系列の前提情報
- データソース（消費電力やリソース使用率、スループットなどメトリクスの種類）
- どの程度の粒度の時系列を入力するか

・評価インターバル：評価を実行する時間的な間隔

・出力するべきスコア情報のスキーマ

といった情報を正しく把握している必要があります。
Dynamic Scoring Frameworkでは、これらの「このScoring APIがどのように実行されるべきか」をScoring API自身のコンフィグエンドポイント内で宣言します。具体的には、Scoring APIの開発者は、「実装したロジックをどのように呼び出してほしいか」をコンフィグエンドポイント内で表現することができます。
これにより、Scoring APIを呼び出す際には、評価ロジックの開発者が意図する情報に基づいて適切な入力を行うことができます。

実際に先端技術研究所が開発したScoring APIでは、将来の消費電力予測を元にしたアプリケーションデプロイの事前評価をすることができます。

図4. 消費電力予測を元にしたアプリデプロイの事前評価

クラスター内の消費電力を予測しつつ、アプリケーションデプロイ時の実績値から将来一定値を超えてしまわないかをGPU設定毎に評価することで、所望のアプリケーションをどのGPU設定でデプロイするのが良いかを判断することができます。

また、Scoring APIは汎化されたインターフェースとして定義されているため、例えばアプリ実行時のリソースとパフォーマンスに対する費用対効果を評価するような、複数メトリクスから複合的に評価を行うScoring APIもDynamic Scoring Frameworkの中で扱うことができます。

図5. 複数メトリクスを元にした推論パフォーマンス評価

3.3. DynamicScorer

開発したScoring APIをDynamic Scoring Frameworkに登録するためのKubernetesリソースがDynamicScorerです。
このカスタムリソースは、評価ロジックの実行に必要な情報を登録するために用いられます。 DynamicScorerにScoring APIのコンフィグエンドポイントを登録すると、自動的にコンフィグエンドポイント内で宣言された設定情報がカスタムリソースの状態として取り込まれます。

もちろん、ユースケースによってはインフラ運用者側で評価周期などの設定を改めて定めたい場合も存在するため、

・完全にコンフィグエンドポイントからの情報に基づいて評価を実行
・インフラ運用者側で上書きした情報に基づいて評価を実行

といった、用途に応じてハイブリッドな設定取り込みができるようになっています。

3.4. DynamicScoringConfig

DynamicScoringConfigは、登録されたDynamicScorerの情報を各マネージドクラスターに配布する設定を行うためのKubernetesリソースです。
例えば、DynamicScorerとしてGPUの評価ロジックを登録する場合、GPUを持たないクラスターに対して評価を行う必要はありません。
このような配布に対するマスクなどの全体設定をDynamicScoringConfigで行います。

DynamicScoringConfigが作成されると、全体設定とDynamicScorerの情報に応じて必要な情報が各マネージドクラスターごとに集約され、ConfigMapとして各クラスターに配布されます。

3.5. DynamicScoringAgent

DynamicScoringAgentは各クラスターに自動配置されるエージェントであり、クラスター内のメトリクスを用いて評価ロジックに基づいたスコアリングを実行します。
DynamicScoringAgentは、マネージドクラスターに配布されたConfigMapをもとに自身が実行するべき評価ロジックを決定し、周期的にScoring APIをトリガーします。
トリガーする際に、評価ロジックの入力となるメトリクスを自身のメトリクス収集機構（e.g. Prometheus）から取得して実行します。

Scoring APIを通して得られたスコアは、

・Agent自身のメトリクスエンドポイントを通じてクラスター内のPrometheusに格納し、Multi-Cluster Observabilityなど外部機構を経由してハブクラスターに集約。
・Agentから直接ハブクラスター上のAddOnPlacementScoreリソースに送信。

といった方法でハブクラスターに集約することができます。

AddOnPlacementScoreはOCMで定義される、クラスターの状態評価結果を保持するカスタムリソースであり、アプリケーションデプロイなどに活用することが出来ます。

このようにハブクラスターに集約されたスコアは、全体最適なリソース割り当てを実現するために活用されます。

また、Agent自身のメトリクスエンドポイントは、各Scoring APIをコールしたときのレイテンシやエラー回数などを記録しているため、必要に応じてScoring APIのパフォーマンスをモニタリングすることができます。Scoring APIはモジュール分離された構造を前提にしているため、必要に応じてデプロイ先の変更やスケーリングを実施することで、評価が円滑に行われるように調整することが可能です。

4. Dynamic Scoring Frameworkを利用したマルチクラスター環境におけるリソース最適化

ここでは、Dynamic Scoring Frameworkを利用して、マルチクラスターにおけるリソース最適化を動的に実現する構成例を説明します。

今回の例では、マネージドクラスターにいくつかGPUが存在している状態で、MIGの設定変更を行いながらアプリケーションのデプロイを最適化します。

図6. 指標に応じたアプリデプロイのシナリオ

この例で用いられるワークロードはLLMの推論エンドポイントを提供しますが、実行には2つのGPUを必要としています。このとき2つ以上のMIGインスタンスを持つクラスターであればアプリケーションのデプロイが可能ですが、スループットや消費電力の観点で、適したMIGのプロファイルは異なります。
このような場面において、MIG分割を動的に変更しながらアプリケーションをデプロイすることを考えます。

このようなシチュエーションに対して最適化を行う全体のアーキテクチャーを以下のように構成しました。

図7. 最適化を実現するアーキテクチャー全体の構成

このような構成を用いることで、注目する指標で最適化計算を行い、MIGの設定を変更しながらアプリケーションをデプロイすることができます。

以降では、各コンポーネントの動きを説明します。

4.1. Optimization Moduleの動き

まず、ここで出てくるカスタムリソースは以下のとおりです。

・Policy: ノードなどクラスター内の各リソースがあるべき姿を設定するカスタムリソース。
・Placement: 対象としたいクラスターの条件付けを行うカスタムリソース。
・PlacementDecision: Placementによって定められた具体的なマネージドクラスター群。
・PlacementBinding: PolicyとPlacementを紐づけ、「あるクラスタはこのポリシーに従うべき」というルールを与えるカスタムリソース。
・ManifestWorkReplicaSet: 内部にアプリケーションをデプロイするためのマニフェスト群（e.g. DeploymentやService）と、Placementを紐づけるカスタムリソース。

これらはOCMのカスタムリソースを利用しています。

この構成では、Dynamic Scoring FrameworkをベースにAddOnPlacementScoreを用いて各クラスターの評価を行いつつ、Web APIを通じて指定したスコアに対して全体最適な

・MIG設定をコントロールするPolicyに対するPlacement & PlacementBinding
・アプリケーションのマニフェスト（ManifestWorkReplicaSet）に対するPlacement

を生成します。これにより、各クラスターに対してMIGの設定変更を行いつつアプリケーションを最適にデプロイすることができます。

図8. 最適化に基づくPlacementの生成

なお、今回は最適化のトリガーとなるAPIをMCPサーバーとして利用可能な形式で実装しているため、最適化をAIエージェントから実行することが可能です。

これにより、

・MLベースの予測に基づくScoring APIや、Optimization Moduleによる最適性の保証など、個々の性能に特化したロジックを活用
・Score全体から重視すべき指標を運用者の意図に基づいて解釈し、最適化をトリガーするAIエージェント

という、AIエージェントとオーケストレーターが連携することで自律的にマルチクラスターを最適運用する構成を実現できます。

図9. シチュエーションに応じた最適化デモのスクリーンショット

4.2. OCM Policy Frameworkによるクラスターの設定変更

この構成ではOCM Policy Framework[6]を利用することで、各クラスターのMIG設定を動的に変更しています。

Policy FrameworkはOCMの仕組みで、Kubernetesリソースが望ましい状態（Policy）を定義し、クラスターに紐づける（PlacementBinding）ことでクラスター内のリソースを所望の状態に設定（もしくは通知）する機能を提供します。

今回の例では、GPUオペレーターに設定変更を要求するためのノードラベリングをenforceしつつ、設定変更が途中である状態を違反としてinformするようなポリシーを定義することで、設定変更が正しく行われている場合にcompliantになるようなPolicyを作成しています。

これをPlacementBindingを適用してクラスターに紐づけることにより、MIGの設定変更を実現しています。

図10. Policyを利用したNodeの設定変更

具体的なPolicyのyamlを例にあげると、以下のようなポリシーを適用することで、クラスター内のexample-target-label=valueとして設定されたノードのMIG設定変更をトリガーし、設定変更後にcompliantになるようなPolicyを利用することができます。

4.3. PolicyWatcherによるClusterClaimの更新

PolicyWatcherは、各クラスター内で自身のPolicyリソースを監視し、リソースの状態を把握してClusterClaimを更新する役割を担います。

単にPolicyの正常性に応じたClusterClaimの更新をするだけであれば、Policy Frameworkを活用することで実現が可能ですが、今回はPolicyがcompliantになってから一定時間経過して安定な状態になってからアプリケーションをデプロイしたいケースを考え、簡易的なPodを立てることで実現しています。

図11. PolicyWatcherの動作イメージ

ワークロードデプロイのためのPlacementはpolicy-compliantなClusterClaimを選択するように生成されるので、Policyが適用された状態のクラスターに対してアプリケーションをデプロイすることができます。

図12. Policy適用後のクラスターへのアプリケーションデプロイ

4.4. Scoring API自体のリソース最適化

更に発展した例として、Scoring API自身のリソース最適化があります。例えばScoring APIをAITRASオーケストレーター管理下のマルチクラスター環境にデプロイする場合、インフラをワークロード実行に対して最大限使いたいため、評価ロジックは空きリソースで実行されることが望まれます。

このようなシチュエーションにおいても、Dynamic Scoring Frameworkは有効です。

例えば各クラスターに対して「空きリソース量に応じたスコア」を計算するような評価ロジックをScoring APIとして実装し、これをDynamic Scoring Frameworkに登録することで、AddOnPlacementScoreが自動的に更新されるようにします。

この状態で、Scoring API用の

・Scoring APIをクラスター内にデプロイするためのManifestWorkReplicaSet
・空きリソース量に応じたスコア（AddOnPlacementScore）を参照するPlacement

を作成すると、

・Dynamic Scoring Frameworkに登録された評価ロジックが空きリソース量に応じたスコアを計算し、AddOnPlacementScoreを自動的に更新。
・AddOnPlacementScoreを参照するPlacementが、空きリソース量に基づいてクラスターの向き先（PlacementDecision）を変更。
・評価ロジックが空きリソースで実行されるように、ManifestWorkReplicaSetによりScoring APIがデプロイ。

といった流れで、Dynamic Scoring FrameworkはScoring API自身のリソースを調整することができます。

図13. AddOnPlacementScoreを利用したScoring APIの動的再配置

5. Dynamic Scoring Frameworkが導くAIおよびRANワークロードの最適配置

本記事では、AI-RAN時代に求められるマルチクラスター環境のリソース最適化を実現するためのAITRASオーケストレーターと、その中核となるDynamic Scoring Frameworkの仕組みについて解説しました。

Dynamic Scoring Frameworkは、各クラスターのリソース状況や多様な評価ロジックを柔軟に取り込むことで、AIワークロードとRANワークロードの最適な配置・実行を可能にします。評価ロジックのモジュール化や、クラスター自身による分散的なスコアリング、そして中央集約による全体最適化といった特徴により、運用者やAIエージェントの意図を反映した高度なリソース管理が実現できます。

本内容はRed Hat社の技術ブログでも紹介されています。併せてこちらもご覧ください。

参考

1. SoftBank Corp. and Ericsson achieve interworking between AITRAS Orchestrator and Ericsson Intelligent Automation Platform
2. AI-RANにおける社外AIワークロード統合〜AITRASオーケストレーターによる動的リソース制御の実装〜
3. AI-RAN Alliance Platform and Infrastructure Orchestrator White Paper
4. Dynamic Scoring Framework (GitHub)
5. OCM Policy framework