シャーディングとは？水平分割の仕組みとシャードキー設計を実装者目線で解説【2026年版】

シャーディングは、1つの表を行単位で切り分け、複数のデータベースサーバーへ分けて置く手法です。1台では受け止めきれない書き込みとデータ量を台数で分散させる考え方で、シャードと呼ばれる各サーバーは同じスキーマのまま互いに異なる行だけを保持します。効果は分かりやすい一方、導入するとJOINも一意制約もトランザクションも、これまでどおりには使えません。この記事では、シャードキーの選び方と分散方式、失う機能、再配置の手数、VitessやCitus、Aurora PostgreSQL Limitless Database、MongoDBの実装差までを、判断に使える形で整理しました。

まとめ：シャーディング採用の可否を分ける3つの条件

踏み切ってよいかどうかを分けるのは、データ量の大きさではなく次の3点です。第一に、ほぼ全てのクエリの検索条件へ自然に乗るシャードキーの候補が、業務要件の側に存在するか。第二に、シャードをまたぐJOINと集計を、アプリケーション側の実装や事前集計で引き受ける覚悟があるか。第三に、シャード追加時の再配置とスキーマ変更を、誰がどの手順で回すか決められるか、です。

どれかが埋まらないまま分割へ進むと、性能は伸びても改修が止まらなくなります。垂直方向の増強とリードレプリカと不要データの退避を尽くしてなお書き込みが詰まる場合にだけ、この手法は割に合う。以下、判断の根拠を仕組み・設計・制約・運用・実装の順に分解します。

シャーディングの定義とレプリケーションやパーティショニングとの線引き

1つの表を行単位で切り分けて複数のノードへ分散させる基本の仕組み

シャーディングが行うのは、論理的には1つに見える表を行の集合として複数のデータベースへ配ることです。顧客IDが1から100万までの表なら、1番から50万番までを1号機に、残りを2号機に置く。各シャードは同じ列構成を保ったまま、担当する行だけを持ちます。

この構成では、シャード同士がディスクもメモリも共有しません。共有しない設計だからこそ台数を足した分だけ書き込みの受け口が増え、1台あたりの索引サイズも小さく保てます。代わりに、どの行がどのシャードにあるかを知る仕組みが要り、その判断材料になる列がシャードキーです。論理的には1つの表でも、物理的には独立した複数のデータベースが並ぶ。この二重構造が、後述する制約のほぼ全ての出どころです。

レプリケーションやパーティショニングとの役割の違いを整理する

混同されやすい3つの手法は、解決する問題がそれぞれ違います。

レプリケーションは写しを増やす手法なので、参照は分散できても書き込みは主系1台に集まったままです。同期・非同期の選び方とレプリカ遅延の設計はデータベースレプリケーションの仕組みと遅延設計で整理しています。パーティショニングは単一のデータベース内で表を切る仕組みで、古い期間のデータを切り離す運用や索引の効きには向くものの、サーバー1台の限界そのものは動きません。分割方式の選び方と絞り込みが効かないクエリの見つけ方はパーティショニングの実装設計で整理しています。書き込みの上限を押し上げたいときに残る選択肢が、ノードをまたぐシャーディングです。スケーリングの方向そのものはスケールアウトとスケールアップとは？水平・垂直スケーリングの違いで整理しています。

書き込みの限界に当たる前に検討し尽くしておきたい三つの代替手段

実務では、分割の前に打てる手が3つ残っていることがほとんどです。インスタンスの増強はクラウドなら数分の停止で数倍のCPUとメモリへ移せますし、リードレプリカの追加は参照系が負荷の大半を占める構成ならこれだけで数年しのげます。保持期間を見直して古い行を退避させれば、索引が小さくなって書き込みも軽くなる。

それでも詰まるのは、書き込みそのものが1台の上限に張り付いたときです。見るべき指標は増強後のCPU使用率ではなく、書き込みの待ち行列とレプリカ遅延の推移でしょう。増強しても待ち行列が減らず、レプリカ遅延が業務許容を超え始めた段階が、分割の検討へ入る合図になります。

シャードキーの選び方とレンジ・ハッシュの分散方式の使い分けの判断基準

