Sentry を障害検知ツールとして生まれ変わらせるまでの軌跡

こんにちは、株式会社 kikitori の小川です。

kikitori で開発している農業流通分野特化型 SaaS 「nimaru」はローンチから5年以上経過し、当初と比較すると様々な機能が追加され全国様々な事業者に使用されるまでに至りました。ただし利用者が増えたことで nimaru に障害が発生すると影響を受けるユーザーも増えることとなり、発生した際の早期検知/早期対応の必要性が高まっていました。

nimaru にはローンチ当初から Sentry を導入しており、nimaru でエラーが発生すると Sentry がキャッチし、専用の Slack チャネルに通知が送られる仕組みが整っていました。しかし Sentry がどんな軽微なエラーでもキャッチし通知を送信していたため膨大な数の通知が送られ、他の通知に埋もれ重要なものに気付けないことがありました。そのため障害の検知ツールとしては活用しきれず、障害発生の報告を受けた際にエラー内容を確認するためのツールとして使われてきました。

今回はそんな狼少年となってしまった Sentry を障害検知のツールとして生まれ変わらせるまでの軌跡をまとめました。

目的設定

kikitori の開発チームはまだまだ少人数ということもあり、運用の体制が仕組みとして整備されていませんでした。そこで少人数でも運用を回せるようにするために、まずは現在 Sentry から送られてくる膨大な通知を重要度が高いものに限定することで障害をいち早く検知することを目的としました。

ただ重要度が高いものに限定するといっても重要なエラーだけを通知対象に指定する方法では事前に「重要なエラーとは何か」を定義する必要があり、また定義から漏れた想定外のエラーには対応できないため広範な障害検知には向きません。そこで逆のアプローチとしてエラーとして検知されたが問題はない、偽陽性といえるエラーを通知対象から除外していくことで結果として比較的重要度が高いエラーについてのみ通知される状態を目指すこととしました。

既存エラーを Archive 化

まず Sentry ではキャッチしたエラーを通知対象から除外する Archive 機能があったのでこちらを活用することにしました。これは任意のエラーを通知対象から除外してくれる機能で、一定の回数/期間を超過するまでは通知しないといったような設定が可能となっています。

今回は既知のエラーを Archive Until Escalating に変更することで一度全て通知対象から除外することとしました。これは通知対象外にはするものの同じエラーの件数が大幅に増加したと Sentry が判断した場合には再度通知されるようになるものです。この時に Archive したエラーに重要なエラーが含まれている可能性もありましたが、この時点では Sentry からの通知を活用できていなかったこと、Archive したエラーに起因する障害が発生したとしても Archive Until Escalating であれば再度通知が行われることを期待してこのような対処としました。

これにより 1日に数十件あった通知を数件まで削減できました。

特定のエラーを除外

通知件数は大幅に減ったものの通知されるエラーは依然として偽陽性といえるものばかりであり、毎日何件も高確率で偽陽性である通知を確認し続けるのは他の作業の妨げになっていました。

そこで通知されるエラーの内容を分析したところ、不正な入力値を検出して処理を中断したことを示すエラーがありました。これはデータの整合性を保証するために生じたもので、正常なアプリケーションの動作といえるものでした。こういった明らかに偽陽性だと判断できるエラーのパターンについても通知の対象から除外していきました。幸いエラーメッセージに規則性があり、それに基づいたパターンでの検出が可能だったので、通知設定にエラーメッセージの値によるフィルタを追加して通知対象から除外しました。

また、その他のエラーについても対応が不要なものについては Archive Until Escalating にすることで通知件数の抑制を続けました。

この対応を追加したことで通知件数を 1日に数件から 1週間に数件まで削減することができました。

頻度調整

ここまでの対応で当初と比較すると通知されるエラー件数は激減しましたが、依然通知されるのは偽陽性といえるエラーばかりで、あと一歩の削減策が必要になりました。

偽陽性といえるエラーの傾向を観察したところ、ほとんどが新規かつ単発のものであり、継続して複数回検出されるものはありませんでした。そこで通知設定に発生頻度の条件を追加し同じ種類のエラーが一定回数以上発生した時に通知されるよう設定しました。

どれくらいの頻度にするべきか少し悩みましたが、対象期間を長くすると通知の削減効果が得られないこと、また通知させたくない偽陽性のエラーは単発のものばかりだったことを踏まえてひとまず 1日に 2件以上発生したら通知するよう調整しました。

これにより一度限りのエラーについては通知されないようになりましたが、同時に重要なエラーであったとしても 2回以上発生して初めて通知を受け取ることになるので即応性は若干下がるリスクも同時に抱えることにはなりました。ただ正常な操作ができないとなればユーザーは再度試すと想定し、いざ障害が発生すれば同種のエラーは 2回以上発生するだろうと考え、このリスクを許容することにしました。

そして発生頻度の設定を追加してから 2週間が経ちますが、この間に新たな Sentry からの通知は 1件も来ておらず、またユーザーからの障害報告もないことから重要なエラーの発生も見逃しも起きずに経過できています。