AWS から Google Cloud に移行する: Amazon RDS for PostgreSQL と Amazon Aurora for PostgreSQL から Cloud SQL と AlloyDB for PostgreSQL に移行する

Last reviewed 2024-09-12 UTC

Google Cloud には、Amazon Relational Database Service（RDS）または Amazon Aurora から Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。

このドキュメントは、データベース移行プロジェクトの計画、実装、検証を行うクラウド管理者とデータベース管理者を対象としています。また、移行の時期を考え、移行がどのようなものかを知りたい意思決定者を対象としています。

このドキュメントでは、移行元データベースと移行先データベースが同じデータベース テクノロジーである同種のデータベース移行に焦点を当てます。この移行ガイドでは、移行元は Amazon RDS または Amazon Aurora for PostgreSQL、移行先は Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL とします。

このドキュメントは、AWS からGoogle Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。

Google Cloudに移行する場合は、 Google Cloudへの移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。

  1. ワークロードとデータを評価して検出します。
  2. Google Cloud上に基盤を計画して構築します。
  3. ワークロードとデータを Google Cloudに移行します。
  4. Google Cloud 環境を最適化します。

このフレームワークのフェーズの詳細については、 Google Cloudへの移行: スタートガイドをご覧ください。

効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、 Google Cloudへの移行: 移行計画の検証に関するベスト プラクティスをご覧ください。

移行元の環境を評価する

評価フェーズでは、移行元の環境を Google Cloudに移行するための要件と依存関係を明らかにします。

移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、 Google Cloudへの移行を計画して実施するための出発点も理解する必要があります。

評価フェーズは、次のタスクで構成されます。

  1. ワークロードの包括的なインベントリを作成する。
  2. プロパティと依存関係に応じてワークロードを分類する。
  3. チームを Google Cloudでトレーニングして教育する。
  4. Google Cloudでテストと概念実証を作成する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. ワークロードの移行戦略を選択する。
  7. 移行ツールを選択する。
  8. 移行計画とタイムラインを定義する。
  9. 移行計画を検証する。

データベースの評価フェーズを実施することで、ターゲット Cloud SQL データベース インスタンスに移行元と一致するサイズと仕様を選択し、同様のパフォーマンス要件を満たすことができます。ディスクサイズとスループット、IOPS、vCPU の数に特に注意してください。ターゲット データベース インスタンスのサイズが正しくないと、移行が困難になるか、失敗する可能性があります。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。Cloud SQL インスタンスを選択する場合は、ディスクのパフォーマンスはディスクのサイズと vCPU の数に基づくことに注意してください。

以降のセクションの内容は、 Google Cloudへの移行: ワークロードの評価と検出に基づいており、このドキュメントの情報が統合されています。

Amazon RDS インスタンスまたは Amazon Aurora インスタンスのインベントリを作成する

移行の範囲を定義するには、インベントリを作成し、Amazon RDS インスタンスと Amazon Aurora インスタンスに関する情報を収集します。手動で行う方法はエラーが発生しやすく、誤った想定につながる可能性があるため、このプロセスは自動化することが理想的です。

Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL には、Amazon RDS または Amazon Aurora と類似する機能、インスタンス仕様、オペレーションがない場合があります。一部の機能は、実装が異なるか、使用できない場合があります。違いがある領域としては、インフラストラクチャ、ストレージ、認証とセキュリティ、レプリケーション、バックアップ、高可用性、リソース容量モデル、特定のデータベース エンジン機能の統合、拡張機能などがあります。データベース エンジンのタイプ、インスタンスのサイズ、アーキテクチャによっては、データベース パラメータ設定のデフォルト値が異なる場合もあります。

ベンチマークは、移行するワークロードをより深く理解し、移行先の環境に適切なアーキテクチャを定義する際に役立ちます。パフォーマンスに関する情報を収集することは、 Google Cloud のターゲット環境のパフォーマンス要件を見積もるうえで重要な作業となります。ベンチマークのコンセプトとツールについては、移行プロセスのテストと検証を実施するで詳しく説明しますが、これはインベントリの構築ステージにも当てはまります。

評価用のツール

現在のインフラストラクチャの概要を把握するには、Google Cloud Migration Center と、migVisor や Database Migration Assessment Tool（DMA）などの専用のデータベース評価ツールを使用することをおすすめします。

Migration Center を使用すると、 Google Cloudへのデータベース移行の技術的な適合性など、アプリケーションとデータベースの状況を完全に評価できます。移行元のデータベースごとにサイズと構成の推奨事項を受け取り、サーバーとデータベースの総所有コスト（TCO）レポートを作成します。

Migration Center を使用して AWS 環境を評価する方法については、他のクラウド プロバイダからデータをインポートするをご覧ください。

Migration Center に加えて、専用のツール migVisor を使用できます。migVisor はさまざまなデータベース エンジンをサポートしており、特に異種間の移行に適しています。migVisor の概要については、migVisor の概要をご覧ください。

migVisor は、移行の失敗の原因となる可能性のあるアーティファクトと互換性のない独自のデータベース機能を特定し、回避策を示します。また、初期サイズやアーキテクチャなど、ターゲットとなる Google Cloud ソリューションを推奨する場合もあります。

migVisor データベース評価の出力には、次の情報が含まれます。

  • 現在のデータベース デプロイメントの包括的な検出と分析。
  • データベースで使用されている独自の機能に基づく、移行の複雑さに関する詳細なレポート。
  • 移行後のコスト削減、移行費用、新しい運用予算に関する詳細を含む財務レポート。
  • ビジネスへの影響を最小限に抑えながら、データベースとそれに関連するアプリケーションを移行するための段階的な移行計画。

評価出力の例については、migVisor - Cloud 移行評価ツールをご覧ください。

migVisor を使用すると、データベース サーバーの使用率が一時的に増大します。通常、この追加負荷は 3% 未満であり、ピーク時以外であれば問題ありません。

