データベースのシャーディングの仕組み — 理解が難しい理由

シャーディングとは（そして何ではないか）

シャーディング（別名 水平分割）とは、アプリケーションから見ると「1つの」データベースに見えるもののデータを、複数のマシン（シャードと呼ぶ）に分割することです。各シャードは行の一部だけを保持しますが、全体としては完全なデータセットを表します。

1つの論理テーブル、複数の物理配置

役立つ考え方は、論理構造と物理配置の違いです。

• 論理的には：依然として「Users」テーブルが1つ（カラムや意味は同じ）あります。
• 物理的には：そのテーブルの行は別々の場所に保存されています—例えばID 1–1,000,000 がシャードA、次の100万がシャードBにある、という具合です。

アプリからは1つのテーブルのようにクエリを実行したいですが、内部ではシステムがどのシャードに話すべきかを決める必要があります。

レプリケーションでも垂直スケールでもない

シャーディングはレプリケーションとは異なります。レプリケーションは同じデータのコピーを複数のノードに作り、主に高可用性や読み取りスケールのために使います。シャーディングはデータを分割し、各ノードが異なるレコードを保持します。

また、垂直スケーリング（単一データベースをより大きなマシンに移す）とも異なります。垂直スケールは単純な場合が多いですが、実際には限界がありコストが急増します。

シャーディングが自動的に解決しないこと

シャーディングは容量を増やしますが、すべてのクエリが速くなるわけではありません。以下の点は残ります：

• 関連する行が異なるシャードにあれば ジョイン は高コストになる
• シャード間の トランザクション は困難で、全体原子性を保つには協調が必要になる
• 運用の複雑化：ルーティング、リバランス、デバッグ、障害対応がシステムの一部になる

したがってシャーディングは ストレージとスループットをスケールする手段 として理解するのが正しく、すべての挙動を自動的に良くする魔法ではありません。

チームがシャードする理由：解決しようとする問題

シャーディングはほとんどの場合最初の選択肢ではありません。多くのチームはシステムが成功して物理的限界に達したり、運用上の痛みが頻発するようになったときに選びます。動機は「シャーディングしたい」ではなく「1つのデータベースが単一障害点やコストの原因になって成長を阻害している」からです。

シャーディングに駆り立てる痛点

単一ノードが容量不足になるパターンはいくつかあります：

• ストレージ制限: テーブルやインデックスが増えディスクが逼迫し、バックアップが遅くなり保守が危険になる
• 書き込みスループットの限界: CPU、WAL/redo、ロック競合が書き込み/秒数を制限する
• 読み取りスループットの限界: キャッシュやレプリカを使っても一部ワークロードがプライマリを圧倒する
• ノイジーネイバー: あるテナントやワークロードがリソースを独占して他を劣化させる

これらが頻発する場合、多くは単一の悪いクエリが原因というより「一台の機械が過度な責任を負っている」ことが原因です。

目的：スケールアウト、分離、コスト管理

データベースのシャーディングはデータとトラフィックを複数ノードに分散させ、能力をマシン追加で拡張できるようにします。うまくやれば ワークロードの分離（あるテナントの負荷が他のレイテンシを壊さない）や、超大型インスタンスを避けてコストを管理することも可能です。

壁に近づいている初期警告サイン

繰り返し現れるパターン：ピーク時のp95/p99が定常的に上昇する、レプリケーションラグが長くなる、バックアップ/リストアが許容ウィンドウを超える、ちょっとしたスキーマ変更が大仕事になる等。

なぜ通常は最後の手段か

決断前にチームは通常、インデックスやクエリ改善、キャッシュ、リードレプリカ、単一DB内のパーティショニング、古いデータのアーカイブ、ハードウェアアップグレードといったより簡単な対策を使い尽くします。シャーディングはスケール問題を解けますが、協調や運用の複雑性、新しい障害モードを追加するためハードルは高くなるべきです。

コア要素：シャード、ルーター、メタデータ

シャード化されたデータベースは単独のものではなく、協調する小さなシステム群です。シャーディングが「理解しにくい」と感じられる理由は、正しさと性能が単一のDBエンジンではなくこれらの部品の相互作用に依存するためです。

シャード：独立したパーティション（各自インデックスを持つ）

シャードはデータのサブセットで、通常はそのサーバやクラスター上に保存されます。各シャードは通常：

• ストレージ（データファイル）
• インデックス（そのシャード内で高速にクエリできるように）
• ローカル制限（CPU、メモリ、ディスク、接続数）

