Vol.07 エラー運用フローのための Error Reporting 活用術

はじめに

こんにちは。技術本部Bill One Engineering Unitの柳浦です。
BIll One ではGoogle CloudのError Reportingサービスにより、アプリケーションで発生したエラーを検知し、運用に活用しています。この記事では、Bill OneにおけるError Reportingの活用方法について紹介します。

なお、本記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつです。

Error Reporting

Error ReportingはGoogle Cloud Operations Suiteの一部として提供されるサービスです。このサービスは、Cloud Run, Cloud Functions などの Google Cloud 実行環境で発生したエラーを集計し、管理します。集計対象は Error Reporting API により登録されたエラー、もしくは適切な形式でCloud Loggingに記録されたエラーです。
Error ReportingはCloud Loggingに記録されたエラー情報をもとに根本原因が同じであると推測されるエラーをグルーピングします。根本原因が類似したエラーを自動的に分類し集計できるため、エラーが発生したときの原因の切り分けや分類をある程度までは自動で行ってくれます。その他にエラーのステータスをオープン／確認済み／解決済み／ミュートの4種類で管理できます。
Bill Oneは開発者が運用保守も行うこともあり、エラーの収集と分類を効率化し、運用負荷を低減するためになくてはならないサービスとして活用しています。

Bill OneにおけるError Reportingの活用

Bill Oneシステムを構成するアプリケーションには主に以下の3つがあります。

1. Cloud Runで稼働するマイクロサービス群
2. App Engineで稼働するBFF
3. Cloud Functionsで稼働する各種機能モジュール群

Bill Oneで用いるアプリケーションの開発言語としては Kotlin, TypeScript, Go などがありますが、すべてのアプリケーションのエラーログをCloud Loggingに記録し、Error Reportingサービスにより集計・管理しています。

エラー運用フロー

Bill Oneの開発組織はフィーチャーごとの開発チームから構成されています。運用は当番制で開発チームごとに持ち回りで運用担当チームを決めています。
エラー発生から解決までは以下のフローで実施しています。

1. アプリケーションでエラーが発生する。
2. Cloud Loggingにエラーログが記録される。
3. Error Reportingがエラーをグルーピングし、エラーレポートが作成される。このとき、新規発生もしくは解決済みから再度発生したオープン状態とエラー状態のレポートだけがエラー通知の対象になります。
4. エラー通知用 Slackチャンネルにエラー通知が届く。
5. 運用担当がエラーを一次切り分け。対応判断が難しいものはマイクロサービスなどの担当チームに依頼する。
6. 必要な対応を実施してエラーレポートをクローズする。(不具合であれば修正、誤検知であれば誤検知にならないよう改善するなど)

Bill Oneシステムは日々、機能を拡充し多数のアプリケーションが稼働しているため、一人の開発者がすべてを把握することが難しくなってきています。この当番制の運用は開発者が担当外のエラーやコードを解析し、普段触れないコードを知るきっかけにもなっています。

Error Reportingを使った運用フローの工夫

Error Reportingは便利なサービスですが、運用フローがより円滑に回るよういくつかの工夫をしています。

Slack通知のカスタマイズ

Error ReportingからのレポートはCloud Monitoringの通知機能によりSlackチャンネルに通知することもできますが、Bill Oneでは通知内容をカスタマイズするため、Cloud Monitoringではなく、Log Router経由でCloud Pub/Subを通してCloud FunctionsからSlackに通知しています。詳しいやり方については、弊社別組織の以下の記事をご覧ください。 buildersbox.corp-sansan.com

こちらがSlack通知の例です。

Slack通知の例

こちらの通知はError Reporting標準のSlack通知内容に似ていますが、末尾に "Recent Trace Sample" のリンクが追加されています。このリンクは発生したエラーのうち直近のエラーの Trace IDをもとに関連する一連のCloud Loggingログを表示するためのリンクです。
Cloud FunctionsでCloud Logging API 経由で通知されたレポートのTrace IDを取得し、Slack通知にリンクを埋め込むことで 1クリックでTraceを表示できるように工夫しています。運用時のエラー調査の負荷を少しでも減らすために、開発者が主体的にこういったカスタマイズに取り組んでいます。

レポート通知が長時間停止する問題の対策

Error Reportingには制約があり、プロジェクトごとに 1時間あたり5件までの通知が上限になります。この上限に到達するとその後、6時間、通知が停止してしまいます。
cloud.google.com

通常は、この上限に到達し通知を停止することを伝えるメッセージがError Reportingから通知されるのですが、公式ドキュメントにも記載されているように現状ではこの通知が機能していません。
この上限に達する頻度は低いものの、万が一到達したときに何も通知がないためエラーが発生したことに長時間気づかなくなる可能性があります。このような状況を避けるため、Error Reportingの未解決のレポート数を定期的にチェックし、Slackチャンネルに残数を通知する工夫をしています。Error ReportingのステータスチェックにはこちらのAPIを利用しています。

今後の取り組み

Bill OneのGoogle Cloudプロジェクトでは多数のマイクロサービス稼働していますが、現行のエラー通知の仕組みではすべてのマイクロサービスのエラーが一つのSlackチャンネルに通知されます。現在はエラー通知には運用担当チームがアテンションを張っていますが、今後は、エラーレポートの内容をもとにマイクロサービスごとの分類をした上で、マイクロサービス専用のチャンネルに通知することを考えています。これによって運用担当チームの負担を減らしつつ、マイクロサービス担当チームによる自律的な改善を促したいと思います。

おわりに

今回はBill OneにおけるError Reportingを使ったエラー運用フローについて紹介しました。本文中でも触れましたが、Error Reportingには通知に関する制限・既知の問題がありますが、工夫することで回避できます。この記事がError Reportingをより便利に日々の運用に活用するための参考になると幸いです。