migVisor の評価出力は、RDS インスタンスの完全なインベントリの作成に役立ちます。レポートには、汎用プロパティ（データベース エンジンのバージョンとエディション、CPU、メモリサイズ）のほか、データベース トポロジ、バックアップ ポリシー、パラメータ設定、使用中の特別なカスタマイズに関する詳細が含まれます。

オープンソース ツールを使用する場合は、上記のツールとともに（または代わりに）データコレクタ スクリプトを使用できます。これらのスクリプトを使用すると、詳細な情報（ワークロード、機能、データベース オブジェクト、データベース コードなど）を収集し、データベース インベントリを構築できます。また、スクリプトでは通常、移行作業の見積もりなど、データベースの移行に関する詳細な評価が提供されます。

Google のエンジニアが作成したオープンソース ツールである DMA の使用をおすすめします。これは、使用中の機能、データベース ロジック、データベース オブジェクト（スキーマ、テーブル、ビュー、関数、トリガー、ストアド プロシージャなど）を含む、包括的で正確なデータベース評価を提供します。

DMA を使用するには、Git リポジトリからデータベース エンジンの収集スクリプトをダウンロードし、手順に沿って操作します。出力ファイルを Google Cloud に送信して分析します。 Google Cloud は、データベース評価の読み取り結果を作成し、移行の次のステップを提示します。

移行の範囲と受容できるダウンタイムを特定して文書化する

この段階では、移行戦略とツールに影響を与える重要な情報を文書化します。ここまでの段階で、次の質問に答えられるはずです。

  • データベースが 5 TB を超えているかどうか。
  • データベースに大規模なテーブルはあるか。16 TB を超えているかどうか。
  • データベースはどこにあるか（リージョンとゾーン）。また、アプリケーションとの距離はどのくらいか。
  • データが変更される頻度はどのくらいか。
  • どのデータ整合性モデルを使用するのか。
  • 移行先データベースにどのような選択肢があるのか。
  • 移行元と移行先のデータベースに互換性があるか。
  • データが特定の物理的な場所に存在する必要があるかどうか。
  • 圧縮してアーカイブできるデータがあるか。移行する必要のないデータがあるか。

移行スコープを定義するには、保持するデータと移行するデータを決定します。すべてのデータベースを移行するには、かなりの時間と労力が必要になる場合があります。一部のデータは移行元データベースのバックアップに残る場合があります。たとえば、古いロギング テーブルやアーカイブ データは不要な場合があります。戦略とツールに応じて、移行プロセスの後にデータを移動することもできます。

結果と影響を比較して評価する際に役立つデータ移行のベースラインを設定します。これらのベースラインは、移行前と移行後のデータを表す参照ポイントであり、意思決定に役立ちます。データ移行の成功を評価するために、移行元の環境で測定を実施しておく必要があります。このような測定には次のようなものがあります。

  • データのサイズと構造。
  • データの完全性と整合性。
  • 最も重要なビジネス トランザクションとプロセスの所要時間とパフォーマンス。

許容できるダウンタイムを決定します。ビジネスに対するダウンタイムの影響はどのくらいか。データベース アクティビティが低く、ダウンタイムの影響を受けるユーザーが少ない期間があるか。ある場合、その期間はどのくらいか。また、いつ発生するのか。読み取り専用リクエストは引き続き処理されるように、書き込み専用の部分的なダウンタイムを検討してください。

デプロイと管理のプロセスを評価する

インベントリを構築したら、データベースの運用プロセスとデプロイ プロセスを評価し、移行を容易にするために、それらをどのように適応させるのかを判断します。これらのプロセスは、本番環境を準備して維持する方法の基本となります。

次のタスクの実行方法を検討してください。

  • インスタンスのセキュリティ ポリシーを定義して適用する。たとえば、Amazon セキュリティ グループの置き換えが必要になる場合があります。Google IAM ロール、VPC ファイアウォール ルール、VPC Service Controls を使用して、Cloud SQL for PostgreSQL インスタンスへのアクセスを制御し、VPC 内のデータを制限できます。

  • インスタンスにパッチを適用して構成する。既存のデプロイツールの更新が必要になる場合があります。たとえば、Amazon パラメータ グループまたは Amazon オプション グループでカスタム構成設定を使用している場合です。Cloud Storage または Secret Manager を使用してこのようなカスタム構成リストを読み取るように、プロビジョニング ツールの調整が必要になる場合があります。

  • モニタリングとアラートのインフラストラクチャを管理する。Amazon ソース データベース インスタンスの指標カテゴリは、移行プロセス中のオブザーバビリティを提供します。指標カテゴリには、Amazon CloudWatch、Performance Insights、Enhanced Monitoring、OS プロセスリストなどがあります。

評価を完了する

Amazon RDS または Amazon Aurora 環境からインベントリを構築したら、 Google Cloudへの移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。

基盤の計画と構築

計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。

  • Google Cloud 環境でワークロードをサポートします。
  • 移行元の環境と Google Cloud 環境を接続して、移行を完了します。

計画と構築のフェーズは、次のタスクで構成されます。

  1. リソース階層を構築する。
  2. Google Cloudの Identity and Access Management（IAM）を構成する。
  3. お支払い情報を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. ロギング、モニタリング、アラートを設定する。

これらの各タスクの詳細については、 Google Cloudへの移行: 基盤の計画と構築をご覧ください。

移行に Database Migration Service を使用する場合は、Cloud SQL for PostgreSQL のネットワーキング方法で、移行シナリオで使用できるネットワーキング構成を確認してください。

モニタリングとアラート

Google Cloud Monitoring には、Cloud SQL モニタリング ダッシュボードなど、いくつかの Google Cloud プロダクト用に事前定義されたダッシュボードが用意されています。また、Datadog や Splunk など、Google Cloudと統合されたサードパーティのモニタリング ソリューションを使用することもできます。詳細については、データベース オブザーバビリティについてをご覧ください。

