どんな場面で検討するか
大きなトランザクション負荷や複数拠点を含むDBで、リレーショナルな構造と整合性を維持しながら分散・拡張を設計したい場合。単一DBの規模や可用性要求が制約になっているときに比較する。
組織で使う条件
偏りのある主キーによるhotspot、遅いクエリ、セッション、利用容量を監視する。容量追加だけで解決できる問題とスキーマ/アクセス分布の問題を分ける。
採用前に試すこと
- 合成注文1000件を用意し、代表トランザクションと整合性の期待値を定める。
- キーが偏る負荷と分散する負荷を同条件で実行し、遅延・競合・負荷分布を記録する。
- バックアップから検証DBへ復元し、想定容量/構成とCloud SQL案の費用・運用を比較する。
合格と判断する条件
- 注文/在庫の不変条件が保たれ、必要なSQLを実行できる。
- hotspotと容量不足を区別でき、復元・運用・費用面で分散構成が必要である根拠を残せる。
見落としたくない点
- 小規模で単一リージョンの一般業務DBならCloud SQLと比較する。分散DBを必要とする根拠がないまま規模の宣伝だけで選ばない。
- 小規模で単一リージョンの一般業務DBならCloud SQLと比較する。分散DBを必要とする根拠がないまま規模の宣伝だけで選ばない。