PostgreSQL データベースを Azure に移行する

[アーティクル]
04/06/2023

この記事では、Contoso という架空の会社が、オンプレミスの PostgreSQL オープンソースデータベースプラットフォームの Azure への移行をどのように計画し、実行したかについて説明します。

ビジネスドライバー

IT リーダーシップチームは、ビジネスパートナーと密接に連絡を取り合い、彼らがこの移行で何を達成しようとしているのかを理解しました。目的は次のとおりです。

ビッグデータの自動化。 Contoso では、ビッグデータおよび AI イニシアチブのいくつかに PostgreSQL を使用しています。同社は、これらの分析ワークロードの多くを自動化するために、スケーラブルで反復可能なパイプラインを構築したいと考えています。
効率化。 Contoso では、不要な手順を取り除き、開発者とユーザーのプロセスを効率化する必要があります。ビジネス部門は、顧客の要求により迅速に対応するために、IT 部門に対して、時間やコストを無駄にせず、迅速に作業を行うことを求めています。
機敏性の向上。 Contoso IT は、ビジネス部門の要求に対して、対応力を向上させる必要があります。また、グローバル経済での成功を実現し、ビジネスの障害にならないように、市場の変化に遅れることなく対応する必要があります。
スケーリング。 ビジネスが順調に成長している中で、Contoso IT 部門は、同じペースで拡張できるシステムを提供する必要があります。
セキュリティを強化する。 Contoso は、規制上の問題により、監査、ログ、コンプライアンスの要件に基づいてオンプレミス戦略の調整が必要になることを認識しています。

Note

ラボを使用した Azure Database for PostgreSQL への移行に関するガイダンスについては「Azure PostgreSQL 移行ガイド」を参照してください。

移行の目標

Contoso クラウドチームは、この移行の目標を明確にしました。それらを使用して最適な移行方法を決定します。

必要条件	詳細
アップグレード	Contoso では、利用可能な場合は最新の修正プログラムを確実にインストールしたいと考えていますが、これらの更新を管理することは望んでいません。
統合	Contoso では、データベース内のデータを、機械学習用のデータおよび AI パイプラインと統合したいと考えています。
バックアップと復元	Contoso では、データの更新に失敗した場合や、なんらかの理由でデータが破損した場合に、ポイントインタイムリストアを実行する機能を求めています。
Azure	Contoso では、システムを監視し、パフォーマンスとセキュリティに基づいてアラートを発生させたいと考えています。
パフォーマンス	場合によっては、異なる地理的リージョンに並列データ処理パイプラインを設定し、それらのリージョンからデータを読み取る必要があります。

ソリューション設計

Contoso は、目標と要件を明確にした後、デプロイソリューションを設計してレビューし、移行プロセスを確認します。移行に使用するツールとサービスも確認します。

現在の環境

PostgreSQL 9.6.7 は、Contoso データセンターの物理的な Linux マシン (sql-pg-01.contoso.com) で実行されています。 Contoso には、オンプレミスのデータセンターネットワークへのサイト間 VPN Gateway を含む Azure サブスクリプションが既にあります。

提案されるソリューション

Azure Database Migration Service を使用して、データベースを Azure Database for PostgreSQL インスタンスに移行します。
新しい Azure Database for PostgreSQL インスタンスを使用するように、すべてのアプリケーションとプロセスを変更します。
Azure Database for PostgreSQL インスタンスに接続する Azure Data Factory を使用して、新しいデータ処理パイプラインを構築します。

データベースの考慮事項

ソリューション設計プロセスの一環として、Contoso では PostgreSQL データをホストするための Azure の機能を確認しました。 Azure の使用を決定する際に、次の考慮事項が役立ちました。

Azure SQL Database と同様に、Azure Database for PostgreSQL ではファイアウォール規則がサポートされます。
Azure Database for PostgreSQL を仮想ネットワークで使用して、インスタンスにパブリックにアクセスできないようにすることができます。
Azure Database for PostgreSQL には、Contoso が満たす必要のある必須のコンプライアンス認定資格があります。
DevOps と Azure Data Factory との統合によって、自動化されたデータ処理パイプラインを構築できるようになります。
読み取りレプリカを使用して、処理のパフォーマンスを向上させることができます。
データ暗号化のための Bring Your Own Key (BYOK) のサポート。
Azure Private Link を使用して、サービスを内部ネットワークトラフィックだけに公開できます (パブリックアクセスなし)。
選択されたゲートウェイ (Azure ExpressRoute またはサイト間 VPN) に基づいて、アプリケーションからデータベースへの帯域幅と待機時間が十分に確保されます。

ソリューションのレビュー

Contoso は、長所と短所の一覧をまとめて、提案された設計を評価します。

