【ITニュース解説】Building a 'Chat with Your Logs' System on AWS Using OpenSearch Serverless and Bedrock

この記事では、AWSのサービスを活用して、ログデータを自然言語で検索・分析できるシステム構築の方法を解説する。システムエンジニアを目指す読者に向けて、その仕組みと主要なコンポーネントについて具体的に説明する。

従来のログ分析では、複雑なクエリ言語を使い、事前に予測されたエラーを探す必要があった。しかし、本システムでは、Amazon OpenSearch ServerlessとAmazon Bedrockを組み合わせることで、自然言語で質問し、関連するログを抽出して回答を得ることが可能になる。これは、Retrieval-Augmented Generation (RAG)という技術を活用しており、大規模言語モデル(LLM)に外部知識ソース（ログデータ）を連携させ、モデルの再学習なしに、質問に対して適切な回答を生成する。

システムの全体像は以下の通り。まず、アプリケーションから送信されたログは、Amazon OpenSearch Ingestionパイプラインに送られる。このパイプライン内で、AWS Lambda関数が呼び出され、Amazon BedrockのTitan Text Embeddingsモデルを使用して、ログのテキスト情報を数値ベクトル（embedding）に変換する。変換されたベクトルは、元のログデータと共にAmazon OpenSearch Serverlessに保存される。ユーザーがウェブアプリケーションを通じて質問をすると、その質問も同様にベクトルに変換され、OpenSearch Serverlessに対して類似度検索（k-NN検索）が行われる。検索結果として得られた関連性の高いログと質問が、Amazon Bedrock上のAnthropic ClaudeなどのLLMに送られ、ログを分析し、人間が理解できる自然な回答を生成する。

ここで重要な役割を果たすのが、embedding_lambda関数だ。この関数は、OpenSearch Ingestionパイプラインから送られてくるログデータを受け取り、各ログのテキスト部分をAmazon BedrockのTitan Text Embeddingsモデルに渡してベクトルを生成する。生成されたベクトルは、元のログデータにlog_embeddingのようなフィールドとして追加され、パイプラインに戻される。このプロセスにより、ログデータは保存される前に意味的な情報が付加され、「スマート」になる。

OpenSearch Serverlessは、ベクトルデータベースとして機能する。log_embeddingフィールドをknn_vectorとして定義することで、類似度検索を効率的に行うことができる。この際、ベクトルの次元数をembeddingモデルの出力次元数と一致させる必要がある。Amazon Titan Text Embeddingsの場合、次元数は通常1024である。検索アルゴリズムとしては、hnsw（Hierarchical Navigable Small World）が推奨されており、大規模データセットにおける検索速度と精度のバランスが良い。

システムの実装には、Terraformが用いられる。コードはモジュール化されており、再利用性と保守性が高められている。modules/ディレクトリには、IAM、Ingestionパイプライン、embedding_lambda、OpenSearchなどのコンポーネントが定義され、envs/ディレクトリには、開発環境などの具体的なデプロイ設定が格納される。

ユーザーインターフェースは、Streamlitで構築されたシンプルなウェブアプリケーションである。LLMへのプロンプトの質が回答の質に大きく影響するため、適切なプロンプトテンプレートを使用することが重要になる。例えば、「あなたはAIOpsのエキスパートアシスタントです。提供されたログエントリのみに基づいて、アプリケーションの動作に関する質問に答えてください」といった指示を与えることで、モデルの性能を最大限に引き出す。

このシステムは、従来のログ分析とは異なるコストモデルを持つ。ログの取り込みとembeddingの生成コストは比較的低いが、LLMの推論コストが主な要因となる。質問の複雑さや量によってコストが変動するため、頻繁なダッシュボード監視よりも、インシデント発生時の詳細な調査に適している。

今後は、このシステムで生成されたベクトルembeddingを、異常検知やインシデントの自動要約など、さらに高度な用途に活用できる可能性がある。ログembeddingに対してクラスタリングアルゴリズムを適用することで、通常とは異なるセマンティックなログのグループを検出し、新しい種類のエラーやアプリケーションの挙動の変化を捉えることができる。また、LLMの要約機能を活用することで、インシデントのタイムラインや根本原因、顧客への影響などを自動的に生成し、事後分析の効率化に貢献できる。