この記事の途中に、以下の記事の引用を含んでいます。
Sharding Postgres at Network Speed
シャーディングの常識を変える!? Postgresスケーリングの新潮流
データベースのスケーラビリティ──この難題に頭を悩ませてきた開発者は少なくありません。
ことPostgresに限れば、一枚岩の“モノリシック”な運用から、より小さな“シャード”への分割（シャーディング）、すなわち水平方向への拡張は、「やりたくても難しい」領域として認識されてきました。
今回紹介する Sharding Postgres at Network Speed は、Postgresのシャーディングを“ネットワーク帯域の上限”まで劇的に高速化したPgDogの新アーキテクチャと、それがいかに既存の運用や設計思想にインパクトをもたらすかを深掘りしています。
この記事はDBエンジニアだけでなく、スケーラビリティやデータマイグレーションに関心があるエンジニア、また現場でDB移行に苦しむ全ての開発者に、決して他人事とは思えない驚きや示唆を提供する内容です。
ついに実現！PgDogによるオンライン再シャーディング
Sharding Postgres at Network Speed の冒頭では、PgDogがこれまでPostgresのスマートなコネクションプーラーでありつつ、オンラインで既存アプリのダウンタイムをゼロに再シャーディングする──という長年求められてきた機能を遂げたことを強調しています。
“PR #279 introduced a long promised architectural change: we can now use logical replication to re-shard databases. This happens online and doesn’t affect production performance.”
つまり、Postgresのロジカルレプリケーション(Logical Replication)という仕組みを応用することで、サービスを止めることなく巨大DBをシャーディングできるようになった、と主張しています。
また、記事は以下のような検証結果にも言及しています。
“In our tests, we were able to copy and shard terabytes of data in a matter of minutes.”
TB級のデータを“数分”で再シャーディング……従来の常識からすれば夢のような話です。
ロジカルレプリケーションとPostgres v16の進化──なぜ高速化が可能になったのか？
従来の課題：「遅くて壊れやすい」大規模データ移行
これまでPostgresの“論理レプリケーション”はプライマリDBだけをサポートしていました。
巨大DB（数TB規模）の移行時、ロジカルレプリケーションのI/O・ストレージ負荷は甚大で、復旧も容易ではありません。
引用によれば、Instacartでは16TBのテーブルをシャーディングするのに「2週間」かかる試算だったと言います。
“Replicating 16 TB worth of tables… would have taken 2 weeks. …with 200 MB of WAL … more than 230 TB of it would accumulate in the time … we would have ran out of disk space and crashed the database.”
つまり、I/Oボトルネック以前にWAL（書き込み先行ログ）の保持容量すらネックになる実態でした。
Postgres v16で拓かれたパラレル世界
転機となったのがPostgres v16での「ストリーミングレプリカ上でのロジカルレプリケーションスロット作成」サポートです。
“Since Postgres v16, we can create logical replication slots on streaming replicas. Since Postgres databases can have many of those, it opened the door to parallelization.”
従来はプライマリ1台＋I/O制約という構図が、複数のレプリカを“独立並列化”することで一気に高スループット化。
大量のテーブルコピーやリアルタイム同期が“並列並走”できるようになったことで、まさに“ネットワーク帯域”がボトルネックになる世界を実現しています。
まさかの実測値──「8GB/秒」到達の裏側
開発チームによる実験では、例えば16台のレプリカを使って16シャードに分割する場合で
以下のようなことが可能となっています。
“A single Postgres database… can copy a table at 500 MB/second. 16 of them can do the same at 8 GB/second.”
さらに、「1ストリーム＝500MB/秒✕16」で8GB/秒超となり、もはや10GbitのNICですら帯域が不足するレベル。
これは、DBI/Oを超えて、ネットワークそのものを使い切る“新次元の速さ”です。
例えば16TBの巨大DBでも、理論上55分で再シャーディングが可能です。
この数字は、従来の「2週間」クラスタ断続・再構築地獄と比較し、
運用コスト・リスクの劇的な削減を意味します。
PgDogの新アーキテクチャが切り拓く現場の実利
エンタープライズDB管理の常識を変える
これまでは「DBをダウンさせないデータ再配置やシャード追加」は、多くのSRE・DBAにとって現実的ではありませんでした。
既存アプリを止めずに再シャーディング（Resharding）し、その間に生じたデータの整合も保つ──この芸当は夢のまた夢。
PgDog 2.0の設計は、こうした悩みを“構造的に”払拭します。
- すべては並列化： テーブル単位でレプリカから並列コピー→各シャードへ直書き
- WALスロットによる厳密な一意同期： コピー開始時点のLSNを“バージョン管理”のごとく保持
- 差分データも漏らさず反映： コピー完了後も、ロジカルレプリケーションで「増分変更」（Insert/Update/Delete）を拾い、シャードごとに“追随同期”
例えば下記のような流れです。
“For each table… Start a transaction… Get the current LSN by creating a replication slot… Copy the table out, splitting rows between shards equally … Once the copy is finished, we stream whatever rows changed since the copy started.”
これにより「コピー中に生じたデータ変更」すら確実に吸収し、かつプロダクションDBの負荷は極小化。
しかも、実際のアプリケーションレベルでは“無停止”を維持できる仕組みなのです。
ODS(運用系)からDWH(分析系)、SaaSまで…活用シーンは無限大
この基礎設計思想は、エンタープライズでの巨大ユーザDBや、分析レイク移行、マルチテナントSaaSアーキテクチャ等、現代的な大規模Webサービスのほぼ“全シーン”に直結します。
実例でイメージを具体化
- ECやモバイルアプリのDB： 新しい地理的拠点、あるいは特定ユーザ群だけをリアルタイム移設し、新たなシャードへ移行する…従来なら数日、時には「夜間作業」必須だったものが“昼休憩1回分”に短縮可能
- DWHへのデータ移行： 過去データのうち特定範囲のみを高速吸出し、バージョニングや一貫性管理もWALでカバー
- SaaSのマルチテナント対応： テナント数増加に応じてDBの分割や再配置を“サービス休止ゼロ”で進行
一歩深読みする──「課題」や「今後の進化」も直視する
とはいえ、課題は全くないわけではありません。
-
ネットワーク帯域が本当にボトルネック化
本手法は「ネットワーク環境がボトルネックになりうる」事態が前提となります。
クラウド環境下で帯域設計が不十分な場合、理論値と現実値の乖離も起こり得ることに注意すべきです。 -
運用・障害時トラブルの検証余地
PgDogは「WALスロットとリアルタイム同期」を駆使しますが、障害時の“データ損失ゼロ保証”を100%担保するにはさらなる検証・実践知も必要です。 -
アプリケーション側の整合性やトランザクション設計
レプリケーション対象DBのスキーマ設計やアプリ層のトランザクション制御方式如何によっては、「アプリ無改修での安定性」には注意が必要とも言えるでしょう。 -
データ重複や部分失敗への対策
並列化された状態で何らかの途中障害が発生した場合、どのタイミングまでが安全に移行されているのか。その「ロールバック」や「再開」のセーフティネットも意識的に設計する必要があります。
とはいえ、この世界がひらく未来
とは言え、これほどまでに“実用水準”で「再シャーディング自動化」された基盤は稀有です。
オープンソースで公開されたことにより、今後はさらに幅広い現場ノウハウや二次検証、あるいはPostgres本体の進化にも波及する可能性が高いでしょう。
エンジニアにとっての「気付き」と「今後の展望」
1. シャーディング移行は“難題”から“標準作業”へ
従来の“オンプレ構築的な発想”では到底できなかった「無停止・短時間・正確」な再シャーディングは、今やOSSの現実解。
2. DBアーキテクチャ設計の「根本を問い直す」きっかけ
アプリ設計時点で「将来的なシャード分割」を前提にせずとも、必要な時に痛みなく“後から”分割できる自由度は、アーキテクチャ思想自体を根底から覆します。
3. 今後のRDB/NoSQL選定やDB運用方針にも影響
パフォーマンスや運用性を理由に“分散型NoSQL”を選択していた現場が、「Postgres＆PgDog＋分散運用」という新たな選択肢を持つことになります。
まとめ──「“やり直し”も“拡張”も後悔しないPostgres運用」へ
Sharding Postgres at Network Speed が鮮やかに示したのは、
「DBの分割やシャーディング、それに伴うデータ移動の苦しみから、エンジニアは（いよいよ）解放される日が近い」という希望です。
技術やパフォーマンスの進化に、DB運用者やSREはどう追随するか。
そしてアーキテクチャ設計において「サービスのスケールは“成長後”でも柔軟に吸収できる」前提が、当たり前となる社会が本当に到来しつつあります。
これからPostgresを採用する組織は、将来の“ゼロダウンタイム・高速移行”も視野に入れた設計が可能となりました。
同時に、既存運用の改善やトラブル対応にも壮大な可能性が広がったと言えるでしょう。
あなたのDB設計思想も、今こそ“アップデート”してみてはいかがでしょうか？
categories:[technology]
コメント