API の異常検知とドリフトに「学習済み実行グラフ」を適用

API の異常検知の常識を変える：JP モルガンの「学習済み実行グラフ」戦略

複雑化するマイクロサービス環境において、従来の静的な監視では対応しきれない「構造的ドリフト」や「ノイズだらけのアラート」という課題を解決する新たなアプローチが注目されています。JP モルガンの決済チームリーダー、リトヴィック・パンディア氏が提案するのは、リクエスト処理フローを動的に捉える「学習済み実行グラフ（Learned Execution Graph）」です。

この手法は、単なる数値の閾値監視を超え、システム全体の可視化と文脈理解を通じて、異常発生箇所を特定し、アラートのノイズを劇的に削減します。以下では、その核心となる技術的アプローチと実装戦略について解説します。

実行グラフによるリクエスト処理の動的モデル化

従来の監視ツールは個々のメトリクスに焦点を当てがちですが、パンディア氏が提案する「実行グラフ」は、リクエストがシステム内を通過する全体像を DAG（有向非巡回グラフ）としてモデル化します。

これは、リクエストがエッジ層から入り、ゲートウェイや認証・認可を経てオーケストレーション層へ、そして並列処理される外部システムへと流れる一連の順序とコンテキストを明確に定義するものです。各ノードでどのようなデータが渡され、どの順序で実行されるかをグラフとして表現することで、異常が発生した際に「どこで」「なぜ」止まったのかを直感的に特定できるようになります。

「リクエスト処理全体を DAG としてモデル化し、各ノードの順序とコンテキストを明確にすることで、異常発生箇所の特定を容易にする。」

また、このアプローチは再試行（retries）やループ処理といった複雑なフローも、それぞれをグラフ上の独立したエンティティとして扱うことで追跡可能にし、システム全体の信頼性を高めつつリソースの無駄を削減します。

ドリフトの種類を分類し、文脈に応じた検知へ

「異常（Anomaly）」と「ドリフト（Drift）」の違いを理解することが、アラートのノイズを減らす鍵となります。例えば、いつもの通勤時間が1時間だったのが20分かかってしまった場合、それは一時的な事故による「異常」ですが、数年かけて徐々に遅延が増えている場合は環境変化による「ドリフト」です。

パンディア氏は、このドリフトを以下の3 つの主要カテゴリに分類し、それぞれに異なる対策とベースラインを適用することを推奨しています。

1. 構造的ドリフト（Structural Drift）: システムに新しいノードが追加されたり、既存のステップが削除されたりすることで処理フロー自体が変わるケースです。例えば、コーヒーショップで突然「会員制」のチェックが加わったようなものです。この場合、ベースラインを再構築し、新しいプロセスを含める必要があります。
2. スケーリング要因によるドリフト: リクエスト量の急増により、特定のサービスが処理しきれず遅延が発生するケースです。これは単なるパフォーマンス低下ではなく、インフラの拡張や非同期呼び出しへの移行など、スケール対応が必要な信号です。
3. コバリアート（共変量）の変化: システム自体には問題がないものの、リクエストの性質が変わることで挙動が異なるケースです。例えば、国内からのリクエストが 60% から海外からのリクエストが急増し、為替処理などの追加ステップが必要になった場合などです。この場合は、地域や通貨ごとに異なるベースラインを設定する必要があります。

「ドリフトの種類を分類し、それぞれに異なるベースラインや対策を適用することで、アラートのノイズを大幅に削減します。」

OpenTelemetry とストリーミング処理による実装

この「学習済み実行グラフ」を実際に運用するには、OpenTelemetry からのトレースデータを基盤としたストリーミング処理が不可欠です。JP モルガンの実装例では、OpenTelemetry から収集した膨大なトレースデータを Kafka などのストリーム処理エンジンに流し込みます。

ここには「ホットパス（Hot Path）」と「リコンパス（Recon Path）」の 2 つの処理経路が存在します。ホットパスでは、即座に判断を下して迅速な対応や自動化を行う一方、リコンパスではより時間をかけて精密な分析を行い、根本原因を特定します。

この二重構造により、リアルタイムでの障害検知と、長期的なシステム改善のためのデータ分析の両立が可能になります。また、ベンチマークテストとして OpenTelemetry と Starbench を活用し、7 日間にわたる数百万回のトレースデータを注入して異常をシミュレーションすることで、本番環境に投入する前にシステムの精度を検証しています。

リスクベースの自動化と段階的ロールアウト

検知された問題への対応を完全自動化する際、いきなり全システムで実施するのは危険です。パンディア氏は、リスク評価に基づいた安全なアプローチを推奨します。

まず、検知された問題に対する自動対応策を実行する前に、全ノードの 5〜10% を対象にテストロールアウトを行います。この段階でリスクが適切に管理され、検証結果が良好であれば、徐々に範囲を広げ最終的に 100% の展開へと移行します。

「検知された問題への対応を完全自動化する前に、まず 5-10% のノードでテストし、リスク評価と検証を経て全展開を行う安全なアプローチを推奨する。」

この段階的なロールアウトにより、誤った自動化がシステム全体に壊滅的な影響を与えるリスクを最小限に抑えつつ、MTTR（平均修復時間）の短縮と運用負荷の軽減を実現します。

まとめ

「学習済み実行グラフ」は、単なる監視ツールの進化ではなく、マイクロサービスアーキテクチャにおける「文脈理解」と「構造的変化への適応力」を備えた新しい監視のパラダイムです。金融機関のような高信頼性が求められる領域だけでなく、複雑化する現代のシステム運用において、リアルタイム障害検知と自動化の標準となる可能性を秘めています。