データ基盤の監視は、Webアプリの監視とは似て非なるものです。APIが200を返していても、上流のCDCが止まっていればダッシュボードの数字は昨日のまま固まります。サーバーは健康、パイプラインも緑、それなのに経営会議で「先週の売上が入っていない」と指摘される――この静かな故障を見抜くための設計が、データ基盤の監視です。本記事では、何を・いつ・どうアラートするのかを3軸で整理し、現場で運用に耐える監視体系を示します。
データ基盤監視の重要性
データ基盤の障害は、Webサービスの障害と違って「目に見えない」のが特徴です。500エラーでユーザーが騒ぐこともなく、アラートも鳴らないままデータの鮮度だけが古くなり、数日後にビジネス側から「数字が合わない」と指摘されて初めて気づく、というケースが少なくありません。意思決定の土台が静かに崩れていく、この遅延型の障害こそが最大のリスクです。
だからこそ、データ基盤の監視は「動いていること」ではなく「正しいデータが、正しい時刻に、正しい場所に届いていること」を確認する設計が必要です。インフラ、パイプライン、データ品質、コストの4レイヤーを監視対象として整理し、それぞれに適したメトリクスとアラートを配置していきます。関連トピックはデータオブザーバビリティでも詳しく扱っています。
何を監視するか――4カテゴリの監視指標
監視対象は大きく「インフラ」「パイプライン」「データ品質」「コスト」の4カテゴリに分けて整理するのが実践的です。闇雲にメトリクスを増やすと通知の海に溺れますので、まずはこの4カテゴリそれぞれで最重要指標を1〜2個選び、段階的に増やしていくアプローチをおすすめします。
| カテゴリ | 代表的な監視指標 | 目的 | 推奨ツール例 |
|---|---|---|---|
| インフラ | CPU/メモリ/ディスクI/O、ネットワーク遅延 | 基盤リソースの健全性確認 | Datadog、CloudWatch、Prometheus |
| パイプライン | ジョブ成功率、実行時間、SLA達成率、リトライ回数 | 処理の完走と時間順守の確認 | Airflow UI、Dagster、Prefect |
| データ品質 | 鮮度、件数変動、NULL率、ユニーク性、値域 | 中身の正しさと鮮度の担保 | dbt tests、Elementary、Monte Carlo |
| コスト | クレジット消費、スキャン量、ストレージ増加率 | 予算超過の早期検知 | Snowflake Resource Monitor、GCPビリング |
この4カテゴリのうち、最優先で実装すべきは「データ品質」の鮮度監視です。インフラもパイプラインも正常に見えているのにデータが古い、という事象はクラウドDWH時代に頻発します。最終更新タイムスタンプがSLAの閾値を超えたら即アラートする仕組みを、最初に組み込んでおきましょう。
いつアラートするか――閾値設計
閾値設計で最も重要なのは、アラートに「重要度」を付与することです。すべてのアラートを同じ通知先に送り続けると、やがて誰も見なくなる「通知コスプレ」状態に陥ります。一般的にはCritical(即対応)、Warning(翌営業日対応)、Info(ログのみ)の3段階で設計するのが現実的です。
| 重要度 | 対象事象の例 | 通知方法 | 対応SLA |
|---|---|---|---|
| Critical | 主要マートの鮮度SLA違反、本番パイプライン停止 | 電話/PagerDuty+Slack | 15〜30分以内に一次対応 |
| Warning | 件数の±30%変動、単発ジョブ失敗 | Slack専用チャネル | 翌営業日中にトリアージ |
| Info | テスト警告、クエリコスト上振れ | ログ/ダッシュボード | 週次レビューで確認 |
dbt testsを使えば、品質テストの結果を重要度別にハンドリングできます。severityを明示的に指定することで、同じテストファイルの中で「壊れたら止める」と「壊れても警告だけ」を切り分けられるのが便利です。
# models/marts/schema.yml
version: 2
models:
- name: fct_orders
columns:
- name: order_id
tests:
- unique:
severity: error # Critical扱い、CIで失敗
- not_null:
severity: warn # Warning扱い、通知のみ
閾値は「固定」ではなく「動的」に設計することも検討しましょう。前週同曜日比や前月比など、過去の分布から自動で閾値を算出する統計的アプローチは、ノイズを大きく減らします。詳しい実装はオブザーバビリティツール比較も参考にしてください。
どうアラートするか――通知チャネルとエスカレーション
アラートは「誰に・どの順で・何分以内に」を決めて初めて機能します。PagerDutyなどのオンコール管理ツールを使い、一次対応者が反応しなければ二次、三次へとエスカレーションする設計が基本です。データチーム独自のオンコールローテーションを組むか、既存のSREチームに相乗りするかは組織次第ですが、いずれにせよ「鳴ったら誰が取るか」を明文化しておく必要があります。
【エスカレーションフロー】
[アラート発火]
|
v
[一次対応: オンコール担当者] --5分以内に確認--> [対応開始]
|
| 5分応答なし
v
[二次対応: チームリード] --10分以内に確認--> [対応開始]
|
| さらに10分応答なし
v
[三次対応: マネージャー] --> 体制再編成・広報判断
※ Criticalのみ電話通知、Warning以下はSlack通知に限定
通知チャネルはSlack中心にしつつ、Criticalだけは必ず電話やPush通知まで届くよう多重化しておきます。Slackだけに依存すると、深夜の障害時に誰も気づかない事態が起こり得ます。またインシデント管理のプロセスと接続し、アラートから振り返りまでを一続きにする設計が理想です。
監視ツールの選択
監視ツールはレイヤーごとに得意分野が異なります。1つのツールですべてを賄おうとするとどうしても穴ができますので、インフラ監視とデータオブザーバビリティを分けるのが現実的な選択です。
| ツール | 得意領域 | 価格帯 | 向いているチーム |
|---|---|---|---|
| Datadog | インフラ/APM/ログ統合監視 | 中〜高 | SRE併設のデータチーム |
| Elementary(OSS) | dbtベースのデータ品質監視 | 無料(OSS) | dbt中心の中小規模チーム |
| Monte Carlo | 機械学習ベースの異常検知 | 高 | 大規模・ミッションクリティカル |
| Bigeye | SLAベースのデータ品質監視 | 中 | SLA駆動の運用重視チーム |
| CloudWatch/Azure Monitor | 各クラウドのインフラ監視 | 低〜中 | 単一クラウド構成のチーム |
まずはOSSのElementaryで無料でデータ品質監視を始め、規模拡大に応じて商用ツールへの移行を検討するのが費用対効果の高いアプローチです。Airflowの実行履歴を監視の起点にする場合も、この選択は変わりません。
アラート疲れを防ぐ設計
監視の最大の敵は障害ではなく、実は「アラート疲れ」です。人間は1日に30件以上のアラートに晒されると、鈍感になり重要なアラートも見逃すようになります。アラート疲れを防ぐためには、以下の3点セットが有効です。第一に、アラートの定期レビューです。週次または月次で「このアラートは本当に対応が必要だったか」を振り返り、ノイズと判断されたものは閾値を見直すか削除します。
第二に、ランブック(対応手順書)の整備です。アラートが鳴ったときに「このアラートが来たら、このSQLを流して原因を確認し、こう対応する」という手順が用意されていれば、対応コストは激減します。第三に、類似アラートのグルーピングです。同じ原因から派生する複数のアラートを1つにまとめる機能をツール側で活用し、通知の総量を抑えます。これらを組み合わせることで、アラートは「鳴ったら必ず対応する通知」として信頼を取り戻せます。
まとめ
データ基盤の監視は、インフラ・パイプライン・データ品質・コストの4カテゴリを押さえ、重要度別の閾値とエスカレーション設計を組み合わせることで機能します。特にデータの鮮度監視は、最初の一歩として取り組むべき最優先の施策です。監視は「鳴らすこと」ではなく「意思決定を守ること」だと意識し、アラート疲れを起こさない運用設計を心がけてください。CI/CDとの連携も、継続的な品質担保に欠かせません。
よくある質問(FAQ)
Q. データ基盤で最も重要な監視指標は?
データの鮮度(最終更新タイムスタンプ)が最重要です。パイプラインが動いていてもデータが古ければ、分析結果は信頼できません。まずはマート層の主要テーブルすべてに鮮度SLAを定義し、閾値超過で即座にアラートする仕組みを構築しましょう。
Q. 監視ツールは何を使うべきですか?
既存のインフラ監視(Datadog、CloudWatch等)に加え、データ品質監視にはElementary(OSS)やMonte Carlo(商用)が効果的です。1つのツールで完結させようとせず、レイヤーごとに最適なツールを組み合わせる構成が現実的です。
Q. アラート疲れを防ぐには?
重要度の3段階分類(Critical/Warning/Info)、ノイズの定期レビュー、ランブック(対応手順書)の整備が基本対策です。加えて、類似アラートのグルーピングとオンコールローテーションの整備で、対応負荷を分散させることが有効です。