フロントエンド監視の全体像と実現方法
必要性
フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。
バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。
それは計算リソースをサービス提供側が管理していないことです。
例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。
これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。
一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。
フロントエンドはその性質上、監視の「盲点」になりがちです。
しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。
マイルストーン
フロントエンドの監視には複数のマイルストーンがあると考えています。
一部はバックエンドやインフラとも共通ですが、固有の観点もあります。
- 正常に動作することを監視する
- 素早く動作することを監視する
- 快適に動作することを監視する
1.では例外が投げられていないなど開発者が意図していない挙動を監視します。
一般的なエラー監視に該当します。
2.はパフォーマンスの監視です。
フロントエンドではページのロード時間などを監視します。
3.では UX を監視します。
誤クリックなどのユーザがストレスを感じる要素を監視します。
SaaS を利用する
ここからは各マイルストーンを達成していくための方法を順に見ていきます。
基本的には『入門 監視』で述べられている監視のデザインパターンに則り、SaaS を利用します。
今回調査した SaaS は以下の 3 つです
- Datadog
- New Relic
- Sentry
エラー監視
フロントエンド JS の例外監視は 3 つの SaaS 全てが対応しています。
ソースマップ
いずれの SaaS も minify されたスタックトレースを読むためにはソースマップをアップロードする必要があります。
セッションリプレイ
フロントエンドに限らずエラー監視をしていると、エラーの原因となった操作が分からず調査が進まないという状況に陥ることがあります。
フロントエンド監視にはユーザの操作を再現するセッションリプレイという概念があります。
セッションリプレイには 3 つの SaaS 全てが対応しています。
カスタムログ
自由にログを出力できると、例外以外のエラーや調査で必要になる情報を監視でき自由度が上がります。
ブラウザのカスタムログには Datadog と Sentry が対応しています。
New Relic はカスタムログには対応していませんが、ブラウザ用の API を利用することで例外以外のエラーも監視することができます。
カスタム属性にログレベルを指定する運用でカスタムログに近いことは実現できます。
パフォーマンス監視
RUM と Synthetic Monitoring
フロントエンドのパフォーマンス監視には RUM と Synthetic Monitoring があります。
RUM (Real User Monitoring) はエンドユーザの実際の操作を監視するものです。
そのためエンドユーザに配信するスクリプトに監視のためのコードを追加し、データを SaaS に送信することになります。
実際のユーザの操作を監視できるのが強みですが、逆にユーザの環境に依存したデータを収集することになります。
Synthetic Monitoring ではテスト環境を用意し、ツールやスクリプトで人工的なアクセスを行って計測します。
測定結果は実際のユーザの操作ではありませんが、比較的安定しているのが強みです。
RUM
RUM には 3 つの SaaS 全てが対応しています。
Synthetic Monitoring
Synthetic Monitoring には Datadog と New Relic が対応しています。
SaaS 以外の選択肢
Synthetic Monitoring は専用のツールが数多く存在します。
そのため、SaaS で導入するよりは工数はかかりますが、導入することはできます。
ここでは Lighthouse, PageSpeed Insights, WebPageTest を紹介します。
これらのツールの多くは手動実行のほか、自動実行も可能です。
Lighthouse
Lighthouse は Node.js 上で動く実装が公開されている他、CI 用のツールも公開されています。
PageSpeed Insights
PageSpeed Insights は API が公開されており、これを CI などから叩くことで任意のタイミングで計測することができます。
WebPageTest
WebPageTest は単体では自動で計測することができませんが、gas-webpagetest などのツールを使うことで実現できます。
UX 監視
UX の監視は Datadog でのみ利用できます。
Datadog では
- Rage Clicks
- Dead Clicks
- Error Clicks
の 3 つの要素を監視することができます。
どの SaaS を利用するか
3 つの SaaS でできることをまとめると以下になります。
| Datadog | Sentry | New Relic | ||
|---|---|---|---|---|
| ログ監視 | 例外監視 | ○ | ○ | ○ |
| セッションリプレイ | ○ | ○ | ○ | |
| カスタムログ | ○ | ○ | △ | |
| パフォーマンス監視 | RUM | ○ | ○ | ○ |
| Synthetic Monitoring | ○ | × | ○ | |
| UX 監視 | ○ | × | × |
この中で Synthetic Monitoring に関しては Lighthouse, PageSpeed Insights, WebPageTest などを別途利用することで導入できることにも触れました。
ではどの SaaS を利用するべきでしょうか。
身も蓋もないですが、それはチームや会社によります。
例えばこの中に既に利用している SaaS があるなら同じものを利用すると、もろもろの説明が楽で導入しやすいと思います。
逆にこれらの SaaS を利用していない場合は、どこまで実現したいか、導入にあたってどの程度の工数と費用が許容されるかを考え、チームに合ったものを選びましょう。
お金がいっぱいあるなら Datadog RUM を使いたいですけどね。
Appendix
SaaS の費用
Datadog
本記事ではログ管理、Synthetic Monitoring、RUM、セッションリプレイを Datadog の機能として紹介しましたが、これらは別々の価格設定になっています。
例外監視とカスタムログに関してはログ管理の部分で課金されます。
既にバックエンドなどのログを Datadog で管理しているなら、ここはどの程度ログが増加するかだけ気にすれば良いです。
Synthetic Monitoring については月間 1000 テストあたり 15$ 課金されます。
この 1 テストとは 25 ステップ、1 ロケーション、1 デバイスでの実行を指します。
RUM については月間 1000 セッションあたり 1.88$、RUM & セッションリプレイでは月間1000セッションあたり2.25$ が課金されます。
セッションについては下記を参照してください。
New Relic
New Relic ではデータ量とユーザタイプによって課金がされ、エディションによってその料金が変わります。
通常チーム開発では Pro 以上のエディションになるでしょう（Standard は 5 人まで）。
今回紹介した機能は「Browser monitoring」と「Synthetic monitoring」の 2 つで、どちらも「Full platform user」のみ利用できる機能です。
そのため全メンバーが利用可能にするのではなく、誰を「Full platform user」にするか選ぶことになるでしょう。
また「Synthetic monitoring」についてはエディション毎に無料枠があり、それを超えた場合は追加で課金がされます。
Sentry
Sentry のプランはシンプルです。
チーム開発では Team 以上のプランを使うことになりますが、基本的にこの Team プランで機能としては足りています。
月次のエラー数やリプレイ数、データ保持期間に応じて追加課金されたりプランを変更することになると思います。
Discussion