このシリーズの第１回はご覧になりましたか？

今回は、JENNIFER APMの生成AIを活用した新機能であるJENNIFERチャットボットと対話型分析、JENNIFER X-Viewのパターン認識、アプリケーションインサイト機能をご紹介します。
リアルタイムでシステムを分析し、異常の兆候を自動検知するJENNIFER AIを活用した、リアルタイムシステム性能管理の方法が分かります。今すぐチェックしてみてください！

トランザクション分析

Xビューチャートの紹介

メトリクス分析はシステム全体の性能が対象ですが、トランザクション分析は個々のユーザ体験を対象とします。
X-ViewチャートはJENNIFERのトランザクション分析の核心部分です。図1のX-Viewでは、ユーザのリクエストの1つが、1つの点として表示され、X軸はリクエストの完了時刻、Y軸はそのリクエストの処理にかかった時間を示します。

図2でX-Viewの上部に点が多く分布している場合、遅延しているトランザクションが多いことを意味し、性能改善の余地があることを示しています。
一方、図3でX-Viewの下部に点が均等に分布している場合、システムが安定してトラフィックを処理している状況を示しています。
更に、このX-Viewチャートは、個別のトランザクション分析に繋がるエントリーポイントの役割も果たします。

X-Viewでトランザクションを選択すると、タイムライン、フレームグラフ、コールツリーなどの個別トランザクション分析ツールにアクセスできます。
X-Viewは非常に強力な分析ツールですが、JENNIFERを初めて使用する方や、この分野に不慣れなユーザにとっては、X-Viewチャートの解釈が難しい場合があります。

X-Viewパターン認識機能

その理由は、散布図に表示される点の形状とシステムのトラフィック処理の状況を関連付けることが、JENNIFER以外のツールではあまり一般的ではないためです。
このギャップを埋めるために、X-Viewパターン認識機能を開発しました。

X-Viewパターン認識機能は、現在のX-Viewの状態を分析し、システムの状況が正常かどうかを判断します。
異常が検出されると、その原因を推定し、X-Viewチャートの解釈を提示します

遅延トランザクションやエラートランザクションが多く発生すると、現在の状況を異常と認識します。

異常な状況が検知されると、X-Viewで現在の状況が「波打ちパターン」や「ウォーターフォールパターン」(図5参照)など、X-Viewで一般的に見られる障害パターンと一致するかを確認します。
また、ユーザがカスタムパターンを登録している場合、それを活用して過去のシステムの状況と現在の状況の類似性を比較することもできます。

X-Viewチャートの形状が図6にあるような、特定のパターンに従っていることが分かれば、それに伴う症状や原因を把握でき、問題解決に役立ちます。
例えば、「波打ちパターン」の場合、トラフィックの増減に応じて応答時間が敏感に反応している状態を意味します。
通常、システムはトラフィックが増加しても遅延なく安定的に処理するべきですが、トラフィックの増加に伴って応答時間が遅延する状況が発生した場合、ボトルネックを特定し、解決できなければ、トラフィックが一定の閾値を超えると、より深刻な障害へと発展する可能性があります。

X-Viewパターン認識機能は、ディープラーニングモデルを学習して開発されたことで、非常に高い精度を達成できました。更に、この計算をサーバではなくフロントエンドで実行することで、サーバリソースを一切追加せずに、非常に高速な処理速度を実現することができました。
X-Viewチャートは1秒毎に更新されるリアルタイムチャートであるため、瞬間毎にパターンの一致率を計算することが非常に重要です。

このディープラーニングのオンブラウザー構造(図7参照)は、その独創性と有用性が認められ、特許として登録されています。
一般的に、このようなパターンやカテゴリ認識モデルを学習する際は、固定されたカテゴリに対して学習を行う場合がほとんどです。
例えば、入力された画像が犬の写真なのか猫の写真なのかを、判別する認識モデルを作成することを、想像すると分かりやすいでしょう。入力された画像が犬であれば0、猫であれば1を返す方式で学習することができます。しかし、このような従来の構造だけでは、ユーザ定義パターンのような拡張性を確保することは困難です。
そこで、私たちは「Few-shot Learning（少数ショット学習）」という手法を用いてこのモデルを学習させました。
少数ショット学習では、モデルが1つのデータを入力して1つのカテゴリを出力するのではなく、2つのデータを同時に入力し、それらの類似度を返す方式で学習を行います。

