【ITニュース解説】How We Migrated 60 million PostgreSQL Rows in 40 Minutes & Now Replicate 220K Rows/Second
2025年09月28日に「Dev.to」が公開したITニュース「How We Migrated 60 million PostgreSQL Rows in 40 Minutes & Now Replicate 220K Rows/Second」について初心者にもわかりやすく解説しています。
ITニュース概要
PostgreSQL 13から15への大規模データベース移行で、2時間のメンテナンス時間に対し6000万行のデータをわずか40分で完了した。Helyxというツールを使い、現在22万行/秒の高速データ同期を実現し、ゼロダウンタイムとデータ損失なしのシステム更新に成功した。
ITニュース解説
今回のニュースは、非常に大規模なPostgreSQLデータベースを、ごく短い時間で新しいバージョンに移行し、さらに毎秒22万行という驚異的な速さでデータを同期できるようになった事例について解説する。システムエンジニアを目指す皆さんにとって、これは現実の世界で直面するデータベースの課題と、それをどのように革新的な方法で解決していくかを知る良い機会となるだろう。
物語は、あるプロジェクトチームが直面した困難な課題から始まる。彼らは、企業の重要な分析プラットフォームを支えるPostgreSQLデータベースを、バージョン13から15へアップグレードする必要があった。このデータベースは、約6000万行もの膨大な時系列データ(時間とともに記録される一連のデータ)を抱え、総容量は2テラバイトにも及んだ。しかし、最大の課題は、この大規模な移行作業を「2時間」という非常に短いメンテナンスウィンドウ(システムを一時的に停止または制限して作業する時間帯)内で完了させなければならないという、厳しい時間制約だった。さらに、データ損失は絶対に許されず、移行作業が進行中でも本番サービスへの性能影響を最小限に抑える必要があった。
従来のデータベース移行方法では、このような厳しい要件を満たすことは困難だった。例えば、PostgreSQLの標準的なバックアップ・リストアツールであるpg_dumpとpg_restoreを使った場合、すべてのデータをエクスポート(取り出し)し、ネットワーク経由で転送し、新しいデータベースにインポート(書き込み)するのに、合計で約8時間もかかる見込みだった。これは与えられた2時間のメンテナンスウィンドウを遥かに超える時間だ。また、PostgreSQLに標準で備わっている論理レプリケーション(データベースの変更内容をリアルタイムで別のデータベースに反映させる技術)を利用する方法も検討されたが、設定に手間がかかり、大量のデータ変更に追いつけなくなるリスクがあった。
この移行作業が特に難しかったのには、いくつかの技術的な背景がある。まず、PostgreSQLのバージョン13から15へのアップグレードでは、新しいデータ型や内部的な挙動の変更が導入されるため、単純なデータ移行だけでは済まない可能性があった。次に、このデータベースは本番環境で稼働しており、毎秒5万件以上の書き込みが絶えず発生していたため、データを移行している間もライブな変更をどう扱うかが問題だった。さらに、データベースのスキーマ(データの構造)も複雑で、大量の時系列データを効率的に管理するための「ハイパーテーブル」(特定の拡張機能で利用される大規模なテーブル構造)や、柔軟なデータ形式を格納できる「JSONBカラム」(JSON形式のデータをバイナリ形式で格納するPostgreSQLのデータ型)など、特殊な構造も含まれていた。そして何より、この分析プラットフォームが企業クライアント向けのリアルタイムダッシュボードを動かしており、ビジネスにとって極めて重要なシステムだったため、いかなる中断も許されない状況だった。
こうした数々の難題を解決するために、プロジェクトチームは「Helyx」という新しいソリューションを採用した。Helyxは、初期の大規模なデータ移行と、その後のリアルタイムなデータ同期の両方を実現できるツールだ。このアプローチは二つのフェーズに分かれて実行された。
最初のフェーズは「初期一括移行」だ。これは、既存のデータベースから新しいデータベースへ、一度に大量のデータをコピーする作業である。プロジェクトチームはメンテナンスウィンドウが始まった午後2時にHelyxの初期同期をトリガーした。すると驚くべき結果が出た。開始からわずか10分後には1000万行、25分後には3000万行、そして40分後には、なんと6000万行すべてのデータ移行が完了したのだ。これは毎分およそ250万行という、信じられないほどのスループット(単位時間あたりの処理量)を達成したことを意味する。これにより、8時間かかると予想された作業がわずか40分で終わり、2時間という厳しいメンテナンスウィンドウ内に余裕を持って収めることができた。この時、Helyxが使用したメモリは最大4.2GB、CPU使用率は65%と、非常に効率的に動作したことも特筆すべき点だ。
初期の一括移行が完了した後は、二つ目のフェーズである「リアルタイムレプリケーション」へとシームレスに移行した。これは、HelyxがChange Data Capture (CDC) モードで動作し、移行元データベースで発生する新しいデータ変更(挿入、更新、削除など)をリアルタイムに検出し、新しいデータベースに反映させ続ける機能である。このリアルタイムレプリケーションの性能もまた驚くべきものだった。現在の運用では、毎秒22万行ものデータを同期しており、ほとんどのケース(95パーセンタイルで)で500ミリ秒(0.5秒)未満という非常に低い遅延でデータが反映されている。さらに、このリアルタイム同期のために、移行元のデータベースにかかるCPU負荷は3%未満と極めて低く、本番サービスのパフォーマンスにほとんど影響を与えないことも確認された。ネットワーク帯域も約180MBpsで効率的に使用されていた。
このような高性能を実現するために、Helyxにはいくつかの技術的な工夫が凝らされている。例えば、「並列ワーカー」という技術が利用されている。これは、複数の処理を同時に実行することで、データベースへのデータの読み書き(I/O)のスループットを最大限に高めるものだ。また、「スマートバッチング」という手法も使われており、5万行のデータをまとめて一度に転送することで、ネットワークの利用効率を最適化している。さらに、「メモリマッピング」により、メモリを効率的に利用し、大規模なデータ処理中にメモリ不足に陥る(OOMエラー)ことを防いでいる。そして、最も重要なことの一つに、「継続的なデータ検証」がある。これは、リアルタイムでデータのチェックサム(データの整合性を確認するための計算値)を検証することで、移行中や同期中にデータが破損したり、不整合が生じたりしないことを常に保証する仕組みだ。
この事例は、大規模なデータベース移行が直面する困難な課題に対し、Helyxのような専門的なツールがいかに効果的な解決策を提供できるかを示している。限られた時間、膨大なデータ、複雑な環境といった制約の中でも、ゼロダウンタイムに近い形で、かつデータ損失なく、高速かつ安定した移行とレプリケーションを実現する技術は、現代のITシステムにおいて不可欠なものとなっている。システムエンジニアを目指す皆さんにとって、このような最先端の技術と、それがどのように実際のビジネス課題を解決しているのかを理解することは、将来のキャリアにおいて非常に役立つはずだ。