DBプロキシによるクエリルーティング

プロキシ層が解決する問題

シャーディングやレプリケーションを導入すると、アプリは「どのシャードに書くか」「どのレプリカから読むか」「プライマリが落ちたらどう繋ぎ直すか」を自前で判断する必要が出てきます。これをアプリコードに埋め込むと、シャード数が変わるたびに全サービスを改修する羽目になります。

DBプロキシ（Vitess の VTGate、ProxySQL、MySQL Router など）は、アプリと実DBの間に挟まる中間層です。アプリからは単一のMySQL/PostgreSQL互換エンドポイントに見え、内部でクエリを解析してどのノードへ送るかを決めます。シャーディング方式がデータの分割方式そのものを扱うのに対し、この記事は「その分割をプロキシがどう隠蔽し、実行時にどうルーティングするか」に焦点を当てます。

読み書き振り分けの仕組み

プロキシは受け取ったSQL文をパースし、以下のように分類します。

• 読み取り専用（SELECT、コメントで明示されたヒントなし）はレプリカ群へ
• 更新系（INSERT/UPDATE/DELETE/DDL）はプライマリへ
• トランザクション内のクエリは原則プライマリに固定（後述）

レプリカが複数ある場合、プロキシは単純なラウンドロビンだけでなく、レプリケーション遅延を監視して遅れが大きいレプリカを一時的に除外する、負荷（アクティブコネクション数）で重み付けするといった選択ロジックを持ちます。遅延の許容値を超えたレプリカへ読みを送ると stale read（古いデータの読み取り）が発生するため、読み取り一貫性の要求が強いクエリはプライマリに固定するオプションを用意するのが一般的です。

シャード間ルーティング

シャーディング構成では、プロキシはさらに一段複雑な判断をします。

1. 単一シャード直送: WHERE 句にシャードキーの等価条件（user_id = 123 など）が含まれる場合、キーからシャードを一意に特定し、そのシャードへ直接転送する。ネットワークホップが1回で済み、レイテンシは非シャーディング構成とほぼ変わらない。
2. ファンアウト（scatter-gather）: シャードキーを含まない集約クエリやレンジスキャンは、該当しうる全シャードへ並列にクエリを転送し、返ってきた結果をプロキシ側でマージ・再ソートしてアプリへ返す。

ファンアウトが必要なクエリが多いスキーマ設計は、シャードを増やすほどファンアウト対象も増えるため、スケールしても改善しにくいという構造的な弱点があります。プロキシのクエリログでファンアウト比率を監視し、シャードキー設計（シャーディング方式参照）にフィードバックするのが実務上の定石です。

JOIN や集計関数を含むクエリは、プロキシ側で分割実行してから再計算する必要があります。例えば COUNT(*) は各シャードから部分カウントを集めて合算し、ORDER BY ... LIMIT は各シャードでソート済み結果を取得してからプロキシ側でマージソートし直します（分散結合とシャッフルで扱うシャッフル処理の縮小版に相当）。シャードをまたぐ JOIN は多くのプロキシでサポート外か、片方のテーブルを全シャードへ複製する設計（reference table）で回避します。

透過的なフェイルオーバー

プライマリ障害が発生した際、プロキシは以下の手順でアプリから障害を隠蔽します。

1. 検出: ヘルスチェック（定期的な軽量クエリ）とレプリケーショントポロジの監視（合意アルゴリズムベースの管理層やオーケストレータからの通知）でプライマリ不達を検知する。
2. 昇格の確認: 新プライマリへの昇格が完了し、書き込み可能になったことを確認する。昇格前のレプリカが古いデータのまま書き込みを受けるとスプリットブレインになるため、旧プライマリを確実に締め出すフェンシングが前提になる（同期/準同期/非同期レプリケーション参照）。
3. 再接続: プロキシは保持しているコネクションプールの向き先を新プライマリへ切り替え、インフライトだったクエリはエラーを返すかリトライキューへ回す。アプリ側はDNSやIPを変える必要がなく、プロキシへの接続を維持したまま処理を継続する。

プロキシ層のコストとトレードオフ

プロキシは万能ではありません。全クエリがプロキシを経由するため、パース処理とネットワークホップの追加で数百マイクロ秒〜数ミリ秒のレイテンシが乗ります。またプロキシ自体が単一障害点にならないよう、プロキシプロセスを複数台配置してロードバランサでラウンドロビンさせる、あるいはアプリのDBドライバに軽量なルーティングロジックを埋め込んでプロキシへの依存を減らす（Vitess の VTGate をサイドカーとして各アプリPodに配置するパターンなど）構成が取られます。

シャード再配置（リシャーディング）中も、プロキシは移行済みキー範囲と未移行範囲を把握し、移行境界にあるキーへのクエリを新旧どちらのシャードに振るか判定する役割を担います。これによりリシャーディングをアプリの無停止のまま進められますが、判定ロジックの実装難度は高く、多くの実装ではダブルライト（新旧両方に書く）期間を設けて安全に倒します。

DBプロキシは、シャーディングとレプリケーションが生む「どこに聞けばいいか」という判断をアプリから完全に切り離すレイヤーです。読み書き振り分け、シャード解決、フェイルオーバーのいずれも、プロキシがSQL解析とトポロジ管理を通じて肩代わりすることで、アプリコードはシャーディングを意識しない単純なクエリだけを書けばよくなります。