データベースシャーディング - 水平分割でスケールアウト

シャーディングとは

シャーディングは、データを複数のデータベース（シャード）に水平分割して格納する技術です。単一のデータベースでは処理できない大量のデータやトラフィックに対応できます。

レプリケーションとの違い: レプリケーションは同じデータのコピーを複数サーバーに持ちますが、シャーディングは異なるデータを異なるサーバーに分散します。

シャーディングの仕組み

flowchart TB
    subgraph Before["シャーディング前"]
        Single["単一データベース<br/>全ユーザーデータ<br/>(1億レコード)"]
    end

flowchart LR
    subgraph After["シャーディング後"]
        S0["Shard 0<br/>ユーザー A-F<br/>2500万"]
        S1["Shard 1<br/>ユーザー G-L<br/>2500万"]
        S2["Shard 2<br/>ユーザー M-R<br/>2500万"]
        S3["Shard 3<br/>ユーザー S-Z<br/>2500万"]
    end

シャーディング方式

範囲ベースシャーディング

キーの範囲でシャードを決定します。

メリット: 範囲クエリが効率的 デメリット: データの偏りが発生しやすい

ハッシュベースシャーディング

キーのハッシュ値でシャードを決定します。

shard_id = hash(user_id) % num_shards

メリット: データが均等に分散 デメリット: 範囲クエリが非効率

ディレクトリベースシャーディング

ルックアップテーブルでシャードを決定します。

メリット: 柔軟なマッピング デメリット: ルックアップのオーバーヘッド

シャードキーの選び方

シャードキーは、シャーディングの成否を決める最も重要な要素です。

良いシャードキーの条件

• ✓ カーディナリティが高い（多様な値を持つ）
• ✓ アクセスパターンに合っている
• ✓ 書き込みが均等に分散する
• ✓ ほとんどのクエリにキーが含まれる

シャードキーの例

ホットスポットの問題

クロスシャードクエリ

複数のシャードにまたがるクエリは複雑になります。

Scatter-Gather

flowchart TB
    Client["クライアント"] --> Router["ルーター"]
    Router -->|"Scatter<br/>(全シャードにクエリ)"| S0["S0"]
    Router --> S1["S1"]
    Router --> S2["S2"]
    Router --> S3["S3"]
    S0 -->|"Gather<br/>(結果を集約)"| Router
    S1 --> Router
    S2 --> Router
    S3 --> Router
    Router --> Client

JOIN の制限

-- 同一シャード内: 通常のJOIN
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.id = 123;  -- シャードキーを含む

-- クロスシャード: アプリケーション側で結合
-- 1. users テーブルからデータ取得
-- 2. orders テーブルからデータ取得
-- 3. アプリケーション側でJOIN

リバランシング

シャード間でデータを再配置する作業です。

必要になる場面

• シャードの追加・削除
• データの偏りの解消
• パフォーマンスの最適化

コンシステントハッシング

シャード数が変わっても、移動するデータを最小限に抑える手法です。

シャーディングの課題

マネージドシャーディング

シャーディングの判断基準

シャーディングが必要な場合:

• 単一DBの容量限界を超える
• 書き込みスループットが限界
• 垂直スケーリングのコストが高すぎる

まず検討すべき代替手段:

• 読み取りレプリカの追加
• キャッシュの導入
• クエリの最適化
• インデックスの見直し
• より大きなインスタンスへの移行

まとめ

シャーディングは、データベースの水平スケーリングを実現する強力な手法ですが、複雑さも伴います。シャードキーの選定が成功の鍵であり、アクセスパターンを十分に分析してから導入を決定しましょう。可能であれば、マネージドサービスの利用を検討することで運用負荷を軽減できます。