PostgreSQL から Google Cloud への移行を加速: Database Migration Service でテラバイト単位のデータを移行
Somdyuti Paul
Data Management Specialist
Pramod Nanduri
Software Engineer
※この投稿は米国時間 2024 年 8 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud に新たなワークロードを導入するすべてのユーザーにとって、Database Migration Service(DMS)は Google Cloud のさまざまなデータベースへのデータ移行プロセスを簡素化する、包括的なデータ移行手段となります。DMS の主な機能には、MySQL、PostgreSQL、SQL Server から Cloud SQL への継続的な移行や、PostgreSQL から AlloyDB for PostgreSQL への移行などがあります。さらに、DMS は Oracle ワークロードを Cloud SQL for PostgreSQL や AlloyDB に移行することもでき、Oracle ワークロードのモダナイズを支援します。DMS を活用すると、データ移行プロセスを効率化し、Google Cloud データベースにスムーズに移行できるようになります。
このブログ投稿では、Cloud SQL for PostgreSQL / AlloyDB ワークロードの移行速度を全体的に向上させるさまざまな方法をご紹介します。それでは詳しく見ていきましょう。
大規模なデータベース移行の課題
Database Migration Service の主な目標は、最小限のダウンタイムでシームレスにデータベースを移行することです。大規模な本番環境ワークロードを扱う場合、移行速度は移行エクスペリエンス全体を決める重要な要素となります。特に PostgreSQL データベースの場合、移行速度が遅いと以下のような悪影響が生じる可能性があります。
-
レプリケーションを設定した後、移行先が移行元にキャッチアップするまでのレプリケーション ラグが大きくなる
-
長時間に及ぶコピー操作によりバキュームが一時停止するため、移行元でトランザクションのラップアラウンドが発生する
-
WAL ログのサイズが大きくなり、移行元のディスク使用量が増加する
移行の高速化
上述の問題を回避するには、設定の一部をファインチューニングして、より高速な移行を実現します。以下の設定は、移行先が Cloud SQL と AlloyDB のどちらであっても適用されます。さまざまなカテゴリで設定を調整することで、移行速度を上げられます。
-
DMS を使用して、初期読み込みと変更データ キャプチャ(CDC)を並列処理する
-
移行元と移行先の PostgreSQL データベース パラメータを構成する
-
マシンとネットワークの構成を最適化する
それぞれについて詳しく見ていきましょう。
1. DMS を使用して初期読み込みと CDC を並列処理する
Google は最近、PostgreSQL のサブスクリプションを複数使用して移行を高速化する、DMS の新機能を導入しました。この新機能では、pglogical を使用して移行元と移行先のデータベース間で複数のサブスクリプションを設定することにより、並列接続でデータを移行します。この機能により、初期データの読み込み時もその後の CDC でも、データは並列ストリームで移行されます。
UI または Cloud SQL API を介して Database Migration Service を使用する場合、データ移行のデフォルトのオプションは OPTIMAL となり、移行元データベースに最適な負荷でバランスの取れたパフォーマンスを提供します。移行をさらに加速させたい場合は、別の設定 MAXIMUM を選択すると、最高のダンプ速度で移行を実施できます。
選択した設定に基づき、以下のように処理が行われます。
-
DMS が、データベースとインスタンス サイズの情報に応じて、データベースごとに最適なサブスクリプション数を算出します(サブスクリプションは pglogical レプリケーション設定の受信側です)。
-
サブスクリプション間でレプリケーション セットのサイズのバランスを取るため、テーブルがサイズに基づいて異なるレプリケーション セットに分散されます(レプリケーション セットは、データベース内のどのテーブルをレプリケートするかを制御するメカニズムを提供します)。
-
データがサブスクリプションごとに個別の接続で同時にコピーされ、初期のコピーや CDC が並列処理されます。
Google の経験では、MAXIMUM オプションを選択すると、MINIMAL / OPTIMAL モードを選択しているときと比較して、移行速度が数倍に向上します。
注意点として、MAXIMUM 設定は最高の速度を提供しますが、移行元がすでに高負荷状態にある場合、アプリケーションのパフォーマンスに影響する可能性があります。そのため、移行元のリソース使用状況を確認してから、このオプションを選択するようにしてください。
2. 移行元と移行先の PostgreSQL データベース パラメータを構成する
以下のデータベース パラメータは、初期読み込みと CDC を最適化するのに役立ちます。推奨される値には範囲があることにご注意ください。ワークロードごとにテストしてモニタリングし、その結果に応じて適切に設定する必要があります。
移行先インスタンスでファインチューニングできる構成
以下は、移行先データベースでファインチューニングできる構成です。
max_wal_size: 20 GB~50 GB の範囲で設定
システム パラメータ max_wal_size
は、自動チェックポイント時に拡張できる WAL の最大サイズを決定します。WAL のサイズを大きくすると、チェックポイントの頻度が減り、移行プロセスへのリソース割り当てが改善されます。デフォルトの max_wal_size
では、DMS の読み込みの際、数秒ごとにチェックポイントが発生する可能性があります。これを回避するには、マシン階層に応じて max_wal_size
を 20 GB~50 GB の間で設定します。大きな値に設定すると、特に初期読み込み時の全体的な移行速度を向上させることができます。AlloyDB の場合、チェックポイントは自動的に管理されるため、このパラメータを変更する必要はありません。移行が完了したら、本番環境ワークロードの要件に合わせて値を変更してください。
pglogical.synchronous_commit: オフに設定
pglogical.synchronous_commit
の名前が示すように、WAL レコードをディスクにフラッシュする前に commit の確認を行うことができます。WAL のフラッシュはすぐには行われず、wal_writer_delay
の設定に沿って行われます。これは一般的に非同期 commit と呼ばれ、DML の変更を適用する際の CDC での commit を高速にしますが、耐久性が犠牲になります。PostgreSQL インスタンスがクラッシュすると、直前の数回の非同期 commit が失われる可能性があります。
wal_buffers: 4 vCPU マシンでは 32~64 MB、8~16 vCPU マシンでは 64~128 MB に設定
WAL バッファは、まだディスクに書き込まれていない WAL データに使用する共有メモリの量を示します。その目標は、初期読み込み時の commit の頻度を減らすことです。移行先の vCPU が多い場合は 256 MB に設定できます。wal_buffers
を小さくすると commit の頻度が増えるため、初期読み込みでは値を大きくすると効果的です。
maintenance_work_mem: 1 GB を推奨 / 可能であれば最大インデックスのサイズ
PostgreSQL のメンテナンス オペレーション(VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY など)では、maintenance_work_mem と呼ばれる専用のメモリ領域が使用されます。これらのオペレーションは、データベースによって順番に実行されます。DMS は最初に初期読み込みデータを移行した後、移行先のインデックスと制約を再構築してから CDC フェーズを開始します。そのため maintenance_work_mem
は、これらの制約の構築に最適なメモリ量を使用するのに役立ちます。この値は、デフォルトの 64 MB よりはるかに大きな値に設定するようにします。過去のテストでは、1 GB に設定すると良い結果が得られました。可能であれば、移行先で再作成する必要がある最も大きいインデックスのサイズに近い値に設定するのが理想的です。移行が完了したら、このパラメータをデフォルト値にリセットし、アプリケーションのクエリ処理に影響が出ないようにします。
max_parallel_maintenance_workers: CPU 数に見合った値を設定
DMS は先にデータを移行した後、pg_restore を使用して移行先のセカンダリ インデックスを再作成します。DMS は移行先のマシン構成に基づいて、–jobs パラメータに最適な並列構成を選択します。CREATE INDEX 呼び出しをさらに高速化するには、移行先の max_parallel_maintenance_workers
パラメータを設定してインデックスを並列作成します。デフォルト設定は 2 ですが、この値は移行先インスタンスの CPU 数とメモリ量に応じてさらに増やすことができます。移行が完了したら、このパラメータをデフォルト値にリセットし、アプリケーションのクエリ処理に影響が出ないようにします。
max_parallel_workers: max_worker_processes に見合った値を設定
max_parallel_workers
フラグを使用すると、システムが並列処理でサポートできるワーカーの最大数を増やすことができます。デフォルト値は 8 です。max_worker_processes より大きな値に設定しても、並列ワーカーは max_worker_processes の設定を使って確立されたワーカー プロセス プールから取得されるため、効果はありません。max_parallel_workers
には、max_parallel_maintainence_workers
以上の値を設定するようにしてください。
autovacuum: オフに設定
CDC フェーズ中に移行先でキャッチアップするデータが大量にある場合、レプリケーション ラグが最小になるまで移行先の autovacuum を一時的にオフにします。インスタンスの昇格前に、max_parallel_maintenance_workers=4
(Cloud SQL インスタンスの vCPU 数に設定)、maintenance_work_mem=10GB
以上で 1 回だけ手動バキュームを行うと、バキュームを高速化できます。手動バキュームでは maintenance_work_mem からメモリが取得されることにご注意ください。移行後は必ず autovacuum をオンにしてください。
移行元インスタンスでファインチューニングできる構成
最後に、移行元インスタンスで以下の構成のファインチューニングを検討します。
shared_buffers: RAM の 60% に設定
shared_buffers
パラメータは、データベース サーバーが共有メモリバッファに割り当てるメモリ量を制御します。初期読み込みのパフォーマンスを向上させ、SELECT 用のメモリバッファをより多く確保するために、shared_buffers を移行元の PostgreSQL データベースで使用できる RAM の最大 60% まで増やすことをおすすめします。
3. マシンとネットワークの構成を最適化する
より高速な移行の実現において重要な役割を果たすもう一つの重要な要素が、マシンまたはネットワークの構成です。移行先と移行元の構成が大きい(RAM 容量、CPU 性能、ディスク IO の数値が高い)と、より高速な移行が実現しやすくなります。
これを実現するための方法をいくつかご紹介します。
-
DMS を使用して移行する場合、移行先インスタンスに大きなマシン階層を使用してみてください。移行が完了したら、インスタンスを昇格させる前に、マシンを小さい階層にダウングレードできます。この場合、マシンを再起動する必要があることにご注意ください。ただし、これはインスタンスを昇格させる前に行うため、ほとんどの場合、移行元のダウンタイムに影響しません。
-
ネットワーク スループットは vCPU の数によって制限されます。どの VM にも、マシンタイプに応じて書き込みスループットの下り(外向き)ネットワークの上限があります。最大ディスク スループット(1 GB あたり 0.48 MBps)は、VM の下り(外向き)ネットワーク スループットによって制限されます。ディスクの IOPS は 30 IOPS/GB です。移行先には vCPU 数がより多い Cloud SQL インスタンスを選択してみてください。また、より多くのスループットと IOPS を得るために、十分なディスクを割り当てます。
-
Google のテストでは、プライベート IP を使用した移行は、パブリック IP に基づいた移行より移行速度が高くなりました(20% 高速化)。
-
移行元データベースのサイズだけに基づいて初期ストレージのサイズを決めず、移行ワークロードのスループットと IOPS の要件を考慮に入れます。
-
移行先データベースのインデックス再構築のための並列スレッドは、移行先 Cloud SQL インスタンスの vCPU 数によって決まります(DMS はセカンダリ インデックスと制約の作成を初期読み込みの後、CDC の開始前に行います)。
制限事項とまとめ
単一の大きなテーブルに関して、移行するデータベースのデータの大部分が格納されている大きなテーブルが移行元にある場合、DMS を使用しても速度の大幅な向上が見られない可能性があります。これは、pglogical の制限により、現在の並列処理はテーブルレベルで行われているためです。そのため、テーブル内のデータを並列処理することはできません。これは今後のリリースで対処する予定です。
移行中は自動バックアップを有効にしないでください。また、可能であれば、移行元で DDL を実行しないでください。DDL はレプリケーションではサポートされていません。詳しくはドキュメントをご覧ください。
DMS による移行を最適化するには、移行元と移行先の両方のインスタンス構成のファインチューニング、最適なマシン構成とネットワーク構成の活用、さまざまな段階でのワークフローのモニタリングを行います。推奨されるベスト プラクティスに沿って潜在的な制限事項に対処することで、DMS による移行をより迅速かつ効率的に実現できます。ご利用を開始するにあたっては、AlloyDB と Cloud SQL への DMS 移行クイックスタート ガイドをご覧ください。
ー データ マネジメント スペシャリスト Somdyuti Paul
ー ソフトウェア エンジニア Pramod Nanduri