例えば、図8で説明すると、現在の状況とユーザ定義パターンの形状が明らかに異なる場合、モデルは低い数値を返します。これは「ウォーターフォールパターン」に対しても同様でした。一方で、「波打ちパターン」とは有意な類似性が発見され、モデルは56%という比較的高い数値を返すことになります。

最初は、あらかじめ提供されるサンプルパターンを活用しながらX-Viewの使い方を学び、X-Viewに慣れた後はユーザ定義パターンを積極的に活用することで、各サービス状況に適した精密なモニタリングができるようになります。
この柔軟な構造によって実現できるもう一つの機能が、類似アプリケーション検索です。

類似アプリケーション検索

類似アプリケーション検索は、応答パターンが類似したアプリケーションを特定する機能です。
応答パターンが似ているアプリケーションは、トランザクションの詳細も非常に類似している場合が多くあります。

そのため、同じ問題や症状を共有している可能性が非常に高くなります。
システム運用中に特定のアプリケーションで問題が発生した際に、この類似アプリケーション検索機能を活用することで、問題の影響範囲や原因の特定に役立てることができます。

アプリケーションインサイト

次に紹介する機能はアプリケーションインサイト機能です。
アプリケーションインサイトは、先ほど紹介したメトリクス分析とトランザクション分析を含め、広範な分析をサポートする機能です。
この機能は、選択されたドメインやインスタンスに対して、直近10分間のリアルタイムデータを活用し、問題を自動検知します。

ここで発生する問題は、トランザクションで発生するエラーと、メトリクスで発生する異常（アノマリー）に分類されます。
各エラーやアノマリーは分単位でグループ化され、ヒートマップチャートとして表示されるため、エラーの発生傾向や頻度を一目で確認できます(図12参照)。

従来は、運用者がトランザクションやメトリクスなどのデータを自分で分析し、問題を特定する必要がありましたが、専門家のような「アプリケーションインサイト」のサポートで、より迅速に分析を実行できるようになりました。

図13では、アプリケーションインサイトのヒートマップで問題を選択すると、画面のサマリーカードによって詳細情報を確認できます。
サマリーカードには、「SQLの応答時間が長すぎます」といった簡単な説明とともに、「トランザクションの分析、または設定時間を変更できます。」という推奨アクションが表示されます。

そのトランザクションの速度が特に重要でない場合は、画面を移動せずに直接タイムアウトの設定値を調整し、エラーの発生を防ぐことができます。
一方で、AIが検知したエラーが、実際に対処が必要な場合は、トランザクション分析を通じてさらなる原因を特定する必要があります。

図14では、Bad Response Timeエラーが発生しているため、このトランザクションの遅延ポイントを特定する必要があります。
スタックトレースを分析するために、スタックトレースフライトレコーダー機能を使用してみましょう（図15参照）。

図16では、分析の結果、sleep関数が全体の応答時間の中で最も大きな時間を占めていることが確認できました。
プロセスがsleep状態に陥った原因を特定するために、コールスタックを追跡し、更に詳細な分析を進めます。

このsleepはDBCP（Database Connection Pool）で発生しており、「DBCP」をキーワードで検索した結果、全体の応答時間の約74%を占めていることが分りました。
そのため、応答遅延の主な原因はDBCPにあると考えられます。

TomcatのDBCPが、データベース関連の処理においてシステムトランザクション遅延の主な要因となっている可能性があります。

図17では、このスタックトレースをさらに分析することで、コードのどの部分でデータベースクエリが発生しているか、各クエリがどのリクエストによって遅延しているかを特定できます。
これにより、コードを修正するか、データベースの仕様を調整することで問題を解決できます。

