ストレージ設計における「書き込みの成功」と耐久性のトレードオフ

すべてのストレージシステムは、クライアントに対して「書き込みが成功した」と報告する前に、どのレベルでデータを永続化する必要があるかという決断を迫られます。この決断が遅延と耐久性（障害耐性）に直接影響を与えます。

1. 書き込みの成功条件と障害耐性

システムは以下のいずれかの戦略を選択します。各選択肢は、低遅延と耐久性という要素のバランスを変化させます。

• メモリのみ
  • バイトデータをメモリにコピーした時点で即座に応答します（最も高速）。
  • 欠点: メマクラッシュやマシンクラッシュが発生すると、未フラッシュのデータは失われます。
• ローカル SSD（同期）

  • fdatasync()

    を完了させ、ホスト上の NVMe SSD に物理的に書き込みを完了してから応答します。
  • 利点: プロセスやカーネルのクラッシュには耐性があります。
  • 欠点: その HDD/SSD 自体やホストマシンの消失には耐えません。
• リモートストレージ / レプリケーション
  • ネットワークボリュームへのコピー、オブジェクトストレージへの PUT、または他のデータベースサーバーへの WAL コピーを完了させるまで待機します。
  • 利点: ネットワーク時間とコピー時間を要するため遅延が増加しますが、ホスト消失や一部のサーバー障害に耐性があります。

重要: システムコール（syscall）の名前が同一であっても、その背後で待機する遅延の種類や、システムが受け入れられる障害の範囲は大きく異なります。

2. 新しいストレージ設計：オブジェクトストレージと WAL の役割

従来のデータベースはローカル NVMe SSD を事前ログ（WAL）やキャッシュとして利用し、データを LSM-Tree で整理してきました。これに対し、オブジェクトストレージを中心とした設計は以下の特長があります。

• 不変のファイル: 一度 PUT 成功すれば、データを変更せずに保持できます。
• 計算リソースのスケーラビリティ: ストレージサービス自体がスケーリング可能で、共有ディスクページのランダムな更新を回避できます。
• 責任の分断:
  • オブジェクトストレージ: クライアント PUT が成功すれば、永続化のコピー管理はストレージサービス側に委譲されます。
  • データベース: バージョン管理（有効なバージョンの決定）、他のマシンへの決定伝播、読み込み高速化、古いデータ削除、クラッシュ復旧などの責任を担います。

コードと用語の定義

本稿における用語定義は以下の通りです：

• クライアント PUT: キー・バリューリクエストを送信する操作（例：HTTP リクエスト）。
• オブジェクト PUT: オブジェクトストレージへの HTTP リクエスト送信。

これらを分離することで、以下のような 1 つの書き込みの流れを追うことが可能になります。

クライアント PUT 
  ↓ 
メモリ → ローカル SSD → リモートストレージ → 多数の DB サーバー

高速なベンチマーク数値を分析する際、以下の点を理解することが重要です：

• そのコストを負担しているのは誰か？
• 成功しても何が失われる可能性があるか？
• システムは未完成のクリーンアップまでどの程度耐えられるか？

3. オペレーションのコストと追加専用ストア

追加専用キーバリューストアにおける主要なオペレーションのコストは以下の通りです。

コスト詳細（Big O）

O(キーバイト数 + 返却バイト数)

O(キーバイト数 + ペイロードバイト数)

fdatasync()

O(キーバイト数)

注目すべき点:

• 通常の要求では全保存オブジェクトを走査する必要がありません。
• インデックスが既に「キー」→「最新値（またはディスク位置）」のマッピングを持っているため、高速です。

• DELETE

  は古いバイトを即座に消去せず、「無効」という事実だけを記録する軽量な処理です。

4. クライアント PUT の最適化：ローカル SSD への到達経路

データベースホストに直結した NVMe SSD（ホストローカル）を使用する場合、書き込みの永続化ポイントを慎重に選ぶ必要があります。

NVMe の注意点

• NVMe はインターフェース名称であり、ストレージの所在地や障害耐性を示しません。
• リモートブロックボリュームでも NVMe デバイスとして現れますが、これはネットワークを跨ぐため、遅延数値に**認識ポイント（acknowledgment point）**が含まれているか確認が必要です。

