OpenSearchCon North America 2025のセッション「GenAIOps - OpenSearch for AI & GenAI Platform Observability」をまとめます。
スピーカー
Rama Pabolu氏はTransUnionでDirector of Software Engineeringを務めており、Trusted Call Solutions開発チームを率いています。24年以上にわたってスケーラブルで高性能なソフトウェアシステムのアーキテクト設計と提供に携わってきました。クラウドネイティブプラットフォーム、マイクロサービス、Kubernetes、インメモリデータベース、キャッシングベースのソリューション、そして通信プロトコル開発における深い技術的専門知識を持っています。最適化されたインフラストラクチャとデータパイプラインを通じて、1日あたり数百万件の電話を処理し、サブミリ秒のレイテンシーを実現するリアルタイムシステムを構築してきました。現在は、高度な分析、機械学習、セキュアなコール署名と検証技術を適用することで、大規模な詐欺電話やスパムコールを防ぎ、通信ネットワークの信頼性を強化することに注力しています。
Ramesh Kumar Manickam氏はTransUnionのSr Directorとして、バンガロールにあるGlobal Capability CenterのTruContact Enterprise Product Engineeringグループを率いています。TravelTech、FinTech、CommTechの分野にまたがって、ソフトウェアプロダクトとエンジニアリングセンター・オブ・エクセレンスの構築において24年以上の業界経験を持っています。Mobile Developer Summit、Aerospike Summit、そして以前のOpenSearchConでも講演を行うなど、技術カンファレンスでの発表経験も豊富です。
なぜGenAIにオブザーバビリティが必要なのか
技術の進化は私たちのインフラストラクチャとオペレーションの在り方を根本的に変えてきました。クラウドネイティブの時代には、回復力のあるスケーラブルなインフラストラクチャを手に入れることができました。続くAIネイティブの時代では、インテリジェントな自動化と予測可能な機能がプラットフォームに組み込まれるようになりました。そして今、GenAIの時代を迎え、推論、自動生成、そして自律的な行動という新たな能力がシステムに加わっています。
この技術的な進化は、運用面でも大きな変革をもたらしています。DevOpsからMLOpsへ、そして今やGenAIOpsへと運用手法が進化してきました。GenAIOpsとは、GenAIスタックに運用原則を適用することであり、その中核となる原則はオブザーバビリティ、信頼性、そしてセキュリティです。
モニタリングの性質も大きく変わってきました。従来はレイテンシーやスループットといった定量的なメトリクスを中心にモニタリングしていましたが、GenAIの時代には定性的なモニタリングが重要になっています。モデルのパフォーマンス、プロンプトエンジニアリングの品質、エンドツーエンドでのプロンプトのトレーシングなど、より複雑で多面的な監視が必要になっているのです。これらの新しい課題に対応するため、私たちは新しいツール、新しい考え方、そして新しいプラクティスを採用する必要に迫られています。
GenAI時代のオブザーバビリティには、ベクトルDB、エージェント、RAG、LLMシステムといった複数のコンポーネントが含まれます。これらのコンポーネントは、バッチモード、ストリーミングモード、リアルタイム推論といった様々な動作モードで動き、それぞれに適切なモニタリングのフックポイントを設定する必要があります。OpenTelemetryによるインストゥルメンテーション、Jaegerによる分散トレーシング、そしてOpenSearchをバックエンドデータベースとして活用することで、このエコシステム全体からエンドツーエンドでトレースを収集することが可能になります。
このようなGenAIOpsの考え方は、AI Opsエンジニア、アーキテクト、データプロダクトマネージャー、意思決定者など、AIに関わるすべての人々にとって重要です。特にプラットフォーム開発チーム、テストチーム、SREチームにとっては、これらの概念をライフサイクルの早い段階で導入することが、より良いモニタリングとスケーラビリティを実現する鍵となります。GenAIOpsやオブザーバビリティをスタックに深く組み込めば組み込むほど、システム全体がより堅牢で管理しやすいものになっていくのです。
AI/MLスタックの進化とアーキテクチャ
AI/MLアプリケーションスタックは、バッチMLからストリーミング、そしてLLMへと進化を遂げてきました。それぞれの段階で異なるアーキテクチャとモニタリングのアプローチが必要になっています。
バッチMLのユースケースでは、MLモデルとそれを支えるフレームワーク、ツール、ランタイムが基本的な構成要素となっています。ストリーミングのユースケースに進化すると、Feature StoreやStreaming Pipelinesといった新たなコンポーネントが追加され、リアルタイムでのデータ処理が可能になりました。そして現在のGenAI/LLMのユースケースでは、LLMモデルやエージェントといった、より高度で自律的なコンポーネントが中心的な役割を果たしています。
これらのスタックは徐々に複雑さを増しており、ユースケースも継続的に追加されています。機械学習、コンピュータビジョン、自然言語処理、音声認識といった従来の領域に加えて、カスタムモデルのデプロイメント、チャットボットやバーチャルアシスタントといった新しい応用分野も広がっています。
このスタック全体を支える基盤として、Kubernetesのようなスケーラブルなプラットフォームがバックエンドで動作しています。そして、その下にはコンピューティング、ストレージ、メモリ、ネットワーキングといったインフラストラクチャ層が存在し、システム全体の安定性とパフォーマンスを保証しています。MLOpsとLLMOpsの層は、これらの複雑なコンポーネントを統合し、運用可能な状態に保つための重要な役割を担っています。
このような多層的なアーキテクチャの各段階で、何をどのようにモニタリングすべきかを理解することが、GenAIOpsを成功させる鍵となります。それぞれのレイヤーに適切なモニタリングのフックポイントを配置することで、システム全体の可観測性を確保できるのです。
GenAIオブザーバビリティのスペクトラム
GenAIスタックのオブザーバビリティを考える上で、4つの重要な柱があります。
まずLLMsです。大規模、中規模、小規模の基盤モデルや事前学習済みモデルがあり、それぞれにquantisation、fine-tuning、memory tuning、inference prompting、LLM reposといった異なる特性と要件があります。これらすべてがオブザーバビリティのスペクトラムの中核を成しています。
次にAI Agentsは、特定のタスクを実行する重要なコンポーネントです。ネットワーク、セキュリティ、カスタマーサービス、SQLといった様々なエージェンティックワークフローを通じて、Pandas agentsなどの専門的なエージェントが動作しています。
Toolsの領域では、チャットボット、ベクトルストア、データベース、APIコード、音声認識、画像処理といった多様なツールセットが統合されています。これらのツールは、GenAIシステムが実世界のタスクを実行するための重要なインターフェースとなっています。
そしてFrameworksは、システム全体を支える基盤となっています。LangChain、LangGraph、LlamaIndex、AvaTaR、CrewAIといったデプロイメントフレームワークに加えて、OWASP AI SecurityやNIST AR ISO/IEC 42001といったセキュリティとマネジメントのフレームワークも含まれています。これらのフレームワークがGenAIプラットフォーム全体のセキュリティと信頼性を確保しています。
右側の図が示すように、実際のデータフローはユーザーからのクエリで始まります。エージェントがそのクエリを受け取り、LLMの助けを借りて処理を行います。ローカルのOllamaや外部のLLMサービスが必要に応じて使い分けられ、コンテキスト情報を取得するためにベクトルDBも活用されます。これらすべてがKubernetes上でサービスやPodとして動作し、OpenTelemetry（OTLP）を通じてモニタリングされる構造になっています。
このような複雑なエコシステム全体を適切に観測し、管理することがGenAIOpsの本質なのです。
GenAIのアーキテクチャとKubernetes環境での実装
GenAIシステムのアーキテクチャを詳しく見ていくと、複数の重要なステージが連携して動作していることがわかります。ユーザーからのリクエストは、まずGenerative AI APIを通じて処理されます。このAPIは、Kubernetes上でServiceとPodとして展開されており、スケーラブルで信頼性の高い基盤を提供しています。
Generative AIモデルは、システムの中核となる部分です。これらのモデルは、必要に応じて外部ツール（インターネット検索など）や外部LLMと連携しながら動作します。モデル自体もKubernetesのServiceとPodとして管理され、負荷に応じた自動スケーリングや障害時の自動復旧が可能になっています。
データ処理の流れにおいて、Vector Embeddingsは特に重要な役割を果たしています。コンテキストデータを取得し、意味的な検索を可能にするために、ベクトル埋め込みが生成され、管理されます。これらのベクトル埋め込みサービスも、他のコンポーネントと同様にKubernetes上でServiceとPodとして動作しています。
そして、Domain-specific Dataは、各組織や用途に特化したデータを格納し、GenAIシステムがより精度の高い、文脈に即した応答を生成できるようにしています。これらのデータストアも、Kubernetes環境内で管理され、必要に応じてスケールアウト可能な構成になっています。
このアーキテクチャ全体を通じて、OpenTelemetryが優れた統合プラットフォームとして機能しています。すべてのステージからメトリクス、イベント、ログ、トレースといったMELTスタックの情報をエンドツーエンドでキャプチャし、これらのデータをOpenSearchにプッシュします。OpenSearchは、収集されたデータをさらに洗練させ、包括的なダッシュボードの構築を可能にしています。Jaegerとの連携により、分散トレーシングも実現され、システム全体の可観測性が確保されているのです。
モデルライフサイクルとモニタリングポイント
モデルのライフサイクルを理解することは、モデルの様々なステージで何をモニタリングできるかを把握する上で重要です。
モデルライフサイクルは大きく2つのステージに分かれています。最初のステージは「Training - モデルの準備」です。大規模コーパスで学習された基本的なモデルから始まり、これにはMistral、Llama 3、Phi 3といったプライベートLLMが含まれます。新しいモデルを構築する際には、非常に多くのインフラストラクチャが必要となり、数日から数ヶ月かかることもあります。その後、より小さなドメイン知識のトレーニングセットを使用してモデルをファインチューニングします。ファインチューニングされたモデルは、コードリポジトリとモデルレジストリに保存されます。
第二のステージは「Inference - モデルを運用に投入する」段階です。ファインチューニングされたモデルと共に、Feature Store、Streaming Pipelines、ストリーミングデータ、VectorDBやその他のデータベース、APIコード、RBAC、ルーティングコード、フロントエンドコード、バックエンドコードといった様々なコンポーネントが含まれます。これらはリバースプロキシを介してユーザーや管理者に提供され、APIを通じて内部および外部のプラットフォームと連携します。アイデンティティとアクセス管理も実装されています。
本番環境に投入した後も、本番データを取り込んでさらに学習させ、継続的な学習によってモデルをファインチューニングしていきます。
AIデータパイプラインと各レイヤーでのモニタリング技術
モデルのライフサイクルと同様に、データ側でもシステム全体をエンドツーエンドでデータがどのように流れているかを見ることができます。データパイプラインは、Data Ingest、Data Preparation、Training、Inference、そしてInference Loggingという5つのステージから構成されています。
Data Ingestステージでは、NFS、S3、Kafkaを通じて生データが収集されます。Data Preparationでは、SparkSQLやDataFramesを使用してデータが精製されます。TrainingステージではPretrained ModelとTrained Modelが作成され、GPUDirectストレージに保存されます。InferenceステージではQuantized Modelが使用され、Fine-TuningやRe-Trainingも行われます。最後のInference LoggingステージではQuery/ResponseとTransaction Log Storeが記録され、Prompt and Response Logs、Multi-Modal Response Loggingが実施されます。同じデータを使ってモデルを再学習させ、さらに良くしていくことができます。
このパイプライン全体をモニタリングするために、OSスタックの異なるレイヤーで利用可能なテクノロジーがあります。レイヤー2-3では、ハードウェアノード、LLMのためのAIノード、ベクトルDBノード、エッジデバイスといったすべてのノードにおいて、Cilium、NetFlow、eBPF、そしてOpenTelemetryを使用します。eBPFはBerkeley Packet Filterのようなプロトコルで、下位レイヤーのネットワーキング関連のすべてをモニタリングするために使用されます。CiliumもeBPFの上で開発されたツールです。
レイヤー4-7のアプリケーションレイヤーでは、APIゲートウェイ、エージェント、ベクトルDB、Fine-Tuning Pipelines、LLMsがあります。ここでは、OpenTelemetry、サービスメッシュ、OpenSearch、分散トレーシングのためのJaeger、Prometheus、Grafana、そしてLangGraphやLangfuseといった成熟したツールが利用可能です。
メトリクスデータのOpenSearchへのフロー
OpenSearchへのデータフローは、コレクターを介して体系的に構築されています。マイクロサービスや共有インフラストラクチャから、OTel Auto Instrumentation、OTel API、OTel SDKを通じてデータが収集されます。KubernetesやL7 Proxy、その他のインフラストラクチャコンポーネントもOTLPプロトコルを使用してデータを送信します。
OTel Collectorは、これらのデータソースから情報を受け取り、プロセッサ、バッファ、コネクターを通じてデータを少しずつ充実させてから、OpenSearchのIngestion OTLPエンドポイント（Data Prepper）へプッシュします。クライアントインストゥルメンテーションでは、Managed DBsやAPIsからもデータが収集されます。OpenSearchはこのデータを保存し、処理してからOpenSearch Dashboardsに渡します。ダッシュボードは、モデルのパフォーマンス、プロンプトのトレーシング、コスト効率といったニーズに基づいて作成できます。
上部に示されているシグナルタイプには、MELTスタックの一部として一般的に見られるMetrics、Logs、Tracesに加えて、BaggageとProfilingがあります。Baggageは単にキーバリューペアであり、メタデータ情報を格納し、トレーシングのすべてのスパンにそれらを渡します。Profilingは、個々のスパンや個々のコンポーネントのパフォーマンスなどをモニタリングすることに近いものです。
下部のアプリケーション層では、Instrumented AppはOpenTelemetry SDKを使用し、Jaeger AppはJaeger Agent経由で、Zipkin AppはZipkin Collector経由でOpenTelemetry Collectorに接続します。これらのデータは、OTel Trace Src、OTel Metrics Src、OTel Logs Srcを経由し、OTel Trace ProcessorやOTel Service Map Processorで処理された後、OpenSearch Sinkへ送られます。最終的にOpenSearchでストレージと可視化が行われ、Trace AnalyticsやDashboardsで分析されます。
GenAIにおける重要なメトリクス
GenAIにおける重要なメトリクス
これは様々なコンポーネントでどのようなメトリクスがGenAIにおいて重要であるかを示した重要なスライドの一つです。
LLMsとFine-Tuned Modelsにおいては、Cost analysisでLLMパワードアプリケーションからのコール毎のコストを計算します。Response time trackingでは、LLMコールの平均応答時間をモニタリングし、Token usage per callでは、コール毎に使用されるトークン数やプロンプトの詳細を追跡します。A/B testingでは、異なるモデルバージョン、Drift、Cosine similarity distribution、Batch variabilityを比較します。LLM ModelsのTemperatureやDimensionalityといったパラメータも重要です。そしてPolicy guideline complianceでは、LLMコールがアプリケーションによって作成され、組織のポリシーガイドラインに沿っているかを確認します。
Vector DBsとData Pipelinesでは、Similarity Search Behaviorでフィルタリングとコンディションパフォーマンス、リコールと精度、正確性を測定します。Data Ingestionでは、埋め込みの書き込みレイテンシー、バッチインジェスション、損失を監視し、Driftでは、Embedding Drift、Transformation、Cleaning、Labelingを追跡します。PerformanceではMetadata PerformanceやQuery Performance、ScalabilityとAvailabilityを、Index ManagementではOptimization、Rebuild time、sizeを、Resource UtilizationではCompute、Memory、Disk、Network I/Oをモニタリングします。
API GatewaysとOther infra stuffに関しては、Request Volumesでレート制限、リクエストスロットリング、レイテンシーを、ErrorsでFailures、Timeouts、Status Codes、Payload Errを追跡します。Availabilityでは、Circuit Breaking activity、Anomalies、Healthcheckをモニタリングします。これらすべてのメトリクスがGenAIシステムの健全性と性能を確保するために重要なのです。
MLOpsとLLMOpsの違い
GenOpsにおけるMLOpsとLLMOpsの主な違いは何でしょうか。
GenAIのオブザーバビリティには、LangSmith、PromptLayer、Weights & Biases、Helicone、Langfuseといった優れたツールセットが存在します。特にLangfuseとLangGraphが人気で、これらは機能豊富なトレースをOpenTelemetryコレクター経由でOpenSearchに送信し、エンドツーエンドでのデータ収集を可能にしています。
MLOpsとLLMOpsの根本的な違いは、その予測可能性にあります。MLOpsは決定論的で予測可能なモデルを扱いますが、GenAIは非決定論的な性質を持っています。同じクエリを今日与えた場合と明日与えた場合で、モデルの洗練により異なる結果が返される可能性があります。
この非決定論的な性質により、LLMOpsではセマンティックな評価が必要になります。モデルの品質を判断するために、LLM-as-a-judge（LLMを評価者として使用）やHuman-in-the-Loop（人間による評価の組み込み）といった手法が必要とされます。ドリフトのモニタリングにおいても、埋め込み距離などのセマンティックなパラメータを使用します。また、MLOpsが学習とデプロイメントに焦点を当てるのに対し、LLMOpsは推論とプロンプトの最適化により重点を置いています。
サンプルアプリケーション
これは、LLMを通じてドキュメント処理が行われるサンプルアプリケーションの1つです。
右側では、ドキュメントに対してデータ処理が行われているのがわかります。ユーザーがそれらのドキュメントに関する特定のクエリをリクエストすると、BedrockまたはSageMakerがポストプロセスで使用されます。これらすべてがデータをキャプチャし、LLMを使用して応答を返します。
OpenSearchが表示されているところでは、その情報を格納することができます。最初のレベルは基本的なノードレベルの情報、2番目のレベルはいくつかの参照、3番目のレベルはこれらのアクションのオペレーションといったものです。これらのアクションは、CloudWatchのようにOpenSearchを使用してすべての情報を格納することができます。
github.com
ベストプラクティス：AI + OTel + OpenSearch
私たちが経験から学んだ重要なベストプラクティスを紹介します。
まず重要なのは、AIコンポーネントのインストゥルメンテーションです。自動であれ手動であれ、AIコンポーネントをトレーシングでラップする必要があります。LLMの呼び出しにはcreate、invoke_chainといった特定の呼び出しがあり、埋め込みサービスやベクトルルックアップも含まれます。これらすべてをトレーシングでラップすることが重要です。外部ツールを呼び出す際は、モデル名、トークンカウント、コストなどのメタデータを含むカスタムスパンを作成します。これらのスパンはトレーシングで非常に重要で、最終的にエンドツーエンドで表示されます。
次にコンテキスト伝搬が重要になります。あるコンポーネントからコンテキストを取得したら、この情報を別のコンポーネントにも伝搬させる必要があります。トレースIDとバゲージヘッダーを使用することで、複数のエージェントやツールにまたがるワークフロー全体でコンテキストを維持できます。
収集されたテレメトリーはバックエンドにエクスポートします。OTelコレクターは、強力なOSSスタックを構築するためにOpenSearchやPrometheusにプッシュできます。また、OpenTelemetryをサポートしているAWS CloudWatchも使用可能です。これらのデータを基にダッシュボードを作成し、イベントの注釈付けも行います。コスト分析、レイテンシー、エージェントワークフローの進行状況、パイプラインの構成などを追跡できます。
さらに、OpenTelemetryの上に構築されたOpenLLMetryがGenOpsのために参照できます。下位レイヤーのモニタリングには、eBPF、Cilium、Tetragon、Hubbleといったツールがあります。HubbleとTetragonはUIベースの分散トレーシングエンジンで、エンドツーエンドでトレースできます。
まとめ
私たちが話したことを要約します。GenAIコンポーネントには、ベクトルDB、エージェント、RAGシステム、LLM、推論パイプラインなどが含まれます。これらは一般的なMELTアーキテクチャを通じて完全にオブザーバブルであり、OpenTelemetryとOpenSearchを使用することで実現できます。
レイヤー4から7のオブザーバビリティについては、クラウドネイティブ環境ではサービスメッシュを、AIネイティブ環境ではOTel統合されたLangGraph、Langfuse、OpenLLMetryといったツールが役立ちます。GenOps機能は、GenAIシステムのトランザクションインテリジェンスと運用インテリジェンスを強化するために活用されます。
これらの仕組みに加えて、常にシステムを評価し、採用し、改善し続ける必要があります。技術の進化はMLOpsからAIOps、そしてGenAIOpsへと進んでおり、将来的にはAgentOpsへと発展していくでしょう。
下の図は、GenAIにおいてリクエストのフローがエンドツーエンドでどのように起こっているかを示す参照図の1つです。ここではOpenSearchがどのような役割を果たすことができるかについても含まれています。ユーザーがクエリを送信すると、それが生成AIを通り、検索エンジンに移動します。次にドキュメントまたは外部参照に移動します。OpenSearchはそのすべての情報を格納することができ、コンテキストの切り替えが必要な場合は履歴検索にも戻ることができます。関連するドキュメントのチャンクを取得したら、再度LLMで情報が充実され、最終的な応答がユーザーに提供されます。
