jazug_night_be3_20251113

分散システム可観測性：Azure Container Apps における OpenTelemetry 活用 第56回 Tokyo Jazug Night 2025年11月13日 薗部 匡矢 / Masaya Sonobe 1

自己紹介 名前：薗部 匡矢 / Masaya Sonobe 所属・経歴： 株式会社SPARQでプロダクトエンジニアをしています。 2025年9月まで、日本マイクロソフトでAI、アプリケーショ ン領域のCloud Solution Architectをしてました。 趣味 アニメ、映画など（最近だと「The Playlist」、「ちひろさん」 を観た）、服、音楽（ライブに年3~4回くらい） SNS GitHub: Masaya Sonobe@Be3751 X: be3@Blossomrail LinkedIn: Masaya Sonobe 2

• https://github.com/Be3751
• https://x.com/Blossomrail
• https://www.linkedin.com/in/masaya-sonobe-3b9444240/

アジェンダ 1. 分散トレーシング登場の背景 2. OpenTelemetry による分散トレーシング 3. Azure における OpenTelemetry の活用 4. デモ & 実装ポイント 5. まとめ 3

1. 分散トレーシング登場の背景 4

システム構成の変化 モノリシックから分散システムへ かつて：モノリシック構成 1つのアプリケーション内で処理が完結 障害解析も比較的単純 現在：分散システム・クラウドネイティブ時代 1リクエストが多数のサービスを経由 コンテナやサーバーレスで動的にスケール・消滅 外部APIやクラウドサービスを組み合わせた複雑な呼び出し経路 結果：「1つの処理の全体像」を把握するのが困難に 5

従来のアプローチの限界 ログベース監視の課題 各サービスが独立してログを出力 1つのリクエストがどのサービスを経由したか追えない タイムスタンプや相関IDでの突き合わせは人手では非現実的 短命なコンテナ・関数ではログが失われる可能性 メトリクス監視の課題 CPUやメモリ、リクエストレートは「症状」を示すが、原因となるサービス間の関係性 は見えない 「どこで遅延が発生しているのか」「どのサービスがボトルネックか」が特定できない 6

分散トレーシングの登場と意義 1つのリクエストをサービス横断で追跡し、全体の 処理フローを可視化 分散トレーシングの特徴 各サービス呼び出しにIDを付与 リクエストの全経路とレイテンシーを一貫し て記録 ボトルネック特定や障害調査を容易にする https://opentelemetry.io/docs/concepts/observability-primer/#distributedtraces 7

• https://opentelemetry.io/docs/concepts/observability-primer/#distributed-traces

2. OpenTelemetry による分散トレーシング 8

OpenTelemetry テレメトリーデータの収集と送信を統一的に扱うOSS CNCF (Cloud Native Computing Foundation) の卒業プ ロジェクト 設計思想として、 「計装・収集・送信」に焦点 データの 保存や可視化は対象外（他のベンダーツールや OSSと連携） ベンダー中立な テレメトリーデータパイプラインの標準 を目指す https://opentelemetry.io 9

• https://opentelemetry.io/

テレメトリーデータの3本柱 1. ログ (Logs) アプリケーションのイベント記録 エラーメッセージ、警告、デバッグ情報 2. メトリクス (Metrics) 数値データの時系列測定 CPU使用率、メモリ使用量、リクエスト数 3. トレース (Traces) サービス間の呼び出し関係 各サービスの処理時間 10

トレースだけでなくメトリクス・ログも統一的に扱える 観測データの三本柱を1つのSDK・Collector構成で収集可能 従来のアプローチ Prometheus (Metrics) + Jaeger (Traces) + Fluentd (Logs) → それぞれ別々に管理・運用が必要 OpenTelemetry OpenTelemetry SDK + Collector → 1 → つの構成で全てを一元化 データ間の相関関係も管理しやすい 11