待機タイミングの違い

1. メモリコピーのみ: タイマー停止後即座に応答。
2. ローカル SSD 同期完了後:

   fdatasync()

   完了後に応答。
3. リモートボリューム認識後: ネットワーク経由で書き込みが認識された後に応答。

ローカル WAL との遅延比較例

fdatasync()

重要: 50 倍以上の性能差は真実ですが、これは特定のデバイスの特性だけでなく、「どの障害に耐えるか」という設計方針の違いによるものです。

処理フロー：クライアント PUT の通過経路

書き込みが「成功」と見なされるまでの典型的なカーネルとデバイスの流れ（ローカル WAL 使用時）は以下の通りです。

    C["client PUT"] --> E

    subgraph H["DATABASE HOST"]
        E["storage engine"] -->|"WAL を記述"| K["カーネルページキャッシュ"]
        K -->|"fdatasync でページを記述<br/>デバイスキャッシュをフラッシュ"| D["ホストローカル SSD"]
    end

    K -.->|"write() はここで戻ることができる"| V["メモリのみ<br/>永続化されていない"]
    D --> S["成功"]

• write()

  コールは WAL がページキャッシュに到達した時点で返せますが、**「成功」**とは定義されません。
• Linux では

  write()

  でデータをコピーし、ディルティ（汚染）状態のページを後でデバイスに書き込みます。プロセス終了によるキャッシュ破棄はありませんが、カーネルクラッシュやマシン損失では到達していないデータは失われます。

• fdatasync()

  はファイルデータと必要なメタデータの両方を同期します。

  O_DIRECT

  や

  io_uring

  はパフォーマンスを向上させますが、未同期書き込みの永続化という根本的な性質は変えません。

接続切断時のリスク

fdatasync()

• 再試行: クライアントがオペレーション ID を付与して再試行することは可能ですが、異なるバイト列で同じ ID を再利用すると失敗します。
• 高速化の影響: 高速ハードウェアはこのウィンドウを縮小しますが、曖昧さを完全に排除することはできません。

5. スループット向上：1 つのフラッシュで多数の書き込みをカバー

各クライアント PUT 後に

fdatasync()

これを改善するには、WAL ライターが追加記録をバッチ化し、固定のバイト数・回数の後に一度にフラッシュを行う仕組みを導入します。

バッチ化フロー

複数の書き込みを 1 つの

fdatasync()

    A["PUT A"] --> G
    B["PUT B"] --> G
    C["PUT C"] --> G
    D["PUT D"] --> G

    subgraph H["SAME DATABASE HOST"]
        G["WAL バッチを開く"] --> O["バイト数、回数、時間で閉じる"]
        O --> F["1 回の fdatasync()"]
        F --> SSD["ホストローカル SSD"]
        N["次の WAL バッチ"]
    end

    SSD --> S["成功<br/>A, B, C, D"]
    E["PUT E"] -.->|"閉鎖後に来る"| N

• メリット:

  PUT A

  〜

  D

  は 1 つのフラッシュを共有して即座に成功を受けます。スループットが向上します。
• 注意点:

  PUT E

  がバッチ終了後に到着する場合、次のフラッシュまで待機する必要があります。
  • 最初のリクエストは最も長く待機します。
  • フラッシュエラーはバッチ全体に影響します。

バッチ化の制限事項

• メモリエキス: スローなデバイスでは、保留中の書き込みキューが利用可能なメモリを消費し尽くす可能性があります。
• 遅延増大: 負荷が高い状況で

  sleep

  してバッチを埋めようとすると、スループットへの寄与は薄く、単に遅延が増加するだけです。
• デバイスのコスト: デバイス書き込みサイズが大きいほど IOPS は必要です（例：256 KiB で 1 GiB/s を動かすなら約 4,096 IOPS が必要）。

6. ホストを超えてデータを永続化する戦略

ローカル SSD での

fdatasync()

選択肢ごとの成功ポイントと耐性

各ストレージオプションには「安全に成功として返せる」タイミング（認識ポイント）が異なります。

fdatasync()

fdatasync()

ウィンドウ管理：アップロードを後回しにするか？

