「いつ」はCloudWatch、「どこで」はX-Ray。役割の違いを整理した

おはようございます、YASUです。

Step Functionsで複数のLambda関数を連携させる話をしましたが、こうして処理が複数のサービスにまたがるようになると、新しい悩みが出てきます。「結局、どこで処理が遅くなっているのか」が分かりにくくなるという問題です。今日は、それを可視化してくれるX-Rayについて整理します。

結論

CloudWatchが「いつ異常が起きたか」を教えてくれるのに対し、X-Rayは「どこで異常が起きたか」をピンポイントで教えてくれるサービスでした。複数のLambda関数やAPI Gateway、DynamoDBをまたいだ一連の処理を、1本の線として追跡できる点が、これまで見てきたどのサービスとも違う特徴です。

なぜ「どこで遅いか」が分かりにくくなるのか

これまでLambda、API Gateway、Step Functionsと見てきましたが、実際のアプリケーションでは、1つのリクエストがこんな風に複数のサービスをまたいで処理されます。

ユーザーのリクエスト
  → API Gateway
    → Lambda(注文確認)
      → DynamoDB(在庫チェック)
    → Lambda(支払い処理)
      → 外部の決済サービス
    → Lambda(通知送信)

もし「レスポンスが遅い」という問題が起きた時、CloudWatchのログだけを見ても、どのサービスのどの処理が遅延の原因なのかを特定するのは、かなり骨が折れます。それぞれのサービスのログを個別に見比べて、時間を頼りに手作業で繋ぎ合わせる必要が出てきます。

X-Rayがやっていること:1本の線として繋げる

X-Rayは、こうしたバラバラに見える処理を「トレース」という1本の線として繋げて可視化してくれます。仕組みを分解すると、3つの階層になっています。

この階層構造のおかげで、「どのサービスが」だけでなく「そのサービスの中の、どの処理が」時間を食っているのかまで、掘り下げて確認できます。

CloudWatchとの役割分担

調べていて一番腑に落ちたのが、この対比でした。

実務では、まずCloudWatchで「エラー率が上昇した」という異常を検知し、その後X-Rayで「具体的にどのサービスの、何ミリ秒の処理が遅いのか」を掘り下げる、という2段階の流れが標準的な使い方とされていました。これまで個別に見てきたサービス(Lambda、API Gateway、DynamoDBなど)の監視は、X-Ray単体ではなく、CloudWatchとの組み合わせで初めて実用的になる、という理解です。

サービスマップという、視覚的な地図

X-Rayは、トレースデータをもとに「サービスマップ」という図を自動生成してくれます。各サービスが四角いノードとして表示され、どのサービスからどのサービスへリクエストが流れたか、矢印で繋がれて見える仕組みです。各ノードには処理時間やエラー率も表示されるため、「このLambda関数だけ、やけに時間がかかっている」といった異常箇所を、一目で見つけやすくなっています。

Step Functionsとの組み合わせ

前回紹介したStep Functionsで複数のLambda関数を連携させている場合、どのステートで時間がかかっているのかを把握するのにも、X-Rayが役立ちます。ステートマシンの定義上は「次はこの処理」と繋げているだけですが、実際にどこがボトルネックになっているかは、X-Rayのトレースを見て初めて分かる、という関係性になっています。

試験で問われそうなポイント

この分野は「何のためのサービスか」という目的の違いを問う問題が多そうだと感じました。CloudWatch LogsやCloudWatch Alarmsと、X-Rayの役割を混同してしまうと、「障害の検知」と「原因箇所の特定」という、本来別のフェーズの話を取り違えてしまいます。「異常に気づく」のがCloudWatch、「原因を突き止める」のがX-Ray、という住み分けを意識しておくと、迷わず判断できそうです。

まとめ

Lambda・API Gateway・Step Functionsとバラバラに学んできたサービスが、X-Rayという「全体を横断して見る視点」で改めて繋がった感覚がありました。それでは、また明日!