カーディナリティと頻度と単調増加で見るシャードキーの適性の判断軸

シャードキーの選定は、分割後の性能をほぼ決める一発勝負の設計です。MongoDBの公式ドキュメントは観点を4つ挙げています。取り得る値の種類が多いこと（カーディナリティ）、特定の値へ偏らないこと（頻度）、時刻や連番のように単調に増え続けないこと、日常的なクエリの検索条件に含まれること、の4点です。

値の種類が少ないと分割の細かさが頭打ちになります。大陸名のように7種類しか値がない列を選べば、シャードは実質7つまでです。頻度の偏りも同様で、大半の行が同じ値を持てばそのシャードだけが肥大します。単調増加は最も分かりやすい失敗で、作成日時や自動採番のIDを選ぶと新規の書き込みが常に末端の1台へ集中する。1列で条件を満たせないなら、複数列を束ねた複合キーで種類を増やす手が定石です。

レンジ分割とハッシュ分割で変わる範囲検索とホットスポットの出方

選んだキーをどうシャードへ割り当てるかで、性質が変わる点に注意が必要です。レンジ分割はキーの値の範囲で区切る方式で、期間や連番での範囲検索が1〜2台へ収まる利点があります。反面、単調増加するキーとの組み合わせでは末端への集中を招きます。ハッシュ分割はキーの値をハッシュ関数へ通した結果で割り当てる方式で、分布は平らになりますが、範囲検索は全シャードへ散らばる。

3つ目がディレクトリ方式です。キーとシャードの対応表を別に持って振り分けるため、テナント単位の割り当てを後から動かしたい場合に柔軟な半面、対応表が単一障害点になりやすく、参照の一段が全クエリに乗ります。時系列データを大量に扱うなら、日付をレンジで区切りつつ、その中を機器IDのハッシュで散らす複合の構成が扱いやすい落としどころです。

検索条件にシャードキーが乗らないクエリが全ノードへ広がる問題

分割後のクエリは2種類に割れます。シャードキーが検索条件に含まれていれば、ルーティング層は該当シャードだけへ問い合わせを送れる。含まれていなければ、全シャードへ同じクエリを投げて結果を集める動きになります。後者が増えるほど台数を足しても応答は速くならず、増設が性能低下につながる場面すら生じます。

設計段階では主要なクエリを一覧に書き出し、検索条件にシャードキーが乗るかを機械的に確認してください。乗らないクエリが2割を超えるようなら、キーの選び直しか、そのクエリ専用の参照系を別に用意する検討に入ります。MongoDBは7.0系以降、実際のクエリを標本抽出して候補キーの適性を測る analyzeShardKey を備えており、勘ではなく実測で選べます。

シャーディングで失うJOINと一意性と分散トランザクションの扱い

シャードをまたぐJOINと集約がアプリ側の実装に変わる設計上の理由

同じシャード内に閉じたJOINは、これまでどおり動きます。壊れるのは結合相手が別のシャードにいる場合で、データベースは自分の持つ行しか知らないため結合が成立しません。回避策は3つです。関連する行が必ず同じシャードへ落ちるよう親子で同じシャードキーを共有させる。マスタ系の小さな表は全シャードへ複製して置く。それも無理なら、複数シャードから取得した結果をアプリケーション側で突き合わせる。

集約も同じ構図です。全社の合計は各シャードの結果を足し合わせて作る必要があり、中央値や重複排除のように単純な合成が効かない集計は特に高くつきます。日次のバッチで集計結果を別の分析基盤へ書き出し、参照をそちらへ寄せる構成が現実的な逃げ道でしょう。設計の初期に「この画面の数字はどのシャードから来るのか」を1つずつ確認しておくと、実装段階での作り直しを避けられます。

分散トランザクションで整合性を保つときに増える待ち時間と失敗経路

複数シャードを1つの取引としてまとめる場合、二相コミットのような合意の手順が要ります。全ノードへ準備を問い合わせ、全てが応じた段階で確定を指示する流れで、途中でノードが落ちれば宙ぶらりんの取引が残る。応答時間は最も遅いノードに引きずられ、往復が2回分乗ります。単一データベースと同じ感覚で使うと、性能も可用性も想定から外れます。

