こんにちは。FLINTERSでデータエンジニアをしている栗原です。今回の投稿はFLINTERSブログ祭りの記事です。テーマは#監視 #通知 #読書感想です。

背景

私が参加しているプロジェクトでは、以下の監視業務に多くの時間を取られていました。

確認したいこと
- 日々APIやGA4タグ等からデータを取得 -> DBに保存のようなシステムにおいて、データが過不足なく正常にDBに取り込まれていること
初期確認体制
- システムのワークフローが正常に動いたかどうかをメールで毎日通知
- たまにDBへのクエリを実行し、取り込み件数を手動で確認する

徐々にこれらの体制を改善し、現時点では初期と比べて大幅に監視にかける時間を削減できたので、その改善の過程を共有したいと思います。

参考書籍ピックアップ: 入門監視

監視業務の効率化に向けて入門監視―モダンなモニタリングのためのデザインパターンの内容を参考にしました。その中でも特に参考になった部分について、以下に記載していきます。

アンチパターン

監視を支えにすること
- 監視を杖であるかのように寄りかかってはいけない
- 監視とは問題を通知することに長けているだけで、問題の修正を忘れてはいけない
- 注意を要するサービスを運用していて、そこに監視をどんどん追加していることに気づいたら、それはやめてサービス自体を安定して回復力のあるものにしていくべき
手順書に依存しすぎること
- 自動化が不十分であることの兆候かもしれない
- もし手順書が単なるやることの羅列（コマンドAを実行 -> コマンドBを実行...）であるならば、さらなる自動化が必要

アラートにメールを使うのをやめよう

メールは誰かを叩き起こすためのものではないし、そのために使おうと思うべきではない
以下のように使い分けると良い
- すぐに応答が必要なアラート: SMS, PagerDuty
- 注意が必要だがすぐのアクションが必要ないアラート: 社内チャット

手順書を書こう

先述したように単純なやることの羅列になるのは良くないが、なんらかの問題を解決するのに人間の判断や診断が必要なときのために必要なもの
特定のサービスについて以下のような質問に答えられるように書かれていると良い
- これはどのようなサービスで、何をするものか
- 責任者は誰か
- インフラ構成
- どんなアラートが設定されていて、その理由は何か
誰かがアラートに応答したとき、手順書を開くことで、何が起こっているのか、何をすべきなのかを理解できるようにしたい

プロジェクトでの監視業務改善事例：日々DBに取り込まれるログ件数の監視業務

GA4タグが送信してくる行動データや、外部APIを実行するスクリプトにより収集されるデータをDBに取り込むシステムがあるとして、このようなシステムに対して取り込まれたレコード数を日々監視することを考えます。

実際に自分のプロジェクトが辿っていった改善までのステップを以下に示します。

STEP1: 実装

まずはログの取り込みシステムを開発します。この時点では何も監視体制が存在せず、仮に上流システムに不具合があり異常に取り込み数が少ない/多いということがあっても気づくことはありませんでした。

STEP2: 手動でクエリを実行して監視する

時々、下流担当者（このDBを参照するシステムを開発している担当者）から「データが何かおかしいので調査してください」という依頼が来てその対応をするという流れが続くと、例えば定期的に以下のようなクエリを打つようになります。

SELECT time, COUNT(*) FROM target_tbl
GROUP BY time

これで1日ごとの取り込み数をチェックでき、下流担当者から修正催促を受ける前に対応完了することが増えてきました。

STEP3: 可視化してチェックを簡単にする

日毎のインポート数をグラフ化することで、1目でチェックできるようにします。例えば、以下のように1日に1レコードをExcel/SpreadSheet等に出力するようにしておき、それをグラフ化して見る、などです。

日付	インポート数
2024-10-10	255
2024-10-11	545
2024-10-12	366

これをすることで、確認時間が飛躍的に短くなりました。

STEP4: チェックの自動化

こうしてくると、大体どれくらいの変化率があった際に通知すべきなのかが見えてきます。今回の例では前日からインポート数に±10%以上の振れ幅があった場合に通知するようにします。そして、検知したらチャットに送ります。

これをすることで、検知対象の増減が発生しない限り、監視業務にかける時間を0にすることができました。

TOPIC

メールはなぜ適切ではないのか

自分のプロジェクトでも初めのうちはメールで通知を送っていました。経験談としては、メールは気づきにくく、またエラー通知を受け取ってからのアクションも起こしづらかったです。Google ChatやSlackではエラー通知に対してスレッドを掘り、そこからこの対応をお願いしますと@メンションで適切なチームに通知することができ、総合的に効率が良くなりました。

成功通知が必要か？

監視の自動化を実施すると、システムが本当に正常に動いているのか心配になることがあります。例えば、通知が来ないので日々のインポートは順調だと思っていたら、実は自動チェックシステムが正常に動いていなかっただけという事態もあり得ます。成功通知の実装については以下のメリットとデメリットを考慮して決定すると良いです。

成功通知のメリット
- 安心感の提供：システムが正常に動作していることを定期的に確認できるので、安心感を提供します。
- 早期の問題発見：もし通知が来なかった場合、それ自体が異常として認識できるので、早期に問題を発見できます。
- 透明性の確保：チーム全体がシステムの状態を把握でき、透明性が向上します。
成功通知のデメリット
- ノイズの増加：毎日成功通知が送られてくると、本当に重要な通知が埋もれてしまう可能性があります。
- 疲労感：頻繁な通知は受け取る側にとって疲労感を与えるかもしれません。

中間案としては、成功通知は週に一度や月に一度のように頻度を抑えて送ると良いかもしれません。あるいは、重要なステークホルダーには成功通知を送り、日常的な運用者にはエラーメッセージのみを送るといった形で、通知の管理を柔軟にするのも一案です。

まとめ

今回の記事では、日々の監視業務に時間を取られがちだった状況から、効率的で効果的な監視体制を構築するためのステップを具体的に示しました。

日々の監視業務に苦戦している方には、手順書の作成や自動化の導入、通知の頻度の見直し、などが参考になるかもしれません。また、監視業務改善事例を参考に、STEP2までできているのであればSTEP3をやってみる、STEP3までできているのであればSTEP4をやってみる、といった形で少しずつ改善を進めていくなども良いかと思います。