アプリから見るとシャード化構成は1つの論理データベースに見せようとしますが、単一ノードの「インデックス検索1回」が「正しいシャードを見つけてからの検索1回」に置き換わる点に注意が必要です。

ルーター／コーディネータ：リクエストを正しいシャードへ届ける仕組み

ルーター（コーディネータ、クエリルータ、プロキシとも呼ぶ）は交通整理役で、与えられたリクエストをどのシャードが処理するべきか答えます。

一般的なパターンは2つ：

1. クライアントサイドルーティング: アプリのライブラリがシャードマップを保持し直接正しいシャードへ接続する。
2. プロキシルーティング: アプリはルーターサービスに接続し、ルーターがリクエストを転送する。

ルーターはアプリ側の複雑さを減らしますが、適切に設計しないとボトルネックや新たな障害点になり得ます。

メタデータ／設定サービス：シャードマップ、所有権、ヘルス

シャーディングは次のようなメタデータに依存します：

• シャードマップ（どの範囲/ハッシュバケット/IDをどのシャードが所有するか）
• 所有権（マイグレーション中は所有が一時的に重複することがある）
• ヘルスとメンバーシップ（どのノードが稼働中か、プライマリ／レプリカの役割、ドレイン中か）

この情報は設定サービス（小さなコントロールプレーンDB）に置かれることが多く、メタデータが古いか不整合だと、シャード自体が健康でもルーターが誤った場所へ送ってしまいます。

バックグラウンドジョブ：バランシング、マイグレーション、バックアップ

シャーディングは時間経過で使いやすさを保つためにバックグラウンド処理に依存します：

• シャード間で成長に差がついたときの リバランシング
• 所有権を移す マイグレーション
• 多数のシャードをまたいだ バックアップ／リストア 手順

これらは初期には無視されがちですが、稼働中にシステムの形を変える点で多くの本番トラブルの原因になります。

シャードキーの選定：最初の大きなトレードオフ

シャードキーは行をどのシャードに置くか決めるフィールド（または組み合わせ）で、この一択が性能、コスト、将来の機能性に大きく影響します。シャードキーはリクエストが1つのシャードに行くか多数にファンアウトするかを制御します。

良いシャードキーの条件

良いキーは概ね：

• 高カードinality（多くの値）（例：countryより user_id）
• 均等分布：書き込み・読み取りがシャード間に広がる
• 安定したアクセスパターン：現状と次四半期の利用パターンに合っている

例：マルチテナントアプリで tenant_id をキーにすることでテナント内の読み書きが一つのシャードに収まりやすく、テナント数が多ければ負荷も分散します。

悪いシャードキーの条件とその影響

問題を招くキーの例：

• 時間ベースの単調キー（タイムスタンプ、オートインクリメント）：新データが常に最新シャードに集中して書き込みホットスポットを作る
• 低カードinalityフィールド（status、plan_tier、country）：値が少なく一部シャードに負荷が集中する
• 可変識別子（emailや変更可能なユーザー名）：キーが変わるとデータ移動が高コストで危険

低カードinalityキーはフィルタには便利でも、ルーティング不能なクエリを多数のシャードにファンアウトさせる原因になりがちです。

実際のトレードオフ：クエリ利便性 vs 分散品質

ロードバランスに有利なシャードキーが必ずしもプロダクト側のクエリにとって最良とは限りません。

• user_id に最適化すると多くのレイテンシに敏感な操作が単一シャードに収まるが、グローバルなレポーティングは遅くなるか別系統が必要になる。
• region に最適化するとレポートは楽になるが、ホットスポットや不均等な容量配分のリスクが高まる。

多くのチームは主要でレイテンシに敏感な操作に合わせてシャードキーを決め、他はインデックス、デノーマライズ、レプリカ、専用の分析テーブルで補います。

よくあるシャーディング戦略（レンジ、ハッシュ、ディレクトリ）

最良の方法は一つではありません。選択肢はルーティングの容易さ、データの均等分散、アクセスパターンの弱点を形作ります。

レンジシャーディング

レンジシャーディングでは各シャードがキー空間の連続区間を所有します（例：

• シャードA: customer_id 1–1,000,000
• シャードB: customer_id 1,000,001–2,000,000 )

ルーティングは単純ですがホットスポットの問題があります。新しいユーザーに増分IDを割り当てる場合、最新のシャードが書き込みのボトルネックになります。範囲クエリ（例：10月1日〜10月31日の注文）は物理的にまとまっているため効率的に処理できるのが利点です。

ハッシュシャーディング

