> [!abstract] 概要(arXiv abstract の日本語訳) > エージェントベースの推論フレームワークと統合された大規模言語モデル(LLM)は、近年、自律的な意思決定とシステムレベルの操作で強い潜在能力を示している。有望でありながら未開拓な方向の一つがマイクロサービス修復であり、その目標は故障したマイクロサービスシステムを自動的に回復させることだ。しかし既存手法は依然として Site Reliability Engineer(SRE)が手作りしたプロンプトに依存し、LLM はテキスト指示を実行可能なコードに変換するだけにとどまる。この領域の研究を進めるため、本論文では MicroRemed を導入する。これはエンドツーエンドのマイクロサービス修復において LLM を評価する初のベンチマークであり、モデルは診断レポートから実行可能な Ansible playbook を直接生成してシステム機能を回復させなければならない。さらに、SRE の反省的・知覚的推論を模すマルチエージェントフレームワーク ThinkRemed を提案する。実験結果は、MicroRemed が現行 LLM に大きな課題を突きつける一方、ThinkRemed が反復推論とシステムリフレクションを通じてエンドツーエンドの緩和性能を改善することを示す。 ## 論文情報 - タイトル: 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 ## 概要 故障したマイクロサービスシステムを、診断レポートから実行可能な Ansible playbook を生成して自律回復させる **End-to-End Microservice Remediation(E2E-MR)** タスクを定義し、それを評価するライブなベンチマーク MicroRemed を構築する。あわせて、SRE 的な反復推論を模すマルチエージェントフレームワーク ThinkRemed と、ワンショット生成のベースライン SoloGen の 2 つの参照手法を提供し、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 は自然言語指示をコードに変換するだけ。実行時の反復フィードバックを欠き、障害診断からシステム復旧までのエンドツーエンドの自動化を実現できない。MicroRemed はこのギャップを埋める(Figure 1)。 - ソフトウェア保守は異常検知 → 障害診断 → ソフトウェア修復の 3 段階に分かれ、本論文は最終段の修復に焦点を置く(§2.1、Appendix B)。 ## 提案手法 ### MicroRemed ベンチマーク(Figure 2) 実際のマイクロサービスを起動し、Failure Injection で制御された障害を注入、Failure Report と Auxiliary Context を Candidate Remediation LLM に渡して Ansible playbook を生成させ、Execution Engine が実行、Status Verification が回復を検査、Evaluation and Recovery が元の状態へ復元する閉ループ。 - **Failure Injection**: 2 系統。リソース/実行時系(CPU/memory/network 等)は [[ChaosMesh]] による **chaos injection**、設定系(環境変数の誤り・依存設定のミス)は設定ファイルを直接書き換える **configuration injection**。 - **Status Verification**: 一般の異常検知と目的は似るが機構が異なり、注入した特定の障害が完全に解消したかだけを**標的検査**する(CPU-stress を注入したら service A の CPU メトリクスのみ検査)。これにより検証精度 100% を担保すると主張(§3.2)。 - **設計原則**(§3.1): Dynamic Execution Benchmark(静的データセットでなくライブな実行環境)/ 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 回あたりの入力+出力トークン総量(コスト効率)。 ### SoloGen(§4.1) 全 context を 1 プロンプトに入れ、中間推論や反復的な精緻化なしに最終的な Ansible playbook を一発生成する純粋なワンショットのベースライン。 ### ThinkRemed(§4.2、Figure 3) SRE の緩和過程を模すマルチエージェントフレームワーク。4 つの協調エージェントが reasoning–action–reflection のループで動く: - **Coordinator**: auxiliary context $C_0$ と failure report $R_0$ を受け、Probe Agent を呼ぶか適応的に判断し、候補 playbook $p_t$ を合成。 - **Probe Agent**: 稼働中システムから動的に追加の実行時情報を収集(kubectl 等)。 - **Execution Agent**: 生成した playbook を実行して故障した microservice を緩和。 - **Verification Agent**: 結果を評価し二値 $v_t \in \{0,1\}$ を出す。失敗ならリフレクション段階に入り Coordinator へ制御が戻り反復精緻化。反復は最大の trial budget $T_{max}$ で打ち切る(Equation 2)。 - Coordinator は経験豊富な SRE として振る舞う Role Definition Prompt で初期化され、失敗時は Regeneration Prompt で前回の失敗の原因を推論し再生成する(Appendix D、Figure 8/9)。プロンプトはオンライン service を中断させないこと、再起動を主戦略にしないことを指示する。 ## 新規性 - マイクロサービス修復を**初めてエンドツーエンドの生成タスク**として定式化し、人手プロンプトへの依存(KubePlaybook・Andromeda・Wisdom-Ansible・MAPE-Ansible)から脱却。LLM が診断の洞察を直接 repair action に翻訳する閉ループを評価する(§2.2)。 - 関連の SWE-Bench は GitHub issue のバグ修正が対象で実行時の緩和ではない。AIOpsLab は自律 AIOps エージェントの枠組みを提供するが緩和有効性の再現可能な標準評価機構を欠く、と位置づける(§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 つの自動的な障害注入・検証機構と 3 システムから 421 の相異なる fault–recovery pair を生成可能。標準化された難度は easy(23)/medium(49)/hard(80 cases)。 - **実装**: 最大の思考時間は 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 に弱い。ネットワーク系(Loss/Delay)が全モデルで最難(時間依存・サービス間通信グラフの推論を要する)。Configuration Error は分散が大きい(GLM-4.5 が Simple-Micro で最大 76%、他はほぼ失敗)。 - **ablation(Table 3、Qwen3-Plus、Appendix F)**: probe+reflection の両方を除去すると実質的に SoloGen に縮退する。平均でリフレクション除去は -7.16%、プローブ除去は -1.57% とリフレクションの寄与が大きい。一部(Train-Ticket/Simple-Micro の medium)ではプローブ除去で精度がわずかに改善——現行モデルの文脈推論の能力が限られ、過剰なプロービングがノイズを招いて最終的な 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 のトレードオフが顕著。 ## 考察 - リフレクション(失敗からの再推論)がプローブ(情報収集)より緩和精度に効く。情報を取りすぎると却って害になり得る点は、「最適な緩和は試行錯誤と自己修正のループ」という SRE 観と整合する。 - 緩和を一発勝負(SoloGen)でなく、検証フィードバックに基づく反復(ThinkRemed)にすることが鍵だが、トークン/latency のコストは大きく増える。オーケストレーション(適応的なプロービング・動的な timeout・選択的なリフレクション)の最適化が今後の課題。 - Configuration Error は観測可能なリソース異常でなく振る舞いの微妙な不整合(endpoint mismatch・環境変数の誤設定)として現れ、記号的な推論とデプロイの意味理解を要する。リフレクションを持つ ThinkRemed でも精度は 60% を超えにくく、設定レベルの推論が LLM 緩和の根本的なボトルネックとなる。 ## 強み / 弱点・課題 - **強み**: 実環境で playbook を実行し回復を検証する実行ベースの評価で、テキストの類似に依存しない。標的検査により検証精度 100% を主張。failure/system/method/LLM の scalability を設計に織り込む。 - **弱点・課題(Limitations)**: 対応する failure type が最頻の 7 種に限られ、実世界の多様で進化する障害モードをカバーできない(設計上は拡張可能だが、新たな障害ごとに注入・検出機構の実装が要る)。手法の面では、source code や過去の緩和記録のような追加データの活用、より高度なドメイン特化のエージェントの構築が更なる改善余地として残る。