このように、アプリケーションインサイトは問題を発見して提示し、解決への道筋を提供します。
データ分析において、最も時間がかかる作業の一つは、関連するデータを一箇所に集約することです。
しかし、AIを活用することで、この分析の初期段階を少しでも迅速に進められれば、問題の特定と解決をスピードアップし、システムの障害時間を短縮することに貢献できると期待されます。

生成AIベースの新機能

次に紹介するのは、生成AIを活用した新機能です。
現在、生成AIは大きな注目を集めていますが、APMと組み合わせることで、どのような可能性が期待できるでしょうか？

最近の研究で、コンピューターが数値を自然に処理するように、人間の言語も自然に扱えることが明らかになりました。
弊社を含め、多くの企業がこの新しい能力を活かして、何ができるのかに関心を持っています。

それが、JENNIFER AIの対話型分析です。

弊社自身も未だその答えを完全には分かっていませんが、研究と学習を重ねる中で、皆さまにとって有用なサービスや機能を開発できたため、ここでご紹介します。

JENNIFER AIは、JENNIFERを使用中に発生する疑問を、24時間いつでも解決できるサービスです。

このチャットボットは、最新のLLM（大規模言語モデル）技術を活用し、ユーザの質問の意図を理解し、それに適した回答をします。
そのため、チャットボットを利用することで、JENNIFERの複雑な機能や設定を理解する過程で、マニュアルや技術文書を一つひとつ確認する手間を省き、即座に必要な情報を取得できます。

例えば、図18でJENNIFER AIに「Web Flux環境で非同期モニタリングを設定する方法を教えてください」と質問すると、このボットは、JENNIFERでOpen Telemetryを有効にし、非同期モニタリングを設定する方法を案内します。

更に、関連するヘルプドキュメントへのリンクも提供し、ユーザが追加の情報を確認できるようにサポートします。

チャットボットが正確な回答を提供できる秘密は、カスタムRAG（Retrieval-Augmented Generation）システムにあります。

RAG（検索拡張生成）とは、一般的な知識を持ったLLM（大規模言語モデル）に、ニーズに特化した資料を提供し、回答の精度を向上させる技術です。
JENNIFERチャットボットは、JENNIFERのマニュアル文書に特化しています。
更に、関連する文書を検索するシステムを独自の用途に最適化して実装しているので、OpenAIのGPTsやAmazonのBedrockのような汎用ソリューションを使用する場合よりも、高品質な回答ができるようになりました。

JENNIFER AI

このJENNIFER AIは、現在APMユーザ向けに公開されています。
過去1年間の運用で、100人以上のユーザから寄せられた1万件以上の質問に対応し、その役割を忠実に果たしてきました。

もし読者の中でJENNIFER APMを利用中であれば、アカウントの発行をリクエストし、モニタリングのサポートを受けることをお勧めします。

対話型分析

対話型分析の目標は、サービス運用者が複雑なクエリ言語を使用せずに、日常的な自然言語でリクエストをすると、適切なデータを提供し、分析結果を提示することです。

例えば、特定のインスタンスを選択し、「このインスタンスの応答時間とエラー数をチャートで表示してください」とリクエストすると、AIが自動的に対応するチャートを生成します。

また、データの出所となるAPIも提供することで、追加の検証や更なる分析を行えるようになっています。

図21では、応答時間とエラー数が同時に増加していることが観察されます。
更に詳細な数値を確認するため、同じデータをテーブル形式で取得してみましょう。

図22を見ると、全く同じデータをリクエストしたため、同じAPIが再び呼び出されたことを確認できます。
リクエスト通り、時間毎の応答時間とエラー数がテーブル形式で表示されています。

午前9時から11時の間に、応答時間とエラー数が大幅に増加していることが確認されました。この時間帯に何が起こっていたのかを特定する必要があります。

図23で、AIは推奨質問を自動生成し、その時間帯の主要トランザクションリストを確認することを提案しています。
AIは、先ずメトリクス分析でシステム全体の異常を検出し、その後、トランザクション分析によって具体的な原因を特定するという流れを理解しているようです。

AIの提案に従い、主要なトランザクションリストをリクエストしてみます。
今回は、図23に見るように異なるAPIが呼び出されていることを確認できます。

AIが主要トランザクションの概要を表示してくれるため、次のように問題の状況が一目で把握できるようになっています。

