Splunk AI Assistant：AIドリブンなオブザーバビリティを実現するための7つのユースケース

Splunkが先頃、米国と欧州地域でリリースしたObservability CloudのAI Assistantが、大変な反響を呼び、多くの関心を集めました。しかし、大きな力には大きな責任が伴うものです。目新しい最新技術が登場するときはいつもそうですが、AI Assistantについても、どうすれば適切に活用し、その可能性を最大限に引き出せるのかわからない方もいらっしゃるかもしれません。

そのようなお客様は、ぜひこの記事を参考にしてください。私はグロースエンジニアリングマーケティングチームに所属するSplunk社員ですが、自分自身でもAI Assistantを試してみずにはいられませんでした。そして、AI Assistantを日々の仕事に役立てられないかと試行錯誤した結果、オブザーバビリティの関連作業を大幅に改善するのに役立つ7つのユースケースを見つけたので、ご紹介します！

ユースケース1：インスタンスの健全性分析

エンジニアであれば誰もが答えを知りたい単純ながら重要な問いがあります。それは、インスタンスの現在の稼動状況です。最新のSplunkなら、インスタンス名を入力するだけで、AI Assistantがインスタンスの詳細な分析結果を提示してくれます。まるで魔法のように思えるかもしれませんが、それは実際に魔法と言う他ありません。以下は、あるインスタンスについてAIが生成したシンプルな応答の例です。

このインスタンスの管理を数年間担当してきましたが、これほど深いインサイトを得たことはありませんでした。今では、AIが提案する最適化の内容を確認しながら、自信を持ってシステムの信頼性を高める作業を進めることができます。

ユースケース2：トレース分析

アプリケーションへのリクエストにはそれぞれトレースIDが付けられます。OpenTelemetryにおける「トレースID」とは、システムによって監視されている特定のリクエストや処理に割り当てられた一意の識別子です。いずれかのバックエンドの呼び出しについてAPMのアラートを調査する場合、そのトレースIDを取得してAI Assistantに渡し、問題を個別に分析することができます。以下に示すのは、あるトレースIDについてAIが生成した応答の例です。応答内容を確認したら、余計な手間をかけることなく、後はチケットを作成するだけで、開発チームが迅速に問題を解決してくれます。

主な調査結果 このトレースには、内部サービス間の通信およびMkoなどの外部サービスとの通信の両方に関する、複数のHTTP GETリクエストとPOSTリクエストが含まれています。 処理内容は、トークンの取得、フォームデータの送信、メタデータの抽出など多岐にわたります。 トレースには、リード管理とフォーム送信のための外部サービス(特にMko)とのやり取りが含まれています。 エラー分析 www-commons-svcサービス内のMkoService.createMkoPostRequestFormRequestBodyの処理でエラーが検出されました。このエラーは、java.net.MalformedURLExceptionの例外に関連したものであり、これはURLの生成に問題があることを意味します。具体的には、「no protocol:」というエラーメッセージが表示されており、これは、生成または使用されたURLにプロトコルの指定(「http」や「https」など)が欠落していることを示します。 このエラーは、トレース内の問題の根本原因としてマークされており、MkoServiceでのURLの生成または処理方法に問題がある可能性を示唆しています。 推奨事項 MkoService.createMkoPostRequestFormRequestBodyの実装を確認し、プロトコルの指定を含め、URLが正しく生成されていることを確認します。 サービスで使用されているすべてのURLとURIテンプレートを検証し、同様の問題の発生を防止します。

ユースケース3：迅速なフィードバック

私は常に、コード、サービス、機能に関するフィードバックを重要視しています。運用開始後のパフォーマンスに問題はないか、重大なボトルネックはないか、要件を満たしているか、などを把握したいからです。フィードバックを活用すると、自分の仕事に不備がないことを確認するだけでなく、改善すべき箇所をあぶり出して、必要な変更に備えることもできます。ちなみに、フィードバックは特定の実装に関するものであっても問題ありません。

