Intelligent Root Cause Analysis and Incident Diagnostics for Microsoft Fabric and Power BI through Telemetry Correlation and Kusto Query Language

あなたは、巨大でハイテクな宇宙船「アナリティクス・エンタープライズ号」の船長になったと想像してください。この船は、Microsoft FabricとPower BIという2つの超複雑なエンジンによって動いています。これらのエンジンはただ飛行するだけでなく、膨大なデータを処理して、乗組員が大きな決断を下すための手助けをします。しかし、時として船がガタつきます。ダッシュボードが空白になったり、レポートの読み込みに時間がかかったり、データパイプラインが停止したりすることがあるのです。

このような事態が起きたとき、従来の修理方法は、懐中電灯とメモ帳を持った整備士をエンジンルームに送り込み、あてもなく歩き回らせるようなものでした。彼らは燃料パイプ、配線、冷却システム、そしてナビゲーション・コンピューターを一つずつチェックし、どこに問題があるのかを推測しなければなりません。それは遅く、疲れやすく、もし整備士がエキスパートでなければ、間違った箇所を直してしまう可能性もあります。

これは、Shujath Baig Mirzaによる論文が述べていることそのものです。著者は、Microsoft FabricやPower BIのような巨大なプラットフォームにおいて、「懐中電灯を持って歩き回る（手動での調査）」方法はあまりにも遅く、ミスを招きやすいと主張しています。代わりに、この論文は、船のエンジンルームにおける超強力なGPSのように機能する、**「スマートな探偵システム」**を提案しています。

スマートな探偵のツールキット

この新しいシステムは、謎を解くために2つの主要なツールを使用します。

1. テレメトリ相関（「すべてを見通す目」）:
   宇宙船には、あらゆる場所に数百万もの小さなカメラやマイク（ログ、メトリクス、トレース）があると考えてください。昔のエンジニアは、これらのカメラの映像を一つずつ個別に見ていなければなりませんでした。新しいシステムは、これらすべての映像を一つに繋ぎ合わせ、同期された一つの巨大な映画のようにまとめ上げます。これにより、燃料パイプのちらつきが、ナビゲーション・コンピューターの奇妙な音と「全く同じタイミング」で発生したことを把握できます。人間が一度に多くの画面を見ているために見落としてしまうような、点と点をつなぎ合わせることができるのです。

2. Kusto クエリ言語（「魔法の呪文集」）:
   これは、探偵が宇宙船に質問をするために使う言語です。何かが壊れるたびにゼロから複雑な質問を書き直すのではなく、探偵はあらかじめ用意された再利用可能な「呪文（テンプレート）」を使用します。これらの呪文は、船の各パーツが互いにどのように依存しているかを理解するように設計されています。もしエンジンが故障した場合、呪文は自動的に燃料、配線、冷却システムを正しい順序でチェックし、即座に容疑者のリストを絞り込みます。

大規模な実験：シミュレーションされた衝突

このスマートな探偵が本当に機能するかどうかを確認するために、著者は単に推測するのではなく、制御されたシミュレーションを実施しました。彼らはMicrosoft FabricとPower BIの環境を模した偽の環境を作成し、意図的に以下の4つの方法で故障を引き起こしました。

• データ更新の失敗: 燃料タンクを満たそうとしているのに、ポンプが詰まっているような状態。
• クエリ・パフォーマンスの退行: ナビゲーション・コンピューターがスローモーションのように停滞しているような状態。
• セマンティック・モデルの不整合: 地図の座標が間違っているような状態。
• キャパシティ・スロットリング・イベント: あまりにも多くの人が同時に使用しようとしているため、エンジンがオーバーヒートしているような状態。

それぞれの「衝突」に対して、著者は2つのチームを比較しました。

• マニュアル・チーム: 従来の「懐中電明とメモ帳」の手法を用いるエンジニア。
• インテリジェント・チーム: 新しいスマートな探偵システムと魔法の呪文集を使用するエンジニア。

結果：スピードと賢さ

シミュレーションの結果、明確な違いが示されました。スマートな探偵システムは、単に少し優れたレベルではなく、劇的に優れた結果を出しました。

• 真の犯人を突き止める:
  船が故障した際、マニュアル・チームが正しい根本原因を特定できたのは、データ更新失敗で約71.2%、低速クエリで68.9%、マップエラーで73.5%、オーバーヒートで65.7%でした。
  対してインテリジェント・チームは、それぞれ92.5%、90.3%、94.1%、**91.8%**の確率で正しい根本原因を的中させました。彼らは、エンジンの誤った部品を原因だと決めつけることがはるかに少なかったのです。

• 修理までの時間:
  宇宙旅行において、時間は金であり、信頼でもあります。マニュアル・チームは、燃料ポンプの詰まりの原因究明に平均47.8分、低速ナビゲーションに52.1分、マップエラーに39.6分、そしてオーバーヒートしたエンジンにはたっぷり58.9分を要しました。
  一方、インテリジェント・チームは、燃料ポンプの謎をわずか18.4分で、低速ナビゲーションを21.7分で、マップエラーを15.2分で、そしてオーバーヒートを23.5分で解決しました。彼らは診断時間を半分以下に短縮したのです！

• 推測の減少:
  マニュアル・チームは、燃料ポンプの問題を見つけるために平均18.6回もの異なる調査チェック（クエリ）を実行しなければなりませんでした。インテリジェント・チームは、わずか6.2回のチェックで済みました。彼らは間違った場所を探すことに時間を無駄にしませんでした。

これが意味すること（および、そうではないこと）

この論文は、このようにスマートでコネクテッドなアプローチを採用することで、危機に直面した際に個々の専門家が推測に頼って進む必要がなくなることを示唆しています。代わりに、自動的に点と点をつなぎ、問題の場所を直接指し示すシステムを利用できるのです。これにより、運用はより信頼性が高まり、乗組員のストレスも軽減されます。

ただし、留意すべき重要な点がいくつかあります。

• これはシミュレーションである: これらの結果は、厳密に制御されたシミュレーション環境から得られたものです。論文は、これがまだ何百万もの実際のユーザーがいる本物のライブ宇宙船でテストされたとは主張していません。著者らは、結果は素晴らしいものの、実世界でのテストが次のステップであると示唆しています。
• 探偵であって、修理屋ではない: このシステムは、問題を「見つけ」、それが何であるかを伝えることには非常に優れています。しかし、まだエンジンを自動的に「直す（修復）」ことはできません。これは極めて優秀なガイドですが、レンチを回すためのメカニックは依然として必要です。
• あらゆるものに対する魔法ではない: このシステムは、パターンとタイミングを見つけることに依存しています。もし問題が非常に微細であったり、パターンに当てはまらないような奇妙な遅延を伴って発生したりする場合、システムは完璧ではない可能性があります。

要約すると、この論文は、Microsoft FabricやPower BIのような複雑なデータ・プラットフォームにおいて、「懐中電明と推測」の手法を「スマートでコネクテッドな探偵」の手法に置き換えることで、問題をより速く、より正確に、そしてより少ないストレスで発見できることを示しています。これは、私たちのデータ船をスムーズに航行させ続けるための、有望な一歩です。