• 応答時間が長くなり、Bad Response Timeエラーを引き起こしているトランザクションがある。
• 応答時間は比較的短いものの、サービス例外（Service Exception）が発生しているトランザクションも存在する。

少なくとも2種類以上のエラーが発生しており、その他のトランザクションの応答時間も約20秒に達しているため、早急に解決策を検討する必要があります。

これらの問題は全て同じアプリケーションで発生しています。
今回は問題を再現するために意図的に開発されたアプリケーションですが、実際のシステム環境であれば、アプリケーション名からどのビジネスロジックに問題があるかを推測できます。

対話型分析は、その多くの機能により、単なるデータ抽出や可視化だけでなく、エラー分析でも非常に効果的です。

例えば、図25ではトランザクション分析中にエラーが発生したトランザクションを発見した場合、即座に対話型分析を利用して、そのエラーについて詳細な問い合わせを行うことができます。

また、対話型分析は、LLMが持つ一般的なIT知識に加え、トランザクションデータのスタックトレースやエラーメッセージなどの情報を活用し、問題を診断し、解決策を提示することができます。

例えば、図26ではBad Response Timeエラーが発生したトランザクションについて質問すると、AIは「応答速度の低下の原因は外部呼び出しにある」と診断します。

SQLに問題がある場合は、プロファイルデータからSQLの実行時間を正確に抽出し、その情報を提供することもできます。
また、LLMの一般的なIT知識を活用し、SQLクエリの最適化手法の提案もできます。

これらの機能は、アラート通知から直接対話型分析に移動して同様に実行することもできます。

このような機能は、緊急時に特に役立ちます。
サービス運用者がより迅速に問題の状況を把握し、適切な対策を見つけることができれば、障害時間を短縮し、システム運用の効率化に大きく貢献します。

現在の限界と今後の展望

生成AIとAPMの融合により、多くの革新的なアイデアが生まれる可能性があります。
しかし、現時点ではこれらの機能には一定の制約が存在します。

最大の課題は、対話型分析やJENNIFER AIが、最高レベルのLLM（大規模言語モデル）に依存している点です。
これは、OpenAIなどの外部APIの呼び出しが必要であることを意味します。

そのため、JENNIFER AIは現在、APMとは別のサービスとして提供されており、
対話型分析は、外部APIの呼び出しが可能な環境でしか利用できないという制約があります。

まとめ

ここまで、システムの複雑化の拡大が運用コストの増大に繋がる可能性がある点から始まり、JENNIFERとAIを活用してこの複雑化を、どのように管理できるかについて説明しました。

今後もシステムの複雑化は急速に拡大するものと予測されています。
現在、クラウド環境でサーバを構築し、Kubernetesでリソースを管理し、クラウドネイティブアーキテクチャに適応したシステム開発が益々増えています。

この流れは、一つの大規模システムを複数の小さなシステムへ、また、大きな組織を小さな単位へ分割することで、個々のシステムや組織をシンプルにし、保守性を向上させるというトレンドに沿ったものです。
その結果、従来では実現が困難だった大規模なシステムを構築できるようになったという利点があります。

一方で、システムが大規模化し、複雑化するにつれて、全体構造を把握することが益々難しくなっているという課題も生じています。
JENNIFERを含むモニタリングツールは、こうした変化する環境に適応するため、継続的に進化しています。

生成AIとAPMの融合は、システム運用の効率化や問題解決の迅速化に、大きく貢献できる可能性を秘めています。
JENNIFER AIの新機能であるチャットボット、対話型分析、X-Viewパターン認識、アプリケーションインサイトは、リアルタイム監視や障害分析をより直感的かつ迅速にするための重要なツールです。

現在の技術には未だ外部API依存などの制約がありますが、今後の技術の進歩で、
より統合的かつ高度なAI活用が可能になることが期待されます。

APMとAIの融合による新たな可能性を引き続き探求し、より強力なモニタリング・分析環境の構築を目指します。

以上、AI活用事例をご紹介しました。
今後も、より進化したAPMを提供できるよう、引き続き努力して参ります。