要点: DBのスケールは、まずどこで資源が競合しているかを特定するところから始まります。
この記事の用語: 接続プール：再利用するDB接続群。レプリカ：読み取りを分担するDB複製。パーティション：ルールに基づくデータ分割。
現場の課題
アプリケーションはDBの接続上限より速く台数を増やせます。大きすぎる接続プール、重複クエリ、長いトランザクションが能力を使い切り、早すぎる分割は運用を複雑にします。
DBは新しい分割技術がないから遅いのではなく、接続競合、重いクエリ、長いトランザクションで詰まることが多いものです。実測前のレプリカやシャーディングは問題を隠します。
設計と実装
- システム全体の接続上限を決め、API、ワーカー、デプロイへ配分します。
- 総コストが大きいクエリから、実行プランと本番に近いデータを使って改善します。
- 整合性要件とルーティング規則が明確になってからレプリカやパーティションを追加します。
実装例
with db.transaction(timeout = 800ms) as tx:
order = tx.orders.lock(orderId)
tx.orders.update(orderId, nextState)
readTarget = PRIMARY if session.justWrote else REPLICA
return query(readTarget, tenantId, orderId)本番導入の進め方
クエリと接続を可視化し、大きすぎるプールと高コストなクエリを先に直します。古い読み取りを許容できる一経路でレプリカを試し、パーティションはロールバックと照合を持つ別プロジェクトとして扱います。
まとめ
拡張可能なDBは、分割する前に資源上限と予測可能なアクセス パターンで守られています。