AWS Distro for OpenTelemetry で実現するエンドツーエンドの可観測性
参考になった
1
株式会社kubell / 山本大輔
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2025年5月 | B to B |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2025年5月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
本構成では、OpenTelemetry を採用しつつ、AWS 環境との親和性を最大化するために AWS Distro for OpenTelemetry（ADOT）を Collector として採用した。
ECS Fargate 環境では、タスク単位で Collector をサイドカー起動させ、API コンテナからのトレースデータを直接 X-Ray に送信する設計とした。
Amplify でホストされる Next.js 側では SSR 部分までが Amplify Managed な環境となるため、API 層まで引き継ぐようにカスタムミドルウェアを挟み、リクエスト全体のトレース一貫性を担保した。
フロントエンド（Amplify）:
- Amplify の制約により、トレーシングとログの完全な紐付けは困難だが、トレーシング データ自体は取得可能になった
ADOT Collector の設定:
- OTLP プロトコルで gRPC（4317）と HTTP（4318）の両方に対応した
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- AWS Amplify でホスティングしているフロントエンドと Render（Next.js）、ECS で動作するバックエンドの連携が可視化されていなかった
どのような状態を目指していたか
- リクエストのフロー全体を可視化し、ボトルネックを特定できる状態にした
- AWS サービス（X-Ray、CloudWatch）との統合により、一元的な監視体制の確立した
- フロントエンドからバックエンドまでのエンドツーエンドのトレーシング実現した
- 開発環境から本番環境まで一貫したトレーシング基盤を構築した
比較検討したサービス
- AWS X-Ray SDK（直接使用）
- AWS Distro for OpenTelemetry (ADOT)
- SaaS 型 APM
比較した軸
- AWS サービスとの親和性（特に X-Ray、CloudWatch との連携）
- Next.js アプリケーションへの実装容易性
- ECS での運用のしやすさ（Sidecar パターンのサポート）
- ローカル開発環境での動作確認の可能性
選定理由
- AWS サービスとの統合が容易: ADOT は AWS が提供する OpenTelemetry ディストリビューションで、CloudWatch との連携が最初から考慮されていた
- OpenTelemetry 標準への準拠: 将来的な SaaS 型 APM への移行の柔軟性を確保できた
- ECS での運用性: Sidecar パターンで簡単にデプロイでき、ヘルスチェックも実装しやすかった
導入の成果
改善したかった課題はどれくらい解決されたか
- フロントエンド・バックエンド間の連携が可視化: X-Ray のサービスマップにより、リクエストフロー全体が一目で把握可能になった
どのような成果が得られたか
- CloudWatch と X-Ray の統合により、メトリクスとトレーシングを一元管理できる体制を確立した
導入時の苦労・悩み
- Amplify の制約: サポートに確認したところ、公式ドキュメントで APM の対応有無・プラクティスについては公開されている情報は存在せず、Amplify 管理下の Lambda 関数では Layer の追加に制約があった。（2024年12月時点）
- IAM Policy の設定: ADOT Collector が X-Ray や CloudWatch と連携するため、IAM ポリシーは最小権限設計を行い、CDK に定義して再利用可能にした
- 設定ファイルの最適化:
config.yamlでヘルスチェックやエクスポーターを適切に設定するまでに調整が必要だった
導入に向けた社内への説明
上長・チームへの説明
- 問題提起: 現状のパフォーマンス問題の原因特定に時間がかかっており、調査効率が低下していることを具体例とともに説明した
活用方法
- パフォーマンス監視: X-Ray のサービスマップを確認し、レスポンス時間の異常を検知した
- デバッグ: エラー発生時にトレース ID を特定し、リクエストの流れを追跡した
よく使う機能
- OTLP プロトコル対応: 標準的な OpenTelemetry プロトコルで、Next.js から簡単にトレースを送信した
- X-Ray 統合: AWS X-Ray のサービスマップやトレース詳細画面で、視覚的に問題を把握した
ツールの良い点
- AWS サービスとの親和性: X-Ray や CloudWatch との連携が非常にスムーズで、既存の AWS 基盤に自然に統合できた
- OpenTelemetry 標準準拠: ベンダーロックインを避けつつ、将来的な選択肢を確保できた
ツールの課題点
- Amplify Managed の制約: Lambda の設定が変更できないため、フロントエンドのトレーシングとログの完全な紐付けが困難だった。（2024年12月時点）サポートの回答は以下の通り。
現状ではサポートされず、X-Ray トレース情報とログを紐づけてご参照いただくことができないものとなります。 [1] (#3062) X-Ray Support for NextJs Applications · Issue #3515 · aws-amplify/amplify-hosting · GitHub https://github.com/aws-amplify/amplify-hosting/issues/3515
ツールを検討されている方へ
- ローカル環境で試す: Docker で ADOT Collector を起動し、ローカルで動作確認してから本番環境に適用することをお勧めする
- 公式ドキュメントを活用: Next.js の公式ドキュメントに OpenTelemetry の実装例があるので、そこから始めるとスムーズだと思う
- 制約を理解する: Amplify など、管理されたサービスを使用している場合は、事前に制約を確認することが重要だと思う
今後の展望
- ログとの統合: 可能な範囲でトレース ID をログに含め、トレーシングとログの相関をより強化にすることを検討している
株式会社kubell / 山本大輔
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
株式会社kubell / 山本大輔
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法