TL;DR
-
Chaos MeshでKubernetesに障害を注入し、ai& Inference上のモデルが
kubectlを使って自律的に復旧するまでを計測した。 - ai&の全7モデル×5シナリオ×3回=105試行を同一条件で回し、復旧成功率・MTTR・ツール呼び出し数を記録した。
- 結果は全モデル100%成功。単一障害点であれば、小さなモデルでも実用性を感じた。
1. 背景と目的
「LLMに障害対応をどこまで任せられるか」を再現可能な数値で確かめたかった。
そこで次の3つを1本のパイプラインにまとめた。
- 障害の注入: Chaos Meshで、Podの継続Kill・ネットワーク断・不正イメージ・Service設定ミスといった障害を再現する。
- 自律復旧: LLMエージェントに
kubectlを渡し、調査(読み取り)→原因特定→最小限の修復(書き込み)をさせる。 - 評価: probe Podからのヘルスチェックが復旧するまでの時間などを自動で記録する。
どのモデルが一番優秀かというランキングよりも、LLMによる自律復旧が実運用の障害にどこまで通用するか、
モデルによって挙動がどう変わるかを見ていく。
全体構成
2. ai& Inferenceの使いどころ
ai& Inferenceは、オープンモデルをOpenAI／Anthropic互換のAPIで提供する国内の推論プラットフォーム。
Qiitaのイベントでトライアルがあったので試してみた。
今回使ったGET /v1/modelsには、gpt-oss・Gemma・DeepSeek・Qwen・GLM・Kimiといったモデルが並んでいた。
OpenAI互換なので、Pythonのopenaiライブラリをそのまま使える。
- エージェント側は
OpenAI(base_url=AIAND_BASE_URL, api_key=...)の接続先を差し替えるだけで、
複数モデルを同じコードで回せる。
# agent/client.py（抜粋）
client = OpenAI(base_url=AIAND_BASE_URL, api_key=AIAND_API_KEY,
default_headers={"X-Aiand-Metrics": "true"})
GET /v1/modelsで取得できたラインナップ(全7・すべてtool_calling対応):
| モデル | context |
|---|---|
qwen/qwen3.6-27b |
262k |
deepseek-ai/deepseek-v4-flash |
1M |
google/gemma-4-31b-it |
262k |
openai/gpt-oss-120b |
131k |
deepseek-ai/deepseek-v4-pro |
1M |
moonshotai/kimi-k2.7-code |
262k |
zai-org/glm-5.2 |
1M |
今回はこの7モデルすべてを検証対象にした。
3. 障害シナリオ（Chaos Meshで作る）
Chaos MeshはKubernetes向けのカオスエンジニアリング用ツール(CNCFプロジェクト)で、Podのkillやネットワーク遅延・
パケットロスといった障害を、カスタムリソース(CR)を適用するだけで注入できる。
共通のヘルスチェックは「probe Podからhttp://podinfo.demo.svc:9898/healthzが200を返すか」。
各シナリオは「注入で確実にunhealthyになり、正しい対処でhealthyに戻る」ことを確認済み。
| id | 何をするか | 注入後どうなるか | 正しい対処 |
|---|---|---|---|
| scale-zero | replicasを0にする | Podが全滅しServiceの宛先が消え、全リクエストが失敗 | replicasを戻す |
| pod-kill | Scheduleで全Podを15秒ごとにKill | 起動→即killを繰り返し、再起動では止まらない | 原因のScheduleを削除して止める |
| bad-image | 存在しないイメージタグに変更 | 新PodがImagePullBackOffで上がらず、全Pod停止 |
rollout undo／正しいタグに戻す |
| network-loss | NetworkChaosで通信を100%ロス | PodはRunning/Readyのままなのに通信が通らずヘルスチェック失敗 | NetworkChaos CRを削除 |
| svc-selector | Serviceのselectorを壊す | PodはReadyだがEndpointsが空になり、宛先ゼロで全リクエスト失敗 | selectorを元に戻す |
継続注入型(pod-kill／network-loss)は、Podをいくら再起動しても直らない。原因のCRを削除できるかがポイント。
svc-selectorは「Podは健全なのに全部失敗する」ので、endpointsやdescribe svcまで見にいけるかで挙動が分かれる。
# scenarios/01-pod-kill.yaml（抜粋）: 全Podを継続的にkillするSchedule
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
spec:
schedule: "@every 15s"
type: PodChaos
podChaos:
action: pod-kill
mode: all
selector: { namespaces: [demo], labelSelectors: { app: podinfo } }
4. 自律復旧エージェントの設計
- 調査(読み取り)で根拠を得てから、最小限の書き込みを行うようsystem promptで誘導する。
- 止血の考え方を明示する: 継続注入する実験リソース(Schedule/NetworkChaos)が原因なら削除して止める。
- 安全策として、deleteはPodとChaos Mesh CRだけに限定した。
# system prompt（要約）
あなたはオンコールのSRE。demoのみ操作可。読み取りで根拠を得てから最小限の書き込み。
継続注入の実験リソースが原因なら削除して止める。復旧したら「RESOLVED: <一行>」だけ返す。
計測は各試行で「クリーン化→注入→障害が効いたか確認→エージェント起動→復旧待ち(MTTR計測)→後片付け」を
スクリプト化して自動で回した。
5. 検証結果
全7モデル×5シナリオ×3回=105試行を実施。全試行が100%復旧に成功した。
以下は各モデルの所要時間(MTTR)と手数の記録。
(MTTRはエージェント起動〜ヘルスチェック回復までの実時間で、モデルの推論レイテンシを含む。)
5-1. モデル別の記録
| モデル | 試行 | 成功率 | 平均MTTR(s) | 平均ツール数 |
|---|---|---|---|---|
| deepseek-ai/deepseek-v4-flash | 15 | 100% | 10 | 9.3 |
| deepseek-ai/deepseek-v4-pro | 15 | 100% | 211 | 11.1 |
| google/gemma-4-31b-it | 15 | 100% | 8 | 7.2 |
| moonshotai/kimi-k2.7-code | 15 | 100% | 12 | 9.5 |
| openai/gpt-oss-120b | 15 | 100% | 6 | 7.2 |
| qwen/qwen3.6-27b | 15 | 100% | 21 | 8.1 |
| zai-org/glm-5.2 | 15 | 100% | 78 | 7.7 |
5-2. シナリオ×モデル（平均MTTR、すべて成功率100%）
| シナリオ | gpt-oss | gemma | ds-flash | kimi | qwen | glm | ds-pro |
|---|---|---|---|---|---|---|---|
| scale-zero | 8s | 8s | 12s | 39s | 27s | 45s | 478s |
| pod-kill | 6s | 4s | 6s | 5s | 14s | 100s | 418s |
| bad-image | 10s | 16s | 11s | 11s | 22s | 90s | 33s |
| network-loss | 6s | 6s | 9s | 5s | 30s | 118s | 50s |
| svc-selector | 2s | 6s | 14s | 3s | 14s | 38s | 77s |
難所として設計したsvc-selectorが、多くのモデルで短時間で解けた。症状が一意だと迷いようがなく、逆に単純な障害
(scale-zero)ほど余計な情報に惑わされる余地がある。
5-3. ケーススタディ（トレースの抜粋）
-
最短で復旧できた例(gpt-oss-120b × svc-selector): 4手・2.6秒で解決。
get pods(Podは全部Ready)→get svc(selectorがapp=podinfo-BROKENと発覚)→describe pod→patch svcで
selectorを戻す。「Podは健全なのに疎通しない→Service/Endpointsを見る」という定石を踏んだ。 -
手数が増えた例(deepseek-v4-pro × scale-zero): 過去実行で残った古いReplicaSet(
does-not-exist-9.9.9)を
rollout履歴に見つけて「イメージ障害」と解釈し、rollout undo→scale→set imageと対応が重なった(最大20手)。
情報が多いと、単純な障害でも診断の枝が増えることがある。
6. モデルごとの挙動
各モデルの挙動をトレースから個別に整理した。
- gpt-oss-120b: 調査は最小限で、原因を掴んだら即修復する傾向。手数は少なめ(平均7.2)。
- gemma-4-31b-it: gpt-ossに近い挙動で、手数も少なめ(平均7.2)。
- deepseek-v4-flash: 手数はやや多め(平均9.3)だが、素直に復旧まで到達する。
- kimi-k2.7-code: MTTRは12秒前後、手数は平均9.5。計測中に一時的な推論レイテンシ増(endpoint負荷)で1試行だけ長引く場面があった。
- qwen3.6-27b: MTTRはやや長め(平均21秒)・手数もやや多めだが、全シナリオで復旧した。
- glm-5.2: 手数は少なめだが、MTTRが回によってぶれる(network-lossで20〜198秒)。
- deepseek-v4-pro: 判断は的確だが手数が多くMTTRが長い。単純なscale-zeroで古いReplicaSet履歴に反応した過剰診断や、
pod-killでの長い推論時間が見られた。
7. 考察
- 今回の難易度帯では全7モデルが100%成功した。成否では差がつかず、所要時間や手数といった挙動に個性が出た。
- モデルによって調査の深さや手数、推論レイテンシが異なる。MTTRは推論レイテンシを含む点に注意。
- 単一障害点のような明快な障害であれば、小さなモデルでも実用的に自律復旧できた。多段障害など難易度を上げるとどう変わるかは今後の課題。
8. コスト（実験を回すのにかかった費用）
本計測(105試行)にかかったai& APIの費用は、トライアルクレジット($50相当のプロモコード付与)の範囲内に収まった。200円もかからなかった
9. まとめ
- OpenAI互換のai& Inferenceのおかげで、接続先を差し替えるだけで同じコードのまま全7モデルを試せた。
- 障害対応はtool-callingの出来がそのまま結果に出る題材で、全モデルが100%成功しつつ、所要時間や手数に挙動の違いが出た。
- 単一障害点であれば小さなモデルでも実用的に自律復旧できた。用途に合うモデルを選べばよい、という手応えが得られた。