シャーディング

1. 目的

DBサーバの可用性の向上

• 単一サーバでは扱いきれない量のデータ量やクエリを複数のサーバに分割することで処理を分散し、システムの可用性を向上させる

2. 課題

システムで扱うデータ量が単一サーバで処理できるレベルを超えている

• 例えば、1秒間に数万件の投稿があるサービスの場合、1台のDBサーバでは書き込みのスループットが追いつかなくなってしまう
• 結果として、クエリレスポンスタイムの悪化やCPU/メモリリソースの枯渇からシステム停止に至ってしまう

3. 対策

データベースの水平分割（Horizontal Partitioning）

• 1つの巨大なテーブルを複数の小さなテーブル（シャード）に分割し、それぞれを異なるDBサーバーに配置する
• 例えば、ユーザーIDに基づいて分割する場合、「ID 1-1000はサーバーA」「ID 1001-2000はサーバーB」のように振り分ける
• 物理的にテーブル（データ）を分割することでひとつのDBサーバで処理するデータ量を処理可能な量に制御することが可能になる

4. メリット

書き込み/読み込み性能の向上

• 複数サーバーで並列処理、負荷分散を行うことで書き込み性能が向上する
• 各サーバーで扱うデータ量を物理的に削減することでクエリの高速化が見込める

ストレージ容量の拡張

• 複数サーバを束ねて扱うことになるので、単一サーバーの容量限界を超えたデータを保存することができる

可用性・耐障害性の向上

• データが物理的に複数のサーバに分散しているので、一部のDBサーバに障害が発生した場合も他シャードのデータには影響がない
• DB障害の影響範囲が一部のユーザーに限定される（ことがあるかもしれない）

水平スケーラビリティの実現

• 複数サーバーでの並列処理による高速化が期待できる

5. デメリット

複雑性の増大

• 複数シャードにまたがるJOIN、集計クエリの困難化
• 分散トランザクション管理の複雑化
• ACID特性の保証が困難

データ分散の課題

• データの偏り（ホットスポット）の発生リスク
• リシャーディング（再分割）の困難さ
• シャーディングキー変更の大規模作業

運用コストの増加

• 管理サーバー台数の増加
• バックアップ、監視、セキュリティ対策の複雑化
• 障害対応の難易度上昇
• 開発・保守コストの増加
• アプリケーションコードの複雑化

その他

• シャード間のデータ整合性確保の困難さ
• スキーマ変更の全シャード適用の手間
• 柔軟性の低下

6. 注意事項

導入タイミング

• 本当に必要になってから導入する（早すぎる最適化は禁物）
• 他の手法で限界が見えた時点で検討
• データ量：数百GB〜数TB、書き込み：秒間数万件以上が目安

設計上の注意

• シャーディングキーの選択が最重要（後から変更困難）
• データの偏りを避ける設計
• ホットスポット対策の検討
• 将来的なリシャーディングを見据えた設計

運用上の注意

• 監視体制の強化（各シャードの状態把握）
• バックアップ・リカバリ戦略の策定
• 障害時の切り分け手順の確立
• 開発チームの学習コスト考慮

ビジネス判断

• 運用コストとメリットの比較検討
• SLA要件の確認
• 成長予測に基づく判断（6ヶ月〜1年先を見据える）

Appendix-1. シャーディング導入前に試すべき手法

• クエリとインデックスの最適化
• 垂直スケーリング（サーバースペック向上）
• リードレプリカの追加
• キャッシュの導入（Redis、Memcached）
• 垂直分割（機能・ドメインごとのDB分離）
• テーブルパーティショニング

Appendix-2. シャーディングの実装方法

• シャーディングキーの選定（ハッシュベース、レンジベース、地理的分散）
• データ分散ロジックの実装
• アプリケーション層での分散管理