対処は、分散トランザクションを避ける設計へ寄せることです。1つの取引が1シャードに収まるようシャードキーを選び、複数にまたがる処理は状態遷移を分けて非同期で整合させる。分離レベルやコミットの挙動を前提から確認したい場合はトランザクションとは？ACID・分離レベル・commit/rollbackを解説を参照してください。単一ノードで保証されていた性質のどれが分散で崩れるのかが見えると、線の引き方が決めやすくなります。

連番の主キーが使えなくなる採番設計とUUIDv7という選択肢

意外と足をすくわれるのが採番です。自動採番はそのシャードの中でしか一意を保証しないため、シャード1とシャード2で同じIDが振られます。全体で一意なIDを得る方法は、採番専用のサービスを立てる、シャードごとに開始値と刻み幅をずらす、分散環境で衝突しにくいIDを生成する、の3つです。

ランダムなUUIDは衝突を避けられる一方、値が散らばるためB木索引の更新が広い範囲に及び、書き込み性能を落とします。折衷として広がったのが、先頭に時刻を置いて時間順に並ぶUUIDv7で、2024年5月公開のRFC 9562で標準の一形式として定義されました。PostgreSQL 18系では uuidv7 関数が組み込みで提供され、Citus 14系のリリースノートでも索引の更新範囲を抑える利点として挙げられています。ただし時刻順に並ぶ以上、レンジ分割のシャードキーへ流用すれば集中を招くため、主キーと分散キーは切り分けてください。

シャードの追加とスキーマ変更で効いてくる運用コストの実像と対策

シャード追加時の再配置をオンラインで進めるための前提条件と手順

台数を足すとき、既存のデータは自動移動の対象外です。ハッシュ分割で単純に剰余を取る実装だと、シャード数が変わった瞬間にほぼ全ての行の割り当てが変わり、全件の再配置が必要です。これを避けるため、多くの製品はキー空間を細かい単位へ区切って単位ごとに移動させる方式を採ります。MongoDBのチャンク、Vitessのシャード分割、Citusのシャード再配置がそれにあたります。

自前で分割層を作る場合、この再配置の仕組みまで自作する点は見落とされがちです。移動中に書き込まれた行の追随、移動完了後のルーティング切り替え、失敗時の巻き戻し。ここを軽く見た設計は、台数を増やす初回に長時間の停止を強いられます。製品側の再配置機能をどこまで当てにできるかは、選定時に必ず確認しておくべき項目でしょう。

スキーマ変更とバックアップと監視がノード台数だけ増える負担の実態

分割後は、日常の作業が全て台数倍になります。列を1つ足すだけでも全シャードへ同じ変更を適用し、失敗したシャードがあれば版がずれた状態を解消しなければなりません。バックアップも、シャードごとの断片が同一時点を指すとは限らず、全体を整合した状態へ戻す手順は単一構成より込み入ります。

監視で見るべきは、クラスタ全体の平均ではなくシャード間の偏りです。特定のシャードだけ書き込み待ちが伸びていれば、キーの選定か再配置の遅れを疑ってください。

2026年8月時点の主要な実装とアプリから隠す分散SQLという道

MySQL向けのVitessが担うルーティングとシャードキーの対応付け

MySQLを分割したまま1つのデータベースのように扱う仕組みが、広く使われているVitessです。アプリケーションはVTGateというルーティング層へMySQLの接続として話しかけ、VTGateがVIndexと呼ばれる対応付けの定義を見て該当シャードへ振り分けます。分割の単位はキースペースとシャードで表現され、シャードの分割や結合もオンラインの操作です。

版数は、endoflife.dateとVitess公式のリリース一覧で2026年8月8日時点の最新系が24系（2026年5月公開・24.0.2）、1つ前が23系です。公式ドキュメントはメジャー版を4か月ごとに出し、各メジャー版を1年間支援する方針を示しています。更新の間隔が短いため、追随する系を先に決めないと運用の途中で支援終了に当たります。

PostgreSQL向けのCitusとAurora Limitlessが取る分散の方式

