自社に適した運用でフロントエンドのエラーを迅速に対応することを実現

Sentryを導入する前は、自前のエラー管理システムを使用していました。
簡単に説明すると、フロントエンドで発生したエラーをサーバーに送信し、エラーのログをファイルに書き込むというものでした。

自前のエラー管理システムには以下のような課題がありました。

1. 大量のエラー発生時にアラートをあげる仕組みがない
   　・エラーへの対応が遅れる
   　・ユーザーからのお問い合わせでエラーに気づくことがある
2. エラーに関する情報が少ない
   　・原因を素早く突き止め対応することができない
   　・大量のエラーの中で優先して対応すべきエラーが埋もれる
3. 食べログはアクセス数が多くサポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生
   

上記の課題を解決するため、フロントエンドのエラーをいち早く検知し、素早く原因を突き止め対応できる状態を目指して、エンジニア主導で Sentry の導入を提案しました。

• BugSnag
• Rollbar

*Sentry を導入したのは 2019 年でサービス毎の比較は古い情報になるため詳細は記載しません。

以下のような軸で比較を行いました

• コスト(サービス利用料・導入・運用に掛かるコスト)
• Microsoft Teams との連携（食べログでは Microsoft Teams を使用している）
• 対応の必要がないエラーを課金対象外にする機能
• 管理画面の使いやすさ
• ドキュメントの情報量と読みやすさ
• 運用環境
• ログの保存期間

多くのエラートラッキングツールには、1ヶ月に受け取れるエラーの数にプランごとの上限があります。食べログでは日々大量のブラウザエラーが発生しているため、全てのエラーをキャッチしてしまうとすぐ追加料金が発生してしまいます。

そのため、スクレイピングやユーザーの環境依存など、対応の必要がないエラーを課金対象外にする機能を重要視していました。

Sentry ではスクレイピングやユーザーの環境依存など、対応の必要がないエラーはエラーとしてカウントされないInbound Filter 機能 が充実していました。追加料金が発生することなくプラン料金内で運用できるポイントが決め手となりました。

Inbound Filter 機能を使うことで以下のようなエラーをエラーとしてカウントしないようにできます。

• バージョンの古いブラウザで発生したエラー
• クローラーで発生したエラー
• 特定のエラーメッセージのエラー
• 特定の IP アドレスで発生したエラー
  

他にも Rate Limiting 機能を使うことで、設定した時間内に設定した回数以上発生したエラー（1分間に10回以上発生したエラーなど）をカウントしないようにできます。

上記の Inbound Filter と Rate Limiting 機能はデプロイせずに管理画面からすぐに設定変更することが可能なのも決め手の1つです。

これらの機能を活用することで追加料金が発生することなく、プラン料金内で運用できています。

導入の背景に記していた、導入前に抱えていた課題は以下のように全て解決することができました。

1. 大量のエラー発生時にアラートをあげる仕組みがない
   　・エラーへの対応が遅れる
   　・ユーザーからのお問い合わせでエラーに気づくことがある
2. エラーに関する情報が少ない
   　・原因を素早く突き止め対応することができない
   　・大量のエラーの中で優先して対応すべきエラーが埋もれる
3. 食べログはアクセス数が多くサポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生

大量のエラー発生時にアラートの仕組み化

Sentry と Microsoft Teams を連携し、エラーを通知する設定を行ったことで、エラー対応の初動が大幅に早くなりました。

実際、クライアントサイドエラーが原因で UI に表示問題が生じましたが、この連携により迅速に検知。ユーザーからの指摘がくる前に、食べログの開発者が素早く問題に対応することができるようになりました。

Associate Commits機能によって原因を素早く突き止め対応

食べログでは1日に4回ほどリリースが行われています。発生したエラーがどのリリースから発生しているのかを素早く特定する必要がありました。

そこでSentry のAssociate Commits機能を使用してエラー発生タイミングと GitHub のコミットハッシュの紐付けをしています。

これによってユーザーが使用しているブラウザ・OS やユーザーの操作ログ、エラーが発生したコードの行などといったエラー発生時の情報が充実し、導入前と比べてエラーを検知してから対応するまでの時間が短縮され、食べログサービスの安定性が向上しています。

大量のエラーの中で優先して対応すべきエラーが埋もれる

食べログはアクセス数が多いサービスなので、サポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生します。

そこでInbound Filter 機能を使用してサポート外のブラウザやOSなど、ユーザーの環境依存によるもので対応の必要がないエラーは検知しない設定としています。

このInbound Filter 機能を使用してからは、食べログの開発者が実際に即座に対応が必要なエラーに集中できるようになり、結果として、チーム全体の生産性が向上しました。

ただ、Inbound Filter 機能だけでは対応の必要がないエラーを全て検知しないようにすることは困難です。対応しきれない部分は運用方法でカバーしています。運用方法については次で詳しく説明します。

Sentry はデモ環境を提供しているので、まずはデモ環境を触ってみることをおすすめします。デモ環境を触ってみることで Sentry の使い勝手や機能を体感できるので、導入を検討している方にとって参考になると思います。

※本投稿はFindy株式会社からの依頼に基づいて株式会社カカクコムが執筆・作成しています。