Amazon RDS と Amazon Aurora for PostgreSQL インスタンスを Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL に移行する

インスタンスを移行するには、次の操作を行います。

  1. 移行戦略（継続的レプリケーションまたは定期メンテナンス）を選択します。

  2. 選択した戦略と要件に応じて、移行ツールを選択します。

  3. 準備と実行のタスクなど、各データベース移行の移行計画とタイムラインを定義します。

  4. 移行ツールが適切に機能するように、準備タスクを定義します。

  5. 実行タスクを定義します。これには、移行を実装する作業アクティビティが含まれます。

  6. 実行タスクごとにフォールバック シナリオを定義します。

  7. テストと検証を行います。これは、別のステージング環境で行うこともできます。

  8. 移行を実行します。

  9. 本番環境のカットオーバーを実施します。

  10. 移行元の環境をクリーンアップし、移行先インスタンスを構成します。

  11. チューニングと最適化を行います。

以降のセクションでは、これらのフェーズについて説明します。

移行戦略を選択する

この時点で、各データベースのユースケースに最適な移行戦略を評価して選択するための十分な情報を取得しているはずです。

  • 定期メンテナンス（1 回限りの移行またはビッグバン移行）: ダウンタイムを許容できる場合は、この方法が理想的です。このオプションでは、ワークロードとサービスのリファクタリングがほとんど必要ないため、費用と複雑さが比較的低くなります。ただし、移行が完了する前に失敗した場合は、プロセスを再開する必要があります。これにより、ダウンタイムが長くなります。

  • 継続的レプリケーション（オンライン移行またはトリクル移行）: ミッション クリティカルなデータベースの場合、このオプションはデータ損失のリスクが低く、ダウンタイムがほぼゼロになります。作業は複数のチャンクに分割されるため、失敗した場合のロールバックと再試行にかかる時間が短くなります。ただし、設定が複雑になり、より多くの計画と時間が必要になります。データベース インスタンスに接続するアプリケーションをリファクタリングするために、追加の作業が必要になります。次のいずれかのバリエーションを検討してください。

    • Y（書き込み / 読み取り）アプローチを使用する。これは並行移行の一種であり、移行中に移行元インスタンスと移行先インスタンスの両方でデータを複製します。
    • データアクセス マイクロサービスを使用すると、Y（書き込み / 読み取り）アプローチで必要なリファクタリングの労力を削減できます。

データ移行戦略の詳細については、データ移行方法の評価をご覧ください。

次の図は、単一データベースの移行戦略を決定する際に考慮すべき質問の例に基づくフローチャートを示しています。

移行戦略を選択するためのフローチャート。

上のフローチャートには、次の判断ポイントが示されています。

  • ダウンタイムを許容できるかどうか。

    • 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
    • 「はい」の場合、次の判断ポイントに進みます。

  • カットオーバーまでのダウンタイムを許容できるか。カットオーバー ウィンドウは、データベースのバックアップ、Cloud SQL への転送、復元、アプリケーションの切り替えにかかる時間を表します。

    • 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
    • 「はい」の場合は、定期メンテナンスの移行戦略を採用します。

同じインスタンス上にある場合でも、データベースによって戦略が異なる場合があります。戦略を組み合わせることで、最適な結果を得ることができます。たとえば、規模が小さく使用頻度の低いデータベースは定期メンテナンスで移行し、ダウンタイムが発生すると費用がかさむミッション クリティカルなデータベースは継続レプリケーションで移行します。

通常、移行は、最初の移行元インスタンスと移行先インスタンスの切り替えが行われたときに完了したと見なされます。レプリケーション（使用されている場合）は停止し、すべての読み取りと書き込みはターゲット インスタンスで実行されます。両方のインスタンスが同期している状態で切り替えが行われると、データ損失がなく、ダウンタイムが最小限に抑えられます。

データ移行戦略とデプロイの詳細については、データベース移行の分類をご覧ください。

アプリケーションのダウンタイムが発生しない移行構成では、より複雑な設定が必要になります。設定の複雑さと、トラフィックの少ない業務時間帯にスケジュールされたダウンタイムとの間で適切なバランスを見つけます。

各移行戦略には、移行プロセスに関連するトレードオフと影響があります。たとえば、レプリケーション プロセスでは、移行元インスタンスに負荷がかかり、レプリケーション ラグによってアプリケーションに影響が及ぶ可能性があります。アプリケーション（とユーザー）は、新しいデータベースが使用されるまでレプリケーション ラグが続く限り、アプリケーションのダウンタイム中に待機しなければなりません。実際には、次の要因によりダウンタイムが増加する可能性があります。

  • データベース クエリの完了には数秒かかることがあります。移行時に、処理中のクエリが中止される可能性があります。
  • データベースが大きい場合や、バッファメモリが大量にある場合は、キャッシュがいっぱいになるまでに時間がかかることがあります。
  • 移行元で停止し、 Google Cloudで再起動したアプリケーションは、 Google Cloudデータベース インスタンスへの接続が確立されるまで少し遅延が生じることがあります。
  • アプリケーションへのネットワーク ルートを再ルーティングする必要があります。これは、DNS エントリの設定方法によってはある程度時間がかかることがあります。DNS レコードを更新する場合は、移行前に TTL を短くします。

