稼働するだけでは不十分：OceanBaseが保証するデータ整合性

2021年、Meta社は数十万台のマシンを対象に18ヶ月間にわたり実施した監視調査をまとめた研究論文「Silent Data Corruptions at Scale」を発表し、サイレントエラーを引き起こすCPUが数百個も検出されたことを明らかにしました。結論として、サイレントデータ破損（Silent Data Corruption: SDC）は、特定のハードウェアにおける偶発的な故障ではなく、「世代を超えたシステム的な課題（systemic problem）」であると明確に指摘されています。同年、Google社も論文を発表し、大規模クラスターにおける異常なCPUに起因する相関障害は「十分に頻繁に発生しており、すでに独立した一カテゴリの課題となっている」と指摘しました。

ハイパースケールなインフラを支える2社の報告は、いずれも同じ示唆を与えています。サイレントデータ破損は、「起きるかどうか」を問うようなまれな偶発事象ではなく、「いつ起きるか」を前提に備えるべきリスクだということです。問うべきなのは「データ破損が起きるか」ではなく、「それがいつ起きるか」、そして「システムがそれをどれだけ迅速に検知できるか」です。

サイレント破損が恐ろしいのは、まさにその「サイレント」にあります。ディスクがI/Oエラーを全く報告しないまま破損したデータを返したり、バグやコンパクション処理の不具合、あるいはインデックスメンテナンスの異常などによって、ベーステーブルとインデックスの間で論理的な不整合が発生したりします。こうした問題が起きても、通常データベースのプロセスはクラッシュせず、サービス自体は稼働し続けているように見えます。

ここで重要なのは、この二つを区別して捉えることです。高可用性（HA）が扱うのは、「システムがサービス提供を継続できるか」という課題です。これに対してデータの正確性が扱うのは、「サービスが継続していても、返されるデータが正しいとは限らない」という課題です。両者は別個に考えるべきエンジニアリング目標です。

従来のHAメカニズム（複数レプリカによる自動フェイルオーバーなど）は、この種のサイレントデータ破損を検知することを前提に設計されておらず、対処にも限界があります。これに対してOceanBaseは、複数レプリカとPaxosプロトコルによって高可用性を実現すると同時に、データライフサイクル全体にわたり、システムレベルでデータ整合性検証を組み込んでいます。本記事では、この検証体系を「物理検証」「論理検証」「アーキテクチャの強み」「エラー検知後の復旧戦略」という4つの観点から順に解説します。

---

1. 物理的整合性：多層的なチェックサム保護

物理的整合性が扱うのは、データの保存・転送プロセスにおける「バイナリレベルでの正確性」です。その目的は、下位のハードウェアやストレージメディア、あるいは転送経路で何らかの異常が発生しても、システムがデータ内容の意図しない変化を適時に検知できるようにすることです。

物理検証の基本的な考え方はシンプルです。データの書き込み時にチェックサムを記録し、読み出しやレプリケーションの際に再計算して照合します。2つのチェックサム値が一致しなければ、保存中または転送中にデータ内容が変化したことを意味します。OceanBaseでは、データのライフサイクル全体をカバーするため、ログレイヤー（Redo Log）とストレージレイヤー（SSTable）の両方に物理検証を組み込んでいます。

1.1 ログレイヤー：データ永続化における最初の防御線

RedoLogは、データをディスクに書き込んで永続化する過程における最初の防御線です。トランザクションがコミットされるとRedoLogが生成され、Paxosプロトコルを介してレプリカ間で同期され、最終的にディスクへ永続化されます。各ログのヘッダーにはチェックサムが記録されており、以下の重要なタイミングで検証が実行されます。

• ログ生成時: RedoLogの生成時にチェックサムを計算して記録し、以後の検証の基準とします。
• ネットワーク転送時: レプリカ間でログを同期する際、受信側でチェックサムを検証し、転送中にデータが破損していないことを確認します。
• ログのリプレイ時: RedoLogをメモリやディスクに適用する際、システムはチェックサムを再検証します。これにより、破損したログがデータの一貫性に影響を及ぼすのを未然に防ぎます。

この仕組みの核心的な価値は、破損したログを他のレプリカへ同期される前に排除できる点にあります。物理レイヤーで発生したエラーを発生源で確実に食い止めることで、レプリケーションを通じて分散システム全体へ波及するのを防ぐことができます。

1.2 ストレージレイヤー：マルチレベルでのチェックサム記録

