Sentryを有効活用するための下準備としてやったこと

こんにちは。フロントエンドエンジニアの藤野です。
暑くなってきましたね。ハーゲンをダッツしてる時が幸せなこの頃です。

＊＊＊

スペースマーケットではアプリケーションのエラーの監視の為に Sentry と Datadog を利用しています。実は、今年の4月中旬に Sentryのプランを Businessプラン にアップグレードしました！

プラン変更にあたっての下準備には少し苦労したのですが、アップグレードによってコスト削減に繋がったうえに機能向上し、有効に活用できるようになったため、その過程を共有したいと思います。

これまでのSentry活用

スペースマーケットでは以前からSentryを契約しており、古いプランではありますが、2021年4月末までは smallプラン を利用しておりました。料金としては 29$(年間契約の場合)で100,000エラーまでは定額、以降のエラーは1件あたり$0.00024 の従量課金制でした。 
機能としては最低限のものとなっており、IPによるフィルタリングは可能ですが、横断的なフィルタリング（リリース、エラーメッセージ、特定の問題による）は business プランのみ可能となっております。
参考：Sentryドキュメント

スペースマーケットでは DataDog による監視も フロントエンド(FE) / バックエンド(BE) ともに行ってますが、Sentry も同様に両方で利用しております。

通知の確認方法（Slack活用）

Sentryを使ったエラー検知はSlack連携しており、外部要因で何度も発生しているエラーはSlack上で Ignore ボタンをクリックすることで対応したり、リリース後に新たなエラーが発生したら確認するようにしていました。
（ここで外部要因エラーが各ページで発生するたびに Ignore する必要があると気付いて非常に面倒になり、課題感が出てきました）

FEエラー管理に課題が発生

BE / FEチームでそれぞれ定期的にエラーを確認していますが、FEに関しては以下のような課題がありました。

・外部要因のエラーが多く、サービス要因のエラー発見が遅れる
・外部要因エラーは横断的にフィルタリングすることで通知を切りたいが、businessプラン以上でないとできない

エラーの管理は small プランでも問題なくできるのですが、同じエラーが発生するたびに Ignore とするのも手間がかかるため、エラーメッセージごとにフィルタリングしたいという要望が上がりました。

そこで、small プランから business プランに切り替えるために、現時点のエラー数から金額と費用対効果を見積もりました。

やったこと1: 現状把握

日々Slackの通知は確認していましたが、毎月どの程度のエラーが発生しているのか、コストはどの程度かかっているかを把握してFEチームに共有するとことから始めました。

調査の結果、FEはエラーの種類は1,000以上、件数はBEの10倍でした。Sentryでかかっているコストの大半はFEが占めていることがわかりました。
中でも重複して発生しているエラーがいくつもあり、発生回数の多い順でソートしてみると、2週間で数千〜数万回発生しているエラーが数十件ありました。

また、small プランでは 100,000件までが定額の $29 に収まるのですが、毎月軽くオーバーするようになっていました。（従量課金の上限は設定しており、何度か上限値まで到達していました）

やったこと2: コスト削減に向けた調査、下準備

重複したエラーの発生回数が異様に多いため、横断的なフィルタリングが可能になれば大幅に削減できると判断し、 Business プランに変更することを検討しました。

その際、Business プランは50,000エラーまでは定額 $80/month (年間払いの場合) で従量課金は1件あたり $0.000500 と smallプランと比較すると2倍になります。

エラー数が多いままでプランを上げるとコストがかかるため、Businessプラン乗り換え時に Trial を利用し、トライアル期間の2週間でフィルタリング作業を実施することにしました。

リポジトリごとのエラー数と発生頻度が異様に多いエラーを洗い出し、Businessプランのトライアル契約開始後にエラーメッセージごとにフィルタリングする作業にかかりました。
ここでかかった作業工数は以下の通りです。ちょっと辛い作業になります。

・エラーの種類、発生数調査（2h程度）
・フィルタリング作業、スプレッドシートに実施記録（8h〜10h程度）
・エラーメッセージによるフィルタリングができなかったものは discarded issues扱いとする（※）（1週間ほど監視、適宜作業）

※ discarded issues とすると、エラー詳細の参照ができなくなって今後も検知されなくなるが、discarded issues 一覧から取り消すことで再度検知できるようになる

上記のように、エラーメッセージとエラー詳細URL（Sentry）を記録しながらの作業だったため、それなりに時間はかかりました。

やったこと3: Sentry運用ルールを確立する

スプレッドシートに記録したSentryフィルタリングリストを元に、FE/BEチームそれぞれが毎週当番を決めて最低1件調査する運用にしています。外部要因かサービス要因かを判断し、外部要因であればフィルタリングしたままになります。

発生回数の多いエラーから記録されているため、上から順に対応、あるいはフィルタリングできなくてdiscardedとしたものから調査を進めるルールです。現在は頻発するエラーがほぼフィルタリング（未調査のため仮にはなりますが）されており、ノイズのない状態で新規エラーの発生を検知することができます。

新規エラーがあれば当番の人は新たに調査することになりますが、加えて1件はフィルタリング済みのエラーを調査するルールです。これにより、未調査でフィルタリングしたエラーを少しずつ確実に減らしていける運用となりました。

Businessプランに切り替えた結果

コスト面
2021年4月16日からBusinessプランに切替えて年間払いしてから、まだ追加の請求はきておりません。無事に定額内でエラー数が収まって、コストの削減に成功しました🎉🎉🎉（smallプランの定額は $29/month ですが、従量課金によって $80/month を上回っていました）

エラー監視
何度も発生しているノイズと化したエラーをフィルタリングしたことにより、新規エラーの発見が早くなりました。しかし、新規エラーにしても数は多いので、確認・対応が追いついていないのが正直なところです。

↓新規エラーの頻発に気づいた様子

運用面
認識されていても優先度が低くて放置されていたSentryエラーですが、少しずつではあるものの確実に解消されていくようになりました。
これにより、見落としてはならないエラーの早期発見に繋がりますし、本来のSentryの良さが活かせてきますね。

ふりかえり

コストが下がったうえに上手く活用できるようになった、という話になりますが、逆に言うと今までお金は払っていたけど効果があまり得られていなかったことになります💸

便利なサービスは最大限に活用し、プロダクトの成長と安全性の向上に繋げていきたいですね。

Businessプランになると機能面が大幅に向上し、small プラン（今のTeamプラン相当）に比べるとできることがかなり増えます。
まだ弊社もより便利に使いこなせるよう探っているところなので、他社の事例を見たり聞いたりしたいなと思っております。

Classi さんの記事はとても参考になりました！
（Sentryプラン変更検討中に公開され、早くやろう！となりました）

Sentryを活用するためにやっていること - Classi開発者ブログ

最後に

スペースマーケットでは、エンジニアを募集しています！
一緒にシェアリングエコノミーで社会課題を解決したい！新しい技術にどんどんチャレンジしたい！という方からの応募をお待ちしております〜！