標準化されたデータフォーマットとプロトコル OpenTelemetryは、単なるライブラリではなく、「可観測性の標準化を推進するプロジェク ト」 標準化の一例: データモデル: ログ、メトリクス、トレースの構造を定義 セマンティック規約: トレースやメトリクスで使用する属性キーと値のセットを定義 プロトコル (OTLP): データ送信の標準方式 W3C Trace Context: トレース伝播の標準 12

標準化のメリットと業界動向 標準化によって実現すること ツールの自由な選択: ベンダー依存を避け、事業的な観点、技術的な観点で技術選択の柔 軟性を維持 エコシステムの統合: 異なるツール間でも互換性が担保され、既存の仕組みを捨てる必要 がない 長期的な保守性: フォーマット等が標準化され、チームメンバーが入れ替わっても学習コ ストを抑えられる 業界の動き クラウドベンダー: Azure, AWS, GCPが正式サポート OSSツール: Jaeger, Zipkinが統合方向 言語エコシステム: 主要言語の公式サポート拡大 13

分散トレーシングの基本概念 トレース (Trace) 1つのリクエストの完全な経路を表現 一意のトレースIDで識別 スパン (Span) トレース内の個別の作業単位 各サービスの処理が1つのスパンに対応 開始時刻、終了時刻、メタデータを持つ 親子関係 スパンは親子関係を持つ 親スパンIDで関連性を追跡 14

トレースの構造 https://opentelemetry.io/docs/concepts/observability-primer/#distributed-traces 15

• https://opentelemetry.io/docs/concepts/observability-primer/#distributed-traces

各スパンが持つ情報 基本プロパティ トレース ID: リクエスト全体を識別する一意識別子 スパン ID: 個々のスパンを識別する一意識別子 親スパン ID: 呼出し元のスパンを識別する一意識別子（ルートスパンの場合は存在しな い） スパン名: 処理の名前 開始時刻 / 終了時刻: 処理の実行時間 その他のプロパティ 属性（Attributes）、イベント（Events）、エラー情報など https://opentelemetry.io/ja/docs/concepts/signals/traces/#spans 16

• https://opentelemetry.io/ja/docs/concepts/signals/traces/#spans

{

}

"name": "/v1/sys/health",
"context": {
"trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d",
"span_id": "086e83747d0e381e"
},
"parent_id": "",
"start_time": "2021-10-22 16:04:01.209458162 +0000 UTC",
"end_time": "2021-10-22 16:04:01.209514132 +0000 UTC",
"status_code": "STATUS_CODE_OK",
"status_message": "",
"attributes": {
"net.transport": "IP.TCP",
"net.peer.ip": "172.17.0.1",
"net.peer.port": "51820",
"net.host.ip": "10.177.2.152",
"net.host.port": "26040",
"http.method": "GET",
"http.target": "/v1/sys/health",
"http.server_name": "mortar-gateway",
"http.route": "/v1/sys/health",
"http.user_agent": "Consul Health Check",
"http.scheme": "http",
"http.host": "10.177.2.152:26040",
"http.flavor": "1.1"
},
"events": [
{
"name": "",
"message": "OK",
"timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC"
}
]

https://opentelemetry.io/ja/docs/concepts/signals/traces/#spans

17

• https://opentelemetry.io/ja/docs/concepts/signals/traces/#spans

コンテキスト伝播とは サービス間・プロセス間でトレース情報を引き継ぐ仕組み トレース ID と親スパン ID の引き継ぎ HTTPヘッダーやgRPCメタデータなどのリクエストメタデータに含めて伝播 サービス間通信、プロセス間通信で次のサービスへ引き継ぐ これにより、リクエスト全体を1つのトレースとして追跡可能に W3C Trace Context 仕様に準拠 W3Cによって標準化されたトレース伝播の仕様 OpenTelemetryが生成するトレースID・スパンIDはこの仕様に準拠 異なるツール・ベンダー間でも互換性を保証 18

