はじめに
みなさん、フロントエンドの監視ってどうしてます？
「バックエンドはCloudWatchでエラーログ見てるからヨシ！」
「外形監視で毎朝チェックしてるから大丈夫！」
…本当に大丈夫ですか？
アラートがなくても、メトリクスが調子良くても 「なんか特定の回線だと遅くない？」「Chromeだと動くけどSafariだと死んでる」 みたいな特定ユーザーの手元でだけ起きている問題って、実は結構あるんじゃないかと思ってます。
そんな見えない問題を救ってくれるのが、Amazon CloudWatch RUM (Real User Monitoring) です。
今回は、この「ユーザーのリアルな体験」を確認できるCloudWatch RUMについて、Google Analyticsとの違いや、どう使うの？というところまで紹介します。
CloudWatch RUM とは？
Real User Monitoring (RUM) は、文字通り「実ユーザー」のブラウザから直接データを引っこ抜いてくる監視手法です。
よくある外形監視との違いはこんな感じです。
| CloudWatch RUM | CloudWatch Synthetics | |
|---|---|---|
| 情報のトリガー | 今アクセスしてる生身の人間 | 定期的に走らせるBot |
| 範囲 | 全ユーザーの多様な環境 (OS/回線/端末) | 決められたシナリオ・環境 |
| 得意領域 | 体感速度、環境依存バグ | 死活監視、いつもの性能チェック |
外形監視とはちょっと観点が違い、本当のユーザーの問題をRUMならチェックできるんです。
「Google Analytics入れてるから良くない？」
「アクセス解析ならGAあるし、わざわざRUM入れる意味ある？」と言われたことがあるのですが
同じようなサービスだと誤解されてますが、実は結構別物のサービスなんです。
| Google Analytics | CloudWatch RUM | |
|---|---|---|
| 主な対象ロール | マーケター、PdM | エンジニア、SRE |
| 目的 | 「ユーザーが何をしたか」 (CV、離脱) | 「ユーザーがどう感じたか」 (重い、エラー) |
| アクション | 広告費の調整、LP改善 | ボトルネック特定、バグ修正 |
GAは「ボタンが押された回数」は教えてくれますが、「ボタンを押してからAPIが返ってくるまでの秒数」や「その時発生したJSのスタックトレース」はデフォルトでは教えてくれないのです。
開発現場で役立つ使い道
じゃあ具体的にどう使うのよ？と思いますよね。個人的におすすめなのがこの2つです。
「なんか遅い」の犯人探し
「サイトが重い」って言われた時、一番困りません？
フロントのレンダリングが遅いのか、画像がデカすぎるのか、APIが返ってこないのか…。
RUMを使うと、ロード時間を「DOM処理」「リソースDL」「API待ち」みたいに分解して見せてくれます。「なんだ、犯人は3MBの画像じゃん！」って即答できるようになります。
「私のPCでは動くんですけど」問題にさようなら
営業「お客さんの環境だと動かないらしいです」
開発者「えー、こっちだと再現しないけどなー」
これ、結構開発あるあるじゃないですか？
RUMならエラーが出た端末のOS、ブラウザ、バージョンが全部見えます。「特定OSのブラウザバージョンだけで起きてるバグか...」このようなことが起きた場合も気づけるかもしれませんよ？JSのエラーログもそのまま見ることができますし。
【実践】導入は簡単で一瞬で終わる
導入は拍子抜けするくらい簡単です。2ステップで終わります。
ステップ1：モニター作成
- AWSコンソールで [CloudWatch] から [RUM] を開く
- 「アプリケーションモニターを追加」をクリック
- ドメイン名（例:
example.com）を入れる- 開発中に試すなら
localhostも入れとくと吉
- 開発中に試すなら
- 設定はだいたいデフォルトでOK
- Amazon Cognito のIDプール周りは「新しいIDプールを作成」にしとくと、権限周りを勝手にやってくれるので楽です
- Amazon Cognito のIDプール周りは「新しいIDプールを作成」にしとくと、権限周りを勝手にやってくれるので楽です
ステップ2：コードスニペットを貼る
モニターを作ると、コードスニペットが表示されます。
これをアプリに貼るだけで導入完了です！
※もちろん、npmパッケージ (aws-rum-web) を使った導入も可能です。
これだけで、アクセスがあるたびに勝手にAWSにデータが飛び始めます。
【Tips】Terraformで構築する場合のハマりポイント
もしコンソールではなく、TerraformなどのIaCで構築する場合は一点だけ注意が必要です。
Cognito Identity Poolの設定で 「認証されていない ID」へのアクセス許可 を必ず有効にしてください。 RUMはログイン前のユーザーも含め、不特定多数のブラウザからデータを送る仕様のため、これがないと権限エラーになります。
既存のCognitoを流用しようとすると設定変更が必要になる場合があるため、RUM専用のCognitoの作成もご検討ください！
ダッシュボードで何が見える？
データが溜まるとこんな感じで見えてきます。
パフォーマンス
「大半の人は2秒で見えてるけど、下位10%の人は6秒かかってるな…」みたいな分布が見えます
エラー
JSのエラーログ一覧。Source Mapを上げておけば、元のソースコードの行数まで分かります。すごい！
※Source Mapとは？
ブラウザで動いているコードと開発時に書いた元のコードを紐づけるもの
これをS3にアップロードし、設定しておくとエラー発生時に難読化されたコードを元のコードに復元して表示してくれます。AWSの参考外部リンク
ブラウザとデバイス
「えっ、Chrome Headlessからアクセスあるの！？」みたいな発見があったり
モニタリング
ここで、Latencyをスコアで確認する事が出来ます。改善が必要であることを教えてくれたりしますよ！
...こんな風にね！
「導入して終わり」にしないための運用フロー
うちの現場でもRUM入れて満足しちゃうということがあったので、普段の開発にどう組み込むか？という話も書いておきます。
リリース直後の正常性チェック
新たな機能をリリースした後、実はフロントで特定の環境だけ問題が起きてるかもしれません。
リリース直後はRUMを見て、「急にJSエラー増えてないか？」「HTTPエラー率上がってないか？」をチェックするとサイレント障害を防げるかも？
パフォーマンスチューニングのきっかけ
「とりあえず速くしたい」だと何からやっていいか分からないので、RUMを見ます。
- 一番アクセスが多いページ はどこ？
- その中で 表示速度が一番ヤバい のはどれ？
- 原因は 画像？ API？
などボトルネックになっている箇所を特定するきっかけになります。
X-Ray連携
今後自プロジェクトでも実施したいのですが、
RUMの設定で「X-Rayトレース」をONにできます。
そうするとフロントのリクエストにトレースIDが付いて、バックエンドのX-Rayと繋げる事が出来ます。
「ボタンをクリック」→「API Gateway」→「Lambda」→「DynamoDB」
この一連の流れが1つの画面で見えるようなるとのこと！
「遅いのはDBじゃなくて、Lambdaのコールドスタートだ！」みたいな事が分かるようになればかなり便利だなぁと期待してます。
まとめ
CloudWatch RUM、無料枠もあるので試してみてはいかがでしょう？
とはいえ、かなりアクセスのあるサービスに導入した場合は、料金が馬鹿にならないためセッションサンプリングを利用して取得するログの量を減らして運用するのが良いでしょう。
「ユーザーのために品質上げたい！」と思ってるエンジニアの皆さん、まずはスニペット貼ってみてはいかがでしょうか。
「えっ、私のアプリ、こんなにエラー吐いてたの…？」って驚くかもしれません。