考慮事項	詳細
長所	現在の必須および使用中の機能はすべて、Azure Database for PostgreSQL でご利用いただけます。
短所	Contoso は、PostgreSQL のメジャーバージョンからの移行を引き続き手動で実行する必要があります。

提案されたアーキテクチャ

シナリオのアーキテクチャの図。 図 1. シナリオのアーキテクチャ。

移行プロセス

準備

Contoso は、PostgreSQL データベースを移行する前に、自社のインスタンスが、移行を成功させるための Azure の前提条件をすべて満たしていることを確認します。

サポートされているバージョン

同じバージョンまたはそれ以降のバージョンへの移行のみがサポートされます。 PostgreSQL 9.5 から Azure Database for PostgreSQL 9.6 または 10 への移行はサポートされますが、PostgreSQL 11 から PostgreSQL 9.6 への移行はサポートされません。

Microsoft では、Azure Database for PostgreSQL - 単一サーバーでの PostgreSQL エンジンの n-2 バージョンのサポートを予定しています。バージョンは、Azure の現在のメジャーバージョン (n) とその前の 2 つのメジャーバージョン ( -2) です。

サポートされているバージョンの最新情報については、「サポートされる PostgreSQL のメジャーバージョン」をご覧ください。

Note

メジャーバージョンの自動アップグレードはサポートされていません。たとえば、PostgreSQL 9.5 から PostgreSQL 9.6 への自動アップグレードはありません。次のメジャーバージョンにアップグレードするには、データベースをダンプし、ターゲットエンジンのバージョンで作成されたサーバーに復元します。

ネットワーク

Contoso は、オンプレミス環境から、Azure Database for PostgreSQL データベースが配置されている仮想ネットワークへの仮想ネットワークゲートウェイ接続を設定する必要があります。この接続により、オンプレミスのアプリケーションからデータベースにアクセスできるようになりますが、クラウドに移行することはできません。

評価

Contoso では、レプリケーションの問題について、現在のデータベースを評価する必要があります。次のような問題があります。

移行するソースデータベースのバージョンは、ターゲットデータベースのバージョンと互換性があります。
レプリケートするすべてのテーブルに主キーが存在する必要があります。
データベース名にセミコロン (;) を含めることはできません。
同じ名前であっても大文字と小文字が異なる複数のテーブルを移行すると、予期しない動作が発生する可能性があります。

図 2: 移行プロセス。

移行:

Contoso は、いくつかの方法で移行を実行できます。

Contoso は、メジャーからメジャーへのアップグレードを実行する必要があるときに移行プロジェクトを常に再利用できるように、Azure Database Migration Service を選択しました。 1 つの Database Migration Service アクティビティは最大 4 つのデータベースにしか対応しないため、Contoso は次の手順を使用して複数のジョブを設定します。

準備するには、データベースにアクセスするための仮想ネットワークを設定します。さまざまな方法で、VPN ゲートウェイを使用して仮想ネットワーク接続を作成します。

Azure Database Migration Service インスタンスを作成する

Azure portal で、 [リソースの追加] を選択します。
Azure Database Migration Service を検索して選択します。
[+ 追加] を選択します。
サービス用のサブスクリプションとリソースグループを選択します。
インスタンスの名前を入力します。
Contoso データセンターまたは VPN Gateway に最も近い場所を選択します。
サービスモードについては、 [Azure] を選択します。
価格レベルを選択します。
[Review + create](レビュー + 作成) を選択します。

図 3: 確認と作成。
［作成］ を選択します

Azure Database for PostgreSQL インスタンスを作成する

オンプレミスサーバーで、postgresql.conf ファイルを構成します。
サーバーとデータベースへのアクセスに Azure Database Migration Service によって使用される適切な IP アドレスをリッスンするように、サーバーを設定します。
- listen_addresses 変数を設定します。
SSL を有効にします。
1. ssl=on 変数を設定します。
2. TLS 1.2 をサポートするサーバーに対して、公的に署名された SSL 証明書を使用していることを確認します。それ以外の場合、Database Migration Service ツールでエラーが発生します。
pg_hba.conf ファイルを更新します。
- Database Migration Service インスタンスに固有のエントリを追加します。
各サーバーの postgresql.conf ファイルの値を変更して、ソースサーバーで論理レプリケーションを有効にする必要があります。
1. wal_level = logical
2. max_replication_slots = [少なくとも、移行するデータベースの最大数]
  - たとえば、4 つのデータベースを移行する場合は、値を 4 に設定します。
3. max_wal_senders = [同時に実行されているデータベースの数]
  - 推奨値は 10 です。
移行 User には、ソースデータベースに対する REPLICATION ロールが必要です。
PostgreSQLpg_hba.conf ファイルに、Database Migration Service インスタンスの IP アドレスを追加します。
データベーススキーマをエクスポートするには、次のコマンドを実行します。
```
pg_dump -U postgres -s dvdrental > dvdrental_schema.sql
```
ファイルをコピーし、そのコピーに dvdrental_schema_foreign.sql という名前を付けて、すべての非外部キーおよびトリガー関連項目を削除します。
dvdrental_schema.sql ファイルから、すべての外部キーおよびトリガー関連項目を削除します。

