# アーキテクチャ要件

LLMS index: [llms.txt](/llms.txt)

---

## 概要 {#summary}

OpenTelemetry コミュニティのデモアプリケーションは、本番環境に近いクラウドネイティブアプリケーションにおいて、OpenTelemetry API、SDK、およびツールを紹介することを目的としています。
このアプリケーションの全体的な目標は、OpenTelemetry コンポーネントの標準的な「デモ」を提供するだけでなく、エンドユーザー、ベンダー、およびその他のステークホルダーがさらにカスタマイズするためのフレームワークとしても機能することです。

### 要件 {#requirements}

- [アプリケーション要件](../application/)
- [OpenTelemetry 要件](../opentelemetry/)
- [システム要件](../system/)

### アプリケーション目標 {#application-goals}

- 開発者に OpenTelemetry 計装を学ぶ際に利用できる堅牢なサンプルアプリケーションを提供する。
- オブザーバビリティベンダーに、さらにカスタマイズ可能な（またはそのまま使える）単一かつ十分にサポートされたデモプラットフォームを提供する。
- OpenTelemetry コミュニティに、OTel API、SDK、ツールの機能と能力を示す実際に動く成果物を提供する。
- OpenTelemetry のメンテナーやワーキンググループに、「実環境」で新機能/コンセプトをデモするためのプラットフォームを提供する。

以下は、デモアプリケーションの論理コンポーネントの一般的な説明です。

## メインアプリケーション {#main-application}

デモアプリの大部分は、eコマースサイトのような「実務的な」動作を行う自己完結型のマイクロサービスベースのアプリケーションです。
このアプリケーションは、gRPC や HTTP を介して相互に通信する複数のサービスで構成されており、Kubernetes（またはローカルの Docker）上で動作します。

各サービスには、（適用可能または利用可能な範囲で）トレース、メトリクス、ログについてOpenTelemetryの計装を行うものとします。

各サービスは、同じビジネスロジックを実行し、同じ gRPC エンドポイントを実装しながらも、異なる言語/実装で書かれたサービスと相互に置き換えが可能である必要があります。

各サービスは、分散アプリケーションにおいてテレメトリーが問題解決にどのように役立つかを示すために障害を有効化/無効化する目的で、フィーチャーフラグサービスと通信できる必要があります。

## フィーチャーフラグコンポーネント {#feature-flag-component}

フィーチャーフラグは、クラウドネイティブアプリケーション開発における重要な要素です。
デモでは、CNCF の Incubating プロジェクトである OpenFeature を使用して、フィーチャーフラグを管理します。

フィーチャーフラグは、flagd configurator のユーザーインターフェイスを通じて設定できます。

## オーケストレーションおよびデプロイメント {#orchestration-and-deployment}

すべてのサービスは Kubernetes 上で実行します。
OpenTelemetry コレクターは OpenTelemetry Operator を用いてデプロイされ、サイドカー + ゲートウェイモードで実行される必要があります。
各 Pod からのテレメトリーは、エージェントからゲートウェイにルーティングされる必要があり、ゲートウェイはデフォルトでオープンソースのトレース + メトリクス可視化ツールへテレメトリーをエクスポートする必要があります。

ローカル環境や Kubernetes 以外の環境でのデプロイにおいて、コレクターは compose ファイルを用いてデプロイされ、アプリケーションからのトレース/メトリクスだけでなく、`dockerstatsreceiver` 経由で Docker コンテナも監視する必要があります

このプロジェクトの設計目標の一つは、クラウド環境への自動デプロイのための CI/CD パイプラインを含めることです。
ローカル開発においては、このパイプラインは省略することもできます。