レプリケーションとシャーディング

なぜ DB を増やすのか

最初は1台の DB で十分でも、アクセスとデータが増えると壁にぶつかります。台数を増やして性能を上げる（スケールアウト）には、大きく2つの方向があります。

• 読み取りが多すぎる／止まると困る → コピーを増やす＝レプリケーション
• 書き込みが多すぎる／データが1台に乗り切らない → 分けて配る＝シャーディング

この2つは目的が違うので、しばしば併用します（各シャードをさらにレプリケーションして冗長化する、など）。まずは別物として押さえましょう。

レプリケーション：同じデータを複製する

典型構成は プライマリ（書き込み担当） と レプリカ（読み取り担当、別名リードレプリカ） の組み合わせです。

• 書き込みはプライマリ1台が受ける。
• プライマリは変更ログ（更新の履歴）をレプリカへ送り、レプリカが同じ更新を再生して追従する。
• アプリは読み取りを複数のレプリカに分散できる。

これで「読み取りが多い」アプリは台数ぶん読みをさばけ、プライマリが壊れてもレプリカを昇格させて復旧できます（後述のフェイルオーバー）。

同期レプリケーション vs 非同期レプリケーション

複製を「いつ確定とみなすか」で2種類に分かれます。これが遅延とデータ欠落のトレードオフの核心です。

多くの実システムは非同期（または準同期）をデフォルトにし、速さを取りつつ「ほんの少し古い・最悪わずかに欠落しうる」を受け入れます。逆に金額や在庫など1件も失えない箇所だけ同期にする、といった使い分けが現実的です。

シャーディング：データを分割する

シャーディングは、1つの大きなテーブル（やDB）を、ある基準で行を複数のサーバー（シャード）に振り分けること。テーブルを縦ではなく横（行単位）で割るので「水平分割」とも呼びます。

どの行をどのシャードに置くかを決める鍵が シャードキー（パーティションキー） です。代表的な分け方は次の通り。

-- イメージ：user_id を 4 シャードに振り分ける（ハッシュ方式）
-- shard_no = user_id % 4
SELECT * FROM users WHERE user_id = 1234;  -- → shard (1234 % 4 = 2) だけに問い合わせ

シャードキーで1件を引くクエリは速い一方、全ユーザーを横断するような集計は全シャードに投げて結果をマージする必要があり、重くなります。

2つの違いを整理

ポイントは「レプリケーションは台数を増やしても“同じ中身”、シャーディングは台数を増やすと“違う中身”」。だからレプリカは1台失っても代わりがいますが、シャードは1つ失うとその範囲のデータが欠ける——だからシャードもさらにレプリケーションして守る、という併用に行き着きます。

つまずきポイント

レプリカラグ（複製遅延）：コピーは一瞬“古い”

非同期レプリケーションでは、プライマリへの書き込みがレプリカへ届くまでにわずかな時間差があります。これがレプリカラグ。通常は数ミリ〜数十ミリ秒ですが、負荷が高いと数秒に伸びることもあります。

フェイルオーバー：プライマリが落ちたら誰が引き継ぐ

プライマリが故障したとき、レプリカの1台を新しいプライマリに昇格させて運転を続けることをフェイルオーバーと呼びます（自動／手動があります）。可用性の要ですが、注意点が2つ。

• 非同期構成では、未反映ぶんのデータが失われることがある（昇格したレプリカが最新まで追いつけていない）。
• 古いプライマリが復活して2台が同時にプライマリだと思い込むと、書き込みが衝突する。これをスプリットブレインと呼び、避けるための仕組み（過半数決定など）が必要です。

まとめ