次の一般的な方法を実施すると、ダウンタイムと影響を最小限に抑えることができます。

  • ダウンタイムがワークロードに与える影響を最小限に抑えられる期間を見つけます。たとえば、通常の業務時間外、週末、その他の定期メンテナンスの期間中などです。
  • 移行と本番環境のカットオーバーをさまざまな段階で行うことができるワークロードの部分を特定します。アプリケーションには、影響なく分離、適応、移行できるさまざまなコンポーネントが含まれている場合があります。たとえば、フロントエンド、CRM モジュール、バックエンド サービス、レポート プラットフォームなどです。このようなモジュールには、プロセスの前半または後半に移行をスケジュールできる独自のデータベースが存在する場合があります。
  • ターゲット データベースでレイテンシが発生しても問題ない場合は、段階的な移行の実施を検討してください。増分バッチデータ転送を使用し、ワークロードの一部を調整して、ターゲット インスタンスの古いデータを処理します。
  • 移行の影響を最小限に抑えるために、アプリケーションのリファクタリングを検討してください。たとえば、移行元データベースと移行先データベースの両方に書き込むようにアプリケーションを調整し、アプリケーション レベルでのレプリケーションを実装します。

移行ツールを選択する

移行を成功させるための最も重要な要素は、適切な移行ツールを選択することです。移行戦略が決まったら、移行ツールを確認して決定します。

利用可能なツールは多数あり、それぞれ特定の移行ユースケースに合わせて最適化されています。ユースケースには、次のようなものがあります。

  • 移行戦略（定期メンテナンスまたは継続的レプリケーション）。
  • 移行元と移行先のデータベース エンジンとエンジン バージョン。
  • 移行元インスタンスと移行先インスタンスが配置されている環境。
  • データベース サイズ。データベースが大きくなるほど、最初のバックアップの移行に時間がかかります。
  • データベースの変更頻度。
  • 移行にマネージド サービスを使用できるかどうか。

シームレスな移行とカットオーバーを確実に行うには、アプリケーションのデプロイ パターン、インフラストラクチャ オーケストレーション、カスタム移行アプリケーションを使用します。ただし、マネージド移行サービスと呼ばれる専用のツールを使用すると、データ、アプリケーション、さらにはインフラストラクチャ全体を環境間で移動するプロセスを容易に実施できます。これらのツールは、移行元データベースからデータを抽出して、データを移行先データベースに安全に転送します。また、転送中にデータを変更することもできます。これらの機能により、移行の複雑なロジックをカプセル化し、移行モニタリング機能を利用できます。

マネージド移行サービスには次のような利点があります。

  • ダウンタイムを最小限に抑える: サービスは、利用可能な場合にデータベース エンジンの組み込みレプリケーション機能を使用し、レプリカのプロモーションを実行します。

  • データの整合性とセキュリティを確保する: データは、移行元から移行先のデータベースに安全かつ確実に転送されます。

  • 一貫した移行エクスペリエンスを提供: データベース移行の実行可能ファイルを使用すると、さまざまな移行手法とパターンを一貫した共通インターフェースに統合できます。このインターフェースで管理とモニタリングを行うことができます。

  • 信頼性が高く実績のある移行モデルを提供: データベースの移行は頻繁ではありませんが、重要なイベントです。初歩的なミスや既存のソリューションに関する問題を回避するには、カスタム ソリューションを構築するのではなく、経験豊富な専門家が提供するツールを使用します。

  • 費用を最適化する: カスタム移行ソリューション用に追加のサーバーとリソースをプロビジョニングするよりも、マネージド移行サービスのほうが費用対効果に優れている場合があります。

以降のセクションでは、選択した移行戦略に推奨される移行ツールについて説明します。

定期メンテナンスでの移行用のツール

以降のサブセクションでは、1 回限りの移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。

Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL への 1 回限りの移行では、データベース エンジンのバックアップを使用して、ソース インスタンスからデータをエクスポートし、そのデータをターゲット インスタンスにインポートすることをおすすめします。Database Migration Service では、1 回限りの移行ジョブはサポートされていません。

組み込みデータベース エンジンのバックアップ

大幅なダウンタイムが許容でき、移行元データベースが比較的静的である場合は、データベース エンジンの組み込みダンプと読み込み（バックアップと復元とも呼ばれます）機能を使用できます。

特にデータベースの数が多い場合は、設定と同期に手間がかかりますが、通常、データベース エンジンのバックアップはすぐに利用可能で、使いやすいものです。このアプローチは、あらゆるデータベース サイズに適しており、通常は大規模なインスタンスで他のツールよりも効果的です。

データベース エンジンのバックアップには、次のような一般的な制限があります。

  • バックアップは、特に手動で行う場合はエラーが発生する可能性があります。
  • スナップショットが適切に管理されていない場合、データは保護されません。
  • バックアップには適切なモニタリング機能がありません。
  • 多くのデータベースを移行する場合は、バックアップのスケーリングに労力を要します。

PostgreSQL の組み込みバックアップ ユーティリティである pg_dump と pg_dumpall を使用して、Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL の両方を移行できます。ただし、pg_dump ユーティリティと pg_dumapall ユーティリティには、次の一般的な制限があります。

  • 500 GB 以下のデータベースを移行するには、組み込みのバックアップ ユーティリティを使用する必要があります。大規模なデータベースのダンプと復元には時間がかかり、大量のディスク容量とメモリが必要になることがあります。
  • pg_dump ユーティリティにはユーザーとロールは含まれません。これらのユーザー アカウントとロールを移行するには、pg_dumpall ユーティリティを使用します。
  • Cloud Storage は、最大 5 テラバイト（TB）の単一オブジェクト サイズをサポートしています。5 TB を超えるデータベースの場合、Cloud Storage へのエクスポート オペレーションは失敗します。その場合は、エクスポート ファイルを小さなセグメントに分割する必要があります。

