> [!abstract] > マイクロサービスアーキテクチャ内の複雑な相互作用は、個々のサービスが高レベル要件に与える影響を不透明にする。これはマルチテナント・マルチベンダーのシナリオ(エッジコンピューティングなど)においてさらに深刻となり、異なるステークホルダーが相反するSLO(たとえばエネルギー消費の最小化と応答時間の最小化の同時要求)を指定する可能性がある。SLO内の矛盾を回避し、SLOを充足する条件を明らかにするため、本論文は高レベルSLOを複数の低レベルSLOおよびパラメータ割り当てに拡散する方法論を提示する。これにより、個々のサブプロセスが高レベルSLOにどのように貢献するか、またそれらをどのように設定すれば充足が促進されるかが明確になる。本方法論を複数のマイクロサービスパイプラインに対して評価した。課題は、影響を与えるすべての要因を見つけ出し制約することで、複数の高レベルSLO(顧客満足度など)を確保することにある。結果として、複数レイヤーの低レベル制約を推論することで、高レベルSLOを最大100%まで充足できることが示された。注目すべきは、低レベルSLOの制約度合いとコンフリクト発生がSLO充足に重大な影響を及ぼすことが抽出できた点である。 ## 論文情報 - **タイトル**: Diffusing High-level SLO in Microservice Pipelines - **著者**: Boris Sedlak, Víctor Casamayor Pujol, Praveen Kumar Donta, Schahram Dustdar - **所属**: Distributed Systems Group, Vienna University of Technology (TU Wien), Vienna, Austria - **メールアドレス**: {b.sedlak, v.casamayor, pdonta, dustdar}@dsg.tuwien.ac.at - **掲載媒体**: 2024 IEEE International Conference on Service-Oriented System Engineering (SOSE) - **発行年**: 2024 - **DOI**: 10.1109/SOSE62363.2024.00008 - **ページ**: 11–19(9ページ) ## 概要 マイクロサービスパイプラインにおいて、ステークホルダーが指定した高レベルSLOをベイズネットワーク(BN: Bayesian Network)の条件付き依存関係を利用して低レベルSLOとパラメータ割り当てに自動拡散する3ステップ方法論を提案する。エッジコンピューティング等のマルチテナント・マルチベンダー環境で生じる競合SLOを事前に検知・解決し、SLO充足を最大100%まで高められることを実験で示した。BNの品質がボトルネックとなりうるという制約も明確にしている。 ## 問題設定 - **入力**: マイクロサービスアプリケーションの実行時メトリクス(多次元時系列)と、ステークホルダーが指定した高レベルSLO群 - **出力**: 低レベルSLO群と各パラメータの割り当て値、および解決不能なコンフリクト一覧 - **前提条件**: - マイクロサービスは有向非循環グラフ(DAG)状のパイプラインを形成している - 各サービスの変数状態は離散値(もしくは離散ビン化した連続値)として表現可能 - BN学習のための十分なトレーニングデータが収集可能 - 個々のサービスのデプロイ先ホストは事前に決定済み(本論文ではデプロイ最適化を対象外とする) ## 提案手法 本論文の核心は、**高レベルSLOを低レベルSLOへ拡散する3ステップ方法論**である(図2参照)。 ### ステップ1: ベイズネットワーク学習(BNL) - 各マイクロサービスの実行時メトリクス(Ms)を収集し、結合データセット(D)を構築する - BNL(ベイズネットワーク学習)アルゴリズムで D からグラフ G を学習する - G はサービス変数間の条件付き依存関係と確率分布を表現する - BNL アルゴリズムには先行研究 [14] で提案した BNL を採用し、実装には pgmpy を利用する ### ステップ2: 高レベルSLOの拡散(HLD: High-level SLO Diffusion) - 高レベルSLO変数はグラフ G 上の葉ノード(受信辺のみを持つノード)に対応し、パラメータはルートノード(受信辺を持たないノード)に対応する - 拡散アルゴリズム(Algo. 2)は高レベルSLO変数から G を遡り、祖先ノードを順に訪問する - 各親ノード p に対して、変数消去法(VE: Variable Elimination)により、高レベルSLOを充足する確率が閾値 t 以上となる低レベル状態群を推定する - 閾値 t は超パラメータ λ ∈ (0, 1] によって制御される。λ が大きいほど許容範囲が狭まり(より厳しい制約)、小さいほど広がる(より緩い制約) ### ステップ3: コンフリクト管理(CIR: Conflict Identification and Resolution) - ステップ2で得られた制約リスト L には、複数の高レベルSLOから同一変数への重複制約が含まれる場合がある - **マイナーコンフリクト**: 重複制約の積集合が空でない場合。交差区間 k を採用して自動解決する - **メジャーコンフリクト**: 重複制約が互いに素で積集合が空の場合。解決不能として開発者に通知する - 最終出力は一意制約リスト U(A∪B)とメジャーコンフリクト一覧 C である ## 新規性 先行研究との比較を下記に示す。 | 観点 | 先行研究 | 本論文 | |------|----------|--------| | SLO記述の複雑さ | Pusztai ら [9,16,17] の多変数閾値SLO、Seo ら [19] のMLタスク分解 | 高レベルSLOから低レベルSLOへの**自動拡散**を実装 | | BN活用 | Yazdi ら [11]・Chen ら [4]・Wang ら [24] はBNをシステムモデリング・障害推定に活用 | BNの**条件付き依存関係**を利用して目標状態を低レベル要件として逆推論 | | クラウド→エッジのSLO変換 | DeepSLOs [22] やCao [20] はビジョンとして提示するにとどまる | エッジコンピューティング環境を想定した実装と評価を提供 | | コンフリクト検知 | 既存研究にはSLO間コンフリクトの事前検知機構が不在 | 低レベルSLO推論後に**実行前コンフリクト検知**を実現 | ## 実験設定 - **評価シナリオ**: 3種類のコンシューマアプリケーション(VehicleRouting、TrafficPrediction、LiveMonitoring)を対象とし、それぞれ異なるマイクロサービスパイプラインを構成する - **マイクロサービス**: 12サービス(Table II参照)。プロデューサ(TrafficSensors、HistoricDB、CameraWrapper、WeatherSensors)、ワーカー(AnomalyDetection、HistoricProvision、StreetAnalysis、PrivacyTransform、IsentropicPrint)、コンシューマ(TrafficPrediction、VehicleRouting、LiveMonitoring) - **ホスト**: NVIDIA Jetson Xavier・Nano・Orin、フォグノード、クラウドサーバの異種ハードウェア環境 - **データ分割**: メトリクスの80%をBNL学習に、残り20%をSLO充足率の評価に使用 - **超パラメータ**: λ ∈ {0.1, 0.2, ..., 1.0} を走査してSLO充足率への影響を分析 - **評価指標**: 高レベルSLO充足率(%)および低レベルSLO充足率(%) ## 実験結果 ### SLO拡散(RQ-1): SLO充足率 Table IV より、各アプリケーションで拡散したパラメータ割り当てを適用したときの高レベルSLO充足率は以下のとおりである。 | アプリ | 高レベルSLO | 達成率 | |--------|------------|-------| | VehicleRouting | cumm_delay ≤ 45 ms | 94 % | | VehicleRouting | min(energy) | 99 % | | TrafficPrediction | cumm_delay ≤ 40 ms | 83 % | | LiveMonitoring | cumm_delay ≤ 110 ms | 93 % | | LiveMonitoring | max(viewer_sat.) | 100 % | 全体として83〜100%の充足率を達成した。最低値はTrafficPredictionのcumm_delay SLOで83%であった。 ### 許容範囲(RQ-2): λ の影響 - 低レベルSLO充足率は常に高レベルSLO充足率より高く、高レベル充足は低レベル充足の帰結であることが確認された - λ を0.1から0.7へ増加させると高レベルSLO充足率が向上する傾向がある - λ が過度に大きくなると(許容範囲が狭くなりすぎると)LiveMonitoringでコンフリクトが発生し充足率が0に急落する - アプリケーションごとに最適なλが異なるため、コンフリクトを回避しながらλを動的に最大化する仕組みが必要である ### コンフリクトと解決(RQ-3): コンフリクト発生パターン Table V より、LiveMonitoringで高レベルSLOの組み合わせと閾値を変化させたときのコンフリクト発生状況は以下のとおりである。 - cumm_delay ≤ 120 msでは単一SLOとの組み合わせでコンフリクトなし。両SLO同時指定でfpsにコンフリクト発生 - cumm_delayの閾値を厳しくするにつれてコンフリクト変数数が増加 - cumm_delay ≤ 25 msかつmin(energy)では3変数にコンフリクトが伝播 - コンフリクトは実行前に特定可能であり、どの高レベルSLOの組み合わせが実行可能かを事前に把握できる ## 考察 - BNの品質が方法論全体のボトルネックとなる。エッジの方向が正しくない場合、拡散結果も誤った方向へ逸脱する。本評価では専門知識に基づいてエッジの向きを固定し、安定した評価環境を確保した - アルゴリズム複雑度はO((h × l × |Q|)^m)であり(h: 高レベルSLO変数の状態数、l: 祖先変数の状態数、m: 祖先の深さ)、状態数の少ない離散変数または低ビン数の連続変数に対して適切に動作する - メジャーコンフリクトの解決には高レベルSLO間の優先順位付けが必要であり、これは今後の課題として残されている - 単一親のサブツリーを「折り畳む」最適化によってSLO一覧を簡素化できる可能性があるが、本評価では該当するケースが出現しなかった ## 強み / 弱点・課題 ### 強み - 高レベルSLOから低レベルSLOへの**自動拡散**という新しいアプローチを実装・評価した初の研究 - ベイズネットワークの確率的推論を活用することで、単純な閾値分解ではなく確率分布を考慮した制約推定が可能 - 実行前にコンフリクトを検知できるため、ランタイム障害の予防に貢献する - プロデューサ・ワーカー・コンシューマの3層構造を持つ現実的なマイクロサービスパイプラインで評価しており、エッジコンピューティング環境への適用可能性を示した ### 弱点・課題 - BN学習の品質依存性が高く、エッジ方向の誤りが拡散結果の信頼性を大きく損なう。BNL手法の選択とその影響の調査が必要 - パラメータの全排列をトレーニングデータとして収集することを前提としており、大規模システムへのスケーラビリティに課題がある(補間による回避策[32]を示唆するのみ) - メジャーコンフリクトの自律解決には高レベルSLO間の優先順位付けが必要だが、本論文では未実装 - アルゴリズム複雑度が変数の状態数と祖先の深さに対して指数的に増大するため、深いパイプラインや状態数の多い連続変数への適用が困難 - 最適なλをアプリケーションごとに動的に決定する機構が未実装