# データ完全性 ## 定義 データ完全性(data integrity)とは、データストアの正確性とアクセス可能性の尺度であるだけでなく、ユーザ視点で「クラウド上のサービスがアクセス可能であり続け、そのアクセスが完全な状態に保たれていること」を指す。データ完全性は可用性(uptime)とは独立の要求であり、両者は数値上似たSLO(例: 99.99%)であっても意味も帰結もまったく異なる——99.99%の稼働率SLOは年間1時間程度のダウンタイムを許すが、99.99%の正常バイト率SLOは2GBのアーティファクトで最大200KBの破損を意味し、実行ファイルやデータベースを不可逆に破壊しうる致命的な水準である。データ完全性の達成手段として実務がまず思い浮かべるのはバックアップだが、真に価値を持つのはバックアップそのものではなく「復旧できること」であり、これは継続的なエンドツーエンドの復旧テストによってのみ検証できる。バックアップは復旧のために払う税金にすぎず、税金そのものを目的化してはならない。(Source: [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]]) データ完全性への防御は多層防御(defense in depth)として設計する。第1層はソフト削除(ユーザ操作・開発者操作いずれによる誤削除にも猶予期間を与える)、第2層はバックアップとその復旧手法、第3層は定期的なout-of-bandのデータ検証(早期検知)である。各層は前の層より発生頻度の低い障害シナリオを守るために存在し、いずれの層もレプリケーションでは代替できない——自動同期するレプリカは、破損した行や誤った削除も即座に全コピーへ伝播させてしまうため、レプリケーションと冗長性は復旧可能性(recoverability)そのものではない。障害モードは根本原因・影響範囲・発生速度という3つの独立した軸の組み合わせで24通りに分類でき、単一の戦略ではこれらすべてをカバーできない。(Source: [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]]) ## 横断的知見 - **データ完全性の早期検知は、グレイ障害の「Observer/App 観測非対称性」と同型の構造を持つが、対象が可用性ではなくデータの正しさである点で異なる**: [[グレイ障害]]([[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]])は、システム内部の Observer が「健全」と報告する一方でアプリケーション利用者が劣化を経験する非対称性を核心とする。本ページのSRE Book第26章が説く out-of-band データ検証も構造は同じである——ストレージAPIが「書き込み・読み出しは成功した」と報告していても、実際にはデータが破損・欠落している可能性があり、アプリケーションは自分自身で検証(trust but verify)しない限り「100%のデータが健全である」ことを知りえない。両者の違いは、グレイ障害が主に**性能・可用性の劣化**の観測ギャップを扱うのに対し、本ページのデータ完全性は**データの正しさそのもの**の観測ギャップを扱う点にある。Gmailのデータ検証器は日次で稼働し、本番投入から24時間以内にバグを検知できるという安心感がエンジニアの開発速度を上げたと報告されており、これは[[グレイ障害]]が論じる「プロアクティブ検証がエンジニアリング速度を支える」という構図とも符合する。(Source: [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]], [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) ## 未解決の問い - 「バックアップではなく復旧が目的である」という原則を運用に落とし込むとき、復旧テストの自動化・継続実行のコストは、バックアップそのものの保存コストと比べてどの程度になるべきか。本章は「継続的にテストせよ」と述べるが、テストの頻度・粒度・コストのトレードオフには踏み込んでいない。 - 障害モードの3軸(根本原因・影響範囲・発生速度)24通りの組み合わせのうち、実際にどの組み合わせがもっとも高頻度・高インパクトなのか。本章はGoogleの19件の復旧事例調査から「ソフトウェアバグによるデータ削除・参照整合性の喪失」が最も一般的だったと述べるが、24通り全体の頻度分布は示されていない。 - out-of-band データ検証の「厳しすぎると放棄され、緩すぎると見逃す」というバランスの取り方を、具体的にどのような指標・プロセスで運用可能にするか。 - データ完全性の早期検知(本ページ)とグレイ障害検知は、検知対象(データ正しさ 対 性能・可用性)は異なるが検知手法(統計的なピア比較・閾値設計)は転用可能か。[[PERSEUS]]のようなグレイ障害検知手法の統計的アプローチは、データ検証バリデータの設計にも応用できるか。 ## 関連 - ソース: [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]] - 概念: [[データ保護]](バックアップ・スナップショット・レプリケーションの技術的手段) / [[グレイ障害]](観測非対称性という同型の構造) - 実体: [[Raymond Blum]] / [[Rhandeev Singh]] / [[Gmail]] / [[Google Music]] - 書籍: [[SRE Book]] ## 出典 - [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]](Raymond Blum, Rhandeev Singh, "Data Integrity: What You Read Is What You Wrote", Betsy Beyer et al. (eds.), *Site Reliability Engineering*, O'Reilly, 2016, Chapter 26)