## Memo ### Summary on Tweet #SRE論文紹介 マイクロサービスにおけるオートスケールによるインスタンスの動的な増減に対して、メトリクスの値を集約して、サービス間の因果構造を学習すると、平均化されて情報損失してしまう。それを避けるために、SREゴールデンシグナル間の因果関係の仮定を導入した集約を行い、インスタンス固有の変動を捉える因果構造の検出手法を提案している。 [WWW'23]: "CausIL: Causal Graph for Instance Level Microservice Data" https://arxiv.org/abs/2303.00554 https://twitter.com/yuuk1t/status/1648925850065326080 ### 0. Metadata - Adobe Research Indiaとテキサス大学の著者らによる論文。 ### 1. Contributions 1. オートスケールによるインスタンスの動的な増減に対して、インスタンスレベルの集約による情報損失を避けるために、[[SREゴールデンシグナル]]に基づくメトリックセマンティクスに由来するドメイン知識を取り入れることで、各メトリクスのインスタンス固有の変動が他のメトリクスにどのように因果関係を持つかについて、よりきめ細かい情報を捉えた、サービスメトリクス間の因果構造を検出する手法CausILを提案。 2. 合成データセットによる評価の結果、因果グラフ推定精度を[[構造ハミング距離]]で測定すると、ベースラインに対するCausILの有効性が約25%向上した。さらに、実世界のデータセット（モノリスが9個のマイクロサービスを呼び出すスター型）で有効性を示した。 ### 2. Standpoints - オートスケールによるインスタンスの動的な増減について、Adobeでは、3ヶ月以内に1117のユニークなインスタンスが生成され、平均8インスタンスがアクティブであった。寿命の中央値はわずか350分であった。 - 既存の因果グラフ構築アルゴリズムは、メトリクスをノードとする因果構造を構築できるが、インスタンスレベルでの因果構造学習はできない。一方で、インスタンスレベルでメトリクスを集計すると、情報損失により、インスタンス固有のメトリクスのバリエーションが失われてしまう（図３）。しかし、各インスタンスは短命かつ総数は時間変化するためインスタンスレベルでのモデル化は困難であり、そのようなモデル化の試みは初である。 - 本研究では、図１のような因果構造を推定することを目標とする。 ![[Pasted image 20230420110650.png|400]] - 因果構造推定アルゴリズムのタスクは、式（１）について、各メトリック$x_{ijt}$の親$P(x_{ijt})$と、因果関数$f_{ij}(.)$を識別すること。 $𝑥_{𝑖𝑗𝑡} =𝑓_{𝑖𝑗}(P(𝑥_{𝑖𝑗𝑡}))+\epsilon_{𝑖𝑗𝑡}$ (1) - [[因果探索]]アルゴリズム - スコアベースの[[Greedy Equivalence Search|GES]]を高速で並列化した形式である[[fGES]]を用いる。スコアリング関数として、[[ベイズ情報量規準|BIC]]を用いる。 ### 3. Major Ideas - ゴールデンシグナルに基づくシステムアーキテクチャの因果知識の取り込み - ゴールデンシグナル：ワークロード(W)、CPU利用($U_c$)、メモリ使用($U_m$)、レイテンシ(L)、エラー(E)の５つ。（オリジナルの[[SREゴールデンシグナル]]のうち、Saturationに相当する具体的なメトリクスとしてCPU使用とメモリ使用として選んでいる。） - ![[Pasted image 20230420111234.png|400]] - ワークロードが入力となり、レイテンシとエラーが最終出力となる因果の仮定を置く。 - インスタンス間の情報集約法 Avg-fGES - ゴールデンシグナルのメトリクスに、因果的に影響を与える関連メトリクスをグループ化する。各サービスのメトリクスの数が時間変化するため、各時刻tにおいて、サービス$x_{ijt}\Delta j$のすべてのインスタンスのメトリクス値を平均化し、1つの集約メトリック$y_{it}$を形成する。$y_{it}\Delta i$に対して、fGESを実行する。 ![[Pasted image 20230420133056.png|250]] - なぜ集計により情報を損失するのか？ - 図３のように、全インスタンスのメトリック値を平均化すると、特定のインスタンスの影響が希薄となる - ![[Pasted image 20230420133358.png|400]] - メトリクスはそれ自体が非線形な依存性をもつため、図４(a)のように平均化すると変形してしまう。図4(b)のインスタンスレベルでみると、レイテンシはCPU使用率に対して非線形な依存性を示し、利用率の高い期間と低い期間で依存性が異なる。 - ![[Pasted image 20230420133617.png|400]] - 情報損失を考慮した最終的な提案法 CausIL - ロードバランサー配下の複数のインスタンスは同じ構成で、互いに独立して動作するため、利用率やレイテンシーといった上流と下流のメトリクスに対して[[条件付き独立性]]をもつため、モデル化する。 - ![[Pasted image 20230420134655.png|400]] - 図4(a)から、エラーとワークロードをマージする(b)。複数のインスタンスのレイテンシ（例）の親を呼出元のレイテンシへ接続する(c)。サービス間に集約ノードを構築し、潜在ノードとして機能する（d）。(c)の接続する親メトリックの選択には、同じインスタンスからの全メトリック、呼び出し側サービスの全インスタンスのワークロード、Sの呼び出し側サービスの全インスタンスのレイテンシとエラーが含まれる。 - ![[Pasted image 20230420135851.png|400]] - ドメイン知識による禁止されたエッジリストを作成する。 - サービス内のエッジ：(i)どのインスタンスの同じサービス内の他のメトリックもワークロードに影響を与えない、(ii) レイテンシはリソース利用率に影響を与えない - サービス間のエッジ：(i) 呼び出しグラフで接続されていない場合、サ ービス間のすべてのエッジを禁止する。(ii) 接続されているサービス間のエッジを禁止する。ただし、(a) 呼び出しグラフの方向にワークロード、(b)呼び出しグラフの反対方向にレイテンシとエラーを禁止する ### 4. Experimental design & Results - [[fges-py]]と[[tetrad]]を実装に使う。 - ベースライン - 全インスタンスに渡ってデ ータを平均化する[[FCI]] - Avg-fGES: 推定関数に最小二乗法、次数２、次数３をそれぞれ選択 - CausIL: 推定関数に最小二乗法、次数２、次数３ - データセット：合成と半合成データセット。 - 合成：10/20/40個サービス、各サービスは5つのメトリックノードをもち、因果グラフではそれぞれ合計50/100/200のノードをもつ。 - 半合成：実世界データセットをもとにランダムフォレスト回帰を学習し、ランダムエラーを追加する。 - 因果グラフの評価指標 - Adjacency Metrics (Adj)：エッジ方向を無視したときのエッジの正しさ - Arrow Head Metrics (AH)：真のグラフに対するエッジの因果方向の正しさ - Structural Hamming Distance (SHD)：真のグラフに対して加えるべき変更の数 - ドメイン知識からの禁止エッジリストにより、精度が大幅に向上し、計算量も改善された。 - ベースラインとの比較では、提案法の次数３の推定関数が最良の結果となってなり、平均で25%向上。 - リアルデータでの評価 - 1つのモノリスが9つのマイクロサービスを呼び出すスター型アーキテクチャで、5分間の粒度で2ヶ月間のデータを収集した。 - 表２では、次数２の提案法が最良で、Avg-fGESはエッジの方向が悪い。 - ![[Pasted image 20230420141954.png|400]] ### 5. Discussions & Limitations - スケーラビリティ：マイクロサービス数に対して線形の計算時間は平均時間は12-13sであり、標準偏差は1.09である。マイクロサービスごとに並列実行可能である。 - 実際のシステムの中には周期的な依存関係があるが、マイクロサービスは複数のリージョンにデプロイされたり、異なるコンポーネントが呼び出される。そのようなケースでは、提案法はサブサービスに分割して対処できる。 ### 6. Thoughts - 提案法は[[2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition|CIRCA]]のメタメトリクスに関する仮定とよく似ているが、出力側のメトリクスとしてエラーだけでなくレイテンシを置いているのがより現実的な仮定であるようにみえる。CIRCAのメタメトリクスの仮定は、出力がエラーのみだったが、実際にはレイテンシの増大やリソースのSaturationが必ずエラーを導くわけではないためである。 - 評価指標がAC@KやAVG@Kのような原因メトリクスの特定に対すするものではなく、因果グラフ自体を評価している。二ヶ月間という長期間のデータに対して因果グラフを生成し、グラフの精度を評価しているが、障害発生時の対応にはどの程度有用なのか不明である。 - ドメイン知識の有効性の評価について、真の因果グラフが事前の仮定（ゴールデンシグナルによるドメイン知識）にそもそも基づくため、仮定の妥当性を先に確認しないと意味のある評価とは言えないのではないか。 - 合成データとリアルデータで、推定関数の次数により差がでているが、これは実システムにあわせて次数を選択するチューニングが必要であることを示唆しているのではないか。 ## Abstract クラウドベースのサービスでは、その規模の大きさからAIを活用したモニタリングが重要となっています。AIベースのモニタリングの一般的なアプローチは、サービスコンポーネント間の因果関係を検出し、因果関係グラフを構築することです。ドメイン情報を利用できるクラウドシステムは、このような因果関係の検出アプローチにさらに適しています。しかし、最近のクラウドシステムでは、オートスケーラーがマイクロサービスのインスタンス数を動的に変更し、ロードバランサーが各インスタンスへの負荷を管理する。このため、既成の因果構造検出技術では、システムアーキテクチャのドメイン情報を取り込むことができず、また、様々な数のサービスインスタンスにまたがる分散コンピューティングをモデル化する方法も提供されていないため、難題となっている。そこで、動的インスタンスに分散した計算を考慮し、システムアーキテクチャから得られるドメイン知識を取り入れることで、サービスメトリクス間の因果構造を検出するCausILを開発する。CausILは、クラウドシステムへの応用に向け、性能指標のインスタンス固有の変動を用いて因果関係グラフを推定し、サービスの複数のインスタンスを、システムの仮定を条件として独立したものとしてモデリングする。シミュレーションでは、CausILがベースラインよりも有効であることを示し、グラフ推定精度を約25%向上させた（Structural Hamming Distanceで測定）一方、実世界データセットでは、CausILが展開環境において適用できることを示した。 ## 1. Introduction