# データ保護 ## 定義 データ保護(data protection)は、ユーザの誤削除からデータセンタの災害まで、あらゆる規模のデータ損失・データ破損に対してデータを守る一連の手段の総称である。『ウェブオペレーション』14章は、バックアップ・スナップショット・レプリケーションという3つの基本手段を、データ資産の棚卸しで決めたRTO(目標復旧時間)・RPO(目標復旧時点)に照らして組み合わせることを説く。バックアップは、データのコンテンツを仮想/物理テープや別のストレージにコピーするものであり、最低限だが標準的なデータ保護である。スナップショットは、データと同じディスクサブシステムに保存する、ある時点のデータの状態である。両者の違いは保存場所であり、スナップショットはディスクサブシステム自体の障害には無力である。レプリケーションは、他のストレージシステムへデータを複製する手段であり、同期・非同期の2方式がある。著者は、これら単体ではいずれも不十分であり、夜間バックアップ・ローカル複製・トランザクションログの保存を組み合わせて初めて実用的な保護になると述べる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## バックアップの一貫性レベル アプリケーションはデータ/メタデータの変更をファイルシステム・LUN・データベースに対して行う。この操作の途中にバックアップを取ると、データの一部分だけが書き込まれた**非一貫性バックアップ**になる。途中のデータを含まないバックアップは**アプリケーション一貫性バックアップ**(単に一貫性バックアップ)と呼ばれる。アプリケーションが非一貫性バックアップからの復旧を前提に設計されている場合、それは**クラッシュ一貫性バックアップ**と呼ばれ、復旧したデータが使用可能かどうかの検証に時間を要する。著者は、クラッシュ一貫性バックアップだけに頼るのは適切でないとし、一貫性バックアップを別途用意したうえで、クラッシュ一貫性バックアップをスナップショットとして取得する組み合わせを推奨する。現代の多くのアプリケーションは、操作を数秒止めるだけで一貫性バックアップを取得できる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## 同期レプリケーションと非同期レプリケーション 同期レプリケーションは、書き込みデータをレプリケーション先へ確実にコミットしてから応答するため、両システムのデータは常に最新に保たれる。ただし、クライアントへの応答時間にレプリケーション送信時間が加算され、この遅延はストレージシステム間の物理的距離に比例するため、数百マイルを超えると許容できないレベルまでパフォーマンスが低下する。非同期レプリケーションは、書き込みを受け付けてから一定時間後にレプリケーション先へ送るため距離・遅延の影響を受けないが、送信前にプライマリシステムに障害が発生したり通信が長期間切れたりすると、その分のデータを失う可能性がある。どちらを選ぶかはRTO・RPOで決まり、いかなるデータ損失も許さない方針なら同期、数分〜数時間の損失が許容できるなら非同期でよい。近距離は同期、遠距離は非同期という組み合わせも可能である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## スナップショット無効化による永久喪失の実例 著者は、マルチテラバイトのMySQLデータベースをスナップショット機能付きNFSアプライアンスに置いていた事例を語る。ストレージには災害復旧用の複製もデータベースのバックアップもなく、容量も限界に近づいていた。DBAと協議のうえ、他所への複製・定期スナップショット・トランザクションログの別所保存を導入する移行を進めたが、移行が半分進んだ時点でDBAがまだコピーしていないテーブルを誤削除した。復旧のためにスナップショットを確認したところ、スナップショットが意図的に無効化されており、削除前の状態に戻せず、データは永久に失われた。根本原因分析では、誰が・なぜ無効化したかは特定できなかった。著者はこの経験から「ごく少数の例外はあるものの、常にスナップショットを有効にしておくこと」を教訓として導く。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## 非同期レプリケーションとフェイルオーバーの実例 著者は、ロンドンからダブリンへ非同期複製していた重要アプリケーションの事例も語る。ロンドンで異常な熱波が発生し、データセンタの冷却システムが数十台連鎖的に故障するカスケード障害が起きた。温度センサーの検知で数千台のサーバがシャットダウンされ、夜になって温度が下がったところでダブリンへのフェイルオーバーが検討されたが、非同期レプリケーションを使っていたためデータがまだダブリンに複製されていない可能性があり、後からのマージは容易ではなかった。結局ロンドンの温度が正常化してからネットワークとストレージを復旧し、データをダブリンへ複製し終えてからフェイルオーバーを完了させた。教訓は、過去の傾向(ロンドンは猛暑が続かない)だけで将来のリスクを予測しないことと、非同期のままフェイルオーバーすると都合よくデータをマージできないことである。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## 横断的知見 - **RTO/RPOは「サイト・データセンタ単位」と「個々のデータ資産単位」という異なる粒度で論じられる**: [[事業継続計画（BCP）]]が集約する[[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]]は、RTO・RPOを「9の数で語らない実務的な可用性指標」としてサイト全体・フェイルオーバーアーキテクチャ(ホット/ホット、ホット/ウォームなど)の文脈で扱う。これに対し本ページの[[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]]は、同じRTO・RPOという指標を、データ資産の棚卸表の1行(例: 「作物データベース」というアプリケーション固有のデータ)に対して個別に設定するものとして扱う。前者はデータセンタ・アプリケーション全体を落とすかどうかの意思決定に、後者は特定のストレージシステムがどれだけの頻度でバックアップを取るべきかという運用判断に、それぞれRTO・RPOを接続しており、同じ指標が異なる抽象度の意思決定に使われることを示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.2) - **非同期レプリケーションが抱える「フェイルオーバー時の未複製データ」という同一の問題が、データ層とサイト層の双方から独立に報告される**: 本ページのロンドン-ダブリンの事例は、非同期レプリケーションのままフェイルオーバーするとデータのマージが容易でないことを、ストレージ運用者の視点から具体的に示す。[[事業継続計画（BCP）]]が集約するホット/ウォーム構成の「致命的な読み取り」(最新版が到達する前に他拠点から読み取ってしまう)も同根の問題であり、両者は「レプリケーション遅延」というストレージ層の制約が、サイト全体のフェイルオーバー設計に直接波及することを、異なる具体例で裏づけている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.1) - **RTO/RPOという定量指標による設計(本ページ)と「バックアップではなく復旧が目的である」という定性的な原則(SRE Book第26章)は、同じ「バックアップは手段であって目的ではない」という結論に、異なる方法論で到達している**: 本ページの『ウェブオペレーション』14章は、バックアップ・スナップショット・レプリケーションという3手段を、データ資産ごとのRTO(目標復旧時間)・RPO(目標復旧時点)という定量指標に照らして選択することを説く。一方[[データ完全性]]([[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]])はRTO/RPOという用語こそ使わないが、「バックアップは復旧のために払う税金にすぎず、価値を生むのは復旧できることの継続的な検証である」という定性的な原則を掲げ、階層化バックアップ戦略(層ごとに保持期間・復旧時間・コストが異なる)で同じ発想を具体化する。両者はいずれも「バックアップを取ること」自体を目標にする発想を明示的に退けるが、前者はこれを数値指標(RTO/RPO)に翻訳して個々のデータ資産に割り当てる設計論として、後者は復旧の実演・演習という運用文化の問題として論じており、同じ結論に至る2つの異なる経路を示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.1, [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]]) - **「スナップショットが誰にも気づかれず無効化されていた」という本ページの実例は、SRE Book第26章が説く「復旧プロセスは継続的にテストしない限りいつの間にか壊れている」という原則の具体的な裏づけになる**: 本ページのMySQLデータベース誤削除事例では、スナップショット機能が(誰が・なぜかは特定できないまま)無効化されており、削除前の状態に戻せなかった。[[データ完全性]]が説く「システム構成要素は継続的に運用されない限り、いざ必要になったときに壊れている」という原則([[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]])は、まさにこの種の"サイレントな劣化"を防ぐために「復旧プロセスの常時テストとハートビート型アラート」を処方箋として提示しており、本ページの実例が持つ「根本原因不明のまま終わった」という未解決の問い(下記)に対する一般的な解法を、別ソースの原則として補完する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2, [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]]) - **バックアップの階層化(RTO/RPO)と、セキュリティログの段階的劣化(データサマリゼーション)は、異なる対象に対する同一の「限られた予算内で価値の高いデータを長く高精度に残す」という階層化原則の適用である**: 本ページの『ウェブオペレーション』14章は、バックアップ・スナップショット・レプリケーションをデータ資産ごとのRTO・RPOに照らして組み合わせ、層ごとに保持期間・復旧時間・コストの異なる構成を推奨する。[[セキュリティログの設計と保護]]が集約する*Building Secure and Reliable Systems*第15章も、ストレージ上限に達したら収集を止めるのではなく、全量ログの一部を低精度な要約データへ切り替えて段階的に劣化させる(完全パケットキャプチャは*N*日で削除するがネットフローデータは1年保持する、など)ことを推奨しており、対象(バックアップ対セキュリティログ)は異なるが「価値の高いデータほど長く高精度に、価値の低いデータほど早く低精度に落とす」という同じ設計判断に独立に到達している。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs > Budget for Logging) ## 未解決の問い - スナップショットが意図的に無効化されていた根本原因(誰が・なぜ)は本章でも特定されないまま終わっている。運用上、スナップショットの無効化を防ぐ・検知するための具体的な仕組み(変更管理・監視・アラート)はどうあるべきか。 - クラッシュ一貫性バックアップとアプリケーション一貫性バックアップを併用する場合、両者の取得頻度・保持期間の最適な比率はどう決めるべきか。本章は組み合わせの有効性を述べるが、具体的な運用設計には踏み込んでいない。 - 同期レプリケーションが実用的な距離の上限(本章は「数百マイル」とのみ述べる)は、ネットワーク技術の進化(専用線・低遅延インターコネクト)でどこまで伸びるか。 - 「知らないでいることを知らない」(unknown unknowns)相関障害・運用者の操作ミスが現実のデータ損失の主因であるという[[データ耐久性]]の知見と、本ページのスナップショット無効化事例(運用者の操作ミスに起因)はどう接続できるか。 ## 関連 - 概念: [[事業継続計画（BCP）]](RTO/RPOをサイト・データセンタ単位で論じる) / [[キャパシティ計画]](本章の別の主題。RPO割れを引き起こす接点を持つ) / [[データセンター信頼性]] / [[データ耐久性]] / [[ハードディスク信頼性]] / [[データ完全性]](「バックアップでなく復旧が目的」という同じ結論への定性的な経路) / [[セキュリティログの設計と保護]](段階的劣化・階層化保持という同型の設計原則) - 実体: [[Anoop Nagwani]] / [[Raymond Blum]] / [[Rhandeev Singh]] - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] / [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] - 書籍: [[ウェブオペレーション ―サイト運用管理の実践テクニック]] / [[SRE Book]] / [[Building Secure and Reliable Systems]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]](アヌープ・ナグワニ, 「ストレージ」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 14 章, §14.1, §14.2) - [[@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) - Pete Nuttall, Matt Linton, David Seidman, "Investigating Systems", Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 15, §Collect Appropriate and Useful Logs > Budget for Logging。