ハッシュシャーディングはシャードキーをハッシュ関数に通し、その結果でシャードを選びます。これによりデータがより均等に分散され、「最新シャードにすべてが行く」問題を避けやすくなります。

代償として範囲クエリが困難になります。ID X〜Y のようなクエリは少数のシャードに絞れず、多数に触れる可能性があります。

現実的な実装では一貫ハッシュを使い、シャード数が増えても全キーが大きく再配置されないように仮想ノードを配置することが一般的です。

ディレクトリ（ルックアップ）シャーディング

ディレクトリシャーディングはキー→シャードの明示的マッピングを保持します。柔軟性が高く、特定テナントを専用シャードに置く、個別に移動する、不均一なシャードサイズを許容するといった運用が可能です。

欠点は依存先が増えることです。ディレクトリが遅い、陳腐化、または利用不能になるとルーティングが破綻します。

複合キーとサブシャーディング

実際のシステムは戦略を混ぜます。複合シャードキー（例：tenant_id + user_id）はテナントを分離しつつテナント内の負荷を分散できます。サブシャーディングは類似のアプローチで、まずテナントでルートし、その内部をハッシュして大きなテナントが1つのシャードを独占しないようにします。

クエリの動き：ルーティング対スキャッター・ギャザー

シャード化されたデータベースには非常に異なる二つの「クエリ経路」があります。どちらの経路になるかを理解すれば、パフォーマンスの驚きの多くが説明できます。

単一シャードクエリ：高速経路

理想はクエリが正確に1つのシャードにルーティングされることです。リクエストにシャードキーが含まれているか、ルーターがマッピングできればシステムは直接正しいシャードに送れます。

そのためチームは一般的な読み取りを「シャードキーに気づかせる」ことに執着します。単一シャードだとネットワーク往復や協調が少なくなり、ロックや実行もシンプルです。

スキャッター・ギャザー読み取り：ファンアウトとテールレイテンシ

クエリが正確にルーティングできない場合（非シャードキーでフィルタしている等）、システムは多くのまたは全シャードにブロードキャストすることがあります。各シャードがローカルでクエリを実行し、ルーターが結果をマージ（ソート、重複除去、LIMIT適用、部分集計の合算）します。

このファンアウトはテールレイテンシを増幅します：9個のシャードが速くても1つの遅いシャードが全体を遅らせる。ユーザーの1回のリクエストがN回のシャードリクエストになるので累積負荷も増えます。

シャード間ジョインと集約

シャード間ジョインは高コストです。通常は各シャードで部分計算をしてから集約する二相計画が必要になります。

インデックスの制約：ローカル vs グローバル

多くのシステムはデフォルトでローカルインデックスを使います：各シャードが自身のデータだけをインデックスする。保守コストは低いがルーティングは助けません。

グローバルインデックスは非シャードキーでのターゲットルーティングを可能にしますが、書き込みオーバーヘッドや追加の一貫性問題を伴います。

シャード間の書き込みとトランザクション

書き込みはシャーディングが「ただのスケール手段」から設計を変える領域です。単一シャードで完結する書き込みは速く単純ですが、複数シャードに跨る書き込みは遅く失敗が起きやすく、正しく実装するのが難しくなります。

単一シャード書き込み：ハッピーパス

各リクエストが1つのシャードにルーティングされる場合（通常はシャードキーを利用）、そのシャードの通常のトランザクション機構を使えます。原子性と分離性はそのシャード内で保証され、運用上の課題は単一ノードのものと似た形になります。

複数シャード書き込み：複雑さが跳ね上がる場所

2つ以上のシャードを1つの論理操作で更新する必要が出ると（例：送金、注文の所有者移動、別の場所にある集計の更新）、分散トランザクションの領域に入ります。分散トランザクションは遅延、ネットワーク分断、再起動などにより難しく、二相コミットのようなプロトコルは追加の往復を生み、タイムアウトでブロックしたり失敗時の状態が曖昧になりがちです。

シャード越え書き込みを避けるパターン

• データローカリティ: 関連レコードを同一シャードに寄せる（例：顧客に関するすべて）
• リクエスト所有: 操作を1つのシャードが“所有”するように設計し、他は読み取りのみとする
• デノーマライズ: 小さなデータを複製して更新のファンアウトを減らす

冪等性と再試行の安全性

シャーディング環境ではリトライは不可避です。書き込みを冪等にするために、安定した操作ID（冪等性キー等）を使い、既に適用されたマーカーをDBに保存しておくと、タイムアウト後の再試行が二重課金や重複注文を生まないようにできます。