W3C Trace Context の実装 HTTPヘッダーでの伝播 traceparent: 00-{trace-id}-{parent-id}-{trace-flags} 実際のリクエスト例 GET /api/data HTTP/1.1 traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 trace-id: 0af7651916cd43dd8448eb211c80319c - リクエスト全体を識別 parent-id: b7ad6b7169203331 - 呼び出し元のスパンを識別 trace-flags: 01 - サンプリングフラグ（01=サンプリング対象, 00=対象外） 19

計装（Instrumentation）とは アプリケーションにテレメトリーデータを収集・送信する仕組みを組み込むこと 計装の種類 手動計装（Manual Instrumentation） 開発者がアプリケーションコードに OpenTelemetry のライブラリを組み込む テレメトリーデータを収集するためのコードを自分で追加 特定のビジネスロジックや重要な処理のトレースをカスタマイズ可能 自動計装（Auto Instrumentation） アプリケーションコードに手を加えずにテレメトリーデータを収集 ライブラリやフレームワークが OpenTelemetry に対応していれば利用可能 エージェント注入などにより自動的にテレメトリを収集 20

3. Azure における OpenTelemetry の活用 21

Azure における OpenTelemetry 活用のポイント 1. 計装（Instrumentation） OpenTelemetryをどう備え付けるか 自動計装（Auto Instrumentation） Azure Monitor OpenTelemetry Distro による手動計装 サービスと言語による使い分け 2. 可視化（Visualization） 収集したデータをどう活用するか Application Insights での分散トレース確認 エンドツーエンドトランザクションの可視化 アプリケーションマップによるシステム全体の把握 22

Azure Monitor の OpenTelemetry サポート 1. 自動計装（Auto Instrumentation） コード変更なしで計装を有効化 App Service、Functions で Java/Python に対応 エージェント注入により自動的にテレメトリを収集 2. Azure Monitor OpenTelemetry Distro (AzMon Distro) Microsoft が提供する 本家 OpenTelemetry SDKのカスタマイズ版 手動でコードに計装を追加 対応言語: .NET, Java, JavaScript (Node.js), Python きめ細かな制御と柔軟なカスタマイズが可能 https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/codeless-overview#supported-environments-languages-and-resource23 providers

• https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/codeless-overview#supported-environments-languages-and-resource-providers

Microsoft の OpenTelemetry ロードマップ https://techcommunity.microsoft.com/blog/azureobservabilityblog/making-azure-the-best-place-to-observe-your-apps-with24 opentelemetry/3995896

• https://techcommunity.microsoft.com/blog/azureobservabilityblog/making-azure-the-best-place-to-observe-your-apps-with-opentelemetry/3995896

ACA における OpenTelemetry サポート状況 自動計装はサポートされていないため、AzMon Distroを使用して手動計装する必要がある https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/codeless-overview#supported-environments-languages-and-resource25 providers

• https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/codeless-overview#supported-environments-languages-and-resource-providers

AzMon Distro が使用できる言語 ASP.NET Core .NET Java Node.js Python https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/app-insights-overview#manual-instrumentation 26

• https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/app-insights-overview#manual-instrumentation

Application Insights で分散トレーシ ングを確認する Azure Portal でのアクセス 1. Application Insights リソースを開く 2. 画面左のブレードから「調査」のセクション を選択 3. 「検索」または「アプリケーション マップ」 を選択 27

エンドツーエンドトランザクション リクエスト全体の流れと内訳を時系列的に可視化 28

エンドツーエンドトランザクション 各スパンにおける通信や処理時間、イベント（ログメッセージやエラー情報）などのメタデ ータが確認できる 29

エンドツーエンドトランザクション 一部のコンポーネントでエラーが発生した場合は、スパンが赤く強調される 30

エンドツーエンドトランザクション エラーのスタックトレースも確認できる 31

アプリケーションマップ システム全体のトポロジーや各サービスのパフォーマンス、エラー率が直感的に把握できる 32

アプリケーションマップ 一部のコンポーネントでエラーが発生した場合は、コンポーネントの枠線が赤く強調される 33

5. デモ & 実装ポイント 34

