推論：可観測性のAI主導の未来？
推論：AI主導の未来の可観測性？
過去9ヶ月間、生成AIの急速な進歩がほぼすべての産業に影響を与えています。生産システムの監視とモニタリングに対して、どのような影響があるのでしょうか？
私は、次の進化は「推論」と呼ばれる新しいクラスのソリューションであり、開発者がエラーの原因を合理的な精度で直接特定できるようになると考えています。
この記事では、以下のことを考察します：
- 監視の自然な次のステップとしての推論。
- AIOpsからの学び-なぜ普及しなかったのか、および推論への影響。
- 推論ソリューションのクラスに関するいくつかの新興原則。
現状
次世代の監視を理解するために、これらのツールの根本的な目標から始めましょう。それは、生産システムを健全かつ予想どおりに稼働させ、何か問題が発生した場合には、迅速に理解し問題を解決するためのものです。
そこから、ツールが私たちをサポートするための3つの異なるレベルがあることが分かります：
- レベル1：「システムに何か問題がある場合に私に警告してください」- 監視。
- レベル2：「何故問題が発生しているのか（そしてどのように修正するか）を教えてください」- これを推論と呼びましょう。
- レベル3：「自分で修正し、私がしたことを教えてください」- 自動修復。
監視ツールはレベル1（問題の検出）を比較的うまく行います。次の自然なステップはレベル2であり、システムが自動的に何故何かが壊れているのかを教えてくれるようになります。まだこれを行えるソリューションはありませんので、私たちはレベル1とレベル2の間に「観測可能性」というカテゴリのツールを追加しました。その目標は「何故何かが壊れているのかを理解するのを助けること」であり、これは基本的に「何が起こっているのかを理解するのに役立つ可能性のあるデータ」となりました。
観測可能性 vs. 推論
現在の観測可能性の問題点
現在の観測可能性の主な問題は、定義と実行が緩くなっていることです。これは、事前に必要なデータがわからないためです。生産エラーの性質上、それらはロングテールで予期しないものです。予測できた場合は解決されていたでしょう。したがって、私たちはさまざまなデータタイプを収集します。メトリクス、ログ、分散トレース、スタックトレースエラーデータ、K8sイベント、連続プロファイリングなど、何かが問題が発生した場合に何らかの可視性を確保するためです。
実際の実装における観測可能性を理解する最良の方法は、「メトリクスの外側のすべて、さらにメトリクス」と言えます。
実践における観測可能性
観測可能性プラットフォームは、どれだけのデータをキャプチャして保存するかについても選択を行わなければなりません。この決定は現在は顧客に押し付けられており、顧客はできるだけ多くのデータを収集するようにデフォルトになっています。急速なクラウドの採用とSaaSモデルにより、大量のデータを収集して保存することが可能になりました。
観測可能性データの種類とボリュームを増やす人間の要因は、「何かが壊れた場合にトラブルシューティングするために十分なデータを持っていない場合はどうなるか？」ということです。これはすべてのエンジニアリングチームの最悪の悪夢です。その結果、現在次のような状況があります：
- 観測可能性データの種類が継続的に拡大しています。
- 観測可能性データのボリュームが爆発的に増加しています。
- ツールの乱立が増加しています – 平均的な企業は5つ以上の観測可能性ツールを使用しています。
これらすべての問題により、新たな問題に直面し始めました。開発者がエラーを特定するために数十のデータ集中型ダッシュボードを手動でナビゲートすることはますます困難になっています。また、観測可能性は非常に高価になっており、企業は保存するデータについて複雑なトレードオフを行う必要があります。場合によっては、可視性を失うこともあります。これに加えて、生産システムの複雑さの持続的な増加により、生産エラーのMTTRは実際に年々増加していることがわかっています。
推論 – 観測可能性にAIを加えたもの
私は、観測可能性の次のステップは、エラーが発生した理由を合理的に説明し、それを修正することができるプラットフォームである推論だと主張します。これは、2023年にAIモデルの急速な進化によって可能になったものです。
次のようなソリューションを想像してみてください：
- 開発者の即時の注意が必要なエラーのみを自動的に提示します。
- 開発者に、問題の原因と問題が発生している場所- このポッド、このサーバー、このコードパス、この種類のリクエスト- を正確に伝えます。
- 開発者に修正方法を案内します。
- 開発者の実際のアクションを使用して、推奨事項を継続的に改善します。
この領域では、まだ初期の活動がありますが、まだ非常に初期段階であり、次の数年間にいくつかの新しい会社が登場することが予想されます。
ただし、AI + オブザーバビリティに関する話し合いは、AIOPsについての議論なしでは不完全です。AIを使用してプロダクションオペレーションを自動化するという同じ約束がされ、’15-20年の間に多くの投資が行われましたが、限定的な成功に終わりました。AIOPsがなぜ失敗したのかについての包括的な探求については、こちらをお読みください- AIOps Is Dead。
AIOpsの落とし穴を回避する
AIOpsの元々の前提は、5つまたは6つの異なるオブザーバビリティソースからのデータを統合プラットフォームにプッシュし、そのデータ（メトリック、ログ、依存関係、トレース、設定、更新、K8sイベント）にAIを適用すると、何かが壊れた理由についての洞察を得ることができるというものでした。
AIOPのプラットフォームのアーキテクチャ。
理論的には魅力的ですが、この議論はいくつかの点で不十分でした。
まず、すべてを結び付けることは実用的ではなく、推定よりもはるかに困難な問題でした。異なるオブザーバビリティツールは、異なる時間間隔で異なるシステムについての異なるデータを収集し、収集したデータの異なるサブセットをサードパーティツールに公開しました。さらに、各個別の顧客は独自のデータ収集プラクティスを持っていました。たとえば、エンタープライズでは、非常にカスタマイズされた非標準のデータ収集を行うさまざまなオブザーバビリティツールが複数あり、エンタープライズは新しいAIOPツールに関するそれらについてのコンテキストを手動で提供する必要がありました。これらすべてが、MLモデルが到達できる品質の応答/ルート原因特定と提供される価値に影響を与えました。
次に、AIOPのモデルは広範であり、ユースケースに関連付けられていませんでした。たとえば、モデルはどのような特定の種類のエラーを対象としていましたか？インフラエラー/コードエラー/ハードエラー/ソフトエラー？ほとんどのAIOPのプラットフォームはここで非常に広範であり、パターンや異常を見つけるために8つの異なるデータタイプを取り込もうとし、顧客がプラットフォームに押し込むデータの量と品質に過度に依存していました。その結果、出力の品質が異なりました。
第三に、各企業での統合プロセスが複雑すぎました。大企業は、さまざまなチームが実行する数十のツールを持つフラグメント化されたオブザーバビリティツールを持っています。AIOpsプラットフォームは、価値を追加するためにそれらのすべてのツールに統合される必要がありました。大規模なオブザービリティプラットフォーム（例：DatadogやDynaTrace）のAIOPモジュールの場合でも、要件はオブザーバビリティスタック全体が単一のベンダーに移動すること（インフラとアプリのメトリック、ログ、分散トレーシング、エラーモニタリングなど）、AIOPモジュールが効果的に機能するためのものでした。
第四に、大量のデータとデータ処理に必要な処理能力のため、これらのツールはその疑問の余地のある価値に対して非常に高価でした。
これらすべての結果、AIOpsツールの早期採用者の多くの幻滅が生じ、ほとんどの企業が単純な「データを収集し、ダッシュボードに表示する」メカニズムに戻りました。
ここから多くの学びが適用でき、推論を試みる際に学んで適用できます。
推論の原則
推論は、最終目標を効率的に達成するためにいくつかの点で異なるアプローチを取る必要があります。
AIを念頭に置いて最初から設計されたアーキテクチャ
推論ソリューションは、AIのユースケースに適したように、データ収集、処理、パイプライン、ストレージ、ユーザーインターフェースがすべて「AIを使用したルート原因分析」を目的として最初から設計される必要があります。
実際には、既存のオブザービリティソリューションまたは既存のオブザービリティデータの上にAIを追加するのではなく、それは見えるでしょう。ルート原因分析を実行するためにAIを使用するという明示的な目標のために、すべてがデザインされたフルスタックシステムである必要があります。
実践では、これはどのようになるでしょうか？
データ収集、処理、ストレージ、および可視化を備えたフルスタックAIネイティブアーキテクチャ
推論ソリューションは、垂直統合される必要があります。つまり、テレメトリデータを収集し、データを処理し、データパイプラインとユーザーとの対話レイヤーを所有する必要があります。
これは重要です。なぜなら、ユーザーの対話を使用して、ソリューションがデータ処理と収集のメカニズムを学習し更新することができるからです。
インファレンスソリューションにとって、顧客環境から必要なデータを必要な形式で必要な文脈で収集することが重要です。これにより、ルート原因の効果とユーザーエクスペリエンスを制御することができます。
適応型データ収集
インファレンスソリューションには、データ収集そのものに組み込まれた知能が必要です。つまり、エージェントはデータのストリーミングを見て、その時点でキャプチャするか破棄するかを判断できる必要があります。
現在のすべての計測エージェントは「ダム」として機能しています。つまり、すべてのデータのスナップショットを取り、それを送信し、後で処理が行われます。これは主にコードエージェントを使用し、エージェントをできるだけ軽量にし、最小限のオーバーヘッドを追加したいため、現在の状況に合っています。
しかし、eBPFなどの技術が登場し、ほとんどゼロのオーバーヘッドでカーネルからのデータ収集をオンバンドで行うことができるようになったことで、インファレンスモデルが要求するデータ品質を積極的に解決する知能を持つ計測エージェントを想像することができるようになりました。
特定のユースケースに調整されたデータ処理
インファレンシングでは、すべてのデータ処理技術は特定のユースケースを中心に展開される必要があります。例えば、エラータイプAを確実に特定する方法、エラータイプBを確実に特定する方法などです。
すべてのデータ処理モデルは、特定のエラータイプのルート原因を確実に特定できるようにする原則に従い、モデルが進化するにつれて特定できるエラータイプを徐々に増やしていきます。これにより、異なるデータ型、データパイプライン、および各エラータイプごとのプロンプトが生じる場合があります。インフラエラーのルート原因特定に優れたインファレンシングプラットフォーム、セキュリティの問題に優れたプラットフォーム、コードエラーに優れたプラットフォームなど、それぞれがわずかに異なるデータセットとデータパイプライン、異なるモデルフレームワークを使用するプラットフォームが存在するかもしれません。
おそらく行われないのは、「一般的な異常検出」を行い、それから異常の原因を調べるということです。これは、エラーのルート原因を特定するために必要なデータが、「エラーを特定/検出」するために必要なデータとは非常に異なるためです。
AIに適したストレージ
インファレンシングの世界におけるストレージのビューは、監視や観測の世界とは異なっています。すべての発生データのための大容量のデータストアがありますが、インファレンシングでは、信頼性の高いルート原因特定に必要な最も関連性の高い最新のデータのみを保存する必要があります。これには、簡単なクラスタリングと引き出しのためのベクトルDBにデータを保存する、成功事例の一部のみを保存し、それ以外のデータを破棄する、エラーの重複を排除するなど、さまざまなプラクティスが関与する場合があります。
その結果、インファレンシングソリューションに必要なストレージ量は、従来の監視や観測ソリューションよりも少なくて済む場合があります。
シンプルでインタラクティブなユーザーインターフェース
インファレンスインターフェースは、データを持つダッシュボードの集まりではなく、開発チーム向けに調整された対話型インターフェースのようになる可能性があります。おそらく、人間の注意が必要な優先度付けされたエラーのシンプルなテーブルがあるかもしれません。各エラーをクリックすると、最も可能性の高いルート原因のリストと正確性の確率が表示されます。その後、ユーザーがルート原因が正しく特定されたかどうかを確認するためのRLHF（人間のフィードバックからの強化学習）が行われ、モデルは時間とともにパフォーマンスを向上させます。ここでの可能性は広範です。
概要
まとめると、Gen. AIの最近の進展により、監視および観測の領域に大きな変革が起こる可能性があります。
最初の波のソリューションは、既存の観測データの周りに薄いGen. AIラッパーを持つAIOPsプラットフォームに似る可能性があります。既存の企業がこの波で最も有利な立場にあります。これは、Github Copilotに似ているかもしれません-おおよそ10％の確率で良い提案が得られます。ただし、真の飛躍はおそらく数年後になるでしょう。それは、エラーのルート原因を80％以上の確率で正確に特定できる新しいクラスのインファレンシングソリューションです。これを実現するには、フルスタックであり、データ収集、処理、ストレージ、モデル、およびユーザーインタラクションを所有する必要があります。スタックの各部分で既存のプラクティスとは異なるインファレンシングソリューションに関するいくつかの初期の仮説を探求しました。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