これらのユーティリティを使用する場合は、次の制限事項とベスト プラクティスを考慮してください。

  • データを圧縮して、費用と転送時間を削減します。pg_dump コマンドで --jobs オプションを使用すると、指定した数のダンプジョブを同時に実行できます。
  • pg_dump コマンドで -z オプションを指定すると、使用する圧縮レベルを指定できます。このオプションの有効な値の範囲は 0 ～ 9 です。デフォルト値はレベル 6 で圧縮することです。値を大きくするとダンプファイルのサイズは小さくなりますが、クライアント ホストでのリソース消費量が増加する可能性があります。クライアント ホストに十分なリソースがある場合は、圧縮レベルを高くすると、ダンプ ファイルのサイズをさらに小さくできます。
  • SQL ダンプファイルの作成時に正しいフラグを使用します。
  • インポートしたデータベースを確認します。復元プロセス中にエラー メッセージがないか、pg_restore ユーティリティの出力をモニタリングします。復元プロセス中に警告やエラーが発生していないか、PostgreSQL ログを確認します。基本的なクエリとテーブル数を実行して、データベースの整合性を確認します。

制限事項とベスト プラクティスの詳細については、次のリソースをご覧ください。

定期メンテナンス移行のその他の方法

組み込みのバックアップ ユーティリティ以外の方法を使用すると、定期メンテナンスの移行をより詳細に制御し、柔軟に対応できる場合があります。これらのアプローチでは、移行中にデータの変換、チェック、その他のオペレーションを実行できます。複数のインスタンスまたはデータベースを 1 つのインスタンスまたはデータベースに統合できます。インスタンスを統合すると、運用コストを削減し、スケーラビリティの問題を軽減できます。

バックアップ ユーティリティの代替手段の 1 つとして、フラット ファイルを使用してデータをエクスポートおよびインポートする方法があります。フラット ファイルのインポートの詳細については、Cloud SQL for PostgreSQL の CSV ファイルを使用したエクスポートとインポートをご覧ください。

別の方法として、マネージド インポートを使用して外部 PostgreSQL データベースからのレプリケーションを設定することもできます。マネージド インポートを使用すると、外部データベースから Cloud SQL for PostgreSQL インスタンスにデータが最初に読み込まれます。この初期読み込みでは、外部サーバー（RDS または Aurora インスタンス）からデータを抽出し、Cloud SQL for PostgreSQL インスタンスに直接インポートするサービスを使用します。詳細については、マネージド インポートを使用して外部データベースからのレプリケーションを設定するをご覧ください。

データを 1 回だけ移行する別の方法として、移行元の PostgreSQL データベースから CSV ファイルまたは SQL ファイルにテーブルをエクスポートする方法があります。その後、CSV ファイルまたは SQL ファイルを Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL にインポートできます。ソース インスタンスの日付をエクスポートするには、PostgreSQL の aws_s3 拡張機能を使用します。または、Amazon Database Migration Service と S3 バケットをターゲットとして使用することもできます。このアプローチの詳細については、次のリソースをご覧ください。

AlloyDB for PostgreSQL インスタンスにデータを手動でインポートすることもできます。サポートされている形式は次のとおりです。

  • CSV: このファイル形式では、この形式の各ファイルにデータベース内の 1 つのテーブルの内容が含まれます。psql コマンドライン プログラムを使用して、データを CSV ファイルに読み込むことができます。詳細については、CSV ファイルをインポートするをご覧ください。
  • DMP: このファイル形式には、PostgreSQL データベース全体のアーカイブが含まれています。このファイルからデータをインポートするには、pg_restore ユーティリティを使用します。詳細については、DMP ファイルをインポートするをご覧ください。
  • SQL: このファイル形式には、PostgreSQL データベースのテキスト再構築が含まれています。このファイル内のデータは、psql コマンドラインを使用して処理されます。詳細については、SQL ファイルをインポートするをご覧ください。

継続的レプリケーションの移行ツール

次の図は、継続的レプリケーション移行戦略を採用し、単一データベースの移行ツールを選択する際に役立つ質問とフローチャートを示しています。

継続的レプリケーション移行に使用するツールを選択するためのフローチャート。

上のフローチャートには、次の判断ポイントが示されています。

  • マネージド移行サービスが必要かどうか。

    • 「はい」の場合、レプリケーション ステップの実行中に書き込みのダウンタイムを数秒間許容できるかどうか。

      • 「はい」の場合、Database Migration Service を使用します。
      • 「いいえ」の場合、他の移行オプションを検討します。

    • 「いいえ」の場合は、データベース エンジンの組み込みレプリケーションがサポートされているかどうかを評価する必要があります。

      • 「はい」の場合は、組み込みレプリケーションを使用することをおすすめします。
      • 「いいえ」の場合は、他の移行オプションを検討することをおすすめします。

以降のセクションでは、継続的な移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。

継続的レプリケーション移行用の Database Migration Service

Database Migration Service には、継続的移行用の特定のジョブタイプが用意されています。これらの継続的移行ジョブは、Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL への高忠実度の移行をサポートしています。

Database Migration Service を使用して Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL に移行する場合、各ターゲット インスタンスに関連する前提条件と制限事項があります。

データベース エンジンの組み込みレプリケーション

データベース エンジンの組み込みレプリケーションは、継続的な移行を行う Database Migration Service の代替オプションです。

データベース レプリケーションは、プライマリ データベースと呼ばれるデータベースからレプリカと呼ばれる他のデータベースにデータをコピーして分散するプロセスです。データベース システムのデータアクセス可能性を高め、フォールト トレランスと信頼性を向上させることを目的としています。データベース移行はデータベース レプリケーションの主な目的ではありませんが、この目標を達成するためのツールとして使用できます。データベース レプリケーションは通常、プライマリ データベースでデータが挿入、更新、削除されるたびにリアルタイムで実行される継続的なプロセスです。データベースのレプリケーションは、一回限りのオペレーションとして、または一連のバッチ オペレーションとして行うことができます。

