ある企業が AWS 上で Amazon EKS クラスターを運用しています。クラスターには数百のマイクロサービスがデプロイされており、障害発生時に原因特定に時間がかかるという問題があります。現在は各マイクロサービスのログが CloudWatch Logs に個別に送られていますが、サービス間のリクエスト追跡（分散トレーシング）ができておらず、ボトルネックのサービスを特定することが困難です。最も効果的な可観測性改善策はどれですか？
- A. すべてのマイクロサービスのログを Kinesis Data Firehose で S3 に保存し、Athena で後からログを分析する
- B. Kubernetes の kubectl top コマンドでリソース使用率を定期的に確認し、問題のあるノードを手動で再起動する
- C. 各マイクロサービスにカスタムロギングコードを追加し、相関 ID を手動でリクエストヘッダーに伝播させる
- D. AWS X-Ray を EKS クラスターに統合し、X-Ray デーモンを DaemonSet としてデプロイする。Amazon CloudWatch Container Insights を有効化してコンテナレベルのメトリクスを収集し、CloudWatch Logs Insights でログの横断検索を行う。AWS Distro for OpenTelemetry（ADOT）コレクターを使ってトレースとメトリクスを標準化する
解答と解説を見る
正解: D
X-Ray は分散トレーシングを提供し、マイクロサービス間のリクエストフローを可視化します。X-Ray デーモンの DaemonSet デプロイにより、コードの最小限の変更でトレース収集が可能です。CloudWatch Container Insights はコンテナとポッドレベルのメトリクスを提供し、ADOT でのメトリクスとトレースの標準化で OpenTelemetry エコシステムとの互換性も確保できます。 C: 手動での相関 ID 伝播は開発負荷が高く、すべてのサービスに実装するには時間がかかります。標準化されたトレーシングフレームワークを使う方がはるかに効率的です。 B: kubectl top は基本的なリソース確認に有効ですが、分散トレーシングやアプリケーションレベルのボトルネック特定には不十分です。手動での再起動は根本原因の解決になりません。 A: S3 + Athena でのログ分析は事後分析に有効ですが、リアルタイムの障害診断や分散トレーシングには対応しておらず、原因特定の時間短縮には効果が限定的です。
📚 関連サービスの解説: AWS X-Ray ・ Amazon EKS