オブザーバビリティの設計 CloudWatch RUMとX-Rayでユーザー体験を可視化する

本記事はDOP(DevOps Engineer Professional)を目指す方向けに、アプリケーションの内部と利用者側の両面から状態を可視化するオブザーバビリティ設計を解説します。試験では、障害の切り分けに必要な情報をどのサービスで収集するかを選ぶ力が問われます。

覚え方のフレームは3つの観点です。視点(サーバー側かブラウザ側か)・追跡(1件のリクエストを追う)・集約(横断的に可視化する)。

視点 CloudWatch RUMでブラウザ側を見る

CloudWatch RUM(Real User Monitoring)は実際の利用者のブラウザにJavaScriptを組み込み、ページの読み込み時間やJavaScriptエラー、地域ごとの体験差を収集します。サーバー側のメトリクスは正常なのに、一部の利用者から表示が遅いと申告があるような要件ではRUMで実際のブラウザ側の挙動を確認します。

追跡 X-Rayで1件のリクエストを追う

X-Rayはリクエストが複数のサービス(API Gateway、Lambda、DynamoDBなど)を通過する経路をトレースとして記録し、どのサービスで遅延やエラーが発生したかをセグメント単位で特定できます。マイクロサービス構成でどのコンポーネントがボトルネックかを特定したい要件で選びます。

集約 CloudWatchダッシュボードとアラーム

RUMとX-Rayのデータもメトリクスとしてダッシュボードに集約でき、しきい値超過時にはCloudWatchアラームからSNS通知やEventBridge経由の自動対応につなげられます。ユーザー体験の劣化を検知したら自動でオンコール担当に通知したい要件ではこの組み合わせを使います。

チェックリスト

• CloudWatch RUMが収集する情報の種類を説明できる
• X-Rayのトレースとセグメントの関係を説明できる
• RUMとX-Rayを併用する典型シナリオを説明できる
• アラームから自動対応につなげる構成を説明できる

まとめ

オブザーバビリティは「視点・追跡・集約」の3観点で捉え、RUMで利用者側、X-Rayでシステム内部を可視化し、アラームで自動対応につなげるのが定石です。この記事の理解度はクイズで確認し、最新の試験範囲はAWS認定 公式ページで確認しましょう。