最新のデータベース エンジンのほとんどは、データベース レプリケーションを実現するためのさまざまな方法を実装しています。レプリケーションの 1 つのタイプは、プライマリの write-ahead log またはトランザクション ログをコピーしてレプリカに送信することで実現できます。このアプローチは、物理レプリケーションまたはバイナリ レプリケーションと呼ばれます。他のレプリケーション タイプは、ファイル システム レベルの変更をレプリケートするのではなく、プライマリ データベースが受信した SQL ステートメントをそのまま送信することで動作します。これらのレプリケーション タイプは論理レプリケーションと呼ばれます。PostgreSQL には、ログ先行書き込み（WAL）に依存する論理レプリケーションを実装する pglogical などのサードパーティ拡張機能もあります。

Cloud SQL は PostgreSQL のレプリケーションをサポートしています。ただし、前提条件と制限事項がいくつかあります。

Cloud SQL for PostgreSQL には、次の制限事項と前提条件があります。

  • 次の Amazon バージョンがサポートされています。

    • Amazon RDS 9.6.10 以降、10.5 以降、11.1 以降、12、13、14
    • Amazon Aurora 10.11 以降、11.6 以降、12.4 以降、13.3 以降

  • 外部サーバーのファイアウォールは、VPC ネットワークのプライベート サービス アクセスに割り振られた内部 IP 範囲を許可するように構成する必要があります。Cloud SQL for PostgreSQL レプリカ データベースは、VPC ネットワークをプライベート ネットワークとして使用します。

  • ソース データベースのファイアウォールは、VPC ネットワークのプライベート サービス接続に割り振られた内部 IP 範囲全体を許可するように構成する必要があります。Cloud SQL for PostgreSQL の宛先インスタンスは、IpConfiguration 設定の privateNetwork フィールドでこの VPC ネットワークを使用します。

  • Cloud SQL for PostgreSQL インスタンスに pglogical 拡張機能をインストールする場合は、enable_pglogical フラグを on（cloudsql.enable_pglogical=on など）に設定していることを確認してください。

  • shared_preload_libraries パラメータに、移行元インスタンスの pglogical 拡張機能（shared_preload_libraries=pg_stat_statements,pglogical など）が含まれていることを確認します。rds.logical_replication パラメータを 1 に設定します。この設定により、論理レベルで write-ahead log が有効になります。

    この変更を適用するには、プライマリ インスタンスの再起動が必要です。

レプリケーションに Cloud SQL for PostgreSQL を使用する方法については、PostgreSQL のレプリケーション セクションの外部サーバーのチェックリストと、Cloud SQL の公式ドキュメントの PostgreSQL の論理レプリケーションとデコーディングを設定するをご覧ください。

AlloyDB for PostgreSQL は、pglogical 拡張機能によるレプリケーションをサポートしています。レプリケーション用に pglogical 拡張機能を有効にするには、CREATE EXTENSION コマンドを使用します。このコマンドを使用する前に、まず拡張機能を使用する AlloyDB for PostgreSQL インスタンスでデータベース フラグ alloydb.enable_pglogical と alloydb.logical_decoding を on に設定する必要があります。これらのフラグを設定するには、インスタンスの再起動が必要です。

継続的レプリケーション移行のその他のアプローチ

Datastream を使用して、ソース PostgreSQL インスタンスの変更をほぼリアルタイムで複製できます。Datastream は、変更データ キャプチャ（CDC）とレプリケーションを使用して、データを複製して同期します。その後、Datastream を使用して、Amazon RDS と Amazon Aurora からの継続的なレプリケーションを行うことができます。Datastream を使用して、PostgreSQL インスタンスから BigQuery または Cloud Storage に変更を複製します。レプリケートされたデータは、Dataflow Flex テンプレートを使用するか、Dataproc を使用して、Dataflow で Cloud SQL for PostgreSQL インスタンスと AlloyDB for PostgreSQL インスタンスに転送できます。

Datastream と Dataflow の使用の詳細については、次のリソースをご覧ください。

継続的レプリケーション移行のサードパーティ ツール

場合によっては、データベース エンジンに 1 つのサードパーティ ツールを使用するほうが適していることがあります。このようなケースとしては、マネージド移行サービスを使用し、ターゲット データベースが常に移行元とほぼリアルタイムで同期されるようにする必要がある場合や、移行プロセス中にデータのクリーニング、再構造化、適応などのより複雑な変換が必要な場合などがあります。

サードパーティ ツールを使用する場合は、次のいずれかをおすすめします。このツールは、ほとんどのデータベース エンジンで使用できます。

Striim は、データをリアルタイムで収集、フィルタリング、変換、拡充、集計、分析、配信するためのエンドツーエンドのインメモリ プラットフォームです。

  • メリット:

    • 大量のデータと複雑な移行に対応。
    • SQL Server の組み込み変更データ キャプチャ。
    • 事前構成済みの接続テンプレートとノーコード パイプライン。
    • 大量のトランザクション ロードで動作するミッション クリティカルな大規模なデータベースに対応。
    • 1 回限りの配信。

  • デメリット:

Striim の詳細については、 Google Cloudでの Striim の実行をご覧ください。

Debezium は CDC 用のオープンソース分散プラットフォームであり、外部サブスクライバーにデータ変更をストリーミングできます。

  • メリット:

    • オープンソースである。
    • 万全のコミュニティ サポート。
    • 優れた費用対効果。
    • 行、テーブル、データベースに対するきめ細かい制御。
    • データベース トランザクション ログからリアルタイムで変更をキャプチャするように特化されている。

  • デメリット:

    • Kafka と ZooKeeper に関する特定の経験が必要。
    • データ変更を 1 回以上配信。つまり、重複の処理が必要になります。
    • Grafana と Prometheus を使用してモニタリングを手動で設定。
    • 増分バッチ レプリケーションは非対応。

Debezium の移行の詳細については、Debezium を使用したニアリアルタイム データ レプリケーションをご覧ください。

