## 概要 Booking.com の検索サービスを題材に、可用性・レイテンシ SLO だけでは不十分だった経験と、データ一貫性・新鮮性・完全性という「データ品質 SLO」を定義するまでの試行錯誤を語ったトークである。SREcon19 EMEA (2019-10-02) で Yoann Fouquet が発表した。30 分のセッションで、SLO の基礎復習・予約システムのアーキテクチャ紹介・SLO 定義の旅・得られた恩恵の 4 部構成をとる。 ## 主要メッセージ - **可用性とレイテンシだけでは不十分**: 最初に定義した SLO（可用性・レイテンシ・予約成功率）を見た検索サービスのステークホルダーは無関心だった(p.8)。検索サービスにとって重要なのはデータの「一貫性・新鮮性・正確性・耐久性」である(p.9)。 - **プローブによるデータ品質計測**: 一貫性 SLO の第 1 案は外部プローブが DB の注文 ID を取得して全データノードで一致を確認する方法、第 2 案はゲートウェイ内部でノード間比較を行う方法へ進化した(p.10–13)。 - **SLO が自動化の根拠になる**: Freshness Probe が SLO 違反を検知するとトラフィックを自動停止し（自動緩和）、Completeness Probe が検知すると Hadoop スナップショットから再処理して修復する（自動修復）(p.26–27 / テキスト参照)。 - **得られた最大の恩恵は Awareness と Confidence**: SLO 導入前には不可視だったデータ品質の問題が顕在化し、対応行動に根拠が生まれた(p.28 / テキスト参照)。 ## 視覚的に重要な図表 **p.5 予約システムのアーキテクチャ** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig01-reservation-system-architecture.png]] 予約サービス（DB 書き込み）→ ストリーム → 検索サービス（データノード群 + ゲートウェイ）という構成。検索クエリはゲートウェイ経由で複数のデータノードに分散される。 **p.9 欠けていた SLO の次元** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig02-missing-slos.png]] 可用性・レイテンシでは捉えられていなかった「Durability / Accuracy / Consistency / Freshness」の 4 次元が吹き出しで示される。データ集約型サービス固有の SLO 次元を整理した図。 **p.10 一貫性 SLO (第 1 案) — 外部プローブ** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig03-consistency-slo-probe.png]] プローブが DB から注文 ID を取得し、検索サービスの全データノードで同一データが返ることを確認する構成。SLO 目標: 99.99% の予約が全データノードで一致する。 **p.12 一貫性 SLO (第 2 案) — ゲートウェイ内部比較** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig04-consistency-slo-gateway.png]] ゲートウェイが複数のデータノードにクエリを発行し内部で比較する方式。第 1 案（外部 DB 参照）から第 2 案（サービス内部の自己一貫性）へと計測単位を変えた。SLO 目標: 99.99% の検索結果が一貫している。 **p.14 新鮮性 SLO — 外部プローブ** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig05-freshness-slo-probe.png]] プローブが DB から直近の予約を取得し、検索サービスに同データが出現するまでの時間を計測する構成。SLO 目標: 99.9% の予約が最長 1 分以内に検索可能になる（口頭: "at worst one minute old"）。 **p.19 予約サービス全体の SLO 構成** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig06-reservation-slos-complete.png]] Hadoop MR で耐久性(Durability)を、ストリームコンシューマー + プローブで完全性(Completeness)とレイテンシを測定する。DBアーカイブと合わせて最終的なSLO全体像。 **p.22 クエリバケット（手動分類）** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig07-query-buckets-manual.png]] クエリを特性ごとに手動でバケットに分類し、バケット別に異なるレイテンシ SLO（50ms / 100ms / 目標なし）を設定する。 **p.23 クエリバケット（自動分類）** ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig08-query-buckets-automated.png]] スコア(Score)とタイムアウト(Timeout)のしきい値に基づいてクエリを自動的にバケットへ振り分ける。`Score ≤ X AND Timeout ≥ x` → 50ms バケット、`X ≤ Score ≤ Y AND Timeout ≥ y` → 100ms バケット、`Score ≥ Y OR Low timeout` → 目標なし。 ## Booking.com のシステム規模 (2019 時点) - 1 日 150 万件以上の体験予約 - 創業 1996 年（当時 23 年） - 物理サーバー 50,000+ 台、4 データセンター (p.4) ## 定義した SLO の一覧 | SLO | 対象 | 計測方法 | 目標値 | |---|---|---|---| | 可用性 | 予約サービス | リクエスト成功率 | — | | レイテンシ | 予約サービス | クライアントレイテンシ | — | | 予約成功率(Res. success rate) | 予約サービス | — | — | | 可用性 | 検索サービス | — | — | | レイテンシ | 検索サービス | — | — | | 一貫性 (Consistency) | 検索サービス | 外部プローブ → 全ノード比較 | 99.99% | | 一貫性 (第2案) | 検索サービス | ゲートウェイ内部比較 | 99.99% | | 新鮮性 (Freshness) | 検索サービス | 外部プローブ | 99.9% / 最長1分以内 | | 耐久性 (Durability) | 予約ストリーム | Hadoop MR | — | | 完全性 (Completeness) | 予約ストリーム | プローブ | — | | 可用性・レイテンシ (バケット別) | 検索クエリ | バケット自動分類 | 50ms / 100ms | 注: 正確度(Accuracy)・耐久性(Durability)の SLO 定義は断念している(p.16–17)。口頭では「パイプラインの 90% を無視して、監視がない Storage と比較しようとしていた。何が入っているか分からない状態では測れなかった」と説明している（transcript l.186–195）。 ## SLO が有効化した自動化 ### 自動緩和 (Auto. Mitigation) Freshness Probe が新鮮性 SLO 違反を検知すると、影響を受けたデータノードをトラフィックから自動的に除外する。複数のデータノードがあるため、1 ノードを切り離しても他ノードでサービスを継続できる（transcript l.327–335）。 ### 自動修復 (Auto. Repair) - **データノードの日次リセット**: MapReduce ジョブが全データの整合性（参照先の存在確認・バージョン順序確認等）をチェックし、エラーを検出して修復する。23 年分のデータのスナップショットを毎日ダンプしてデータノードに上書きするため、古いレコードを個別に検証する必要がなくなった（transcript l.339–347）。 - **ストリームの再エンキュー**: Completeness Probe が「受け取り漏れ」を検知すると、予約サービスに再送信を要求して再エンキューする。インシデント発生時にはページングより前に緩和が始まる（transcript l.348–365）。 ## SLO 導入の恩恵 ### Awareness（意識の変化） HTTP サービスの障害は可用性ダッシュボードで即座に可視化され、全員が反応する。一方、サービスが 200 を返しながら不正なデータを返している場合は誰も気づきにくい。SLO によってデータ品質の問題が「契約違反」として格付けされ、「この SLO が違反されている」と主張することで優先度が明確になる（transcript l.368–393）。 ### Confidence（信頼の確立） 利用者側はサービスのレスポンスが正しいかを都度検証していない（実際には検証不可能なことも多い）。SLO が「このデータは常に良質だ」と保証することで、利用者は結果を盲目的に信用してサービスを使えるようになる（transcript l.395–406）。 ## Q&A (transcript l.408–498) **Q: 可用性(Availability)と予約成功率(Success Rate)の違いは？** > A: 可用性は HTTP レスポンスの成否（200 を返したかどうか）。予約成功率は、200 を返した後に実際に予約が完了したかどうか。例えば 200 を返したが決済処理で後から失敗した場合、可用性は正常だが予約成功率は落ちる（transcript l.413–442）。 **Q: SLO 違反時に依存サービス（Storage など）に何か強制力はあるか？** > A: 強制力（ペナルティ等）はないが、SLI 違反の原因サービスに技術メトリクスとともにアラートを送る仕組みを構築した。自サービスの SLI 違反が外部依存に起因していると判明した場合、自チームをページングせずに依存先チームだけに通知して対応を待つことも可能になった（transcript l.445–497）。 ## 概念・実体への接続 - 概念: [[サービスレベル目標]] / [[SLI-SLO段階的導入]] / [[データ品質SLO]] / [[合成モニタリング]] - エンティティ: [[Yoann Fouquet]] / [[Booking.com]] - 関連 MOC: [[structures/SRE - MOC]] ## 限界・不確実点 - p.21 の可用性・レイテンシダッシュボード数値（Client Latency 96.983%/99.5%、Availability 99.031%/99.99%）が実際の本番 SLO 状態なのかデモ用の値なのかは不明。 - Whisper 自動書き起こしのため固有名詞の誤認識がある（例: 冒頭の "adversary" は "SRE" の誤認識とみられる）。 - p.26–27 の画像は API サイズ制限のため直接確認できておらず、内容はテキスト抽出とトランスクリプトで補完している。