PostgreSQL側の代表がCitusです。拡張として組み込む形を採り、調整役のコーディネータと実データを持つワーカーで構成されます。表は、分散キーで切り分ける分散テーブルと全ノードへ複製する参照テーブルを使い分ける設計です。2026年2月公開の14系はPostgreSQL 18対応が主眼で、同時にPostgreSQL 15の支援が外れ、直近3メジャー版を支える方針が示されました。

マネージドの選択肢がAmazon Aurora PostgreSQL Limitless Databaseで、2024年10月に一般提供へ入りました。DBシャードグループの中にルーターとシャードが置かれ、ルーターがSQL接続を受けて振り分ける構造です。表はシャードキーで分散する表、全シャードへ複製する参照表、単一シャードに置く通常表の3種類に分かれ、シャードキーは複数列を組み合わせたハッシュ分散も指定できます。2026年7月には16.13.101が出ています。自前でCitusを運用するかマネージドへ寄せるかは、シャード追加と版上げを誰が担うかで決めてください。

MongoDBのシャーディングとシャードキー変更を支える運用機能

ドキュメント指向のMongoDBは、シャーディングを製品の中核機能として持ちます。コレクション単位でシャードキーを指定し、レンジ方式とハッシュ方式のどちらかを選ぶ形です。チャンク単位でバランサーが自動的に平準化するため、偏りへの対処が運用の手作業になりにくい点が利点でしょう。

この製品を特徴づけるのは、選び直しの余地が残されていることです。5.0系以降は reshardCollection でシャードキーそのものを変更でき、既存キーへ列を足して細かくする refineCollectionShardKey も用意されています。8.0系ではデータ分散の高速化が公表されました。2026年8月8日時点では8.0系が主系で、短期リリースの系として8.3が2026年5月に出ています。一発勝負になりがちなキー設計に修正の道が残る点は、他の実装と比べた際の判断材料です。

分散SQLへ寄せてシャードキー設計をデータベース側へ委ねる判断

もう1つの道は、分割をアプリケーションから見えなくする製品を選ぶことです。分散SQLと呼ばれる系統は、データを内部でレンジ単位に切り分けてノードへ配り、分割も再配置も自動で進めます。開発側は通常のSQLとトランザクションをそのまま書ける。MySQL互換で分散を担うTiDBとは？MySQL互換の分散SQLの仕組みとHTAP・採用判断や、PostgreSQL互換のCockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断が該当します。

代わりに払うものもあります。ノード間の合意処理が入るぶん、単一ノードのMySQLやPostgreSQLと比べて1件あたりの応答は伸びやすく、運用対象のコンポーネントも増える。既存のアプリケーションを大きく書き換えずに書き込みを伸ばしたい要件なら、自前で分割層を組むより分散SQLのほうが総コストは低く収まる場面が多いはずです。逆にテナントごとにデータが完全に独立していて分割の境界が明確なら、素直にシャーディングを組むほうが速く安く仕上がります。

シャーディングを採用してよい条件と見送るべき場面の判断基準の整理

採用に踏み切ってよい負荷水準とデータ量の具体的な線引きの目安

踏み切る条件を先に言い切ります。垂直方向の増強を上限まで実施し、参照はリードレプリカへ逃がし、保持期間の見直しで不要な行を退避させてなお、書き込みの待ち行列が業務時間中に解消しない。この状態が観測できて初めて分割が第一候補へ上がります。データ量が数テラバイトでも、書き込みが詰まっていないなら理由になりません。

設計上の前提が揃っていることも条件です。テナントIDや利用者IDのように、ほぼ全てのクエリの検索条件へ自然に現れる列があり、その列で分けても1つのシャードへ全体の何割も集まる偏りが出ない。ここを確認しないまま分割へ進むと、クロスシャードのクエリが増えて分割前より遅い構成が出来上がります。

受託開発の現場でシャーディングを見送ると判断する典型的な条件

見送るべき場面も明確です。1つ目は、集計や横断検索が主要機能で、シャードキーに乗らないクエリが機能の中心にある場合。2つ目は、運用担当が実質1人で、再配置やスキーマ変更の手順を平常時に回せない場合。3つ目は、書き込み量の増加が催事や季節要因によるもので、平常時は現行構成で足りている場合です。

