🐱 うさねこ教室 Python と可観測性の教室

レプリケーション

🐱 この章の目次

なぜレプリケーションが必要か

レプリケーションとは、同じデータのコピーを複数のノードに保持することです。 目的は可用性の向上(ノード障害時の継続稼働)、読み取りスループットのスケールアウト、そして地理的に近いレプリカによるレイテンシ削減です。 『データ指向アプリケーションデザイン』第 5 章では、3 つのレプリケーション方式を整理しています。

リーダー・フォロワー方式

リーダー・フォロワー(single-leader)方式では、1 台のリーダーがすべての書き込みを受け付け、フォロワーに変更を伝播します。 リーダーからフォロワーへの伝播は同期レプリケーション非同期レプリケーションに分かれます。 同期は一貫性が強い代わりに、フォロワー障害時にリーダーがブロックされるリスクがあります。

# PostgreSQL streaming replication の設定例 (postgresql.conf)
wal_level: replica
max_wal_senders: 5
synchronous_standby_names: 'first 1 (standby1, standby2)'

マルチリーダー方式

マルチリーダー方式は、複数のデータセンターにそれぞれリーダーを配置する構成です。 各拠点でローカルに書き込みを受け付けられるため、WAN レイテンシの影響を回避できます。 しかし、同じデータへの同時書き込みによる書き込みコンフリクトの解決が最大の課題です。

リーダーレス方式

リーダーレス方式(Dynamo スタイル)では、クライアントが複数のレプリカに同時に書き込みと読み取りを行います。 クォーラム条件(w + r > n)を満たせば最新値を読める保証が得られます。 Amazon DynamoDB や Apache Cassandra がこの方式を採用しています。

レプリケーションラグの問題

非同期レプリケーションでは、フォロワーがリーダーに追いつくまでの遅延(ラグ)が問題を引き起こします。

問題現象対策
自分の書き込みが見えない書き込み直後にフォロワーから読むと古いデータが返るread-after-write 一貫性: 自分の書き込み後はリーダーから読む
時間が巻き戻る異なるフォロワーから読むとデータが前後するモノトニックリード: 同一ユーザーは同一レプリカから読む
因果の逆転応答が質問より先に見える一貫プレフィックス読み取り: 因果順序を保証する

結果整合性で十分なケースとそうでないケースを見極め、必要な一貫性保証を選択することが設計の要です。