リファレンスアーキテクチャ: 大規模 / 高トラフィック
トラフィックが増加する中でデータベースを守るには、正しい順序がある: まずシンプルで安価な対策、次に複雑な対策。このツリーは、垂直スケーリング → リードレプリカ → シャーディングの順序、キャッシュパターン (cache-aside、write-back)、キュー + バックプレッシャーによるバッファリング、レート制限、バルクヘッド/サーキットブレーカーによるデータベースの隔離、ホットスポットの防止を段階的に説明する。基本原則: シャーディングのように元に戻しにくい判断は最後に回し、まず安価な改善を尽くす。
ボトルネックはどこか: 単一インスタンスが飽和しているのか、読み取りまたは書き込みが多いのか、それともトラフィックが突発的なのか?
スケーリングの問題を適切な場所で解決するには、まずボトルネックを特定する。単一インスタンスの CPU/メモリが飽和しているのか、読み取りが支配的なのか、書き込みが上限に達しているのか、それとも突発的なトラフィックの急増がデータベースを圧迫しているのか? それぞれ異なるコンポーネントを示す。
- 単一インスタンスが飽和している。シンプルな対策はまだ試していない
- 読み取りが非常に多く、増加している
- 突発的なトラフィックの急増 / バースト負荷が DB を圧迫している
スケーリングのどの段階にいるか: 垂直、リードレプリカ、シャーディング?
スケーリングには正しい順序がある。垂直スケーリング (より強力なハードウェア) は最もシンプルな最初のステップ。次に読み取りをレプリカに分散し、単一のプライマリが書き込みを処理しきれなくなって初めて水平分割 (シャーディング) に移行する。現在どこにいるか?
- まだハードウェアのスケールアップ / 基本的なチューニングを尽くしていない
- 書き込みは 1 つのインスタンスに収まるが、読み取り負荷を分散する必要がある
- 単一のプライマリでは書き込み負荷を処理しきれなくなった
データベースを負荷からどう保護するか: バッファリング、制限、それとも隔離か?
スケーリングとは常に DB を大きくすることではなく、多くの場合は DB を過負荷から守ること。突発的な書き込みの急増をキューで平準化するのか、受信リクエストのレートを制限するのか (レート制限)、それとも単一の依存先がシステム全体をダウンさせないようにするのか (バルクヘッド/サーキットブレーカー)?
- 突発的な書き込みの急増を平準化したい
- 受信リクエストのレートを制限/公平に配分したい
- 障害を起こした 1 つの依存先がシステム全体をダウンさせないようにしたい
推奨: まず垂直スケーリングと基本的なチューニング
最も安価でリスクの低いステップは垂直スケーリング: CPU/RAM の増強や高速なディスクの追加と、基本事項 (インデックス、コネクションプーリング、メモリパラメータ) の修正。シャーディングのような複雑な判断の前に、これらの改善を尽くす。
推奨: リードレプリカで読み取りを分散する
書き込みは単一のプライマリにとどめ、読み取り専用のトラフィックを 1 つ以上のレプリカに分散する。シャーディングよりはるかにシンプルで、読み取り中心のワークロードの大半を解決する。プライマリは書き込みと一貫性が重要な読み取りのみに使用する。
推奨: 最終手段としてのシャーディング (水平分割)
単一のプライマリが書き込み負荷を処理できない場合、データをキーで複数の独立した断片 (シャード) に分割し、各シャードが書き込みの一部を担う。強力だが元に戻しにくく、シャードをまたぐクエリとトランザクションを複雑にするため、最後に回す。
推奨: キャッシュパターン (cache-aside + write-back)
読み取り中心の高トラフィックでは、DB の前段にインメモリキャッシュ (Redis) を置き、大半の読み取りを DB に到達させずに処理する。大量の書き込みには、write-back が書き込みをバッファリングしてバッチで DB にフラッシュし、プライマリの負荷を軽減する。
推奨: キューによるバッファリング (バックプレッシャー)
突発的な書き込みの急増が直接 DB に到達しないよう、間に耐久性のあるキュー (例: Kafka/メッセージキュー) を置き、DB が維持できるレートで書き込みを消費する。キューが急増を吸収し、システムは同期的に失敗する代わりに、制御されたレイテンシで動作する (バックプレッシャー)。
推奨: レート制限 (リクエストのレートを制限する)
ソースごとに受信リクエストを制限する (レート制限) ことで、悪用と、単一のクライアントがすべてのリソースを消費することの両方を防ぐ。DB に到達する負荷に上限を設けることで、システムを予測可能かつ公平に保つ。
推奨: バルクヘッド + サーキットブレーカー (隔離)
依存先 (例: 低速化した DB や外部サービス) がシステム全体をダウンさせないよう、リソースを区画 (バルクヘッド) に分割し、失敗し続ける依存先への呼び出しを一時的に遮断する (サーキットブレーカー)。これにより、部分的な障害がシステム全体に広がらない。