マスター・スレーブ レプリケーション

たとえ話: 1人の編集長と複数のコピー機

新聞社で、編集長(マスター)だけが記事を書けるとします。書き上がった記事は**コピー機(スレーブ)**で大量に複製され、読者はそのコピーを読みます。

• 読者(読み取り)が増えても、コピー機を増やせば捌ける。
• でも記事を書けるのは編集長1人だけ。書き込みは増やせない。
• 編集長が倒れたら、誰か(昇格したスレーブ)が新しい編集長になるまで、新しい記事は出せない。

図を描画中...

なぜ『読み取りが多いシステム』に効くのか

多くのWebサービスは読み:書き = 100:1のように読み取りが圧倒的に多い(read heavy)。だから読み取りを担当するスレーブを増やせば、その大部分を分散して捌けます。書き込みはマスター1台でも足りることが多い。

レプリケーションラグ(遅延)というつまずき

マスターに書いた内容がスレーブに届くまで、わずかな時間差があります。この間に別のスレーブを読むと古い値が見えることがあります。

例: 投稿ボタンを押した直後に画面を再読み込みしたら、自分の投稿がまだ出てこない。

これは結果整合性そのもの。対策として『書き込み直後の読み取りはマスターから読む』といった工夫をすることがあります。

マスター昇格の手間

マスターが壊れると、システムは読み取り専用になります(スレーブは読めるが書けない)。サービスを復旧するには、どれかのスレーブを新マスターに昇格させ、他のスレーブをそれに付け替える必要があり、この切替ロジックは自前で用意するか仕組みに頼る必要があります。

つまずきポイント

• これで解決するのは読み取りのスケールであって、書き込みのスケールではない。書き込みもスケールしたいなら master-master や sharding が必要。
• 『書いた直後に読めない』問題(レプリケーションラグ)は、結果整合性として受け入れるか、特定の読み取りだけマスターに向けるかで対処する。

📊 図解

図解: 書き込みと読み取りの流れ(レプリケーション遅延)

書き込みはマスターのみ。マスターからスレーブへ複製が伝わるまでの遅延(replication lag)の間に読むと、古い値が返ることがある。

図を描画中...

図解: マスター故障時のフェイルオーバー

マスターが壊れると書き込み不可(読み取り専用に縮退)になり、いずれかのスレーブを新マスターへ昇格させて復旧する。

図を描画中...