第6章：パーティションは“設計の先読み力”が試される
第6章：パーティションは“設計の先読み力”が試される
『データ指向アプリケーションデザイン（DDIA）』第6章を読んだメモです
スケーラビリティ設計の核心「パーティション」の話
将来予測と構造的な割り切り、その間で揺れる設計思考を整理しました
シャーディングって、実際どのタイミングで必要？
まず前提として、シャーディング（パーティション）を導入すると、もう戻れない設計になる
だからこそ：
- 現時点でのスケール要件
- 将来の伸び方（件数？ユーザー？リクエスト？）
- 更新頻度とデータの“偏り方”
これらを読んで、将来に先回りした構造を選ぶ必要がある
でも当然、予測なんて大体ハズれる
ホットスポットの正体は、“意図してない集中”
- 月末に請求データが集中する
- 特定のテナントにだけアクセスが集中する
──こういうのがホットスポット。
重要なのは、「偏りを予測できたか」ではなく「偏っても破綻しない構造か？」という視点
アプリケーション側のルーティング戦略が鍵を握ることが多い
パーティションキーは“設計の芯”
たとえば：
- ユーザーIDで分ける
- 日付で分ける
- テナント単位で分ける
などがあるが、一度選ぶとテーブル設計もクエリ構造もその前提に縛られる
つまり、あとからの変更＝全再設計レベルの作業になる
図6: ハッシュパーティションとノード追加時の再シャーディング概念図
ルーティング層は地味に“命綱”
「このデータはどのインスタンスに送るか？」を決める層
軽く見られがちだが：
- 単一障害点になりうる
- 再編タイミングのズレで迷子が発生
- キャッシュと実データのズレも起きうる
など、意外と繊細な存在
ただし、パーティションキー生成のタイミングが静的（例：テナント作成時）なら
コピーしやすく、スケールにも強くなる
リバランシング：設計者が一番やりたくないやつ
パーティションを増減させて負荷分散する処理
でも現場ではこう言われがち：
「これ、サービス止めずにできるんですか？」
理屈ではYES。でも現場感覚ではNOに近い
- データ転送が重い
- 切替タイミング次第で迷子が出る
- 並行実行で整合性が壊れる
→ 自動化よりも、人手での慎重な運用設計が無難
テイルレイテンシ：遅い1つのせいで全体が終わらない
10個の処理を並列化しても、最後の1個が遅ければ全体が遅くなる
これがテイルレイテンシ
「全体を速くしたつもりが、1つの“しっぽ”で台無しにされる」構図は、地味に根深い
パーティションキー選定の難しさ＝「将来見えない」問題
理想：
- 均等に分散されるキー
- 将来も分布が変わらない
- ユースケースの変化にも対応できる
でも現実は：
- そんな都合のいいキーはない🙃
なのでリスク変化に耐えられる構造を考える
たとえば：
- 一部データだけ「キー→インスタンス」マップ管理
- 残りはラウンドロビンで自動分配
- 将来はマップだけ更新してリバランス
──みたいな「変えやすい構造」を仕込んでおくと安全
✍️ まとめ：スケーラビリティ設計とは、“確実に失敗する未来”との折り合い
パーティション設計とは、将来の爆発を前提とした**“敗北前提の準備”**
大事なのは「失敗しないこと」じゃなく、
「失敗しても壊れない」設計をしておくこと
💡 設計Tips
- シャーディングは引き返せない設計、導入は慎重に
- パーティションキーは「変えられない前提」で選ぶ
- ホットスポットは“必ず来るもの”として構えておく
- リバランシングは人手の介在を前提にして設計する
- テイルレイテンシは、“最後の1件”に意識を向ける
Discussion