OceanBaseのストレージエンジンはLSMツリーアーキテクチャを採用しており、データはMemTableからイミュータブルなSSTableへと書き込まれます。SSTableは、物理的には以下のような多層構造を持ちます。

• マクロブロック（固定長2MB）: ディスクI/Oの基本単位であり、ヘッダーにチェックサムが記録されます。
• マイクロブロック（約16KB）: 読み取りI/Oの基本単位であり、ヘッダーにチェックサムが記録されます。
• SSTableとパーティション: さらに上位のデータ構造でも、同様に検証情報が保持されます。

これにより、データがどの粒度でアクセスされても、それに対応した整合性保護が機能する仕組みになっています。

1.3 データフロー全体のカバー：あらゆるポイントに組み込まれた検証

物理検証の価値は、定期スキャンの有無だけでは測れません。重要なのは、データが流れる主要な処理経路の各所に検証が組み込まれており、破損データがシステム内に残留・拡散する余地を最小化していることです。

• 書き込み時: flushやメジャーコンパクションによってマクロブロックへデータを書き込んだ直後に、システムは再検証を実施します。これにより、書き込み処理自体は成功したように見えても、実際には内容が破損しているようなサイレントエラーを検知できます。
• 読み取り時: マイクロブロックのヘッダーに記録されたチェックサムを都度検証します。クエリが参照するすべてのマイクロブロックは、この検証を通過しなければ処理を継続できません。結果として、破損データがアプリケーションへ返却されるのを防げます。
• 複製時（レプリケーション時）: データ移行やバックアップの際には、複製先がマクロブロックへ書き込む前に、複製元データの整合性を検証します。これにより、破損データが他ノードやバックアップ媒体へ伝播するのを防ぎます。
• 非アクセス時: バックグラウンドスレッドが全マクロブロックを定期巡回し、チェックサムを検証します。これは、履歴パーティションやアーカイブテーブルのようなコールドデータを保護するうえで不可欠です。読み取り時のみ検証する設計では、長期間参照されないデータの破損が長く見過ごされる可能性があります。

---

2. 論理的整合性：複数レプリカによるクロスチェック

2.1 物理検証の限界

物理検証で分かるのは、「データそのものが物理的に壊れているかどうか」までです。レプリカ同士の内容が論理的に一致しているかどうかまでは、物理検証だけでは分かりません。

たとえマイクロブロックのチェックサム検証を通過していても、それは「ストレージメディア上ではデータが壊れていない」ことを示すだけです。たとえば、次のような問題は物理検証だけでは見つけられません。

• 3つのレプリカが同じ論理バージョンで、内容まで完全に一致しているか
• ベーステーブルとインデックスで、対応する列の値が一致しているか

こうした問題は、プログラムのバグやインデックス更新の不具合、あるいは同時実行制御の異常などによって起こります。これは論理レイヤーの不整合であり、物理レイヤーにはチェックサムエラーのような痕跡は残りません。

2.2 論理検証の仕組み

物理検証は、個々のデータが正しく保存されているかに焦点を当てるため、各レプリカごとに独立して実行できます。一方、論理検証では、「同じ論理時点で複数レプリカのデータ状態」を比較します。常に書き込みが発生しているシステムでは、レプリカごとに書き込みの進捗が異なることがあるため、単純に最新状態同士を比較しても意味がありません。

これに対するOceanBaseの解決策は、日次メジャーコンパクションの仕組みを活用することです。メジャーコンパクションの際、すべてのレプリカはグローバルに統一されたスナップショットバージョンに基づいて、ベースラインデータを生成します。メジャーコンパクションの完了後、システムは各レプリカのデータチェックサムを比較します。不一致が検出された場合は、ただちにコンパクション処理を停止し、アラートを発報します。また、ベーステーブルとインデックス列のチェックサムも比較し、両者の間に論理的不整合が生じていないかを確認します。

この論理検証は、メジャーコンパクションの過程ですでに読み書きが完了したデータを再利用するため、検証のために別途フルスキャンを実行するような追加負荷を生まない設計になっています。

2.3 ベーステーブルとインデックス：データ構造間の整合性

OceanBaseは、レプリカ同士の整合性だけでなく、ベーステーブルとインデックスの間でも列レベルのチェックサムを比較します。これによって、同じパーティション内でローカルインデックスとベーステーブルの対応が正しいか、グローバルインデックスでパーティションをまたぐ対応関係が正しいか、またユニークインデックスに重複キーがないかといった問題を検出できます。

