データベースのシャーディングって何？そしてシャードが枯渇するってどういうこと？
こんにちは！この記事では、よく聞く「シャーディング」について軽くおさらいしつつ、
「シャードが枯渇する」ってどういうことなのか？を調べたのでまとめます。
🍣 シャーディングってそもそも何？
簡単に言うと、データを複数のデータベース（≒シャード）に分割して管理することです。
1つのDBにデータが全部詰まってると重くなるし、スケールもしづらい。
なので「ユーザーIDの1〜100万はこのDB」「100万〜200万はこっち」みたいに水平分割してあげるわけですね。
「スケールしやすくていいじゃん！」って話なんですが、うまくやらないとシャードが枯渇するという落とし穴があるんです。
💀 シャードが枯渇するってどういうこと？
「シャードが枯渇」＝そのシャードが限界超えて苦しんでる状態です。
以下のような状況を指します：
- データが多すぎてディスク容量が逼迫
- 書き込みが集中してI/O負荷が高騰
- クエリが重すぎてレスポンスが遅延
- CPUが常に80%超えでスロークエリ連発
- 同時接続が限界に達してタイムアウト多発
例：
「ユーザーIDでシャーディングしてたら、人気VTuberのファンがたまたま全員同じ範囲に固まってて、
そのシャードだけアクセス過多で死んだ」みたいなこと、普通にあります
🔥 具体的にどれくらいで枯渇するの？
これは使ってるDBやインスタンスによってバラバラですが、ざっくり目安として：
- RDS（MySQL, PostgreSQL）で 1シャードあたり1000万〜5000万レコードくらい
- 書き込みQPSが300〜500を超えると怪しくなる（インスタンスタイプによる）
- ストレージ容量80%以上で警戒、I/O wait が5%以上なら赤信号
もちろんCPU、RAM、インデックス設計、クエリ最適化などでも大きく変わります！
🚨 なんで枯渇するの？
原因の多くはデータ分布やアクセスが偏ってしまうことです。
- シャーディングキーの設計ミス（例：時系列で連番IDを使うと最新シャードだけホットになる）
- 一部のユーザー/商品にアクセス集中（例：特定ユーザーにだけ通知爆撃）
- 不均等なデータ生成（あるシャードだけに巨大JSONが詰まってる）
🧯 枯渇しないためにできること
| 対策 | 説明 |
|---|---|
| シャーディングキーの見直し | 偏りにくいキー（例：UUIDやハッシュ値）を使う |
| モニタリング強化 | CloudWatch, Datadogなどでホットシャードを早期検知 |
| 再シャーディング可能な構成 | シャードを動的に増減できるような設計にする |
| RedisやS3などの外部ストレージ併用 | 一部データはRDB以外に逃す設計にする |
| 書き込み分散 | 書き込みピークを吸収するキュー設計なども有効 |
🤔 結局、シャーディングってどう付き合う？
- 小規模のうちは不要！早すぎるシャーディングは複雑さを増やすだけ
- でもデータが伸びる見込みがあるなら、枯渇しにくい設計を最初から意識しておくと◎
- あと、「枯渇＝死」ではなく、ちゃんと観察して、リカバリできる仕組みを作っとけって話っぽい
✍️ まとめ
- シャーディングはスケーラビリティのために重要
- でも偏ると「シャードが枯渇」して性能が死ぬ
- モニタリング、設計、再分割戦略が超大事！
おしまい