自社に適した運用でフロントエンドのエラーを迅速に対応することを実現
株式会社カカクコム / endo shiki
メンバー / フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
利用プラン | ツールの利用規模 | ツールの利用開始時期 |
---|---|---|
Business(年契約、Monthly errors for Error Monitoring: 1.5M) | 101名〜300名 | 2019年10月 |
利用プラン | Business(年契約、Monthly errors for Error Monitoring: 1.5M) |
---|---|
ツールの利用規模 | 101名〜300名 |
ツールの利用開始時期 | 2019年10月 |
導入の背景・解決したかった問題
導入背景
Sentryを導入する前は、自前のエラー管理システムを使用していました。
簡単に説明すると、フロントエンドで発生したエラーをサーバーに送信し、エラーのログをファイルに書き込むというものでした。
自前のエラー管理システムには以下のような課題がありました。
- 大量のエラー発生時にアラートをあげる仕組みがない
・エラーへの対応が遅れる
・ユーザーからのお問い合わせでエラーに気づくことがある - エラーに関する情報が少ない
・原因を素早く突き止め対応することができない
・大量のエラーの中で優先して対応すべきエラーが埋もれる - 食べログはアクセス数が多くサポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生
上記の課題を解決するため、フロントエンドのエラーをいち早く検知し、素早く原因を突き止め対応できる状態を目指して、エンジニア主導で Sentry の導入を提案しました。
比較した軸
*Sentry を導入したのは 2019 年でサービス毎の比較は古い情報になるため詳細は記載しません。
以下のような軸で比較を行いました
- コスト(サービス利用料・導入・運用に掛かるコスト)
- Microsoft Teams との連携(食べログでは Microsoft Teams を使用している)
- 対応の必要がないエラーを課金対象外にする機能
- 管理画面の使いやすさ
- ドキュメントの情報量と読みやすさ
- 運用環境
- ログの保存期間
選定理由
多くのエラートラッキングツールには、1ヶ月に受け取れるエラーの数にプランごとの上限があります。食べログでは日々大量のブラウザエラーが発生しているため、全てのエラーをキャッチしてしまうとすぐ追加料金が発生してしまいます。
そのため、スクレイピングやユーザーの環境依存など、対応の必要がないエラーを課金対象外にする機能を重要視していました。
Sentry ではスクレイピングやユーザーの環境依存など、対応の必要がないエラーはエラーとしてカウントされないInbound Filter 機能 が充実していました。追加料金が発生することなくプラン料金内で運用できるポイントが決め手となりました。
Inbound Filter 機能を使うことで以下のようなエラーをエラーとしてカウントしないようにできます。
- バージョンの古いブラウザで発生したエラー
- クローラーで発生したエラー
- 特定のエラーメッセージのエラー
- 特定の IP アドレスで発生したエラー
他にも Rate Limiting 機能を使うことで、設定した時間内に設定した回数以上発生したエラー(1分間に10回以上発生したエラーなど)をカウントしないようにできます。
上記の Inbound Filter と Rate Limiting 機能はデプロイせずに管理画面からすぐに設定変更することが可能なのも決め手の1つです。
これらの機能を活用することで追加料金が発生することなく、プラン料金内で運用できています。
導入の成果
導入の背景に記していた、導入前に抱えていた課題は以下のように全て解決することができました。
- 大量のエラー発生時にアラートをあげる仕組みがない
・エラーへの対応が遅れる
・ユーザーからのお問い合わせでエラーに気づくことがある - エラーに関する情報が少ない
・原因を素早く突き止め対応することができない
・大量のエラーの中で優先して対応すべきエラーが埋もれる - 食べログはアクセス数が多くサポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生
大量のエラー発生時にアラートの仕組み化
Sentry と Microsoft Teams を連携し、エラーを通知する設定を行ったことで、エラー対応の初動が大幅に早くなりました。
実際、クライアントサイドエラーが原因で UI に表示問題が生じましたが、この連携により迅速に検知。ユーザーからの指摘がくる前に、食べログの開発者が素早く問題に対応することができるようになりました。
Associate Commits機能によって原因を素早く突き止め対応
食べログでは1日に4回ほどリリースが行われています。発生したエラーがどのリリースから発生しているのかを素早く特定する必要がありました。
そこでSentry のAssociate Commits機能を使用してエラー発生タイミングと GitHub のコミットハッシュの紐付けをしています。
これによってユーザーが使用しているブラウザ・OS やユーザーの操作ログ、エラーが発生したコードの行などといったエラー発生時の情報が充実し、導入前と比べてエラーを検知してから対応するまでの時間が短縮され、食べログサービスの安定性が向上しています。
大量のエラーの中で優先して対応すべきエラーが埋もれる
食べログはアクセス数が多いサービスなので、サポート外のブラウザとOS、スクレイピングなどといったエラーも多く発生します。
そこでInbound Filter 機能を使用してサポート外のブラウザやOSなど、ユーザーの環境依存によるもので対応の必要がないエラーは検知しない設定としています。
このInbound Filter 機能を使用してからは、食べログの開発者が実際に即座に対応が必要なエラーに集中できるようになり、結果として、チーム全体の生産性が向上しました。
ただ、Inbound Filter 機能だけでは対応の必要がないエラーを全て検知しないようにすることは困難です。対応しきれない部分は運用方法でカバーしています。運用方法については次で詳しく説明します。
導入に向けた社内への説明
上長・チームへの説明
以下3つのポイントを整理して説明しました
- エラートラッキングツール導入によるビジネス影響
- エラートラッキングツール導入以外の手段と比較
- Sentryと類似サービスとの比較
エラートラッキングツール導入によるビジネス影響
エラートラッキングツール導入によりフロントエンドの障害をいち早く検知/対応できることユーザーからのお問合せの減少、システムの安定性と開発生産性の向上を達成することによる、ビジネス影響を説明しました
・ユーザーからのお問い合わせの減少
・システムの安全性と開発生産性の向上エラートラッキングツール導入以外の手段と比較
フロントエンドの障害をいち早く検知/対応する方法を Sentry 導入含め複数提示しました。
・これまで使用していた自前のエラー管理システムの拡張
・Sentry を OSS で利用
・Sentry を SaaS で利用
導入コスト、管理コスト、セキュリティリスクを考慮した上で Sentry を SaaS で利用することが最善であることを説明しました。Sentryと類似サービスとの比較
「比較軸」の項目で書いたように、サービス利用料、導入・運用コスト、Microsoft Teamsとの連携、対応の必要がないエラーを課金対象外にする機能などを比較した上で、Sentry が食べログに一番マッチしていることを説明しました。
活用方法
食べログで Sentry を運用する上での課題
前提として食べログではサポート外のブラウザ・OS、通信環境が不安定、スクレイピングなどといったユーザーの環境依存によるエラーが多く Sentry に通知されています。
その中から優先して対応したい食べログコードのエラーを見つけ出す工夫を紹介します。
優先して対応すべきエラーとそうでないエラーの切り分け手順
Issuesで多くのユーザーで発生しているエラーを見つけて対応すべきエラーの目星をつけます。多くのユーザーで発生しているエラーは様々な環境で発生していると考えられるので、食べログコードのエラーの可能性が高いです。
一方、少ないユーザーで発生しているエラーは特定の環境で発生していると考えられるので、ユーザーの環境依存によるエラーなどの可能性が高いです。
食べログコードのエラーを優先して対応したいので、多くのユーザーで発生しているIssue Detailsを見て分析していきます。
以下の項目を総合的に見てエラーの切り分けを行っています。
- 継続的に発生しているか
- 継続的にエラーが発生していれば食べログコードのエラーの可能性が高いですし、一時的なものであればユーザー環境依存によるエラーの可能性が高いと考えられます。
- 最初に発生した時刻
- デプロイした時刻の直後であれば食べログコードのエラーの可能性が高いと考えられます。
- ブラウザやOSは何か
- エラーが発生しているブラウザやOSが古いバージョンであれば環境依存によるエラーの可能性が高いと考えられます。そもそもサービスのサポート対象外であれば、対応する必要がないと判断ができます。
よく使う機能
1. アラート通知
Alert 機能を用いて1分間に10ユーザー以上で発生しているエラーに関しては Microsoft Teams と連携して通知が飛ぶように設定しています。アラート通知でデプロイに起因するエラーをいち早く検知できるようにしています。
閾値をエラーの数ではなくエラーが発生したユーザー数にしているのには理由があります。
エラー切り分け方法の項目で記述したように、多くのユーザーに影響を与えているエラーは優先して対応すべき食べログコードのエラーの可能性が高いと考えられます。そのため、閾値をエラー数ではなくエラーが発生したユーザー数に設定しています。
2. 毎日の新規エラーチェック
食べログでは環境依存によるエラーが多く Sentry に通知されているので、多くのユーザーに発生しているエラーを中心に詳細まで確認しています。これでアラート通知では検知できなかったエラーをカバーしています。
具体的にはIssuesのSearchable Properties 機能を活用して、過去3日間の新規エラーを確認しています。過去3日間にしている背景として、過去に新規エラーを確認する範囲を過去1日間で運用していた際に、エラーが発生したユーザー数が少なく見逃したケースがありました。そのケースを考慮して過去3日間で新規エラーをチェックしています。
3. 毎日の既存エラーチェック
過去30日の既存エラーを確認しています。アラート通知と毎日の新規エラーチェックで検知できないような、初めはエラーが少なかったが徐々にエラーが増えているケースをカバーしています。
食べログでは以上の運用方法で環境依存を含む多くのエラーの中から優先して対応すべきエラーをいち早く見つけ出して対応することができています。
ツールの良い点
「選定理由」の項目で導入の決め手となったツールの良い点について詳しく述べましたので、ここでは運用してみて良かった点を紹介します。
Sentry が提供する SDK によるアプリケーションへの導入の容易さです。
実際に食べログでは「食べログノート」プロダクトをリリースする際に SDK を使用し、 Next.js のアプリケーションに迅速に組み込むことができました。
導入時の課題と解決策については以下の記事をご覧ください。
https://note.com/tabelog_frontend/n/n7f6822ae0c0d
ツールの課題点
現時点では特記すべき大きな課題点は見当たりませんが、Issue Statusをカスタマイズできる機能があると嬉しいです。
デフォルトで用意されているステータス以外に、新しいステータスを自由に追加できれば運用の幅が広がりさらに便利になると考えられます。
ツールを検討されている方へ
Sentry はデモ環境を提供しているので、まずはデモ環境を触ってみることをおすすめします。デモ環境を触ってみることで Sentry の使い勝手や機能を体感できるので、導入を検討している方にとって参考になると思います。
※本投稿はFindy株式会社からの依頼に基づいて株式会社カカクコムが執筆・作成しています。
株式会社カカクコム / endo shiki
メンバー / フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
株式会社カカクコム / endo shiki
メンバー / フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法