• 株式会社フィードフォース
  • エンジニア
  • 鈴木 将高

エラー情報の適切な管理でストレスを減らす!GitHub連携も可能な「Bugsnag」の活用法

今回のソリューション:【Bugsnag/バグスナッグ】

WEBシステムやアプリケーションに異常が発生したときに出力されるエラー情報は、システムの問題箇所を見極めて適切に改修していくためには必須の情報だ。

クラッシュレポート解析サービス「Bugsnag」を活用すると、その情報をより最適に、必要な分量だけ取り扱う事が可能となる。

「世界中のあらゆるものを繋げる」をミッションとする株式会社フィードフォースは、ソーシャルメディアマーケティングのASPサービスなどを提供する企業だが、新規事業を生み出すことにも積極的だ。

同社でエンジニアを務める鈴木 将高さんは、新規事業の開発時から同サービスを活用しているのだという。鈴木さんに、Bugsnagの強力なフィルタリング機能、GitHub連携といった詳しい活用法を伺った。

武者修行期間を経て、新規事業開発チームのリーダーへ

私のエンジニアとしてのキャリアは、学生時代にWEB制作会社でプログラマーのアルバイトをしていたことが始まりです。

未経験ながら簡単なシステムの構築を担当していたのですが、もっとプログラムの実装や設計の考え方について熟練した人に教わりたいという思いがあって。そこでフィードフォースの前身の、ルートコミュニケーションズという会社に入社しました。

ただ、ずっと同じ会社にいた訳ではなく、武者修行のために2年ほど他のベンチャーに行っていた時期もありました(笑)。

今では3人ほどの新規事業開発チームでリーダーを担当しながら、アプリケーションエンジニアとして働いています。

保守コスト・使いやすさの観点からBugsnagを導入

現在、新規事業を開発している中で、エラー通知の仕組みをどう作るのかという問題がありました。

既存のサービスの運用では、エラーが発生するたびにメールを送信していたんです。でもそうすると今までの経験上、送受信の遅延や気づきにくいといった問題が出てくるということが分かっていました。

それを解決するために、エラー通知に特化したサービスを導入しようと決めました。

今回選択したBugsnag以外にも、AirbrakeやRaygunなどのサービスや、ErrbitやSentryなどのOSSも比較しました。ただ、OSSは早い段階で選択肢から外しましたね。当時はチーム内にエンジニアが2人しかいなかったので、OSSを導入して保守していくコストをかけたくなかったんです。

そして残ったサービスの中でも、BugsnagはUIが優れていて、直感的に使いやすい点が魅力的でした。

長く使いたいサービスなので使うたびにストレスを貯めたくないし、後から人が増えることを考えても手順書なしで使い方が理解できる点が良かったですね。

####▼WEBアプリケーションのエラーを通知する「Bugsnag」

必要なエラー通知だけを選択する、柔軟なミュート設定が可能

Bugsnagの便利なポイントはミュート設定が細かく出来る所です。例えば同じエラーについては始めの1回だけを通知してしばらく送らないような設定ができたり、逆に何度も続けて同じエラーが出た場合にだけ通知するような設定もできます。

また、同じエラーが頻発する場合は個別に手動で止めることも出来るので、ひたすら同じエラーが通知されてストレスが溜まることもありません。

新規サービスの開発中のフェーズだと、まだ安定稼働はしていないのでエラーって割りと頻繁に起こるんです。それを必要な分だけフィルタリングして通知してくれる機能は便利ですね。

簡単な導入も、fluentdを活用したより高度な仕組みの構築も可能

Bugsnagはサービス自体に組み込むことも簡単です。今開発中のサービスはRuby on Railsで作っているのですが、gemを1つインストールして数行の設定を追加するだけで完了します。

それだけでアプリケーション例外がBugsnagに送信される仕組みになっています。

今はこのBugsnagに通知する部分をカスタマイズしていて、*fluentd経由で送信するようにしています。

アプリケーションから同期的に送信してしまうと、送信に失敗したらエラー情報が失われてしまいますし、エラーが頻発するとアプリケーション自体の負荷も上がってしまうので。

GitHub連携とタスク管理機能で、障害対応の進捗も明確に

また、BugsnagにはGitHubと連携できる機能があるんです。連携させると、深刻なエラーが発生した場合にエラー情報を元に自動的にGitHub Issueを作ってくれます。

Bugsnagにはinfo/warning/errorの3段階のエラーレベルが定義されていて、弊社ではerrorレベルのエラーのみIssueを自動で立てる設定にしています。

warning以下のエラーはメールやSlackで通知するようにして、後で振り返って対応できるようにしています。

Bugsnagのサービス内には簡単なタスク管理機能もあり、エラーに対して担当者を割り振る事ができるようになっています。メールで通知していた時は、誰がどうやって対応しているのか分からない状態になることが多かったですね。

こういった機能を活用することで、エラーへの対応状況も共有することができるので、重要な情報が埋もれることも無くなり助かっています。

今メールでエラー通知を受け取っている企業であれば、Bugsnagはおすすめですね。

メールは送信自体にも時間がかかりますし、たまたまエラーがよく通るところで起こっていて、短時間で1,000回起こったら1,000回通知がきてしまいます。

そうすると通常業務にも支障が出ますし、ストレスですよね。エラーを適切に管理して対応することが重要なので、その仕組みづくりのためにBugsnagは使いやすいサービスだと思います。(了)

;