# データ品質 SLO
## 定義
データ品質 SLO とは、検索インデックスや推薦エンジンのようなデータ集約型サービスにおいて、可用性・レイテンシといった従来の「通信品質 SLO」では捉えられないデータ内容の正確性・一貫性・新鮮性・完全性・耐久性を定量的な目標として設定したものである。サービスが「動いている」ことと「正しいデータを返している」ことは別問題であり、後者を明示的に SLO 化する必要がある(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。
### データ品質の主要次元
| 次元 | 説明 | 計測例 |
|---|---|---|
| **一貫性 (Consistency)** | 複数のデータノード・レプリカ間でデータが一致している割合 | 全データノードで同一クエリの結果が一致する予約の割合 |
| **新鮮性 (Freshness)** | ソースシステムへの書き込みから検索サービスへ反映されるまでの時間 | 予約後 最長1分以内に検索サービスで出現する割合 |
| **完全性 (Completeness)** | ストリーム処理によって欠落なくコンシューマーへ届く割合 | ストリームの予約イベントが Consumer に到達する割合 |
| **耐久性 (Durability)** | データがアーカイブ・バックアップに正しく保存されている割合 | Hadoop MR でアーカイブされた予約の割合 |
| **正確性 (Accuracy)** | データの内容が正しい割合 | — (定義困難として断念される場合がある) |
## 計測パターン
### 外部プローブ（合成モニタリング）
プローブがソース DB（または最近の書き込み）を参照し、対象サービスで期待通りのデータが返ることを確認する。新鮮性・一貫性の計測に有効。
```
プローブ
→ DB から最近の注文 ID を取得
→ 検索サービスで全データノードにクエリ
→ 結果を比較して一致率・出現時間を計算
```
### サービス内部比較
ゲートウェイが複数のデータノードにクエリを発行し内部で比較する方式。外部 DB 参照なしにサービスの自己一貫性を計測できる。
```
ゲートウェイ
→ DataNode-1, DataNode-2, DataNode-3 に同時クエリ
→ 結果を比較 → 一致率を SLI として記録
```
(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] p.12)
## Booking.com 検索サービスでの実例
| SLO | 計測方式 | 目標値 |
|---|---|---|
| データ一貫性 (第1案) | 外部プローブ → 全ノード比較 | 99.99% の予約が全データノードで一致 |
| データ一貫性 (第2案) | ゲートウェイ内部比較 | 99.99% の検索結果が一貫 |
| データ新鮮性 | 外部プローブ | 99.9% の予約が 最長1分以内に検索可能 |
| 完全性 | ストリームコンシューマー + プローブ | — |
| 耐久性 | Hadoop MR パイプライン | — |
(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])
## データ品質 SLO が有効化する自動化
SLO が明確に定義されると、SLO 違反に対する自動化アクションの根拠が生まれる:
- **自動緩和**: Freshness Probe が新鮮性 SLO 違反を検知 → 影響ノードへのトラフィックを自動停止。
- **自動修復**: Completeness Probe が欠損を検知 → Hadoop スナップショットから再処理して修復。
(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] テキスト p.197–230)
## 横断的知見
- **可用性・レイテンシ SLO は「サービスが動いているか」を示すが、「正しいデータを返しているか」は示さない**: Booking.com の事例では、可用性・レイテンシ SLO を設定しても検索サービスのステークホルダーは無関心だった。彼らにとって重要なのはデータの品質であり、それが計測されていないことが問題の核心だった (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。
- **一貫性 SLO の計測方式は「外部 DB 参照型」と「サービス内部比較型」に大別される**: 外部プローブ型は正準データ（DB）との比較で絶対的な一貫性を測るが、ソースへのアクセスが必要。内部比較型はサービスの自己一貫性（レプリカ間の同一性）を測り、外部依存が少ない (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。
- **正確性(Accuracy)の SLO 定義は困難**: Booking.com は Accuracy/Durability SLO の定義を試みたが断念した。「何が正確か」の基準が曖昧なデータでは SLI の設計そのものが難しい (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。
## 未解決の問い
- 新鮮性 SLO「最長1分以内」は Booking.com の文脈では妥当だが、他のドメインではどのように目標値を決定するか。ユーザー体験との関係をどう測定するか。
- 複数のデータノードが存在する場合、「一貫性率」の分母は何か（クエリ数？予約数？ノードペア数？）。
- データ品質 SLO の違反はユーザー体験にどう影響するか。Error Budget の消費基準をどう設定するか。
- Accuracy SLO 定義の困難を乗り越える方法として、どのようなアプローチが考えられるか（e.g., A/B 比較、Ground Truth との照合）。
## 関連
- 概念: [[サービスレベル目標]] / [[SLI-SLO段階的導入]] / [[合成モニタリング]]
- エンティティ: [[Yoann Fouquet]] / [[Booking.com]]
- ソース: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]]
- 関連 MOC: [[structures/SRE - MOC]]