本デモのシナリオ コンテナと外部依存間でデータを伝播し、APMツ ールで分散トレーシングの結果を確認する 処理の流れ 1. checkout: 1分間隔で注文データを送信 2. order-processor: 注文データを処理 3. receipt: 領収書データを生成し、Azure Storage に保存 同期通信による処理 各コンテナアプリは同期的に通信するため、 checkout のレスポンス時間には、後続の全処 理時間が含まれる 35

システム構成 36

本デモで使用するリポジトリ Azure Developer CLI (azd) を使用して、リソースの作成からテレメトリーデータの可視化ま で一気に構築できます。 https://github.com/Be3751/aca-otel-tracing 37

• https://github.com/Be3751/aca-otel-tracing

アプリケーションをデプロイして観測してみる 38

Python コード実装のポイント 必要なパッケージ azure-monitor-opentelemetry をパッケージに追加する https://pypi.org/project/azure-monitor-opentelemetry/ 39

• https://pypi.org/project/azure-monitor-opentelemetry/

Python コード実装のポイント 初期化コード これだけで： 受信したHTTPリクエストからトレースコンテキストを抽出 送信するHTTPリクエストにトレースコンテキストを注入 スパンの親子関係を自動的に構築 from azure.monitor.opentelemetry import configure_azure_monitor configure_azure_monitor() 40

Python コード実装のポイント 環境変数の設定 各アプリケーションに共通して設定する環境変数 環境変数名 説明 Application Insights の接続文字列 Azure Monitor OpenTelemetry Distro の APPLICATIONINSIGHTS_CONNECTION_STRING OTEL_SERVICE_NAME セットアップ用の関数の呼び出し時に使 用 アプリケーションのサービス名 Application Insights のアプリケーション マップでノードとして表示される 41

Python コード実装のポイント 計装コード例：エラーハンドリングしてスパンをカスタマイズする場合 tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("Request parent span") as span: try: # Requests made using the requests library will be automatically captured response = requests.get("https://azure.microsoft.com/", timeout=5) # Set the OTEL_PYTHON_EXCLUDED_URLS environment variable to "http://example.com" # This request will not be tracked due to the excluded_urls configuration response = requests.get("http://example.com", timeout=5) logger.warning("Request sent") except Exception as ex: # If an exception occurs, this can be manually recorded on the parent span span.set_attribute("status", "exception") span.record_exception(ex) 42 https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/monitor/azure-monitor-opentelemetry/samples/tracing/http_requests.py

• https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/monitor/azure-monitor-opentelemetry/samples/tracing/http_requests.py

6. まとめ 43

まとめ：OpenTelemetry による分散トレーシング 分散システムの課題を解決 モノリシックから分散システムへの移行で、1つのリクエストの全体像把握が困難に ログやメトリクスだけでは、サービス間の関係性や因果関係が見えない OpenTelemetry が提供する価値 標準化された可観測性: CNCF 標準により、ツールの自由な選択とベンダーロックイン回 避 W3C Trace Context: HTTPヘッダーでトレースIDを伝播し、サービス横断でリクエス トを追跡 トレース・メトリクス・ログの統合: 1つのSDKで全てのテレメトリーデータを収集 柔軟な計装方法: 自動計装と手動計装を使い分け、要件に応じた実装が可能 44

まとめ：Azure における OpenTelemetry の活用 Azure Monitor の OpenTelemetry サポート 自動計装: App Service、Functions で Java/Python に対応（コード変更不要） Azure Monitor OpenTelemetry Distro: .NET、Java、Node.js、Python で利用可能な 手動計装 Azure Container Apps: 現時点では AzMon Distro による手動計装が必要 Application Insights による可視化 エンドツーエンドトランザクション: リクエスト全体の流れを時系列で可視化、エラー箇 所を即座に特定 アプリケーションマップ: システム全体のトポロジーとパフォーマンスを直感的に把握 45

ご清聴ありがとうございました！ 分散トレーシング、OpenTelemetryにトライしてみましょう！ 46