こうした問題を見逃したままにすると、インデックス経由のクエリが誤った結果を返したり、同じデータを問い合わせているのに、ベーステーブルを読むかインデックスを読むかで結果が変わったりする可能性があります。このような不整合は、システムダウンのようにすぐ表面化しないぶん、業務への影響に気付きにくく、原因の特定も非常に難しくなります。

2.4 複数レプリカが持つ「もう一つの価値」

OceanBaseの検証アーキテクチャにおいて、複数レプリカは2つの重要な役割を担います。1つは、障害時の自動フェイルオーバーによって高可用性を支えること。もう1つは、論理検証における基準として機能し、多数決によってどのデータを正とみなすかを判断することです。

論理的不整合が検出されると、システムはコンパクション処理を停止し、詳細なアラートを発報するとともに、エラー情報をシステムビューに記録します。このとき、古いSSTableは引き続き読み取りリクエストを処理するため、サービス全体が直ちに停止するわけではありません。しかしその一方で、誤ったデータが新しいベースラインとなるコンパクション結果に永続化されるのを防ぐことができます。

なお、論理的不整合については、システムによる自動修復機能は提供されていません。これは、運用担当者（DBA）が介入し、根本原因を明確にしたうえで、適切に管理された安全な手順でリカバリを行う必要があるためです。

---

3. 継続的な検証：アーキテクチャが検証コストを左右する

3.1 従来のアーキテクチャが抱える構造的なジレンマ

信頼性の高いデータ検証を実行するには、相応のコストがかかります。頻繁に全量検証を行おうとすれば、通常は大量のデータ読み取りやCPU計算が必要となり、本番ワークロードとディスクI/Oや計算リソースを競合することになります。

従来のB+Treeアーキテクチャでは、データはインプレース更新方式で書き換えられるため、定期的にデータ全体を再書き込みするような自然な契機がありません。そのため、全量検証を行うには別途独立したスキャン処理を実行せざるを得ず、本番のディスクI/Oやリソースを圧迫することになります。その結果、検証処理は深夜などに実行される低頻度のスケジュールジョブや手動実行に限定されがちで、カバー範囲も限られてしまいます。これでは、検証と検証の間の空白期間に発生したデータ破損が長期間潜伏するリスクがあります。

3.2 LSMアーキテクチャにおける構造的な強み

OceanBaseが採用しているLSMツリーアーキテクチャのストレージエンジンは、この課題に対して構造的な強みを持っています。LSMツリーの設計の中核にあるのは、データの差分書き込みと定期的なコンパクションです。新しい書き込みはまずメモリ内のテーブル（MemTable）に保存され、MemTableが一定サイズに達すると、イミュータブルなSSTableへと書き込まれます。さらに、複数のSSTableは定期的にメジャーコンパクションされ、よりコンパクトで統合された新しいSSTableが生成されます。この設計は、検証を組み込みやすい合理的なタイミングをもたらします。

• 検証がデータ処理フローに組み込まれている: 従来のアーキテクチャでは、全量検証のために専用のスキャンタスクを別途起動する必要がありました。一方、LSMツリーを採用するOceanBaseでは、物理検証がマクロブロックの書き込み・読み取りパスそのものに組み込まれており、論理検証はコンパクション処理の際にグローバルに一貫したスナップショットを再利用します。つまり、検証が通常のデータ処理プロセスの一部として機能します。
• SSTableがイミュータブルである: コンパクションによって生成された新しいベースラインデータ（SSTable）は完全に固定されており、後から書き換わることはありません。そのため、検証中にデータが変更される競合を気にする必要がなく、常に安定した状態で検証を行えます。

ただし、検証に伴うコストが完全にゼロというわけではありません。チェックサムの計算には依然としてCPUリソースが必要ですし、検証結果の比較にはメタデータ管理や実行スケジューリングも必要です。しかし、独立したスキャン処理によってディスクI/Oが大きく圧迫される従来方式に比べると、LSMアーキテクチャでは、必須のデータ処理プロセスに検証を重ね合わせることができます。その結果、信頼性の高い検証は、「個別にリソースや実行スケジュールを工面しなければならない低頻度のメンテナンス作業」ではなく、「システム自体に組み込まれた継続的かつ自律的な機能」として動作するようになります。

---

4. エラーに応じた柔軟な復旧プロセス

エラーを検知することは、最初の一歩です。検知したエラーに対して「システムがどう対応するか」もまた、アーキテクチャ設計における核心的な部分です。OceanBaseでは、物理的な破損と論理的な不整合のそれぞれに対し、エラーの性質を見極めた異なる復旧アプローチを採用しています。