Fivetran は、クラウド データ プラットフォームからデータを移動したり、複数のクラウド データ プラットフォーム間でデータを移動するための自動データ移動プラットフォームです。

  • メリット:

    • 事前構成済みの接続テンプレートとノーコード パイプライン。
    • スキーマの変更を移行元から移行先データベースに反映。
    • データ変更の 1 回限りの配信。つまり、重複の処理は必要ありません。

  • デメリット:

    • オープンソースではない。
    • 複雑なデータ変換のサポートは制限付き。

移行計画とタイムラインを定義する

データベースの移行と本番環境へのカットオーバーを成功させるには、明確で包括的な移行計画を準備することをおすすめします。ビジネスへの影響を軽減するために、必要なすべての作業項目のリストを作成することをおすすめします。

移行の範囲を定義すると、データベース移行プロセスの前、最中、移行後に必要な作業タスクが明らかになります。たとえば、データベースから特定のテーブルを移行しない場合は、このフィルタを実装するために移行前または移行後のタスクが必要になることがあります。また、データベースの移行が既存のサービスレベル契約（SLA）と事業継続計画に影響しないようにします。

移行計画のドキュメントには、次のドキュメントを含めることをおすすめします。

  • 技術設計ドキュメント（TDD）
  • RACI 図
  • タイムライン（T-Minus プランなど）

データベースの移行は反復的なプロセスであり、最初の移行は後続の移行よりも時間がかかることがよくあります。通常、計画的な移行は問題なく実行されますが、想定外のトラブルが発生することもあります。常にロールバック計画を用意することをおすすめします。ベスト プラクティスとして、 Google Cloudへの移行: 移行計画の検証に関するベスト プラクティスのガイダンスに従うことをおすすめします。

TDD

TDD には、プロジェクトで行うすべての技術的な決定が文書化されます。TDD には、以下のものを記述します。

  • ビジネス要件と重要性
  • 目標復旧時間（RTO）
  • 目標復旧時点（RPO）
  • データベースの移行の詳細
  • 移行に必要な作業の見積もり
  • 移行の検証に関する推奨事項

RACI 図

移行プロジェクトによっては、RACI マトリックスが必要になる場合があります。RACI マトリックスは、移行プロジェクト内のタスクと成果物に対する責任を負う個人またはグループを定義する一般的なプロジェクト管理ドキュメントです。

タイムライン

移行が必要な各データベースのタイムラインを準備します。実施する必要のあるすべての作業タスクと、その開始日と終了予定日を定義します。

移行環境ごとに T-minus プランを作成することをおすすめします。T-minus プランはカウントダウン スケジュールとして構成され、移行プロジェクトの完了に必要なすべてのタスクと、担当グループ、推定所要時間を示します。

タイムラインには、移行前の準備タスクの実施だけでなく、データ転送後に実施される検証、監査、テストのタスクも考慮する必要があります。

移行タスクにかかる時間は通常、データベースのサイズに依存しますが、ビジネス ロジックの複雑さ、アプリケーションの使用状況、チームの空き状況など、ほかにも考慮すべき点があります。

T-Minus プランは次のようになります。

日付 フェーズ カテゴリ タスク ロール T-minus ステータス
11/1/2023 移行前 評価 評価レポートを作成する ディスカバリ チーム -21 完了
11/7/2023 移行前 ターゲットの準備 設計ドキュメントに従って移行先の環境を設計する 移行チーム -14 完了
11/15/2023 移行前 会社のガバナンス 移行日と T-Minus の承認 リーダー -6 完了
11/18/2023 移行 DMS を設定する 接続プロファイルを作成する クラウド移行エンジニア -3 完了
11/19/2023 移行 DMS を設定する 移行ジョブをビルドして開始する クラウド移行エンジニア -2 未開始
11/19/2023 移行 DMS をモニタリングする 移行元インスタンスの DMS ジョブと DDL の変更をモニタリングする クラウド移行エンジニア -2 未開始
11/21/2023 移行 DMS をカットオーバーする DMS レプリカをプロモートする クラウド移行エンジニア 0 未開始
11/21/2023 移行 移行の検証 データベースの移行の検証 移行チーム 0 未開始
11/21/2023 移行 アプリケーション テスト 機能テストとパフォーマンス テストを実行する 移行チーム 0 未開始
11/22/2023 移行 会社のガバナンス 移行の検証: 可否 移行チーム 1 未開始
11/23/2023 移行後 モニタリングを検証する モニタリングを構成する インフラストラクチャ チーム 2 未開始
11/25/2023 移行後 セキュリティ DMS ユーザー アカウントを削除する セキュリティ チーム 4 未開始

複数のデータベースの移行

移行するデータベースが複数ある場合は、移行計画にすべての移行タスクを含める必要があります。

移行プロセスを開始する際は、小規模なデータベース（できればミッション クリティカルでないデータベース）を移行することをおすすめします。このアプローチにより、移行プロセスとツールに関する知識と自信を深めることができます。移行全体のスケジュールの早い段階で、プロセスの欠陥を検出することもできます。

移行するデータベースが複数ある場合は、タイムラインを並列化できます。たとえば、移行プロセスを高速化するために、次の図に示すように、小規模なデータベース、静的データベース、または重要度の低いデータベースのグループを同時に移行できます。

並列データベース移行タスク。

図の例では、データベース 1～4 は、同時に移行される小規模データベースのグループです。

準備タスクを定義する

準備タスクは、移行の前提条件を満たすために完了する必要があるすべてのアクティビティです。準備タスクがないと、移行を実行できません。また、移行を行っても、移行後のデータベースが使用できなくなります。

準備タスクは、次のように分類できます。

  • Amazon RDS または Amazon Aurora インスタンスの準備と前提条件
  • 移行元データベースの準備と前提条件
  • Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL のインスタンス設定
  • 移行固有の設定

Amazon RDS または Amazon Aurora インスタンスの準備と前提条件