データベーススキーマをインポートします (手順 1)。

  psql -h {host}.postgres.database.azure.com -d dvdrental -U username -f dvdrental_schema.sql

移行:

Azure portal で、Database Migration Service リソースに移動します。
サービスが開始されていない場合は、 [サービスの開始] を選択します。
[新しい移行プロジェクト] を選択します。

図 4: 新規移行の開始。
[新しいアクティビティ]>[オンラインデータの移行] の順に選択します。
名前を入力します。
ソースとして、 [PostgreSQL] を選択します。
ターゲットについては、 [Azure Database for PostgreSQL] を選択し、 [保存] を選択します。

図 5: 新しい移行プロジェクトが強調表示されている。
ソース情報を入力し、 [保存] を選択します。

図 6: ソース情報の入力。
ターゲット情報を入力し、 [保存] を選択します。

図 7: ターゲット情報の選択。
移行するデータベースを選択します。各データベースのスキーマは、以前に移行されているはずです。次に、 [保存] を選択します。

図 8: データベースの選択。
詳細設定を構成し、 [保存] を選択します。

図 9: 詳細設定の構成。
アクティビティに名前を付け、 [実行] を選択します。

図 10: アクティビティの名前付けと実行。
移行を監視する。なんらかのエラーが発生した場合は再試行します。たとえば、外部キー参照が見つからない場合などです。
Full load completed がテーブル数と一致したら、 [一括で開始] を選択します。

図 11: 一括を開始するための移行の監視。
ソースサーバーからのすべてのトランザクションを停止します。
「確認」チェックボックスをオンにして、「適用」を選択します。

図 12: 一括の実行。
カットオーバーが完了するまで待ちます。

図 13: 一括の完了。

Note

上記の Database Migration Service の手順は、Azure CLI を使用して実行することもできます。

データベーススキーマをインポートします (手順 2)。

psql -h {host}.postgres.database.azure.com -d dvdrental -U username -f dvdrental_schema_foreign.sql

オンプレミスのデータベースを使用するすべてのアプリケーションまたはプロセスを、新しい Azure Database for PostgreSQL データベースインスタンスを指すように再構成します。
移行後について、Contoso は、移行が完了したら必要に応じて、リージョンをまたがる読み取りレプリカを設定することもできます。

移行後にクリーンアップする

移行後に、Contoso では保有目的でオンプレミスデータベースをバックアップし、クリーンアッププロセスの一環として古い PostgreSQL サーバーを廃止する必要があります。

デプロイを再調査する

リソースを Azure に移行したら、新しいインフラストラクチャを完全に操作可能にして、セキュリティで保護する必要があります。

セキュリティ

Contoso は次のことを行う必要があります。

新しい Azure Database for PostgreSQL インスタンスとデータベースを確実にセキュリティで保護します。詳細については、「Azure Database for PostgreSQL のセキュリティ - 単一サーバー」をご覧ください。
ファイアウォール規則と仮想ネットワーク構成を確認して、接続を必要とするアプリケーションのみに接続が制限されていることを確認します。
データの暗号化のために BYOK を実装します。
データベースへの SSL 接続を要求するように、すべてのアプリケーションを更新します。
Private Link を設定して、すべてのデータベーストラフィックが Azure とオンプレミスネットワーク内に保持されるようにします。
Microsoft Defender for Identity を有効にします。
対象のセキュリティおよびログエントリを監視し、アラートを生成するように Log Analytics を構成します。

バックアップ

geo リストアを使用して、Azure Database for PostgreSQL データベースが確実にバックアップされるようにします。これにより、リージョン規模の障害が発生した場合は、ペアのリージョンにあるバックアップを使用できます。

重要

Azure Database for PostgreSQL リソースが削除されないように、リソースロックが設定されていることを確認します。削除されたサーバーを復元することはできません。

ライセンスとコストの最適化

Azure Database for PostgreSQL は、スケールアップまたはスケールダウンすることができます。コストを最小限に抑えながら、ニーズを確実に満たすために、サーバーとデータベースのパフォーマンスを監視することが重要です。
CPU とストレージの両方がコストに関連します。選択できる価格レベルはいくつかあります。データワークロードに適した価格プランが選択されていることを確認してください。
各読み取りレプリカは、選択されたコンピューティングとストレージに基づいて課金されます。

まとめ

この記事では、Contoso が PostgreSQL データベースを Azure Database for PostgreSQL インスタンスに移行しました。

PostgreSQL データベースを Azure に移行する

ビジネスドライバー

移行の目標