サービスの成長にともなってデータ量とアクセスが増え、ピーク時間帯にデータベースの応答が遅くなる。書き込みが詰まってタイムアウトが出はじめる。そんな状況で外部のエンジニアや開発ベンダーから「そろそろシャーディングを検討しましょう」と提案され、判断を保留したまま検索にたどり着いた方も多いのではないでしょうか。
慎重になるのは当然です。シャーディングはデータベースを複数のサーバーへ物理的に分割する設計変更であり、いったん分割の基準（シャードキー）を決めてしまうと、後から変更するには全データの移行が必要になります。Microsoft の設計パターン集でも、シャードキーの選択は「シャード化されたシステムで最も重要な設計上の決定」であり、選び直しは「ライブシステムでのコストとリスクの高い操作」だと明記されています（シャーディング パターン - Azure Architecture Center）。一度踏み出すと戻りにくい判断を、DB専任のいない小規模チームが感覚で決めるのは危険です。
一方で、判断を先送りし続けることにもコストがあります。必要な移行を遅らせれば、より逼迫した状態で、より短い期限で設計変更を迫られることになります。必要なのは「怖いから保留する」でも「言われたからやる」でもなく、今の自社が本当にシャーディングの適用条件を満たしているのかを、数字で判定できる物差しです。
判断の軸は2つあります。ひとつは「シャーディングが効く症状かどうか」の見極め。もうひとつは「シャーディングより安く、戻しやすい手段を試し切ったかどうか」の確認です。この2つを順番に潰していけば、投資判断は「やる／やらない」の二択ではなく、「今どの段階にいて、次に何を測るべきか」という具体的なタスクに変わります。
本記事では、シャーディングの仕組みとシャードキーの役割から始め、パーティショニング・レプリケーションとの違い、メリットとデメリットの両面、スケールアップの限界を判定する定量的なサイン、そして導入可否を決める5ステップの判断フローまでを整理します。あわせて、導入後に恒常的に発生する運用課題と、自前実装とマネージド分散データベースの選択軸についても解説します。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
シャーディングとは？データベースを水平分割して負荷を分散する仕組み
シャーディングとは、1つの大きなデータベースを「シャード」と呼ばれる複数の断片に分割し、それぞれを別のサーバーに配置することで、データ量とアクセスを複数台に分散させる設計手法です。英語の shard（破片）が語源で、日本語では「水平分割」とも呼ばれます。
重要なのは、各シャードが同じスキーマ（テーブル構造）を持ち、異なる行（レコード）のサブセットを保持するという点です。たとえば会員テーブルを3つのシャードに分割した場合、テーブル定義はどのシャードも同一で、会員Aのデータはシャード1に、会員Bのデータはシャード2に、というように行単位で振り分けられます。アプリケーションから見れば1つの論理的なテーブルですが、物理的には3台のサーバーに分かれて存在している状態です。
この構成の最大の特徴は、読み取りだけでなく書き込みもスケールする点にあります。後述するリードレプリカ（複製）は読み取り負荷しか逃がせませんが、シャーディングはデータそのものを分けるため、書き込みリクエストも各シャードに分散されます。Azure の設計パターン文書でも、シャーディングを使う状況として「データ量の合計が単一データベースインスタンスのストレージ容量を超えている」「トランザクションのスループットまたはクエリの同時実行数が1つのインスタンスで維持できる量を超えており、書き込み負荷も高いため読み取りレプリカだけではボトルネックが解決しない」という2条件が挙げられています。
なお、この記事ではテーブル設計・インデックス・トランザクションといった基礎用語を前提に説明します。用語に不安がある場合はデータベースの基礎知識もあわせてご確認ください。
シャードとシャードキーの基本構造
シャーディングを構成する要素は、大きく3つに分けられます。
シャードは、分割されたデータの格納先です。それぞれが独立したデータベースとして動作し、通常は別のサーバー（ストレージノード）上で稼働します。ただしシャードとサーバーが1対1である必要はなく、1台のサーバーに複数のシャードを載せる構成も一般的です。
シャードキーは、どのデータをどのシャードに置くかを決める基準となる属性です。パーティションキーとも呼ばれます。会員IDやテナントID、注文日時などが候補になります。このキーの選び方が、後述するホットスポット（特定シャードへの負荷集中）や再分散コストを左右します。
シャーディングロジックは、リクエストを適切なシャードへ振り分けるルーティング処理です。アプリケーションのデータアクセス層に自前で実装する場合と、データベース製品やミドルウェアが透過的に担う場合があります。データの物理的な位置をこの層で抽象化しておくと、シャード間でデータを移動させるときにアプリケーションのビジネスロジックを変更せずに済みます。その代わり、取得のたびに「どのシャードにあるか」を解決するオーバーヘッドが発生します。
処理の流れとしては、アプリケーションがリクエストを発行する → シャーディングロジックがシャードキーから対象シャードを特定する → 該当シャードに対してクエリを実行する、という順序になります。単一DBの構成に「振り分け層」が1段挟まる、とイメージするとわかりやすいでしょう。
水平分割と垂直分割の違い
分割という言葉には2つの方向があり、混同されやすいポイントです。
水平分割は、テーブルを行方向に切る方法です。会員テーブルを「会員IDの下1桁が0〜4のグループ」「5〜9のグループ」のように分けるイメージで、どの分割先も同じカラム構成を持ちます。シャーディングは、この水平分割を複数サーバーにまたがって行うものです。
垂直分割は、テーブルを列方向に切る方法です。会員テーブルから「プロフィール情報」と「認証情報」を別テーブル・別データベースに分けるようなケースが該当します。アクセス頻度や機密性の異なるカラムを分離したいときに使われますが、行数そのものは減らないため、データ量の増加によるスケーラビリティ問題の解決策にはなりません。
なお、水平分割と垂直分割は排他的な選択肢ではありません。Azure の設計パターン文書でも、シャーディングは垂直パーティショニングや機能パーティショニングと補完的に使えるとされています。1つのシャードの中で垂直分割されたエンティティを持つ、といった構成も設計としては成立します。
シャーディングとパーティショニング・レプリケーションの違い
提案されたのが本当にシャーディングでなければならないのかを評価するには、隣接する2つの手法との違いを正確に押さえておく必要があります。判断の軸は「複製するのか分割するのか」「単一サーバー内か複数サーバー間か」「何がスケールするのか」の3つです。
パーティショニングとの違い（1台の中で分けるか、複数台にまたがるか）
パーティショニングは、1つのテーブルを内部的に複数の区画に分けて管理する仕組みです。MySQL の公式リファレンスでは「個々のテーブルの部分をファイルシステムに配分できるようにする機能」と説明されており、各パーティションのデータとインデックスは同一サーバー内の指定ディレクトリに配置されます（MySQL 8.0 リファレンスマニュアル 24.1 MySQL のパーティショニングの概要）。
つまり、パーティショニングとシャーディングの決定的な違いは分割先が同じサーバーの中か、別のサーバーかという点です。パーティショニングでは、検索条件に該当しない区画をスキャン対象から自動的に除外する「パーティションプルーニング」により、大きなテーブルへのクエリを高速化できます。古いパーティションを丸ごと切り離してアーカイブする、といった運用も容易です。
ただし、パーティショニングは同じサーバーのCPU・メモリ・ディスク・ネットワーク帯域を共有し続けます。したがって、単一サーバーの物理リソース上限そのものは突破できません。「テーブルが大きすぎてクエリが遅い」という症状にはパーティショニングが効きますが、「サーバー1台の書き込み処理能力を超えている」「ストレージ容量の上限に達しつつある」という症状には効きません。ここを取り違えると、パーティショニングで済む問題にシャーディングという過剰な投資をしてしまうことになります。
なお、MySQL 8.0 では垂直パーティショニング（カラムを別の物理パーティションに割り当てる方式）はサポートされておらず、導入の計画もないと明記されています。パーティショニングという言葉が出てきた場合、実質的には水平方向の区画分けを指していると理解して差し支えありません。
レプリケーションとの違い（複製か分割か）
レプリケーションは、同じデータのコピーを複数のサーバーに保持する仕組みです。書き込みを受け付けるプライマリと、その内容が反映されるレプリカ（リードレプリカ）で構成されるのが一般的で、Amazon RDS のリードレプリカでもプライマリDBインスタンスへの更新はレプリカへ非同期にコピーされると説明されています（Amazon RDS リードレプリカ）。
シャーディングが「データを分けて別々のサーバーに置く」のに対し、レプリケーションは「同じデータを複数のサーバーに複製する」という点が本質的な違いです。この差から、以下の帰結が導かれます。
- レプリケーションは読み取りをスケールさせるが、書き込みはスケールしない。すべての書き込みは最終的にプライマリ1台が処理するため、書き込みが詰まっている状態はレプリカを増やしても解消しません。
- レプリケーションはデータ量を減らさない。各サーバーが全データを保持するため、ストレージ容量の上限問題には効きません。
- レプリケーションは可用性向上に寄与する。プライマリ障害時にレプリカへ切り替えるフェイルオーバー構成が組めます。一方、シャーディングは可用性を主目的とした手法ではありません（障害の影響範囲を1シャードに限定する効果はありますが、これは可用性向上とは別の話です）。
- 非同期レプリケーションには遅延がある。書き込み直後の読み取りで最新データが返らない可能性があるため、業務要件によってはレプリカに逃がせない読み取りが残ります。
「バックアップのためにシャーディングする」「可用性を上げるためにシャーディングする」という説明が出てきた場合は、レプリケーションと混同されている可能性があります。目的がバックアップ・冗長化であれば、シャーディングは適切な手段ではありません。
3手法の使い分け早見表
観点 | シャーディング | パーティショニング | レプリケーション |
|---|---|---|---|
データの扱い | 分割（各サーバーが一部を保持） | 分割（同一サーバー内で区画化） | 複製（各サーバーが全体を保持） |
分割・配置の範囲 | 複数サーバーにまたがる | 単一サーバー内で完結 | 複数サーバーに同一データを配置 |
読み取りのスケール | ○（キーが特定できる場合） | △（プルーニングによる高速化） | ○（レプリカ追加で分散） |
書き込みのスケール | ○ | ✕（単一サーバーの上限まで） | ✕（プライマリ1台に集約） |
ストレージ容量の拡張 | ○（シャード追加で拡張） | ✕（単一サーバーの上限まで） | ✕（各サーバーが全量を保持） |
可用性への寄与 | △（障害の影響範囲を限定） | ✕ | ○（フェイルオーバー構成） |
実装・運用の難易度 | 高（ルーティング・再分散・分散トランザクション） | 低〜中（DB機能として提供） | 中（遅延と切替設計） |
後戻りのしやすさ | 低（シャードキー変更は全データ移行） | 高（パーティション定義の変更・解除が可能） | 高（レプリカの増減は容易） |
この表の読み方はシンプルです。症状が「読み取りが遅い」ならレプリケーションとキャッシュ、「特定の巨大テーブルへのクエリが遅い」ならパーティショニング、「書き込みが詰まっている・容量が限界」ならシャーディングが候補になります。提案を受けた際は、まず自社の症状がどれに当てはまるかを確認してください。
シャーディングのメリットとデメリット
投資判断に必要なのは効果の一覧ではなく、効果と引き換えに引き受ける負債の総量です。ここではメリットとデメリットを同じ密度で整理します。
メリット：書き込みスケール・データ量削減・障害の局所化
書き込みスループットと容量を水平にスケールできるのが最大の利点です。シャードを追加すれば、その分だけ書き込みを受け付けるサーバーとストレージが増えます。垂直スケール（1台の増強）と異なり、理論上は台数を増やし続けることでスケールできます。
1テーブル・1サーバーあたりのデータ量が減ることによる副次的な効果もあります。インデックスサイズが小さくなり、キャッシュのヒット率が上がり、バックアップやインデックス再構築といったメンテナンス作業の所要時間も短縮されます。
高価な単一マシンではなく、汎用的なハードウェアを複数台使える点はコスト面の利点です。Azure の文書でも、コスト最適化の観点から「コストの高い単一のリソースではなく、よりコストの低いコンピューティング・ストレージリソースの複数インスタンスを使用できる」ことが挙げられています。ハイエンドなDBインスタンスの単価は性能に対して非線形に上昇するため、一定規模を超えると分散のほうが安くなる領域があります。
障害の影響範囲が局所化されるのも重要です。1つのシャードで障害が発生しても、他のシャードのデータにはアクセスできます。メンテナンスや復旧作業も、全データを停止せずにシャード単位で実施できます。
データの物理的な配置をコントロールできる点も、要件によっては決定打になります。地域ごとにシャードを分ければ、データレジデンシー（データを特定の管轄区域内に置く）の規制要件に対応でき、ユーザーに近い場所にデータを置くことで遅延も短縮できます。
デメリット：クロスシャード・運用負荷・後戻りの難しさ
シャードをまたぐクエリのコストが跳ね上がります。単一シャードで完結するクエリは効率的ですが、複数シャードからデータを集める必要があるクエリは、各シャードへ並列にリクエストを投げて結果をアプリケーション側で集約する形になります。並列化しても、最も遅いシャードの応答時間が全体の待ち時間を決めます。JOIN・集計・全件検索といった処理は、単一DB時代と同じようには書けません。
分散トランザクションの難易度が上がります。複数シャードにまたがる更新で強い整合性を保とうとすると、2フェーズコミットなどの分散調整プロトコルが必要になり、レイテンシの増加・障害モードの追加・スループットの低下を招きます。Azure の文書でも「ほとんどのシャード化されたシステムでは分散トランザクションを回避し、代わりに結果整合性を採用する」とされています。つまり、アプリケーション側で一時的な不整合を許容する設計に作り替える必要が出てきます。
シャード追加時の再分散（リシャーディング）が発生します。データの偏りは挿入・削除の繰り返しで時間とともに蓄積し、ホットスポットにつながります。再調整はシャード間でデータを移動させる作業であり、多くの場合ダウンタイムかスループット低下を伴います。
運用の手間がシャード数に比例して増えます。システム全体の健全性を把握するには全シャードのメトリクスとログを集約する必要があり、バックアップは各シャードを個別に取得したうえでシャード間の整合性を保つ復元手順の設計が必要になります。スキーマ変更（DDL）も全シャードで足並みを揃えて実行しなければなりません。
アプリケーション側の実装負担が増えます。シャーディングロジック、シャードマップの管理、接続プールの分散、リトライ処理など、単一DBでは不要だったコードが追加されます。
そして最も重い制約が、後戻りが難しいという点です。シャードキーを選び直すには全データを新しいレイアウトへ移行する必要があり、稼働中のシステムではコストもリスクも高い作業になります。パーティショニングやレプリケーションが「試して合わなければ戻せる」施策であるのに対し、シャーディングは片道の設計判断に近い性質を持ちます。
スケールアップの限界とスケールアウトへの移行点
シャーディングの是非は、「垂直スケールで粘るべきか、水平スケールへ移行すべきか」という問いに言い換えられます。ここが記事の中核です。
スケールアップとスケールアウトの違い
スケールアップ（垂直スケール）は、1台のサーバーの性能を上げるアプローチです。CPUコア数を増やす、メモリを増設する、ストレージのIOPSを上げる、といった対応が該当します。クラウドのマネージドDBであればインスタンスタイプの変更で対応でき、アプリケーションの改修は原則不要です。短時間の再起動を伴うものの、作業としては最も軽量です。
スケールアウト（水平スケール）は、サーバーの台数を増やすアプローチです。リードレプリカの追加もスケールアウトの一種ですが、書き込みと容量をスケールさせるにはシャーディングのようなデータ分割が必要になります。
垂直スケールには2つの限界があります。ひとつは物理的な上限です。Azure の文書が指摘するとおり、ディスク容量・コンピューティングリソース・ネットワーク帯域のいずれも、最終的には1台のサーバーで増やせる限界に到達します。もうひとつはコストの非線形性です。ハイエンドなインスタンスは性能の伸びに対して料金の伸びが大きくなる傾向があり、ある地点から「同じ費用で汎用インスタンスを複数台」のほうが有利になります。
とはいえ、垂直スケールを軽視すべきではありません。同じ文書でも、シャーディングが適さないケースとして「データ量とスループットが、予想される増加を含めても1つのデータベースインスタンス内に収まる」場合が挙げられています。垂直スケールで足りるうちは、クエリの単純さとトランザクションの整合性を維持できるという大きな利点があります。
シャーディングを検討すべき定量的なサイン
以下のサインが複数該当する場合、シャーディングの検討段階に入っていると判断できます。逆に、1つも当てはまらない場合は他の手段を先に試すべき段階です。
1. 総データ量が単一インスタンスのストレージ上限に近づいている 使用中のマネージドDBサービスや自社ハードウェアの最大ストレージ容量に対して、現在の使用量と増加ペースから逆算した到達時期を確認します。増加が線形であれば、残り期間から移行の準備期間を差し引いて判断できます。垂直スケールでの拡張余地が残っているかどうかが分岐点です。
2. 書き込みスループットまたは同時実行数が単一インスタンスで維持できない ピーク時のトランザクション数、コネクション数、書き込みレイテンシを計測します。CPU使用率やディスクIOが張り付いており、インスタンスタイプを上げても改善幅が縮小している場合、垂直スケールの限界が近い可能性があります。
3. リードレプリカを追加しても書き込みのボトルネックが解消しない レプリカ追加後もプライマリの負荷が下がらない、あるいは書き込み待ちが残る場合、症状は読み取りではなく書き込みにあります。これはシャーディングが効く典型的なパターンです。逆に、レプリカ追加で改善するなら、シャーディングは過剰な投資になります。
4. レプリケーション遅延が業務要件を満たさない 非同期レプリケーションの遅延が許容範囲を超えており、読み取りをレプリカに逃がせない業務が増えている場合、レプリケーションによる負荷分散の余地が実質的に残っていないことになります。
5. 規制・契約上、データの物理的分離が必要 データレジデンシー要件や、テナントごとの物理分離が契約で求められる場合は、性能とは別の理由でシャーディング（特に地理的シャーディング）が選択肢になります。
判断のポイントは、これらを「印象」ではなく「計測値」で確認することです。「なんとなく重い」ではなく「ピーク時のCPU使用率が95%で、うち書き込み処理が○%」という粒度まで落とせて初めて、投資判断の材料になります。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
シャーディング導入を判断する5ステップ
ここからは、DB負荷の打ち手を「安く・戻しやすい」順に並べた判断フローを示します。上から順に検証し、各ステップの「次へ進む条件」を満たした場合にのみ次へ進んでください。
ステップ1 ボトルネックを特定する
最初にやるべきは、対策の検討ではなく計測です。「DBが遅い」という症状の裏側で、実際に何が詰まっているのかを特定します。
確認する項目は以下のとおりです。
- リソース使用状況: CPU使用率、メモリ、ディスクIOPS・スループット、ネットワーク帯域のうち、どれが上限に張り付いているか
- スロークエリログ: 実行時間の長いクエリの上位。実行回数×実行時間の積で「合計負荷が大きいクエリ」を特定する
- 待機イベント／ロック: 処理が待たされている原因が、IO待ちなのかロック競合なのか
- 読み取りと書き込みの比率: 負荷の内訳が読み取り中心か書き込み中心か
- ピークと平常時の差: 常時逼迫しているのか、特定時間帯だけなのか
負荷の再現性が低い場合や、増加予測に対する耐性を確認したい場合は、負荷試験で意図的に負荷をかけて限界点を測る方法が有効です。進め方は負荷試験の進め方で解説しています。
次へ進む条件: ボトルネックの箇所（CPU／IO／ロック／ネットワーク）と、読み取り・書き込みの負荷比率が数値で把握できていること。ここが曖昧なまま先に進むと、効かない対策に投資することになります。
ステップ2 クエリ・インデックス改善で足りるか検証する
多くの「DBが重い」問題は、この段階で解決します。実行計画を確認し、フルスキャンが発生しているクエリ、インデックスが効いていない検索条件、N+1問題によるクエリの大量発行がないかを点検します。
見直しの観点は以下です。
- 頻出クエリの検索条件に対して適切なインデックスが張られているか
- 不要なインデックスが更新性能を落としていないか
- 1リクエストあたりのクエリ発行数が過剰になっていないか
- 集計クエリを事前集計テーブルやマテリアライズドビューに置き換えられないか
- アプリケーション側で不要なデータまで取得していないか
改善の費用対効果はこの段階が最も高く、しかも失敗しても元に戻せます。次へ進む条件: 上位のスロークエリを改善しても、ボトルネック指標が業務要件を満たす水準まで下がらないこと。
ステップ3 キャッシュとリードレプリカで読み取りを逃がす
ステップ1で負荷の大半が読み取りだと判明した場合、この段階で解決する可能性が高くなります。
キャッシュは、参照頻度が高く更新頻度の低いデータをインメモリストアやアプリケーション層に保持し、DBへの問い合わせ自体を減らす手段です。リードレプリカは、参照系クエリをレプリカへ振り分けてプライマリの負荷を下げる手段です。
導入時の注意点は、レプリケーション遅延との付き合い方です。書き込み直後に同じデータを読む処理（登録完了画面など）はプライマリを参照する、といった振り分けルールを設計する必要があります。
次へ進む条件: キャッシュとレプリカを導入しても、プライマリの書き込み負荷またはストレージ容量が要件を満たさないこと。ここで解決するなら、シャーディングは不要です。
ステップ4 垂直スケールとパーティショニングの余地を確認する
書き込みまたは容量が問題である場合、次に検討するのが垂直スケールとパーティショニングです。
垂直スケールは、現在のインスタンスタイプに対して上位のプランがどれだけ残っているか、その増強で何ヶ月分の成長を吸収できるかを試算します。「あと2段階の増強余地があり、成長ペースから見て18ヶ月は持つ」という見立てが立つなら、その期間を設計検討と段階的な移行準備に充てられます。
パーティショニングは、特定の巨大テーブルへのクエリが遅い場合に有効です。日付レンジでパーティションを切ればプルーニングによりスキャン範囲が絞られ、古いデータの切り離しも容易になります。DB製品の機能として提供されるため、アプリケーションの改修範囲はシャーディングよりはるかに小さく済みます。Azure の文書でも、シャーディングが適さないケースとして「データベースエンジンがパフォーマンスのニーズを満たすテーブルレベルのパーティション分割をサポートしている」場合が挙げられています。
次へ進む条件: 垂直スケールの余地が乏しく（またはコストが見合わず）、パーティショニングでも単一サーバーのリソース上限を突破できないこと。
ステップ5 書き込み・容量が限界ならシャーディングを設計する
ステップ1〜4をすべて通過して初めて、シャーディングの設計に着手します。この段階では、以下を並行して検討します。
- シャードキーの候補選定: 後述の観点で、偏りが出にくく変更されにくい属性を洗い出す
- 分割方式の選択: ハッシュ・レンジ・ディレクトリ（ルックアップ）・地理のいずれを採用するか
- クロスシャードクエリの棚卸し: 現行クエリのうち、シャードをまたぐものがどれだけあるか。それらをどう作り替えるか
- 運用体制の確認: 監視・バックアップ・スキーマ変更・再分散を回せる人員と手順があるか
- 移行計画: 既存データの移行方法、切り替え時のダウンタイム、切り戻し手順
- 代替案との比較: 自前実装ではなく、シャーディングを製品側が担うマネージド分散データベースへの移行と比較する
この5ステップを踏むことで、「シャーディングをやるべきか」という漠然とした問いは、「今どのステップにいて、次に何を計測・検証すべきか」という具体的なタスクに変わります。チームや経営層への説明も、このフローに沿って現在地を示す形にすれば、投資判断の根拠として機能します。
シャードキーの選び方と分割方式
シャーディングに進むと決めた場合、最も慎重に決めるべきがシャードキーと分割方式です。ここでの選択が、その後の運用コストのほぼすべてを決めます。
ハッシュ方式・レンジ方式・ディレクトリ方式の違い
ハッシュ方式は、シャードキーのハッシュ値をもとに配置先を決める方式です。データと負荷が均等に分散されやすく、マッピング情報を別途保持する必要がありません。一方で、hash(key) mod N のような単純なハッシュ関数を使うと、シャードを増減させた際にほとんどのキーの配置先が変わり、大規模なデータ移行が発生します。コンシステントハッシュ法（一貫性のあるハッシュ）を用いれば、シャード数の変更時に移動するキーを一部に抑えられます。範囲検索には向かず、連続した値のデータが複数シャードに散らばる点も注意が必要です。
レンジ方式は、シャードキーの値の範囲でシャードを分ける方式です。「2026年10月の注文はシャードA、11月はシャードB」といった形で、関連するデータがまとまって配置されます。範囲クエリを1回の操作で1シャードから取得できるため、期間指定の集計が多いシステムに向きます。実装も比較的シンプルです。半面、負荷が均等に分散される保証はなく、最新データにアクセスが集中するようなパターンでは特定シャードが偏ります。再分散にはシャード間でのデータの分割・マージが必要で、その間データストアの一部または全部がオフラインになる場合があります。
ディレクトリ方式（ルックアップ方式）は、シャードキーと配置先の対応表（シャードマップ）を保持し、それを参照して振り分ける方式です。配置を細かく制御でき、特定のテナントを専用シャードに置く、負荷の高いテナントを分離する、といった運用が可能です。論理シャードを多めに定義して少数の物理シャードにマッピングする「仮想パーティション」構成にしておくと、負荷が偏ったときにアプリケーションコードを変更せずマッピングだけ組み替えて再分散できます。デメリットは、配置先を引くためのオーバーヘッドと、マッピング情報自体が単一障害点になりうる点です。キャッシュとレプリカによる保護が前提になります。
地理的方式は、データの発生地域や利用地域でシャードを分ける方式です。データレジデンシー要件への対応と、ユーザー近傍配置による遅延短縮が主な目的になります。ただしユーザー分布が偏っていればデータと負荷の偏りが生じるため、各リージョン内でハッシュやルックアップを併用する構成が現実的です。
方式 | 分散の均等性 | 範囲検索 | シャード増設のしやすさ | マッピング管理 |
|---|---|---|---|---|
ハッシュ | 高い | 不向き | コンシステントハッシュ併用が前提 | 不要 |
レンジ | 偏りやすい | 得意 | 分割・マージが必要（一部オフライン） | 範囲→シャードの対応が必要 |
ディレクトリ | 制御可能 | 設計次第 | 仮想パーティションで柔軟 | 必要（可用性の担保が課題） |
地理 | 地域分布に依存 | 地域内は可 | リージョン単位のプロビジョニング | リージョン→シャードの対応 |
シャードキー選定でよくある失敗（ホットスポット・変更不能）
ホットスポット（負荷の集中）は最も頻繁に起きる失敗です。連番のIDや時系列のタイムスタンプをレンジ方式のシャードキーにすると、新しく登録されたデータが1つのシャードに集中します。新規ユーザーほどアクティブなサービスでは、最新のシャードだけが逼迫し、他のシャードは遊んでいる状態になります。Azure の文書でも、単調増加する値、カーディナリティの低い属性（真偽値や小さな列挙型）、頻繁に変わる揮発性の属性は避けるべきだとされています。
変更される属性をキーにするのも典型的な失敗です。シャードキーの値が変わると、そのデータを別のシャードへ移動させる必要が生じ、更新のたびにオーバーヘッドが発生します。所属部署・ステータス・地域といった、業務上変わりうる属性は避け、不変または自然に一意になる属性を選びます。
主要なクエリパターンと合っていないキーを選ぶと、日常的な処理の大半がクロスシャードクエリになります。理想は、ほとんどのリクエストが1つのシャードで解決することです。もし1つの属性ですべての要件を満たせない場合は、複数の属性を組み合わせた複合シャードキーを検討します。シャードキー以外の属性で検索する必要がある場合は、セカンダリの索引テーブルを別途用意する設計が定石です。
自動採番フィールドをシャードキーにするのも避けるべきパターンです。シャードごとに独立して採番されるため、異なるシャードのデータに同じ値が割り当てられる可能性があります。シャードキーに限らず、分散環境での一意なID生成方法はあらかじめ設計しておく必要があります。
将来のシャード数に上限を作ってしまうのも見落としがちな失敗です。たとえばキーの下1桁で分ける設計にすると、物理シャードの上限が10に固定されます。それを超える規模になった時点で、キーロジックの変更とデータ移行という重い作業が必要になります。想定成長率から逆算し、論理シャードを多めに用意しておく設計が安全です。
シャーディング導入後に発生する運用課題（クロスシャードクエリ・リシャーディング）
シャーディングは「導入して終わり」ではなく、恒常的な運用コストを伴います。自社でこれを回せるかどうかが、導入可否のもう一つの判断軸です。
クロスシャードクエリと分散トランザクション
シャードをまたぐ検索・JOIN・集計は、単一DB時代のようにSQL一発で書けません。全シャードに並列でクエリを投げて結果をアプリケーション側で集約する「ファンアウトクエリ」を実装することになりますが、並列化しても最も遅いシャードが全体のレイテンシを決めます。シャード数が増えるほど、リソース消費と複雑さも増加します。
これを避けるための設計手法として、以下が挙げられます。
- データの非正規化: 一緒に参照されることが多い関連エンティティ（顧客とその注文など）を同じシャードに配置し、シャードをまたぐ読み取りを減らす
- 参照データの複製: 更新頻度の低いマスタデータを全シャードに複製し、別データストアへの往復をなくす（ただし更新時の同期と一時的な不整合への対処が必要になります）
- 外部検索エンジンの併用: 横断検索やファセットナビゲーションは、DBのクロスシャードクエリではなく専用の検索サービスに任せる
- セカンダリ索引テーブルの用意: シャードキー以外での検索に対応する参照用テーブルを別途持つ
複数シャードにまたがる更新については、さらに難易度が上がります。強い整合性を求めて2フェーズコミットのような分散調整プロトコルを採用すると、レイテンシの増加・障害モードの追加・スループット低下という代償が生じます。多くのシャード化されたシステムが分散トランザクションを避けて結果整合性を採用しているのはこのためで、その場合はアプリケーション側で一時的な不整合を許容する設計が前提になります。
もし業務要件としてシャード境界をまたぐ強いトランザクション整合性が必須であれば、シャードキーを再検討するか、シャーディングという手段自体が要件に合っているかを見直すべきサインです。
リシャーディング（再シャーディング）の負荷と手順
シャードの負荷やデータ量は、運用を続けるうちに必ず偏っていきます。レコードの挿入と削除が繰り返されることでデータスキューが蓄積し、特定シャードにホットスポットが生じます。これを是正する作業がリシャーディング（再分散）です。
一般的な手順は以下のようになります。
- 対象範囲のユーザーアクティビティを停止または制限する（通常はピーク外の時間帯）
- 新しいシャードまたは物理パーティションへデータを移動する
- シャードマップ（マッピング情報）を更新する
- 該当データを保持しているキャッシュを無効化または更新する
- アクティビティを再開する
作業自体がデータ移動を伴うため、ダウンタイムかスループット低下のいずれかが発生するのが通常です。負荷を軽減する設計上の工夫としては、以下が有効とされています。
- 仮想パーティションの採用: 多数の論理パーティションを少数の物理シャードにマップしておき、データセット全体を再ハッシュせずに論理パーティション単位で移し替える
- シャードサイズを小さく保つ: 少数の大きなシャードより、多数の小さなシャードのほうが移行が速く、負荷分散の柔軟性も高い
- 定期的な再調整を計画に組み込む: 逼迫してから慌てて実施するのではなく、あらかじめ運用サイクルに含める
監視・バックアップ・スキーマ変更の運用コスト
シャード化されたシステムでは、日常的な運用作業がシャード数に応じて増えます。
監視では、システム全体の健全性を把握するために全シャードのメトリクスとログを集約する仕組みが必要です。1台だけ異常な負荷になっていないか、レプリケーション遅延が特定シャードで拡大していないかを横断的に見られる状態を作らなければなりません。
バックアップと復元は、各シャードを個別にバックアップしたうえで、シャード間の一貫性を保つ復元手順を設計する必要があります。1つのシャードだけをある時点に戻すと、他のシャードとの整合性が崩れる可能性があります。障害復旧訓練の対象も、単一DB時代より広がります。
スキーマ変更は、全シャードでDDLの適用を調整する必要があります。適用漏れがあれば、そのシャードにアクセスした処理だけがエラーになる、という発見しにくい障害につながります。
これらはスクリプトや自動化ツールで実装できる作業ですが、その自動化基盤を作り、維持する工数自体が新たなコストになります。DB専任のいない小規模チームがこれを引き受けられるかどうかは、シャーディング導入の可否を左右する現実的な論点です。
自前シャーディングかマネージド分散データベースかの選択
「シャーディングをやるか、現状維持か」という二択で止まっている場合、第三の選択肢を検討する余地があります。
マネージド分散データベースという選択肢
近年は、データの分散配置とルーティングをデータベース製品側が担うサービスが選択肢になっています。たとえば Azure Cosmos DB は物理パーティション間でのデータ分散・分割・クエリのルーティングをアプリケーションの関与なしに処理します。Google Cloud の Spanner も、リレーショナルデータベースとしての整合性を保ちながら水平方向のスケールを提供するサービスとして位置づけられています（Cloud Spanner の紹介 - Google Cloud 公式ブログ）。
Azure の設計パターン文書も「カスタムシャーディングレイヤーを設計する前に、データプラットフォームが既に処理するシャーディングの役割を判断する」ことを推奨しており、シャーディングパターンを自前で実装すべきなのは「シャーディングロジックを自分でビルドして操作するとき」だとしています。サービスによって、シャーディングを完全に管理するもの、シャードマップ管理とルーティングのツールは提供するがシャードキー設計と分割操作は利用者側が担うもの、と関与の度合いが異なります。まずは現在利用中のDBサービスが、どこまでを肩代わりしてくれるのかを確認するのが出発点です。
内製運用体制・移行難易度・コストで選ぶ
自前実装とマネージドサービスのどちらが適切かは、以下の4つの軸で判断します。
1. DB運用に割ける人員 シャードマップの管理、再分散、シャード横断の監視・バックアップ・スキーマ適用を継続的に回せる体制があるか。DBAが不在で、開発と運用を兼務するメンバーしかいない場合、自前シャーディングの運用負荷は現実的なリスクになります。この軸ではマネージドサービスが有利です。
2. 移行難易度とアプリケーション改修範囲 マネージドの分散データベースへ移行する場合、SQLの方言差、トランザクションの扱い、既存ORMとの互換性、データ移行の手順を検証する必要があります。既存アプリケーションの規模が大きいほど改修範囲は広がります。一方、自前シャーディングもデータアクセス層の全面的な作り替えを伴うため、「マネージドは移行が重い、自前は軽い」とは限りません。両方を同じ粒度で見積もることが重要です。
3. ランニングコスト マネージドの分散データベースは、単一インスタンスのRDBと比べて最小構成のコストが高くなる傾向があります。一方、自前シャーディングはインフラ費用こそ抑えられても、開発・運用の人件費が継続的に発生します。インフラ費用だけで比較せず、運用工数を含めた総コストで判断してください。
4. 必要な整合性レベル シャード境界をまたぐ強い整合性が業務要件として必要な場合、自前シャーディングでは分散トランザクションの実装が必要になります。強整合性を製品として提供する分散データベースであれば、この負担を軽減できる可能性があります。
どちらが常に正解ということはありません。判断は、チームの運用体制と業務要件の組み合わせで決まります。
なお、DBの分割を検討する場面では、サービス自体の分割（マイクロサービス化）の議論と混同されることがあります。両者は目的が異なり、DBのスケーラビリティ問題はサービス分割では解決しません。逆に、サービス分割にともなってDBを分ける場合は、性能ではなく責務の分離が目的になります。議論を分けて整理したい場合はマイクロサービスとモノリスの違いもあわせてご覧ください。
まとめ：シャーディングを判断するためのチェックリスト
シャーディングとは、データベースを複数のサーバーへ水平分割し、書き込みとストレージ容量をスケールさせる設計手法です。効果は大きい一方、シャードキーの選択は後から変えにくく、クロスシャードクエリ・再分散・シャード横断の運用という恒常的なコストを引き受けることになります。
判断を進めるにあたって、以下のチェックリストを使ってみてください。すべてに「はい」と答えられる状態になって初めて、シャーディングは合理的な選択肢になります。
- ボトルネックがCPU・IO・ロック・ネットワークのどれか、数値で特定できている
- 詰まっているのが読み取りではなく書き込みまたはストレージ容量であることを確認した
- クエリ・インデックスの改善を試し、それでも要件を満たさないことを確認した
- キャッシュとリードレプリカを導入しても、プライマリの負荷が下がらないことを確認した
- 垂直スケールの残り余地と、それで吸収できる期間を試算した
- パーティショニングで解決しないこと（＝単一サーバーの物理上限が問題であること）を確認した
- 偏りにくく変更されない属性の中から、シャードキーの候補を挙げられる
- 主要なクエリの大半が単一シャードで解決する見込みが立っている
- クロスシャードクエリになる処理を洗い出し、代替設計の方針を持っている
- 再分散・監視・バックアップ・スキーマ変更を継続的に回せる体制がある
- マネージド分散データベースへの移行と、総コスト（インフラ＋運用工数）で比較した
チェックが埋まらない項目があれば、それが次に着手すべきタスクです。「シャーディングをやるかどうか」という大きな問いを一度に決めようとせず、現在地を示して次の1手を決める。この進め方であれば、チーム内でも経営層に対しても、判断の根拠を言葉にして説明できます。
システム基盤の設計方針や外部人材の活用について、社内での検討材料を整理したい方向けに、要件整理や発注判断に使えるお役立ち資料をご用意しています。詳しくはお役立ち資料一覧をご覧ください。
DBのボトルネック調査や分散設計の妥当性検証でお困りの方は、お問い合わせフォームからご相談ください。現状の計測と選択肢の整理といった、要件が固まる前の段階からご相談いただけます。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- シャーディングを検討する前に、まず何から着手すればよいですか？
最初に行うべきはボトルネックの計測です。CPU・IO・ロックのどこが逼迫しているか、負荷が読み取りか書き込みかを数値で把握してから、クエリ・インデックス改善、キャッシュ・リードレプリカ、垂直スケール・パーティショニングの順に安価な手段を試し、それでも書き込みや容量が限界のときのみシャーディングを検討します。
- リードレプリカを増やせばシャーディングは不要になりますか？
読み取り負荷が原因であればリードレプリカの追加で解消できます。しかし書き込みが詰まっている場合はレプリカを増やしても改善せず、書き込みとストレージ容量そのものをスケールさせる必要がある場合にのみシャーディングが有効な手段になります。
- シャードキーを一度決めたら、後から変更できませんか？
変更自体は可能ですが、全データを新しいシャード配置へ移行する必要があり、稼働中のシステムではコストとリスクが高い作業になります。そのため、偏りが出にくく将来も変わらない属性を最初から慎重に選ぶことが重要です。
- 自前でシャーディングを実装せず、マネージド分散データベースに任せることはできますか？
可能で、Azure Cosmos DBやGoogle Cloud Spannerのように、データ分散とルーティングを製品側が担うサービスがあります。DB運用に割ける人員が少ない場合は、まず現行DBサービスがどこまで肩代わりしてくれるかを確認するのが出発点です。
- シャーディング導入後、社内のDB運用体制はどう変わりますか？
監視・バックアップ・スキーマ変更のいずれもシャード数に応じて作業量が増え、全シャードを横断して管理する仕組みが必要になります。再分散（リシャーディング）も定期的に発生するため、これらを継続的に回せる体制があるかが導入可否の重要な判断軸になります。
