Designing Data-Intensive Applications: Chapter 5

概要

Designing Data-Intensive Applications の**第5章（レプリケーション）**を解説するライブストリーム。Excalidraw などの図を使い、シングルリーダー型レプリケーション、その目的、クラウドでの位置づけを説明している。データシステムの高レベルな参照として本書を推奨し、必要な章（例：レプリケーション）だけ読む使い方も可能。

シングルリーダー（プライマリ–レプリカ）レプリケーション

• 構成： 1台のプライマリが全書き込みを受け付け、1台以上のレプリカ（フォロワー）が変更ストリームを受け取り同期する。用語は primary/replica、master/slave など様々。
• トラフィック： 書き込みはすべてプライマリへ。レプリカは読み取り専用。アプリサーバーから読み取りトラフィックを送れる。プロフィールやタイムラインの読み込みなど、読み取りが大半のワークロードに合う。
• 読み取りスケール： トラフィック増に合わせてレプリカを追加でき、プライマリの停止や既存レプリカへの影響なし。データ分散（シャーディング/パーティショニング）が必要になるまで読み取り容量をスケールできる。

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

• 読み取り容量： 読み取り負荷をレプリカに分散し、プライマリがボトルネックにならないようにする。
• 可用性（多くの場合より重要）： クラウドではインスタンスは一時的で、障害・廃止・ネットワーク断が起きうる。1ノードが60秒でも使えなくなるのは許容できないことが多い。プライマリと最低1台のレプリカ（2台推奨）があれば、プライマリ喪失時にフェイルオーバーできる。
• 配置： プライマリとレプリカは通常、リージョン内の複数アベイラビリティゾーン（AZ）（例：US East 1、US West 1）に分散する。各AZは同じリージョン内の別建物にあり、プロバイダーは複数AZが同時に落ちないよう設計する（電源・回線の分離など）。AZ間への分散で耐障害性が上がる。

まとめ

• シャーディング/パーティショニングが必要になるまでは、シングルリーダー型レプリケーションが標準。多くのマネージドDB（例：PlanetScale）がデフォルトで提供する（例：プライマリ＋2レプリカ）。
• レプリケーションは読み取りスケールと高可用性の両方をもたらし、本番では後者がより重要になりがち。
• リージョンとAZを理解すると、クラウドでプライマリとレプリカを配置しやすくなる。

---

Claudeによる翻訳