このようなケースは、AI Assistantが得意とする分野であり、貴重な洞察を得られるばかりでなく、時には自尊心をくすぐられることもあります。以下は、特によく使用されるサービスエンドポイントの1つを最適化するための新しい実装について、AIに尋ねた際のフィードバックです。思わずニンマリしてしまいました。

APMのAIに、本番環境の共通サービスの過去8日間の分析を依頼したところ、「GET /api/bin/careers/joblistエンドポイントは高い使用率(8万7,001件のリクエスト)ながら、エラーは発生しておらず、高い安定性を示しています」という分析結果が得られました。

ユースケース4：裏付けを得る

先日、友人である「AI」に、「モノリシックアプリケーションの過去6週間のメモリ使用状況を分析してください」と依頼しました。すると予想したとおり、アプリケーションでメモリリークが発生している可能性があるという分析結果が出ました。AI Assistantは「申し上げにくいのですが…」と切り出してから、その分析結果を伝えてくれました。

それに対し私は、「気遣いは要りませんよ。むしろ感謝したいぐらいです」と応えました。実は6カ月前、ある問題が本番環境で発生した後、私も同様の分析を行って同じ結論に達していたのです。ただ、チームメンバーに私の意見は受け入れられず、分析結果は無視されてしまいました。しかし、こうしてAIの分析結果を手に入れた今、もう無視することはできないでしょう。今度こそチームは行動を起こしてくれるはずです。

分析結果 ユニークIDとしてi-039e37a2bdd344f04_us-west-1_576561709469を持つAWSインスタンスの過去24時間のメモリ使用率と合計メモリの分析に基づいて、以下の結果が得られました。 メモリ使用率：過去24時間のメモリ使用率は変動を続けながら、約42.45%から約63.65%まで徐々に増加しています。これは、この期間中のメモリ使用率が確実に増加していることを示しています。 合計メモリ：インスタンスで使用可能な合計メモリは、66,056,302,592バイト(約61.5GB)で一定しています。 メモリ使用率が増加を続け、大幅な低下が見られない点を考慮すると、このインスタンスのワークロードのメモリ消費量が徐々に増加していると考えられます。

ユースケース5：予測分析

想定するトラフィック量に基づいて、現行システムの処理能力を評価する機会は少なくありません。たとえば、新製品のリリース、ブラックフライデーによるトラフィックの急増、システムキャパシティに関する経営幹部への安心材料の提供、などの場面が挙げられます。この評価の際に判断する必要があるのは通常、システムキャパシティが十分であるか、それとも追加のノードが必要になるかということです。

AI Assistantを使用すると、システムの状態に関するインサイトを簡単に取得し、十分な情報に基づいて今後の要件を予測できます。数週間前、私も同様の課題に直面しました。以下がそのときのAIによる分析です。参考にしてください。

先月のwmd-srv-prodのサービスパフォーマンスから判断して、1時間あたりのリクエスト数があと1,000件増えても処理できるかどうかについてお答えします。 以下は、「wmd-svc-prod」環境における「commons-svc」の過去1カ月間のサービスパフォーマンスの分析結果です。 合計リクエスト数：5万2,015件 合計エラー数：308件 エラー率：約0.59% このサービスは、相当な数のリクエストを比較的低いエラー率で処理しています。現在の1時間あたりのリクエスト数は約72件です(1カ月間720時間で5万2,015件のリクエスト)。 1時間あたりのリクエスト数があと1,000件増えても処理できるか？ 現在のパフォーマンスメトリクスから判断する限り、エラー率は低く、サービスは安定しているように見えます。ただし、1時間あたり1,000件のリクエストを追加で処理する場合、負荷は大幅に増加します。以下に考慮事項を示します。 現在の負荷：このサービスは現在、1時間あたり約72件のリクエストを処理しています。 想定される負荷：1時間あたり1,000件のリクエストをさらに処理する場合、1時間あたりの処理件数は1,072件に増加します。 推奨事項： 負荷テスト：負荷テストを実施し、1時間あたり1,000件のリクエストを追加で処理するシミュレーションを行い、負荷が増加した場合のサービスのパフォーマンスを測定します。 リソースの割り当て：サービスが稼動しているインフラに、追加分の負荷を処理するのに十分なリソース(CPUやメモリなど)があることを確認します。 監視：サービスのパフォーマンスメトリクス(特にエラー率とレイテンシー)を継続的に監視し、新たな負荷の下でサービスが安定稼動していることを確認します。

