SREと生成AIを利用したeBayのダウンタイム削減方法：KubeCon EUでのアーキテクトによる洞察

原文リンク(2025-04-05)

KubeCon EUの基調講演で、eBay社のプリンシパルMTSアーキテクトであるVijay Samuel氏は、機械学習やLLMのビルディングブロックを組み込み、自社SREチームのインシデント対応強化を行った際の実体験を披露した。同氏は今回の体験を通し、LLMは万能ではないものの、複数機能を組み合わせることで複雑なシナリオに取り組むエンジニアに役立つことが分かったと語っている。

演説導入部では、過去5年にわたるeBay社のインフラストラクチャー成長実績に基づき、昨今のプラットフォームの複雑性に言及があった。同社のプラットフォームは増加の一途をたどり、マイクロサービスの数は4,000を超えている。同社のプラットフォームの生成データは、15ペタバイトのログデータ、1日あたり100億の動的時系列データ、毎秒1000万のスパン（2％をサンプルとして利用）に相当する。

Samuel氏：仮説を立てる前に、ダッシュボードをいくつ確認すればよいと思いますか？

人力に頼りきった手作業でのインシデントトリアージは試行錯誤の繰り返しが多く、これほど大規模の作業では工数やエラー誘発が起こりやすくなっていた。そこで、Samuel氏とチームメンバーは、このプロセス改善に向けたさまざまな機械学習アプローチを試みた。静的閾値に基づくアラートからの脱却の第一歩が、Grootだった。Grootは、KPIに影響を与えるすべてのアラートと根本原因の関連づけや、小規模問題の自動修復機能まで実装している。また、アノマリ検知アルゴリズムにより、インシデント検知時間が4分未満に短縮されている。しかし、同システムは経験学習を採用しているため、新しいタイプのインシデントが発生するたびに障害が生じていた。

Samuel氏らは将来性の高いLLMの導入を試みた。ChatGPTを使用したPrometheusの転置インデックスの書き換えを行った初期の段階で、身をもってハルシネーションとは何かを学ぶことになった。この試みを通して、「サイトのトリアージ」や「アラートのトリアージ」といった抽象性の高いコンテキストを含むインタラクションにLLMを用いると、ランダム性が伴うとの知見が得られたという。一方で、極めて「明確性の高い」コンテキストで極めて限定的なプロンプトを設定すると、出力の正確性が向上する傾向があった。

試験導入の結果、同氏らは情報量を限定して使用すれば、LLMがインシデント調査の補助ツールとして利用可能であるとの結論に至った。「Explainers」は、限られた量の情報に特化した小規模ツールであり、インシデント調査の中でより多くのコンテキスト提供が可能だ。これらのツールは、可観測性メカニズムを支えるビルディングブロックである、トレース、ログメトリクス、また変更の説明機能を搭載している。

上記のツール改善を受けてAIとエンジニアが相互に補完しあえる関係であるとの確信が得られたものの、より重要度の高い情報を任せるにはLLM側の機能制限や抜け漏れの問題が残っていた。複雑なエコシステムを扱う作業柄、問題を分類してから克服する必要があった。当初は、Uber社のCRISP whitepaperに着想を得たクリティカルパスを踏襲しており、重要度の低いスパンはすべて削除する方針を採用していた。だが、その後に「Few-shot prompting」を採用したことで、通常時のSREインシデントトリアージのケースデータが得られ、アルゴリズムの学習が可能になった。

さらに、コンテキストウィンドウの機能制限に対応するため、全データの「辞書エンコーディング」や、クリティカルパスの「上流工程と下流工程」分割を行った。こうして各工程の説明を生成し、両者を結合して説明の全体像を作成したのだ。結果として、一般的なビルディングブロックであるExplainersから得られた説明の全体像により、作業に複数の問題箇所が存在するか検証できるようになった。

さらに、より複雑な評価メカニズムに組み込まれ、各機能をビルディングブロックに利用可能になった。複雑性の低いExplainersを集約することで、複雑性の高いダッシュボードの分析、説明が可能になり、また複数ダッシュボードの分析に関するその後のトリアージワークフローが構築された。加えて、アラートに障害追跡機能が組み込まれ、最大限のコンテキストが常時利用可能になった。

Samuel氏は、プレゼンテーションの最後でシステムの発展の展望や今回のシステム構築で得られた学びについて言及した。具体的には、ベクトルデータベースと全メトリクスメタデータの統合で、「特定の期間における検索障害の発生件数」や「SLO違反箇所」といったより多くの洞察が得られる可能性があるといった内容である。LLMが万能ではないのは事実であるが、単純な推論、要約生成、内部ナレッジ検索、さらにはコード生成など、要所ごとの活用が望ましいとの認識が得られたという。また同氏は、組織枠を超えたOpenTelemetry採用やクエリ言語の標準化を進めることで、IT業界全体で仮説設定が容易になる可能性を示唆している。