# データ品質 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]])。
- **Booking.com の実務的な5次元(一貫性・新鮮性・完全性・耐久性・正確性)は、Hidalgo の書籍が体系化する13属性タクソノミーの部分集合として位置づけ直せる**: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]]は、データの信頼性属性をデータ属性7個(鮮度・完全性・一貫性・厳密性・妥当性・整合性・耐久性)とデータアプリケーション属性6個(セキュリティ・可用性・スケーラビリティ・パフォーマンス・回復力・堅牢性)に分解する。Booking.com の「新鮮性」は書籍の「鮮度」、「一貫性」「完全性」「耐久性」はそれぞれ同名の属性にそのまま対応するが、Booking.com が一括りに扱った「正確性」は、書籍では**厳密性(Accuracy: 事実との一致)**と**妥当性(Validity: スキーマ・ビジネスルールへの適合)**という2つの独立した計測可能な属性に分解される。両者は独立に成立しうる(妥当だが厳密でない、あるいはその逆)という書籍の指摘は、Booking.com が Accuracy SLO を一枚岩の指標として定義しようとして断念した理由を後付けで説明する(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]])。
- **一貫性計測の「差異の定量化」という書籍側の抽象原理は、Booking.com の2つの具体的な計測パターンをともに説明する**: 書籍は一貫性の計測を「オブジェクトの2つ以上の表現の差異を定量化すること」と定義し、比較対象になりうる表現として上流の信号・冗長コピー・下流ストレージ・権威あるソースを挙げる。Booking.com の「外部プローブ型(DB という権威あるソースとの比較)」と「サービス内部比較型(DataNode 間という冗長コピー同士の比較)」は、この抽象原理が実務で取りうる2つの具体形であったと整理できる(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] §11.3.2.3)。
## 未解決の問い
- 新鮮性 SLO「最長1分以内」は Booking.com の文脈では妥当だが、他のドメインではどのように目標値を決定するか。ユーザー体験との関係をどう測定するか。
- 複数のデータノードが存在する場合、「一貫性率」の分母は何か（クエリ数？予約数？ノードペア数？）。
- データ品質 SLO の違反はユーザー体験にどう影響するか。Error Budget の消費基準をどう設定するか。
- ~~Accuracy SLO 定義の困難を乗り越える方法として、どのようなアプローチが考えられるか~~ → **部分的に解決**: Hidalgo の書籍は「正確性」を厳密性(事実との一致)と妥当性(構文・ルール適合)に分解することを提案する。厳密性は権威ある参照データセットとの照合や定期的な現実世界の在庫確認で計測でき、妥当性はスキーマ検証で機械的に計測できる。ただし「権威ある参照データセットをどう用意するか」という Booking.com の実務課題そのものは書籍でも解決されていない。
## 関連
- 概念: [[サービスレベル目標]] / [[SLI-SLO段階的導入]] / [[合成モニタリング]]
- エンティティ: [[Yoann Fouquet]] / [[Booking.com]] / [[Alex Hidalgo]]
- ソース: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]]
- 関連 MOC: [[structures/SRE - MOC]]