Postgres と MySQL のスケーリング: 768 台のサーバーを 1 台に見せる

スケールアウトしたリレーショナルデータベースで、秒間数百万件のクエリとペタバイト級のデータを処理するには、垂直スケーリングやリードレプリカだけでは不十分で、シャーディングアーキテクチャへ移行する必要があります。高度なプロキシ層を導入すれば、768 台規模のクラスターなど、数百台のサーバーにデータを分散させながら、アプリケーション層には単一で統一されたデータベースインターフェースを提供できます。

垂直スケーリングとリードレプリカの限界

垂直スケーリング（CPU と RAM の増強）やリードレプリカの追加は、初期のスケーリング手法として有効ですが、最終的に次の 3 つの重大なボトルネックに直面します。

• 書き込みボトルネック: Postgres では、すべての書き込みが書き込み先行ログ（WAL）に記録され、プライマリサーバー上の永続ストレージへフラッシュされます。これにより単一の書き込みボトルネックが発生し、リードレプリカを増やしても解消できません。
• データ容量: レプリカはプライマリデータの完全コピーです。レプリカを増やすことで読み取りスループットは向上しますが、システムが保持できるデータ総量は増えません。
• バックアップ遅延: 大規模でモノリシックなデータベースをオブジェクトストレージへバックアップするには、帯域幅の制限により数時間から数日かかります。これは厳格な RPO（Recovery Point Objective）や RTO（Recovery Time Objective）を満たすことができないという問題です。

データベースシャーディングでスケールを解決する

シャーディングはデータとクエリを複数の独立したプライマリサーバーに分散させます。これにより、書き込みスループットとストレージ容量に関する単一ノードの制限が取り除かれます。たとえば、1 ペタバイトのデータを保存する場合、256 シャード（各シャードにプライマリ 1 台とレプリカ 2 台）を使用すれば、合計 768 台のサーバーで実現できます。

この複雑さがアプリケーションコードに漏れ出さないように、プロキシ層を介して分散システムを単一データベースとして見せます。

ルータープロキシの役割

PgBouncer のようなシンプルなプロキシは接続プーリングやリクエストキューイングを行いますが、シャーディングには「ルーター」プロキシが必要です。ルーターはデータトポロジー（データがどのシャードに分散されているか）を理解し、SQL クエリを適切に振り分けます。

• データ分散: ルーターは通常、ID カラムのハッシュ化といったシャーディング戦略を用いて、特定の行が格納されるべきシャードを決定します。
• シンプルな読み取り: 特定の ID を対象としたクエリは、ルーターが直接該当シャードへ転送します。
• 複雑な読み取り: 範囲クエリ（例: WHERE id BETWEEN 3 AND 5）の場合、ルーターはクエリを解析し、関係するすべてのシャードを特定、クエリを分散実行し、結果を集約してクライアントに返します。

データトポロジーの定義

ルーターは JSON 設定ファイルでテーブルのシャーディング方法を定義します。たとえば、user テーブルを id カラムの特定ハッシュインデックスでシャーディングする、といったメタデータです。この情報により、ルーターは多様なスキーマやクエリパターンを汎用的に処理できます。

高可用性とトラフィック分散

秒間数百万件のクエリを処理するには、単一のプロキシだけでは不十分です。ネットワークロードバランサ（NLB）の背後にプロキシ群を配置します。NLB は受信接続を特定のプロキシへ割り当て、接続が生きている間は同じプロキシに固定します。これにより、アプリケーションは単一の接続文字列（例: mydb.pscale.com）だけで済みます。

リクエストフローは以下の通りです: App Server → NLB → Router Proxy → Database Shard

業界の見解とトレードオフ

Vitess（MySQL 用）や Neki（Postgres 用）といったツールでのシャーディングは大規模化の実績ある手段ですが、コミュニティは以下のような技術的課題や代替案を指摘しています。

• 分散 SQL の複雑性: 批判的な声は、シャーディングによりシーケンス、外部キー、分散トランザクション、クロスシャード結合が困難になる点を挙げています。これらの操作は単一シャードのクエリとは異なるパフォーマンス特性を示します。
• 「スケールアップ」論争: 一部のエンジニアは、利用可能な最大単一サーバーの容量を最大化し、キャッシュ層を最適化することを、シャーディングの運用上の複雑さを導入する前に優先すべきだと主張しています。
• 代替アーキテクチャ: Oracle RAC のような同期マルチライトマスタシステムは、ロック調整に高速 RDMA ネットワークを使用することで、手動シャーディングやプロキシルーターなしにリレーショナルデータベースを水平スケールできると提案されています。

"システムの本質的な状態をもはや検査できなくなった日が、会社が NASDAQ に上場し、数百人のエンジニアに年収 30 万ドルを支払うべき日です。"

推奨事項のまとめ

PlanetScale は、データ量が数テラバイトを超える段階で、Postgres と MySQL に対してシャーディングアーキテクチャへの移行を推奨します。この規模になると、モノリシックなプライマリのボトルネックやバックアップウィンドウの制約が顕在化し、継続的な成長のためにシャーディングが最も現実的な道となります。

SUMMARY: PlanetScale は、Neki と Vitess を用いたプロキシ層で Postgres と MySQL を数百台のサーバーにシャーディングし、アプリケーションには単一の接続文字列を提供する方法を解説しています。

TITLE: Postgres と MySQL のスケーリング: 768 台のサーバーを 1 台に見せる