ユースケース6：未知の未知

オブザーバビリティを熟知している方なら、「未知の未知」という言葉の意味をよくご存知でしょう。AI Assistantを使うと、思いもよらない多くの気づきを得られます。

たとえば、以下のような発見があります。

• 「おや、このサービスがデータの保存にMongoDBを使用していたとは知らなかった。別のDBを使用しているとばかり思っていた。これを移行計画に含めなくては」
• 「このサービスは、トークンAPIを4回も呼び出している。呼び出しを1回に減らせば、速度も信頼性も向上できるに違いない！」

AIを活用し始めると、そのような「未知の未知」を数多く見つけられます。アプリケーションの信頼性とパフォーマンスの向上を目指すのであれば、このような気づきの重要性はいくら強調してもし過ぎることはありません。最終的には、エンドユーザーエクスペリエンスの向上をもたらし、さらには、ゴーストサーバーの停止など、本当のコスト削減につながることも期待できます。

ユースケース7：新しいチームメンバーのオンボーディング

私たちが使用しているシステムはきわめて複雑です(そうでないシステムなんて今どきないと思いますが)。新しいチームメンバーがすぐに業務をこなせるようにサポートすることは、それ自体が大変な作業です。コードを提供したり、ドキュメントへのリンクやZoomの録画を共有したり、さらには対面でデモを行ったりすることもあるでしょう。それでも、後から質問を受けるのはよくあることで、「一体何回繰り返さなきゃならないんだ」と思ってしまうこともしばしばです。担当のスプリント作業で手一杯な中、「Googleで検索すればいいじゃないか」と言いたいところですが、社内アプリケーションであるため、そういうわけにもいきません。

こんなときこそ、Splunk Observability CloudのAI Assistantが窮地を救ってくれます。AI Assistantが、システムの概要、アプリケーションの詳細、リクエスト/レスポンスのワークフローやトランザクションフローの全体像について説明してくれます。そのため、新しいメンバーはシステムを隅々まで理解できるようになるだけでなく、AIを使わなければどのスタッフも気づかなかったような興味深い洞察をミーティングの場にもたらしてくれる可能性すらあります。

SplunkのAI Assistantのおかげで、新しいチームメンバーが短期間で生産性を上げるための知識を身につけている間に、私は自分のタスクに集中することができます。

AIがどのように学習を支援するかについて、以下に例をご紹介します。

AIがリンクを提示したダッシュボードで、サービスの詳細を確認できます。以下がそのダッシュボードです。

個々のエンドポイントすべてについての詳細を確認できます。

さらに、特定のトレースIDに関する説明をAIに依頼し、アプリケーションについての理解を深めることができます。

まとめ

私がObservability CloudでSplunkのAI Assistantを使い始めたのは最近のことですが、それがオブザーバビリティにもたらす恩恵の大きさを日々実感しています。ぜひ皆さんにも私と同じ経験を味わっていただきたいと思います。ここまで一般的なユースケースを紹介してきました。チームで生成AIを活用しながら優れたカスタマーエクスペリエンスを提供するための参考にしていただければ幸いです。

善は急げです。さっそく始めましょう！すでにSplunk Observability Cloudをご利用の場合は、上記のユースケースをご自身でお試しいただけます。そうでない場合は、ぜひ無料トライアル版で詳細をご確認ください。AI Assistantのこちらのリソースもご利用いただけます。

こちらからは、AIのE-Bookをダウンロードできます。では、また次の機会にお目にかかりましょう。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。