4.1 物理的破損：レプリカレベルでの再構築と自動復旧

物理的なチェックサムエラーが発生しても、他のレプリカが検証を通過している場合、データ破損は単一レプリカ内に限定されていると判断できます。この場合、次の2点が成り立ちます。

• 正とみなすべきデータが明確である: 正常なレプリカが正しいデータを保持している。
• 復旧経路が明確である: 正常なレプリカからデータを再同期することで、破損したデータを再構築できる。

OceanBaseはレプリカ再構築機能を提供しており、正常なレプリカのデータを基に、破損したレプリカを非同期かつ安全に修復できます。この修復処理の最中も、読み書きリクエストは正常なレプリカが処理し続けるため、オンライン業務が中断することはありません。

万が一、複数のレプリカで同時に物理的破損が発生し、レプリカの冗長性で吸収できる範囲を超えた場合には、最終的な防衛線としてバックアップからのリカバリに頼る必要があります。

4.2 論理的不整合：「現場の保全」と人間による原因分析

論理検証において、レプリカ間やベーステーブルとインデックスの間でチェックサムの不一致が検出された場合、状況は物理的な破損よりもはるかに複雑です。これは、ソフトウェアのバグ、設定のミスマッチ、あるいはその他の未知の要因が関与している可能性が高いためです。そのため、OceanBaseでは、「発生時点の状態をそのまま保全し、二次被害や誤操作を防ぐこと」を基本戦略としています。具体的には、次のように動作します。

• コンパクションの自動停止: 該当パーティションのメジャーコンパクション処理を自動的に停止し、不整合のあるデータが新しいベースラインに固定化されるのを防ぎます。
• 詳細な情報記録: エラー情報をシステムビューに詳細に記録します。これには、Tablet ID、ベーステーブルおよびインデックスのチェックサム値、パーティション情報などが含まれます。
• オンラインサービスへの影響の抑制: 既存のSSTableは引き続き読み取りクエリを処理するため、サービス全体が直ちに停止するわけではありません。
• エンジニアによる根本原因分析: 運用担当者や開発チームが協調してログを分析し、バグなのか、構成ミスなのか、あるいはその他のハードウェアまたはソフトウェアの異常なのかを特定します。

根底にあるのは、「原因が判明するまでは、安易な自動修復を避け、まず状態を正しく保存すべきだ」という考え方です。不用意な自動修復は、根本的なバグを覆い隠す恐れがあります。さらに、本来なら追跡できたはずの論理エラーを、再現不可能なサイレントデータ破損へと変質させてしまう危険もあります。

4.3 エラー分類に基づく復旧戦略

要するに、確実に直せる障害は自動化し、不確実な障害は保全を優先して人が判断する。

4.4 シナリオ例

シナリオA：コールドデータパーティションで発生したサイレント破損（物理検証のサイクル）

• 【背景】 決済システムの過去取引データを保持するパーティション（3レプリカ構成）。日次締め処理後はあまり参照されない。
• 検知フェーズ: 深夜2:00、バックグラウンドの定期巡回がレプリカ2でチェックサムエラーを検出。管理ツールで「checksum error」アラート発報。
• 処理フェーズ: DBAがレプリカ再構築を開始。正常なレプリカ1または3をソースとして再構築。オンライン業務は停止しない。
• 再検証フェーズ: 再構築完了後、定期巡回で異常がないことを確認。メジャーコンパクション完了時の論理検証で最終確認。

シナリオB：メジャーコンパクション後に検出された列チェックサム不一致（論理検証のサイクル）

• 【背景】 注文データベースのインデックス列で、メジャーコンパクション後の論理検証により不一致を検出。
• 検知フェーズ: コンパクション処理は自動停止し、診断情報がシステムビューに記録。監視システムへアラート通知。
• 処理フェーズ: 状態保全を優先し、現状維持。開発チームがログやインデックスDDL変更などを分析してRCAを実施。修正後、管理手順に従ってメジャーコンパクションを再実行。
• 再検証フェーズ: 再マージ後の論理検証成功を確認。システムビューのクリアを確認し、ベーステーブルとインデックスの検索結果が完全一致することを確認。

---

おわりに

サービスが動き続けることと、データが正しいこと。システムの信頼性は、その両方がそろって初めて成り立ちます。OceanBaseの設計は、この2つを無理なく両立させるためのものです。