DDIA Chapter 5: Replication

Tony Duong

Tony Duong

3月 15, 2026 · 1

他の言語:🇫🇷🇬🇧
#ddia#databases#replication#distributed-systems#consistency
DDIA Chapter 5: Replication

概要

Designing Data-Intensive Applications の第5章はレプリケーションを扱う:冗長性のため、低レイテンシ(ユーザーに近いデータ)、高い読み取りスループットのために、複数ノードに同じデータのコピーを置く。シングルリーダー・マルチリーダー・リーダーレスという三つの主な方式と、それぞれに伴う一貫性のトレードオフを比較している。

なぜレプリケーションするか

  • 冗長性: 1ノードが落ちても、他がデータを提供できる。
  • 低レイテンシ: 複数リージョンにレプリカを置き、ユーザーが近くのノードから読めるようにする。
  • 読み取りスループットのスケール: 読み取り負荷をレプリカに分散する;書き込みはスケールしにくいことが多い。

シングルリーダー(リーダー方式)レプリケーション

1ノードがリーダー(プライマリ);書き込みはリーダーへ。レプリカ(フォロワー/セカンダリ)は変更ストリームを受け取り、同じ順で適用する。

  • 同期 vs 非同期: 同期レプリケーションは、少なくとも1つのレプリカが受け取るまで書き込みの応答を待つ — 一貫性は強いが、レプリカが遅い・落ちているとレイテンシとリスクが増える。非同期レプリケーションは即座に応答し、バックグラウンドでレプリケーションする — レイテンシは低いが、リーダー障害で直近の書き込みを失うリスクがある。
  • レプリケーションラグ: 非同期ではフォロワーが遅れる。結果整合性と、次のような問題が現れる:
    • 書き込み後読み取り一貫性: ユーザーが書き込みの直後に読み取り、遅れているレプリカを読むと古いデータが見える。対策:自分の書き込みはリーダーから読む、またはレプリケーション完了までリーダーにしかないキーでルーティングする。
    • 単調読み取り: 連続した読み取りがラグの異なるレプリカに当たると、データが「時間を遡る」ように見える。対策:同一ユーザーの読み取りは同じレプリカへ(例:user IDでルーティング)。
    • 一貫プレフィックス読み取り: パーティション分割されたシステムでは、会話の異なる部分が異なる順でレプリケーションされ、質問より先に答えが見えることがある。対策:因果的に関連する書き込みを同じパーティションに送るか、順序保証を使う。

新規レプリカの追加: 通常、リーダーのスナップショットを取得し、新ノードにコピーし、スナップショット時点からレプリケーションログを再生して追いつかせる。

マルチリーダーレプリケーション

複数のリーダーが書き込みを受け付ける(例:DCごとに1つ)。各リーダーが他へレプリケーションする。ユースケース:マルチDC(ローカルに書き、DC間でレプリケーション)、オフライン対応アプリ(各デバイスが「リーダー」で、オンライン時に同期)。

  • コンフリクト検出と解決: 2つのリーダーが同じキーへの同時書き込みを受け付けると、コンフリクトを検出・解決する必要がある。選択肢:タイムスタンプによる last-write-wins (LWW)(書き込みが消えることがある)、値のマージ(例:CRDT)、コンフリクトを記録してアプリ側で解決。カスタム解決ロジックは読み取り時または書き込み時に実行できる。

リーダーレスレプリケーション

単一のリーダーがない;クライアント(またはコーディネータ)が複数ノードへ書き込み、複数ノードから読み取り。Dynamo系(DynamoDB、Cassandra、Voldemort など)で使われる。

  • クォーラム: n 個のレプリカで、w ノードへ書き、r ノードから読み、w + r > n なら、通常は最新の書き込みが見える(同時書き込みと障害ノードがない前提)。よくある選択:w = r = ⌈(n+1)/2⌉。
  • スロッピークォーラムとヒンテッドハンドオフ: ノードがダウンや unreachable のとき、別ノードへ書き込みを受け入れ、後で本来のレプリカへ渡す(「hinted handoff」)ことがある。読み取りはその書き込みを適用されるまで見逃す可能性がある — クォーラムは厳密ではなく、一貫性は弱まる。
  • コンフリクト解決: 同じキーへの同時書き込みで複数バージョンができる。解決はlast-write-wins (LWW)(タイムスタンプ)やバージョンベクターdotted version vectorsで因果を追い、マージしたり複数バージョンをアプリに渡したりする。

まとめ

  • シングルリーダーレプリケーションはシンプルで広く使われている;レプリケーションラグのため、書き込み後読み取り・単調読み取り・一貫プレフィックスを考慮する必要がある。
  • マルチリーダーはマルチDCやオフライン向けだが、書き込みコンフリクトとより複雑な解決が発生する。
  • リーダーレスは強一貫性より可用性と低レイテンシを優先する;クォーラムは役立つが、スロッピークォーラムと同時書き込みで話は複雑になる。
  • タダ飯はない:レプリケーションは可用性と読み取り性能を上げるが、一貫性・コンフリクト・障害モードの複雑さが増す。

Claudeによる翻訳

Tony Duong

著者: Tony Duong

デジタル日記。思考、経験、そして人生についての考え。