シャーディング

書きが重いなら、コピーを増やしても効かない

読み取りはレプリカで分散できます。しかし書き込みは Primary 1 台に集まったままです。1 台の書き込み性能が上限に来たら、コピーを増やす方向では何も解決しません。

ここで出てくるのが、データそのものを複数のサーバへ分けて持つやり方です。ユーザー ID で分けるなら、ID ごとに担当のサーバが決まり、それぞれが自分の担当ぶんの書き込みを受け付けます。台数を増やせば書き込みの上限も増えます。これがシャーディングです。

効き目は大きいのですが、順番としては最後です。クエリと索引の見直し、サーバの増強、読み取りの分散、古いデータの退避。この 4 つを試し切ってからでも遅くありません。

レプリカと違い、シャードはそれぞれ違うデータを持ちます。1 台失えば、その担当ぶんだけが丸ごと消えます。ですから各シャードをさらに複製する必要があり、台数も運用の手間も掛け算で増えていきます。

分けた瞬間に、できなくなることがある

分けると、1 台では当たり前にできていたことが急に難しくなります。

SELECT COUNT(*) FROM users WHERE created_at > '2026-05-01';

このクエリには、分割の基準になる列が出てきません。ですから全サーバへ同じ問い合わせを投げ、返ってきた数を足し上げることになります。応答時間はいちばん遅い 1 台で決まり、台数を増やすほど遅い 1 台に当たる確率が上がります。並べ替えて上位 10 件、のような問い合わせも、各サーバから 10 件ずつ集めて並べ直す必要があります。

もっと重いのは、複数のサーバにまたがる更新です。片方だけ成功した状態を防ぐには、全員に可否を確認してから確定させる手順が要り、そのぶん遅く、途中で 1 台落ちると全体が止まります。実務では、1 つのトランザクションが 1 台の中で閉じるように業務の側を設計します。

分割の基準は、あとから変えられない

いちばん怖いのはここです。分割の基準にした列は、決めた後に変えるのがほぼ不可能です。全データを別の分け方で入れ直すことになり、その間サービスを止めるか、新旧の両方へ書きながら少しずつ移す仕組みを自作するしかありません。しかもその移行の最中も、書き込みは秒間何万と流れ続けています。分けるのは簡単で、戻すのも分け直すのも極めて難しい、と覚えておいてください。

基準を間違えると偏ります。国や地域で分ければ、利用者の多い国の担当が 1 台だけ火を噴きます。登録順の範囲で分ければ、新規登録が全部いちばん新しい 1 台へ集中します。値の種類が多く、頻度が均されていて、日常のクエリの大半に出てくる列。この 3 つを満たすものを探します。

分け方そのものは 2 通りに集約されます。値の範囲で区切るやり方は、範囲を指定した検索が 1 台で済む代わりに、新しい値ばかりが増える列では偏ります。値をハッシュにかけて振り分けるやり方は均等に散る代わりに、範囲検索が全台に散らばります。どちらを選んでも、基準にした列そのものが偏っていれば偏ったままです。

解説

1 台で耐えられる間は 1 台で粘る。分けた後の開発は、確実に窮屈になる。