CNCFにおけるObservability

理論上は、SecurityやObservabilityのような非機能要件も、すべてをプロンプト (Prompt)や仕様書へ記述することは可能かもしれません。

しかし現実には、Observabilityだけを考えても、分散トレース、メトリクス、構造化診断、相関ID、Payload保護、機密情報マスキング、外部監視基盤との接続など、多数の横断的機能が必要になります。

これらを毎回AIへ自然文で指示し、個別実装へ委譲すると、実装複雑度と運用複雑度は急速に増加します。

SimpleModeling (シンプルモデリング)では、CMLとCNCFによってこれらの品質属性 (Quality Attribute)を吸収し、AIはドメイン・モデル (Domain Model)やドメイン・ロジックの開発に専念できるようにしています。

さらに問題になるのは、生成AIの利用コストです。

SecurityやObservabilityのような横断的品質属性を毎回プロンプトや仕様書で詳細に指示しようとすると、要求仕様は急速に肥大化します。

さらに、Trace、Metrics、Correlation、Payload Protection、Redaction、Export、Retry、Backend Integrationなどの要素が相互作用し始めると、実装複雑度と運用複雑度は実質的に指数関数的に増加します。

その結果、生成AIへ与えるコンテキスト量も急増し、生成コスト・レビューコスト・再生成コストが大きく膨らみます。

しかも、生成AIは理解できない要求や複雑すぎる要求に遭遇すると、簡単に省略・単純化・見落としを行います。

そのため、すべてをプロンプトや仕様書へ押し込む方式では、品質保証そのものが不安定になります。

CML&CNCFでは、この問題をモデルコンパイラと実行フレームワークによる構造化された吸収によって解決します。

CNCFでは、CNCF内で自動的にObservability情報を採取すると同時に、ダッシュボードを含めたObservabilityの運用環境を用意しています。

ただし、CNCFを含めたシステム全体でのObservabilityを考えた場合、各システムの出力するObservability情報を集約して運用管理する機能が必要です。

CNCFでは、この目的で業界標準となっているOpenTelemetryとの連携をサポートしています。

CNCF内部では、以下のような構造化実行情報が保持されます。

OpenTelemetryと連携することにより、システム全体のObservability情報と統合した形で、CNCFが採取するObservability情報を、JaegerやPrometheus、Grafanaといった専用ツールで参照することができるようになります。

CNCFでのObservabilityの実例をチュートリアルを例に説明します。

以下の場所に格納されているチュートリアルを使用します。

展開後の以下のディレクトリにサンプルコードが入っています。

このサンプルは、「最小構成でTrace Exportできるか」を確認するためのものです。

構成:

CNCFは直接JaegerへTraceを送信します。

CNCF自身もObservability機能を持っています。

まず、CNCF自身のObservability機能を使って、オペレーションの実行結果を確認しましょう。

確認順序は以下の通りです。

次にJaegerで、CNCFからExportされたTraceを確認します。

検索条件:

確認内容:

前述の例はObservability機能側は最小構成のJaegerのみでした。

次はOpenTelemetry Collector, Jaeger, Prometheus, Grafanaを使った本格構成です。

製品版でも適用できる構成になっています。

ZIPファイル展開後の以下のディレクトリにサンプルコードが入っています。

こちらは、Collector中心の標準Observability構成です。

Observabilityのシステム構成を以下に示します。

CNCFはOpenTelemetry CollectorにObservabilityの情報を渡すと、JaegerやPrometheusに情報が伝搬されます。

さらにGrafanaはJaegerとPrometheusから情報を取得し、ダッシュボードとして可視化します。

システムを以下のように起動します。

Observabilityで観測する情報を以下のようにして作ります。

確認順序は以下の通りです。

AI駆動開発では、SecurityやObservabilityのような横断的品質属性を毎回プロンプトや仕様書へ詳細に記述し続けることは現実的ではありません。

要求仕様が肥大化すると、生成AIへ与えるコンテキスト量・生成コスト・レビューコスト・再生成コストが急速に増大し、品質保証そのものも不安定になります。

さらに、生成AIは複雑すぎる要求や理解できない要求に遭遇すると、省略・単純化・見落としを行いやすくなります。

そのためCML&CNCFでは、SecurityやObservabilityをアプリケーションコードへ委譲するのではなく、モデルコンパイラと実行フレームワークによるRuntime Capability (ケーパビリティ)として吸収します。

また、CNCFではOpenTelemetryを観測の本体ではなくExport境界として扱い、CNCF Native Observabilityを一次情報源として維持します。

今回のサンプルでは、Jaeger単体構成からCollector中心構成までを通じて、CNCF RuntimeがObservabilityをどのように統合的に実現するのかを確認しました。