月間13億PVのエラートラッキングにSentryで挑む

はじめまして。食べログFE（フロントエンド）チームの佐伯と申します。
このタイトルを書いてみて、数字の大きさに驚きを隠せません。
通常形態のフリーザ様（53万）何人分でしょうか。
2019年9月より食べログではフロントエンドのエラートラッキングにSentryを使用しており、今回は実際に運用して見えてきた課題などをご紹介させていただきたと思います。

※PV数は2020年6月時点のものを参考にしております
https://corporate.kakaku.com/press/mission

概要

・トラッキングツールの選定理由
・Sentry導入だけでは全て解決されません
・費用に対しての成果はものすごくあります

『Sentry、 キミに決めた！』　わけ。

具体的な話に入って行く前にSentryの紹介をいたします。
https://sentry.io/welcome/

Sentryとは複数の言語に対応したアプリケーションモニタリングプラットフォームです。これを使用することでエラーの監視からパフォーマンスの計測などが行えます。

類似サービスとしてBugsnag, Rollbarなどがありますが、以下の点を重視してSentryを採用いたしました。

Volume Controlが存在する
エラートラッキングツールを利用するに当たってクラウドのサービスを利用する前提で選定いたしました。食べログのフロントエンドチームは少数なため、運用コストを出来る限り減らしたかったからです。

しかしながら、事前調査の段階で大量のエラーが飛んでことが分かっていたのでクラウドサービスだと確実に予算が吹き飛びます。

※検証用プロジェクトの管理画面です。

Sentryでは上記のように時間単位で何件まで受け付けるか設定できるため、月の限度件数を超えることはまずありません。

管理画面からのフィルタリング
Sentryでは管理画面上でmessageやIPアドレス指定でエラーを弾くことができます。さらにこのフィルタリング指定をした場合、月の予算を削ることはありません。
デプロイをすることなく微調整を入れられるのはかなりありがたいですね。

他サービスに比べて記事が多い（情報が多く出回っている）
いくらクラウドのサービスとはいえ、困ったときに情報があるかは対応工数に差が出てくるのでこちらも大事です。

Sentry入れれば全て解決すると思った？？残念！
ここからが正念場だよ！

Sentryを入れればエラーが即座に検知出来るようになって、調査も一瞬で終わる、ボーナスも爆上がり、彼女も出来ると思っておりました。

そんなに世の中は甘くありません。
もう残ってはいないですが、最初期は課題数が『+1000』となり計測不能となってしまいました。これでは彼女が出来そうにありません。

PV数は月間13億、クローラーやスクレイピングなどの機械的なアクセスを含めると実際のアクセス数はさらに膨大になりフリーザ様2500人分以上です。
圧倒されてしまいますね。

そしてその大量のアクセスによってSentryには大量のノイズを含んだエラーが飛んできており、これらのエラーは主に４種類に大別されます。

・広告
・クローラー or スクレイピングの機械的なアクセス
・サポート外環境のユーザーによるアクセス(safari 8.0など)
・動作保証環境にも関わらず発生しているエラー

対応すべきエラーは動作保証環境なのにも関わらず発生しているエラーです。しかし何も対策無しにSentryを使用すると他の対応不要のログに埋もれてしまうどころか、Volume Controlによりログが集約されないまま捨てられてしまいます。

このままでは彼女が出来ないのでユーザー影響のあるエラーを取り逃さないようにしましょう。

whitelistUrl,  releaseの設定

IPアドレスやエラーメッセージで弾けるものは管理画面から対応してしまうのですが、フィルタリングで出来ることにも限界はあるので自社のコードのエラーを拾うようにwhitelistUrlオプションを入れております。

{
   dsn: process.env.SENTRY_DSN,
   integrations: Sentry.defaultIntegrations,
   release: process.env.SENTRY_RELEASE,
   whitelistUrls: [/^https:\/\/tblg\.k-img\.com.*$/]
 }

またreleaseにはリリース毎にcommit hashが入るようになっており、エラーがどの時点から作り込まれたか判別出来るようにしております。
管理画面上で見ると以下のように確認できます。エラーが発生した場合はreleaseとログに含まれるスタックトレースから原因を特定します。

※管理画面リリース一覧です。NEW ISSUESが0であれば問題ありません。

大小異なるエラーは二刀流で。（運用でカバーしてます）

あの手この手を使ってもノイズとなるエラーを完全にシャットアウトすることは出来ません。なので食べログでは二種類の対応でサービスに影響のあるエラーを確認しております。

瞬間的に増えたエラーをアラートで通知させる
Sentryにはアラート機能を使用し、既定時間内に閾値を超えた場合は障害としてTeamsに通知が飛ぶようにしております。
アクセスが多いサービスですので、主要ページでエラーが埋め込まれた場合はすぐに通知が飛んできます。

頻度の低いエラーはデイリーで確認
本当は上記のアラートで全て済ませたいところですが、『新規エラー』 && 『閾値以上』というルールでアラートを組むことが出来ないため、課題の検索で『新規エラー』 &&  『１日以内』という条件で絞りこみ、毎朝確認しております。

件数の制限で全ては拾い上げれてていないですが、少ない件数のエラーもこのように確認し対応が必要なものであれば障害としてすぐに対応しております。

俺たちの戦いはこれからだ!! （今後の課題）

まだまだノイズとなるエラーはたくさん来ているのですが、導入当初に比べてSentryに対する知見がたまり、精度高くエラーを監視出来るようになってきました。
新規のエラーが作り込まれた際に即座に通知が届くのでユーザーに安心して使ってもらえますし、開発者にとっては万が一バグを作り込んでもすぐに知ることが出来るという心理的安全性を確保出来たのは控えめに言っても最高です。
食べログはSentryをBusinessプランで使用しておりますが、月数万円の費用でこれだけの価値を生み出せるとは。。。導入して本当に良かったと思います。

しかしながら課題はあります。

・ノイズとなるエラーが多く必要なエラーが通知されない可能性がある
・デフォルトのログからでは原因が特定出来ないエラーがある

Sentryの実装にフィルタリングを追加したり、ユーザーのプライバシーに影響の無い範囲で発生状況などが分かるカスタムタグを設定していく予定です(Cookieが利用可能かなど)。

今回紹介しきれませんでしたが導入時の技術的問題（広告タグが読み込んでいたSentryクライアントとバッティングした件）やエラーログの分析の仕方などをまた書きたいと思います。

最後に

食べログFEチームでは、一緒にリプレースに取り組んでくれる仲間を大募集中です！

・React/TypeScriptでバリバリ開発したい
・レガシーなシステムのリファクタリングがしたい
・アーキテクチャについて探求したい
・食べログというプロダクトに貢献したい
・フリーザ様2500人分の戦闘力と向き合う覚悟がある

どれかに当てはまった方は以下のリンクを是非御覧ください！