• ローカル

  fdatasync()

  を待つ: パスが短く高速ですが、データ損失ウィンドウが「ホスト消失」まで広がります。
• オブジェクト PUT を完了させる: ウィンドウは「サービス障害」に縮まりますが、各書き込みにネットワーク要求が含まれます。
  • バッチ化することで要求数は減りますが、バッチ内の最初の書き込みはバッチ埋まるまで待機します。

7. WAL の複製と協調性

WAL を複数のサーバー（リーダーとフォロワー）に複製すると、システムはステートフルになり、障害耐性が向上します。

複製 WAL フロー

3 ノード構成の場合、クライアントはリーダー宛てに PUT を送ります。リーダーはローカル WAL に追加後、2 つのフォロワーにコピーを送信し、永続コピーが 2 つ達成された時点で成功を返却します。

    C["client PUT"] --> L

    subgraph R["3-ノード複製 WAL"]
        L["リーダー<br/>WAL + ローカル SSD"]
        F1["最初に完了するフォロワー<br/>WAL + ローカル SSD"]
        F2["他のフォロワー<br/>WAL + ローカル SSD"]
        L -->|"複製"| F1
        L -->|"複製"| F2
    end

    L --> Q["最初の 2 つの永続コピー"]
    F1 --> Q
    F2 -.->|"後に完了する可能性がある"| Q
    Q --> S["成功"]

• 耐性: 1 つのサーバー喪失には耐えます。
• 遅延: コミットには全てネットワーク転送と、多数性を形成するための遅いデバイスの同期が含まれます。
• 障害ドメイン: 異なる障害ドメインに配置されたレプリカは、単なるダウンタイムより大きな障害にも耐えられます。

ライター選出の責任分担

• システム内部で自動的にリーダー選出（エレクト）を行う必要はありません（データが重要だから）。
• 別のサービスがライターの割り当てを行い、番号を管理します。
• ストレージエンジンは、古いライターの書き込みを拒絶するだけの役割に留まります。
  • サーバー間通信不能時でも、自分自身でライター選出とコミットログの保存を行う必要があります。

Raft アルゴリズムなどでは、リーダーは現在のテーム（term）、投票数、ログ位置を送信し、多数がディスク上のログを保存した時点でコミットされます。RAM だけの認識（Acknowledgment）に依存せず、必ずディスクへの記述を行います。

8. 高速読み取りとクリーンアップの必要性

WAL を再実行できることは、GET を安価にするだけでありません。すべての読み取りで WAL を走査するとコストが履歴と共に成長するため、以下の最適化が必要です。

• インデックス維持: エンジンは「キー」→「最新値/ディスク位置」のマッピングを常に更新します。
  • ハッシュインデックス: 順序不要な高速ルックアップが可能。
  • B ツリー: 順序付き読み取り・範囲スキャンをサポート（ただし、深さ増加に伴うオーバーヘッドあり）。
  • LSM-Tree: メモリとソート済みファイルに記述し、マージで再記述します。

クリーンアップ（DELETE）の仕組み:

• O(key bytes)

  の DELETE は即座に返ります（古いデータは物理的に削除せず）。
• 真正な解放には後からファイルインデックスを読み込み、代替ファイルにデータをコピーし、不要なファイルを削除するプロセスが必要です。

9. Big O の真偽：成長と耐久性

Big O 記法は「データ量が増えたときにコストがどう増えるか」のみを示しますが、「どのタイミングで永続化するかが異なる」という違いを隠しています。

O(key + payload)

fdatasync()

O(key + payload)

O(key + payload)

決断が必要な領域（テスト対象）

• どのパスを「成功」とみなすか（

  fdatasync()

  のタイミング）。
• タイムアウトの定義。
• クラッシュ時にどうデータを失うべきか（選択不可な問題ではない）。
• 未完成の作業（アップロード、複製ログなど）をどこまで許容するか。

これらの判断は、システムがメモリ→ローカル SSD→リモートストレージ→レプリカという流れを追跡することで初めて明確になります。

結論: より高速なパスはより少ない障害に耐えますが、成功を遅らせることで耐久性を増やすことができます。GET, PUT, DELETE の数値だけを見てシステム評価を行うのは誤りであり、背後にある永続化戦略を理解する必要があります。