次の一般的な設定と前提条件のタスクを検討してください。

  • 移行パスによっては、RDS インスタンスでのリモート接続の許可が必要になる場合があります。RDS インスタンスが VPC でプライベートに構成されている場合は、Amazon と Google Cloudの間にプライベート RFC 1918 接続が必要です。

  • 必要なポートでリモート接続を許可し、Amazon RDS インスタンスまたは Amazon Aurora インスタンスにセキュリティ グループを適用するように、新しいセキュリティ グループの構成が必要になる場合があります。

    • AWS では、デフォルトでデータベース インスタンスのネットワーク アクセスが無効になっています。
    • セキュリティ グループで、IP アドレス範囲、ポート、またはセキュリティ グループからのアクセスを許可するルールを指定できます。同じルールが、そのセキュリティ グループに関連付けられているすべてのデータベース インスタンスに適用されます。

  • Amazon RDS から移行する場合は、Amazon RDS インスタンスの完全読み込み中に先行書き込みログをバッファリングするための十分な空きディスク容量があることを確認します。

  • 継続的なレプリケーション（CDC による変更のストリーミング）では、リードレプリカではなく、完全な RDS インスタンスを使用する必要があります。

  • 組み込みレプリケーションを使用している場合は、PostgreSQL のレプリケーション用に Amazon RDS または Amazon Aurora インスタンスを設定する必要があります。組み込みレプリケーションまたは組み込みレプリケーションを使用するツールには、PostgreSQL の論理レプリケーションが必要です。

  • サードパーティ ツールを使用する場合は、通常、ツールを使用する前に事前設定と構成が必要です。サードパーティ ツールのドキュメントを確認してください。

インスタンスの準備と前提条件の詳細については、PostgreSQL のレプリケーション用に外部サーバーを設定するをご覧ください。

移行元データベースの準備と前提条件

  • Database Migration Service を使用する場合は、移行元データベースに接続する前に、移行元データベースを構成します。詳細については、PostgreSQL のソースを構成すると PostgreSQL から AlloyDB for PostgreSQL へのソースを構成するをご覧ください。

  • 主キーのないテーブルの場合、Database Migration Service が最初のバックアップを移行した後、CDC フェーズでは INSERT ステートメントのみがターゲット データベースに移行されます。これらのテーブルの DELETE ステートメントと UPDATE ステートメントは移行されません。

  • PostgreSQL の論理デコード機能はラージ オブジェクトの変更のデコードをサポートしていないため、Database Migration Service ではラージ オブジェクトを複製できないことを考慮してください。

  • 組み込みのレプリケーションを使用する場合は、論理レプリケーションにはデータ定義言語（DDL）コマンド、シーケンス、ラージ オブジェクトに関する制限事項があることを考慮してください。CDC を有効にして多くの更新を行うテーブルには、主キーが存在するか、追加されている必要があります。

  • 一部のサードパーティ移行ツールでは、すべてのラージ オブジェクト列が null 可能である必要があります。NOT NULL である大きなオブジェクト列は、移行中にその制約を削除する必要があります。

  • 本番環境で移行元環境のベースラインを測定します。次の点を考慮してください。

    • データのサイズとワークロードのパフォーマンスを測定します。重要なクエリまたはトランザクションに平均でどのくらいの時間がかかるか。ピーク時は何分間か。
    • ベースライン測定値を記録して後で比較し、データベース移行の忠実度が十分かどうかを判断できるようにします。本番環境ワークロードを切り替えて移行元の環境を廃止できるかどうか、またはフォールバック用に引き続き必要かどうかを判断します。

Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL のインスタンス設定

移行先インスタンスで移行元インスタンスと同等のパフォーマンス レベルを実現するには、移行元インスタンスのサイズと仕様に合わせて移行先 PostgreSQL データベース インスタンスのサイズと仕様を選択します。ディスクサイズとスループット、1 秒あたりの入出力オペレーション数（IOPS）、仮想 CPU（vCPU）の数に特に注意してください。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL インスタンスを選択する場合は、ディスクのパフォーマンスはディスクのサイズと vCPU の数に基づくことに注意してください。

Cloud SQL for PostgreSQL インスタンスと AlloyDB for PostgreSQL インスタンスを作成する前に、次のプロパティと要件を確認する必要があります。これらのプロパティと要件を後で変更する場合は、インスタンスを再作成する必要があります。

  • ターゲット Cloud SQL for PostgreSQL インスタンスと AlloyDB for PostgreSQL インスタンスのプロジェクトとリージョンは慎重に選択してください。インスタンスは、データ転送なしで Google Cloud プロジェクトとリージョン間で移行することはできません。

  • Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL で一致するメジャー バージョンに移行します。たとえば、Amazon RDS または Amazon Aurora で PostgreSQL 14.x を使用している場合は、Cloud SQL または AlloyDB for PostgreSQL の PostgreSQL バージョン 14.x に移行する必要があります。

  • 組み込みデータベース エンジンのバックアップまたは Database Migration Service を使用している場合は、ユーザー情報を個別にレプリケートします。詳細については、データベース エンジン固有のバックアップのセクションの制限事項をご覧ください。

  • データベース エンジン固有の構成フラグを確認し、移行元と移行先のインスタンスの値を比較します。これらの影響を把握し、同程度の影響にする必要があるかどうかを判断します。たとえば、PostgreSQL を使用する場合は、ソース データベースの pg_settings テーブルの値と、Cloud SQL および AlloyDB for PostgreSQL インスタンスの値を比較することをおすすめします。移行元の設定をレプリケートするように、必要に応じて移行先データベース インスタンスでフラグの設定を更新します。

  • ワークロードの性質によっては、データベースをサポートするために特定の拡張機能を有効にする必要があります。ワークロードでこれらの拡張機能が必要な場合は、サポートされている PostgreSQL 拡張機能と、Cloud SQL と AlloyDB for PostgreSQL でそれらを有効にする方法を確認してください。

Cloud SQL for PostgreSQL の設定の詳細については、インスタンス構成オプション、