3つ目は特に判断を誤りやすい。年に数回の繁忙期のために恒久的な複雑さを抱え込むより、その期間だけ増強するほうが安く済みます。分割は一度入れると戻せません。迷う段階なら、まだ入れる時期ではないというのが実務上の結論です。

設計段階で決め切っておくシャーディング前提の運用要件の確認項目

採用すると決めた場合、設計段階で確定させる項目は5つです。シャードキーに使う列と選定根拠、分散方式、シャードをまたぐ集計をどこで引き受けるか、全体で一意なIDの採番方式、シャード追加時の再配置手順と想定停止時間。ここを曖昧にしたまま実装へ入ると、稼働後の変更コストが跳ね上がります。

設計と実装の両方を社内だけで抱えるのが難しい場合は、外部の設計支援を挟む方法が選択肢になるでしょう。一創ではデータ分析基盤構築・MLOps構築支援として、大規模データの分散設計から集計基盤の切り出しまでを含めた構築を請け負っています。分割へ進むべきか、まだ増強とレプリカで足りるのかという入口の見極めだけでも、先に済ませておくと後戻りを避けられます。

よくある質問

シャーディングの検討時に問い合わせの多い論点を、各製品の公式ドキュメントの記載に沿って整理します。

シャーディングとパーティショニングは何が違いますか？

データを置く先が別のサーバーかどうかが分かれ目です。パーティショニングは1つのデータベースの中で表を小さな単位へ切る仕組みで、索引の効きや古いデータの切り離しには効きますが、サーバー1台の書き込み上限は動きません。シャーディングは行を複数のサーバーへ分けるため、台数を足した分だけ書き込みの受け口が増えます。なお「水平分割」という語は単一DB内の分割を指す場合もあるので、会話ではノードをまたぐかどうかを確認しておくと行き違いが減ります。

シャードキーは後から変更できますか？

製品によります。MongoDBは5.0系以降、reshardCollection でシャードキーそのものを変更でき、既存のキーへ列を追加して細かくする refineCollectionShardKey も用意されています。一方、アプリケーション側で分割層を自作した構成では、変更は全データの再配置と実装の書き直しを伴う大掛かりな作業です。後から直せる保証がない前提で、初回の選定に時間をかけるのが安全でしょう。

シャーディングを入れるとJOINは使えなくなりますか？

同じシャード内で完結するJOINは使えます。使えなくなるのは、結合相手が別のシャードにある場合です。対処は3通りで、親子で同じシャードキーを共有させる、小さなマスタ表を全シャードへ複製する、複数シャードの結果をアプリケーション側で突き合わせる、のいずれかになります。CitusやAurora Limitlessの参照テーブルは2つ目を製品機能にしたもので、コード量を増やさずに済みます。

小規模なシステムでもシャーディングは必要ですか？

必要になる場面はほとんどありません。書き込みが1台で捌けている限り、分割は複雑さだけを持ち込みます。まずはインスタンスの増強、次にリードレプリカ、その次に保持期間の見直しという順で手を打ってください。数百万行程度なら、索引設計とクエリの見直しで解決する場合が大半でしょう。

シャーディングと分散SQLはどちらを選ぶべきですか？

アプリケーション側にどこまで手を入れられるかが決め手です。TiDBやCockroachDBのような分散SQLは分割と再配置をデータベースが引き受けるため、シャードキーを意識しない実装のまま書き込みを伸ばせます。逆に、テナント単位でデータの境界が明確な場合や1件あたりの応答時間へ厳しい要件がある場合は、自前でシャーディングを組むほうが構成も費用も軽く収まります。

関連記事

• Cassandraとは？分散NoSQLの仕組み・データモデル・採用判断：分散を前提に設計されたNoSQLのデータモデルを扱っています
• ScyllaDBとは？Cassandra互換C++実装の仕組みと採用判断：同じ分散モデルを別実装で追った場合の違いが分かります
• Amazon Keyspacesとは？Cassandra互換サーバーレスDBの仕組み：分散の運用をマネージドへ寄せる選択肢の比較対象です
• スケーラブル（スケーラビリティ）とは？意味と拡張性の考え方：拡張性そのものの考え方を非エンジニア向けに整理しています