データパイプラインの「監視」と「オブザーバビリティ」は、似ているようで違います。監視は「パイプラインが動いているか」を確認します。オブザーバビリティは「パイプラインが正しく動いているか」を確認します。この違いは小さいようで、実際の障害対応では大きな差になります。この記事では、データオブザーバビリティの基本概念と、実装の始め方を説明します。

監視とオブザーバビリティの違い

従来の監視は、パイプラインが「完了したか」「エラーが出たか」を確認します。しかしパイプラインが正常に完了しても、データが間違っている場合があります。例えば、ソーステーブルのスキーマが変わってカラムが NULL になっていても、パイプライン自体はエラーなく完了します。オブザーバビリティは、データの中身まで確認することで、この種の「静かな障害」を検知します。

オブザーバビリティの三つの観点

データオブザーバビリティは、新鮮性・完全性・整合性の三つの観点で評価します。新鮮性は「データが期待した時間内に届いているか」。完全性は「期待したレコード数が揃っているか」。整合性は「値の範囲や型が期待通りか」。この三つを定期的にチェックする仕組みを作ることが、オブザーバビリティの基本です。

小規模チームが始めやすい実装

オブザーバビリティを一から実装しようとすると、設定項目が多くて挫折しがちです。まず、最も重要な KPI に使われているテーブルを一つ選び、そのテーブルの行数と更新時刻だけを監視することから始めます。行数が前日比で 50% 以上減ったらアラートを出す、更新が 2 時間遅れたらアラートを出す、という単純なルールでも、多くの障害を早期に検知できます。

BlendAlert でのオブザーバビリティ設定

BlendAlert では、テーブルの行数・NULL 率・値の範囲・更新時刻を監視するルールをパイプラインごとに設定できます。閾値を超えたら Slack または PagerDuty に通知します。深夜の不要な通知を減らすため、サイレント時間帯の設定も可能です。設定は GUI から行えるため、コードを書かずに基本的なオブザーバビリティを整備できます。

オブザーバビリティを文化にする

ツールを入れるだけでは、オブザーバビリティは定着しません。アラートが鳴ったときに誰が対応するか、対応後に事後レポートを書くかどうか、という運用ルールを決めることが重要です。Dex BlendMesh では、自社プラットフォームの障害事後レポートを全ユーザーに公開しています。これは、オブザーバビリティを文化として実践するための取り組みの一つです。

データオブザーバビリティは、大規模なチームだけのものではありません。小さなチームほど、早い段階で整備しておくと後の負債が減ります。BlendAlert の 14 日間無料トライアルで、まず主要テーブルの監視から始めてみてください。