SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は、Amazon ECS（Fargate）上で複数のマイクロサービスから成る注文処理アプリケーションを運用しています。フロントのサービスがバックエンドの在庫・決済など複数の下流サービスをHTTPで呼び出す構成です。特定の時間帯にエンドツーエンドのレスポンスが断続的に遅くなりますが、どのサービス間呼び出しがボトルネックか特定できていません。最小の追加開発で、リクエスト単位に各セグメントの所要時間を可視化したいと考えています。
A各サービスのアプリケーションログをCloudWatch Logs Insightsで集計し、リクエストIDごとに開始・終了のタイムスタンプ差分を計算して遅延の大きい区間を推定する
ログのタイムスタンプ差分でも近似はできますが、複数サービスをまたぐリクエストの相関付けやセグメント分解を自前のクエリとログ設計で実装する必要があり、追加開発が大きく可視化の粒度も限られます。
BAWS X-Rayを有効化してSDK／サイドカーで各サービスを計測し、サービスマップとトレースで下流呼び出しごとのセグメント所要時間から遅延箇所を特定する
✓ 正解
トレースID単位でサービス横断の呼び出しをセグメントとして記録し、サービスマップと個別トレースで下流呼び出しごとの所要時間を直接可視化できます。ECSではSDKやOTELサイドカーの追加のみで導入でき、最小の追加開発でボトルネックを特定できます。
CCloudWatch Container Insightsを有効化し、各タスクのCPU・メモリ使用率とネットワークメトリクスの時系列から遅延が発生しているサービスを絞り込む
Container Insightsはタスクのリソース使用率やネットワーク量を示すインフラ監視で、飽和の兆候把握には有用ですが、リクエスト単位の各サービス間呼び出しの所要時間内訳は取得できず、遅延区間を直接特定できません。
DALBのTargetResponseTimeとHTTPCodeメトリクスをターゲットグループ別に監視し、応答時間が長いターゲットグループを遅延の発生源として特定する
ALBのTargetResponseTimeはターゲットグループ単位の応答時間しか示さず、フロント配下で行われる複数の下流サービス呼び出しの内訳には分解できません。ボトルネックのサービス間呼び出しを一意に特定できません。
解説
AWS X-Rayは分散トレーシングにより、1リクエストが複数サービスを横断する経路をトレースID単位でつなぎ、各サービス・各下流呼び出しをセグメント／サブセグメントとして所要時間を記録します。
サービスマップで遅延やエラーの多いノード・エッジを視覚的に把握でき、個々のトレースでどの呼び出しが遅いかを直接特定できます。ECSではX-Ray SDKやOpenTelemetryサイドカーで最小限の計測を追加するだけで導入できます。
選択肢のLogs Insightsでのタイムスタンプ差分は、サービスをまたぐ相関付けを自前で実装する必要があり手間が大きいです。
選択肢のContainer Insightsはリソース使用率の監視であり、呼び出し単位の遅延内訳は分かりません。
選択肢のALBメトリクスはターゲットグループ全体の平均応答時間しか示さず、下流サービス間の呼び出し内訳までは分解できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →