labolの川村です
皆さんは自分たちのシステムでモニタリングはされてますか？ おそらく大抵の場合システムのモニタリングが実施されていることでしょう。
外形監視やCPU/メモリなどのリソース監視などたくさん監視対象があり、アラート設定なども数多くされていると思います。
今回は上記のようなシステム中心のモニタリングではなく、ユーザー中心の「リアルユーザーモニタリング」について話していきます。
labolではAWS CloudWatch RUMを用いてリアルユーザーモニタリングを実施し日々改善を行っています。
リアルユーザーモニタリングとは？
一般的にリアルユーザーモニタリング（以下RUM）は、 サービス上での実際のユーザーの行動を追跡・分析する手法になります。イメージ的にはGoogle Analyticsと近しい感じです。
RUMは、ユーザーWebサービスをどのように利用していて、
「どれくらい快適に使えているか？」
を把握するために使われます。
どれくらい快適に使えているか？というのは様々な情報を測定しながら総合的に判断していきます。これはサービスの特性や組織が重要視しているところを考慮してチームで考えていくのがいいかと思います。
ちなみにRUMではApdexスコアという業界標準も計測できます（The Apdex Users Group）。 これは「ユーザー満足度」を測定するための指標です。
New Relicで例があったので軽く触れておきます。
以下3つの分類を設け、
- 満足
- 許容範囲
- 不満
「1リクエストあたり500ms以内にレスポンスが返却されたら満足」とするようなApdexスコアだったとします。 そうした場合、リクエストは以下のように分類がされます。
| レベル | 条件 | 時間（T = 0.5秒） |
|---|---|---|
| 満足 | T以下 | 0.5秒以下 |
| 許容可能 | Tを超過し、4T以下 | 0.5～2秒 |
| 不満 | 4Tを超過 | 2秒を超える |
このような分類をして、各リクエストを測定していくことで、サービスを利用しているユーザーの満足度指標が測れる言った感じです。
これはApdexだけの話ですが、他にもツールによって様々な計測対象があると思うので、測りたいサービスに合わせて選んでいくのが良さそうです。
何にせよRUMで得られる情報は、問題を早期に発見したり、パフォーマンスを最適化したり、ユーザー体験を向上させるのにいい手がかりとなると思います。
AWS CloudWatch RUMについて
labolではAWS CloudWatch RUMを使用しています。
CloudWatch RUMでモニタリングできる代表的なものとして以下があります。
- HTTPエラー
- どのなhttp status codeのエラーがいつ、どのリクエストで発生しているか？
- JSエラー
- どんなJSエラーがいつ、どのページで発生しているか？
- パフォーマンス
- ロード時間はどのくらいか？どの日付曜日時間帯で遅くなるか？など
- ※今回深く触れません
もちろんApdexの計測もできます。 ちなみにCloudWatch RUMのApdexスコアは緩めで、「2000ms」以下を満足と置いているようです。
以下よりHTTPエラーとJSエラーについて少し踏み込んでみてみます。
HTTPエラー
ちょっとhttp status 400のエラーについて考えてみます。 400エラーはユーザーの入力によるものが多く、想定内のエラーの場合が多いです。400が出たらbackendから適切なエラーメッセージを返し画面に表示していることでしょう。
通常ユーザーの入力誤りのケースが多いので、ここをモニタリングすることはあまりないんじゃないかと思います。
「適切なエラーメッセージを返しているから、ユーザーはそのメッセージに従って入力内容を変えるだろう」
と思っている人もいるかも知れませんが、果たしてそんな呑気なことを言ってられるでしょうか？実はやぱい400エラーかもしれません。
例えば、フロントエンドのバグがあり、ユーザーの入力値が必ず400エラーになるように書き換えられていたとしたら、どうでしょう。ゾッとしますよね。
これでは、ユーザーからの問い合わせが来て、初めて気づくことになります。
400だからユーザーの入力の問題と決めつけず、バグの可能性も考慮して計測しておくのが良いかと思います。
CloudWatch RUMではhttp statusのエラーを「HttpStatusCodeCount」というメトリクスで計測できます。
これで時間ごとや日ごと件数を予め計測し、異常な件数エラーが発生していればバグを疑うと良さそうです。
まあこれはbackend側のモニタリング（nginxとかのログ）で分かるでもありますが、ログからstatus codeを引っ張り出して集計するメトリクスフィルターを作るのも少し手間なので、CloudWatch RUMを使うのがおすすめです。
あと、web serverのログとかであればユーザー以外のAPIリクエスト（webhookとか）のログも来ちゃうので、リアルユーザーモニタリングとしては使い勝手が悪いかと思います。
JSエラー
http statusエラー以外でフロントエンドで発生するエラーとしては、JSエラーが多いですね。
ユーザーごとに使用するネット環境やブラウザ、デバイスなどが異なるため、これは通常のモニタリングでは計測するのはなかなか難しいです。
CloudWatch RUMではどういうJSエラーが発生したのか、詳細情報やエラーメッセージも確認することができ、特定環境下でのバグを発見することが容易になります。
HTTPエラーとJSエラーについて見てきましたが、パフォーマンスについては今回は触れません。 また、上記以外にもGoogle Analyticsで閲覧できるような情報やWebバイタルなども閲覧することが可能です。
サービス改善に活かす
最後にlabolでCloudWatch RUMを使ってどのようにサービス改善を行っているかを紹介します。
CloudWatch RUMはJSコードをサイト上に埋め込むだけで直ぐにデータ収集出来るようになるのですが、
まず想像以上のエラー件数にびっくりすると思います。
想定していないエラーもあると思いますが、既知のエラー（ブラウザ依存だったり、http status 400などの想定しているもの）が数多く存在します。
自分はSidekickというブラウザを使っており、色々なjs、通信をblockしているので、dev consoleはエラーだらけです。こんなのは残念ながら解決できません。
まずはエラーの大掃除
既知のエラーが多いと想定していないエラーが埋もれてしまうので、 知りたいエラーを検知しやすくするために「既知のエラー」、「修正可能なエラー」をなくしていきましょう。
かなり多く骨が折れる作業かとは思いますが、地道に進めていきます。
ある程度件数が減ってきたら、見るべきものが見えるようになってくると思うので、そうなれば次のステップに進みます。
CloudWatch アラームを設定
CloudWatch RUMにはいい感じのメトリクスが用意されているので、それらを使ってアラームを作成していきます。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-metrics.html
- HttpStatusCodeCount
- JsErrorCount
この辺が利用しやすいかと思います。
上記のメトリクスを到底期間の合計数や平均数でアラームが発火されるように作ります。
これはサービスの特性や測りたい場所によって異なると思うので、色々ためしてみてください。
- 日毎
- 時間毎
- 時間帯毎
- 曜日毎
- 月初、月末
- 業務時間中、外
- 平日、休日
切れる期間はたくさん考えられます。
フロントエンド側のバグが発生して、 ユーザーがそれに対して操作ができないから、何度も同じ操作を繰り返したりするとしたら、 短期間にエラーカウントが跳ね上がると思います。
そうなった場合は短期間で〇〇件数以上などのアラームを設定しておくと、バグ検知に有効かと思われます。
またCloudWatchの異常検出もとても有効な手段かと思われます。
これはざっくりいうと、以下のようなアラーム設定です。
- 今までのエラー発生の推移を学習
- 今後は「こんな感じで推移していくだろう範囲」
- 「こんな感じで推移していくだろう範囲」をはみ出るとアラーム発火
今回はリアルユーザーモニタリングとCloudWatch RUMを紹介しました。
CloudWatch RUMに関しては他にもたくさん機能があるので、いずれ紹介していきます。
またCloudWatch RUMのいとこ的なCloudWatch Syntheticsというサービスも今後紹介していきますのでお楽しみに By モニタリング頑張り隊
ちなみにCloudWatch Syntheticsはユーザーからは離れ外形監視要素が強くなったモニタリングサービスです。
最後に
ラボルでは、エンジニアを積極採用中です。1、2年目のエンジニアから経験豊富なテックリードやエンジニリングマネージャーまで、興味がある方はぜひご応募ください!!
