> [!abstract] 概要(arXiv abstract の日本語訳) > agent ベースの推論フレームワークと統合された大規模言語モデル(LLM)は、近年、自律的な意思決定とシステムレベルの操作で強い潜在能力を示している。有望でありながら未開拓な方向の一つが microservice remediation であり、その目標は故障した microservice システムを自動的に回復させることだ。しかし既存手法は依然として Site Reliability Engineer(SRE)が手作りしたプロンプトに依存し、LLM はテキスト指示を実行可能なコードに変換するだけにとどまる。この領域の研究を進めるため、本論文では MicroRemed を導入する。これは end-to-end microservice remediation において LLM を評価する初のベンチマークであり、モデルは診断レポートから実行可能な Ansible playbook を直接生成してシステム機能を回復させなければならない。さらに、SRE の反省的・知覚的推論を模す multi-agent フレームワーク ThinkRemed を提案する。実験結果は、MicroRemed が現行 LLM に substantial な課題を突きつける一方、ThinkRemed が反復推論と system reflection を通じて end-to-end 緩和性能を改善することを示す。 ## 論文情報 - タイトル: MicroRemed: Benchmarking LLMs in Microservices Remediation - 著者: Lingzhe Zhang¹†, Yunpeng Zhai²†, Tong Jia¹*, Chiming Duan¹, Minghua He¹², Leyi Pan³, Zhaoyang Liu², Bolin Ding², Ying Li¹*(† equal contribution、* corresponding author) - 所属: ¹Peking University、²Alibaba Group、³Tsinghua University - 媒体: arXiv preprint(arXiv:2511.01166v1 [cs.CL]、2025-11-03) - コード: https://github.com/LLM4AIOps/MicroRemed ## 概要 故障した microservice システムを、診断レポートから実行可能な Ansible playbook を生成して自律回復させる **End-to-End Microservice Remediation(E2E-MR)** タスクを定義し、それを評価する live なベンチマーク MicroRemed を構築する。あわせて、SRE 的な反復推論を模す multi-agent フレームワーク ThinkRemed と、one-shot 生成の baseline SoloGen の 2 つの reference methodology を提供し、9 つの代表的 LLM を評価する。 ## 問題設定 - **タスク(E2E-MR)**: 故障 microservice $S_{target}$、failure type $T_{fail}$、auxiliary context $C_{aux}$ を入力に、回復確率を最大化する最適 playbook $p^*$ を生成する($f_\theta: (S_{target}, T_{fail}, C_{aux}) \to p^*$、Equation 1)。出力は実行可能 Ansible playbook、成否はシステムが $S_{fail}$ から $S_{normal}$ へ回復したかで判定。 - **従来との差**: 既存手法(Wisdom-Ansible・MAPE-Ansible 等)は SRE の手作りプロンプトに依存し、LLM は自然言語指示をコードに変換するだけ。runtime からの反復フィードバックを欠き、failure diagnosis から system recovery までの end-to-end 自動化を実現できない。MicroRemed はこのギャップを埋める(Figure 1)。 - ソフトウェア保守は anomaly detection → failure diagnosis → software remediation の 3 段階に分かれ、本論文は最終段の remediation に焦点を置く(§2.1、Appendix B)。 ## 提案手法 ### MicroRemed ベンチマーク(Figure 2) 実 microservice を起動し、Failure Injection で制御された fault を注入、Failure Report と Auxiliary Context を Candidate Remediation LLM に渡して Ansible playbook を生成させ、Execution Engine が実行、Status Verification が回復を検査、Evaluation and Recovery が元状態へ復元する閉ループ。 - **Failure Injection**: 2 系統。resource/runtime 系(CPU/memory/network 等)は [[ChaosMesh]] による **chaos injection**、設定系(環境変数誤り・依存設定ミス)は設定ファイルを直接書き換える **configuration injection**。 - **Status Verification**: 一般の anomaly detection と目的は似るが機構が異なり、注入した特定 fault が完全に解消したかだけを**標的検査**する(CPU-stress を注入したら service A の CPU メトリクスのみ検査)。これにより検証精度 100% を担保すると主張(§3.2)。 - **設計原則**(§3.1): Dynamic Execution Benchmark(静的データセットでなく live な実行環境)/ Execution-based Evaluation(出力の言語的・構造的類似でなく実行結果で採点)/ Comprehensive Scalability(method/LLM/failure/system-scalable)。 ### 評価指標(§3.3) - **Remediation Accuracy(RA)**: 修復に成功した割合。 - **Average Remediation Latency(ARL)**: 1 緩和サイクルの推論+実行の時間効率。 - **Average Token Consumption(ATC)**: 緩和 1 回あたりの input+output トークン総量(コスト効率)。 ### SoloGen(§4.1) 全 context を 1 プロンプトに入れ、中間推論や反復精緻化なしに最終 Ansible playbook を一発生成する pure one-shot baseline。 ### ThinkRemed(§4.2、Figure 3) SRE の緩和過程を模す multi-agent フレームワーク。4 つの協調エージェントが reasoning–action–reflection ループで動く: - **Coordinator**: auxiliary context $C_0$ と failure report $R_0$ を受け、Probe Agent を呼ぶか適応的に判断し、候補 playbook $p_t$ を合成。 - **Probe Agent**: 稼働中システムから動的に追加の runtime 情報を収集(kubectl 等)。 - **Execution Agent**: 生成 playbook を実行して故障 microservice を緩和。 - **Verification Agent**: 結果を評価し binary $v_t \in \{0,1\}$ を出す。失敗なら reflection phase に入り Coordinator へ制御が戻り反復精緻化。反復は最大 trial budget $T_{max}$ で打ち切る(Equation 2)。 - Coordinator は経験豊富な SRE として振る舞う Role Definition Prompt で初期化され、失敗時は Regeneration Prompt で前回失敗の原因を推論し再生成する(Appendix D、Figure 8/9)。プロンプトはオンライン service を中断させないこと、restart を主戦略にしないことを指示する。 ## 新規性 - microservice remediation を**初めて end-to-end の生成タスク**として定式化し、人手プロンプト依存(KubePlaybook・Andromeda・Wisdom-Ansible・MAPE-Ansible)から脱却。LLM が診断洞察を直接 repair action に翻訳する閉ループを評価する(§2.2)。 - 関連の SWE-Bench は GitHub issue のバグ修正が対象で runtime 緩和でない。AIOpsLab は autonomous AIOps agent の枠組みを提供するが緩和有効性の再現可能な標準評価機構を欠く、と位置づける(§2.2)。 ## 実験設定 - **Backbone(9 モデル)**: closed-source = Qwen3-Plus / Qwen3-Max / Qwen3-Flash。open-source = QwQ-32B / Qwen3-Next-80B-A3V / Qwen3-235B-A22B / DeepSeek-V3.2-Exp / Kimi-K2 / GLM-4.5。 - **microservice システム(3)**: Train-Ticket、Online-Boutique(= Google microservices-demo)、自作軽量の Simple-Micro。 - **failure types(7、Table 1)**: resource-level(CPU/Memory/IO Saturation)、network-level(Network Loss/Delay)、application-level(Pod Failure/Configuration Error)。 - **規模**: 7 つの自動 fault 注入・検証機構と 3 システムから 421 の distinct fault–recovery pair を生成可能。標準化された難度は easy(23)/medium(49)/hard(80 cases)。 - **実装**: 最大 thinking 時間 5 分(超過で失敗扱い)。context 長制約から ThinkRemed の $T_{max}$ は既定 1。 ## 実験結果 - **主結果(Table 2)**: モデル順位は Qwen3-Plus が最良(ThinkRemed overall 38.94%)、次いで GLM-4.5・Qwen3-235B。microservice では Train-Ticket が最難、次いで Simple-Micro。ThinkRemed は SoloGen を一貫して上回り平均約 +7.07%。ただし**最易レベルでも ThinkRemed は 50% に届かず**、ベンチの難度を示す。 - **latency–accuracy(Figure 4、§5.3)**: Qwen3-Plus が高精度かつ低 latency で最良バランス。QwQ-32B は小型ながら強制推論で高 latency だが精度向上に繋がらない。Qwen3-Next は低 latency だが精度・安定性を犠牲。 - **failure-type 別(Figure 5、§5.4、Appendix J)**: SoloGen は Pod Failure と Configuration Error をほぼ修復できないが、ThinkRemed は両者である程度成功。両手法とも IO Saturation に弱い。network 系(Loss/Delay)が全モデルで最難(時間依存・サービス間通信グラフの推論を要する)。Configuration Error は分散が大きい(GLM-4.5 が Simple-Micro で最大 76%、他はほぼ失敗)。 - **ablation(Table 3、Qwen3-Plus、Appendix F)**: probe+reflection 両除去で実質 SoloGen に縮退。平均で reflection 除去は -7.16%、probe 除去は -1.57% と reflection の寄与が大きい。一部(Train-Ticket/Simple-Micro の medium)では probe 除去で精度がわずかに改善——現行モデルの contextual reasoning 能力が限られ、過剰 probing がノイズを招いて最終 playbook 生成を誤らせるため。 - **hyperparameter(Figure 12、Appendix I)**: RA は $T_{max}$ を 0→6 に増やすと上昇するが逓減。Train-Ticket easy は 30.43%→52.17%。中難度以上は $T_{max}=3$ 付近で頭打ち。 - **token(Table 5、Appendix H)**: ThinkRemed は SoloGen より大幅に多消費。Qwen3-Plus は Online-Boutique hard で数百 → 100K 超トークンに増大。accuracy と token/latency のトレードオフが顕著。 ## 考察 - reflection(失敗からの再推論)が probe(情報収集)より緩和精度に効く。情報を取りすぎると却って害になり得る点は、「最適な緩和は試行錯誤と自己修正のループ」という SRE 観と整合する。 - 緩和を 1 発勝負(SoloGen)でなく、検証フィードバックに基づく反復(ThinkRemed)にすることが鍵だが、トークン/latency のコストは大きく増える。orchestration(adaptive probing・動的 timeout・選択的 reflection)の最適化が今後の課題。 - Configuration Error は観測可能な resource 異常でなく振る舞いの微妙な不整合(endpoint mismatch・環境変数誤設定)として現れ、symbolic reasoning と deployment 意味理解を要する。reflection を持つ ThinkRemed でも精度は 60% を超えにくく、設定レベル推論が LLM 緩和の根本的ボトルネック。 ## 強み / 弱点・課題 - **強み**: 実環境で playbook を実行し回復を検証する execution-based 評価で、テキスト類似に依存しない。標的検査により検証精度 100% を主張。failure/system/method/LLM の scalability を設計に織り込む。 - **弱点・課題(Limitations)**: 対応 failure type が最頻 7 種に限られ、実世界の多様で進化する障害モードを覆えない(設計上は拡張可能だが、新 fault ごとに注入・検出機構の実装が要る)。methodology 面では、source code や過去の緩和記録のような追加データの活用、より高度なドメイン特化 agent の構築が更なる改善余地として残る。