BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

アプリケーションのエラー監視をRaygunからSentryへ変更するまで

CTOの川口です。
今回はアプリケーションのエラートラッキングツールについてです。

これまでの経緯

BASEでは主にPHPアプリケーションのエラートラッキングにRaygunを利用していました。
https://raygun.com/
これを採用したのは3年以上前で、当時BASEではPHP5.3を利用していたために利用できるツールは限られておりRaygunはPHP5.3でも動いたため採用されたようです。
今では7.3を利用していたのでこの条件は気にする必要はありませんが、積極的に変更する理由もなく使っていました。
当初はPHPのエラートラッキングにのみ利用していましたが最近はfrontendのエラートラッキングにも利用しています。

ここが辛いよRaygun

まず料金が結構高めです。 APMやRealUserMonitoringなどの利用はしておらずエラートラッキングのみ使っています。
https://raygun.com/platform/crash-reporting
APMはPHPに対応していませんし元々Newrelicを利用しています。
small business プランを利用しており、$249/month です。
https://raygun.com/platform/crash-reporting#pricing
これは非常に高額というほどでもありません。 ですが、更にこの上のプランになると$899と一気に値段があがります。これは一気に高額になります。 これのしきい値がエラーイベントの件数になっており、月間の件数を超えてしまうとプランを変更する必要があります。
25万エラーを超えて100万エラーまで受け付けてくれるのはありがたいですが、結果的には30万イベント程度で済むであろう事が想定されコストパフォーマンスが悪くなります。

さらにRaygunはあまりPHPのサポートに積極的でなく、UTF-8以外を含むと問題が出たりします。
https://github.com/MindscapeHQ/raygun4php/pull/69
https://github.com/MindscapeHQ/raygun4php/pull/69#issuecomment-514351759
https://github.com/MindscapeHQ/raygun4php/issues/94
PRに対する反応も鈍いため弊社ではforkしてパッチを当てて運用していました。

WEB UIもあまり良いものでなく全体的に遅く、日付範囲でのサマリなどがし辛いと感じていました。 GitHubへのissue連携も古いAPIなどを利用しているようで、Raygunへ渡す権限があまりに強くこのあたりも問題です。 別のエラートラッキングツールに変更も話題には登っていましたが、ずるずると先延ばしていました。

エラー量増加に依るトラッキングの停止

現在のプランでは250,000 error events/monthを処理することが出来ます。
基本的にこの数を超えることはないのですが、ミドルウェアの変更などで想定外のエラーが出たりするとアクセス量が多いサービスの場合エラーイベントが一時的に大量に発生します。
ある時、これが複数回起きてしまいlimitを超えてしまいました。
完全にトラッキングが止まったわけではありませんが、エラートラッキングツールとして常用出来ません。
当然プランを上げれば動作するわけなのですが、3.5倍近い値段を払ってまで?という気持ちもありこのタイミングで乗換を検討しました。
Raygunのようなサービスでは過去のデータはそこまで重要度は高くありません。
まだ修正出来ていないエラーが有る場合別のトラッキングツールに乗り換えたところで発生することはわかっているので改めて収集すればいいので問題にはなりません。
料金も安く、機能的に優れているものに乗り換える方がメリットになると考えました。もちろん安いからと言って機能が十分でなければraygunでもいいですし別の高額なツールでも問題はありません。

乗り換え先

同様のエラートラッキングツールはいくつかあり

などがあります。 今回は弊社で利用したことがあるメンバーもいたので、Sentryにすることにしました。 値段もRaygunより安価ですし、機能も豊富そうに見えます。 仮に特定の月にエラーが大量に発生しても、その量に応じて追加課金になるので今回のような事態になっても毎月のプランまで変える必要がなくて安心感があります。 https://sentry.io/pricing/ https://docs.sentry.io/accounts/pricing/#faq

14日はトライアルもできるので一時的な乗り換えに使って不満があればRaygunに戻る事もできます。

SDKも用意されています。弊社で使っているCakePHPを完全にサポートされているわけではないですがRaygunを利用しているコードに少し修正を加えるだけで動きそう、ということで移行をはじめました。 https://sentry.io/for/php/

移行の実装は数時間で完了しました。

ここがすごいよSentry

Sentryのエラートラッキング自体はraygunと別に変わりはありませんが、圧倒的に多機能である事がわかりました。 WEB UIを見てみると、動作も速く情報量が非常に多くあります。
Raygunの場合、環境毎にアプリケーションを登録しapi keyを差し替える必要がありますがSentryの場合はenvironmentを指定することで一つのアプリケーションとして登録することが出来ます。
特に便利だと感じたのはエラー時のスコープにある変数がSentry上で確認できるので、どのような変数によってエラーが起きるのかの調査が捗ります。

下記のような事象は「Undefined index: id」というエラーが発生した場合の表示です。
$favorites に特定indexのみないのかそもそも空を参照していたか、というのが判断可能であり、さらにitem_idも空配列ということがわかるのでなぜこのようなエラーが発生したかの調査にとても有用です。

sentry screenshot
error

PHPのコードも一部表示されるので出先でちょっとした調査くらいならできそうです。
とはいえ勝手にSentryにコードがアップロードされているのでは?ということでセキュリティ的にちょっと心配になるのも事実です。

Spike Protectionという機能がデフォルトでオンになっており、一時的に大量にイベントが発生した場合などにイベントを破棄してくれるようです。 DB障害などがあると全てのアクセスでエラーイベントが発生し情報の精度は下がりつつイベント回数を消費してしまい課金額が上がってしまいがちですがこれはそれを回避してくれそうです。 docs.sentry.io

ここがつらいよSentry

トライアルしている状態なので明確な不満があるわけではまだありません。
通知も細かく設定できるのですが、ここはちょっと慣れていないと大変だなという印象です。
RaygunはとりあえずSlack通知くらいだったらwebhookのurlを渡せばよかったのですが、どういう条件で通知するかというのを登録しないといけないので慣れるまでは戸惑いがありました。

他には「Allow Shared Issues」という機能がありカジュアルにエラーのURLを公開出来てしまうのは危険なのでオフにしました。
多機能であるがゆえに、どこを見ればいいか迷ってしまうなとは感じています。あまりにシンプルだったRaygunからの移行なため余計にそう思ってしまうのかもしれません。

おわりに

まだトライアル段階なので使いこなせているというほどではないですが、SentryはRaygunよりも優れているツールだと感じました。
もちろんエラーは通知さえできればいいというものではなく解消していき狼少年にならないようにアプリケーションを改善していくことが重要ですが、どのような場合にエラーが出ているのかの調査がわかりやすく改善もしやすいです。
どのデプロイによってどのようなエラーが引き起こされたか、などを観測していきアプリケーションの改善に役立てていきたいと思います。