データの完全性とリストア
Google SRE Book 26章「Data Integrity: What You Read Is What You Wrote」を 取得して読み、理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
データの完全性とは、必要なデータストアに届き、かつ内容が正しいこと。
この章の中心にある言い換えが効く。
誰もバックアップが欲しいわけではない。欲しいのはリストア。
バックアップは税であって、成果ではない。 だから見るべき指標は「バックアップが取れているか」ではなく、 「実際に戻せたか、目標の時間内に」。
失われ方は24通りある
3つの軸の組み合わせで考える。どの組み合わせも同時に起きうる前提で計画する。
| 軸 | 中身 |
|---|---|
| 原因 | 利用者の操作、運用者の誤り、アプリのバグ、インフラの欠陥、ハードウェア故障、拠点の災害 |
| 範囲 | 広範(多数の実体)か、狭く特定的(一部の利用者)か |
| 速度 | 一瞬(1分で100万行が置き換わる)か、じわじわ(毎分10行が数週間続く)か |
「じわじわ」が最も見落とされる。 一瞬の大量消失は誰でも気づくが、 毎分10行が数週間続く欠損は、バックアップの保持期間を静かに食い破る。 気づいた時には、正しい状態のバックアップがもう残っていない。
3つの層
多層防御。順序に理由がある。
1層目: ソフト削除
削除された時点で使えなくするが、一定期間は保持しておく。
ソフト削除 利用者から見える機能。Gmail のゴミ箱(30日以内なら戻せる)
遅延削除 利用者からは見えない。アプリからは即座に到達不能になるが、
基盤側が数週間保持してから実際に消す
保持期間の一般的な選択肢は 15日 / 30日 / 45日 / 60日。
判断の根拠が具体的で、Google の経験では、アカウント乗っ取りとデータの 完全性の問題の大半は60日以内に報告または検知される。
この層が最初に来るのは、最も速く安いから。 利用者の誤操作と開発者の誤りには、これが効く。
2層目: バックアップとリストア
段階を分ける。
頻繁なローカルのスナップショット 保持は数時間〜数日、復元は数分
分散ストレージへのバックアップ 保持は数日〜十数日、復元は数時間
ニアライン・オフライン 保持は長期。拠点規模の災害向け
多くのサービスでは 30日〜90日のどこかに線を引くのが目安。
アプリのバグ、インフラの問題、ハードウェア故障に効く。 1層目より資源も時間もかかるので、2番目に置かれている。
3層目: 帯域外のデータ検証
破損や参照整合性の崩れを、継続的に自動で検査する。
この層が最後なのは、防ぐのではなく見つけるものだから。 1層目・2層目をすり抜けた、低速で低品位な劣化を捕まえる役割。
レプリケーションはバックアップではない
ここを取り違えると、多層防御のつもりが1層しかない状態になる。
複製を自動で同期する仕組みは、 壊れた行や誤った削除を、問題を切り離すより先に全部の複製へ押し出す。
守れるのは拠点の障害まで。アプリのバグ・利用者の誤り・低レイヤの攻撃には効かない。
鍵は多様性。 ある層の障害から守りたいなら、 その層において異なる構成要素にデータを置く必要がある。
検証は毎日やる
頻度の基準が具体的に示されている。
Gmail の開発者は、本番データに不整合を持ち込むバグが24時間以内に検知されることを 拠りどころにしていて、検証を毎日より低い頻度で走らせることを考えたくない。
たまにしか検証しないと、気づいた時には既に利用者に影響が出ている。 破損は検知されるまで広がり続ける。
運用に必要になるものは、検証の仕組みそのものより多い。
検証ジョブの管理、監視、アラート、ダッシュボード
流量の制限
調査のための道具
本番の手順書と、検証用の API
中央の基盤チームが枠組みを持ち、プロダクトのチームが業務ロジックを持つ 分担が現実的。速く動く小さなチームが、これを全部自前で設計・構築・維持するのは無理がある。
リストアを継続的に試す
最近の状態に戻せることは、実際に戻してみたときにだけ分かる。
確かめるのは、バックアップの有無ではない。
バックアップが有効で、欠けていないか
復元に足りるだけの資源があるか
現実的な時間で終わるか
復元中に状況を監視できるか
決定的な外部依存を持っていないか
演習ではなく、継続的に、可能な限り自動で。 必要になる前に壊れていると分かれば、必要になる前に直せる。
2011年2月27日の Gmail
多重の安全策と冗長性があったにもかかわらず、Gmail は相当量の利用者データを失った。
このとき使われたのが最後の砦であるオフラインのテープで、 推定完了時刻より前に99%以上を回復し、 すべてのアカウントを当初見積りから数時間以内に復旧させた。
成功の理由として挙げられているのが、定期的な予行演習と訓練。 計画と、最良慣行の順守と、労力と、協力。
最後の砦は、使われたことがあるという事実によってのみ、砦だと確認できる。
このリポジトリの他の場所との関係
| ここでの話 | 対応する場所 |
|---|---|
| 戻せることを継続的に確かめる | テスト — 壊れてほしくないものは自動で検査する |
| 破損を24時間以内に検知する | 可観測性 — 検知の仕組みの側 |
| 失った後の指揮 | インシデント対応 |
| スキーマ変更で壊した場合 | スキーマ変更の運用 — 戻せる地点を作ってから出す |
| バックアップの暗号化 | 暗号と鍵の管理 — 失った系の中にしか鍵がないバックアップは、バックアップになっていない |