アプリケーションの移行

完了

オンプレミスから Azure にデータベースを移行したら、既存のアプリケーションを更新して、新しい場所の PostgreSQL にアクセスできるようにする必要があります。

元のオンプレミスのサーバーとデータベースには、ユーザーに関連付けられた特権、実行できる操作、およびこれらの操作を実行する対象のオブジェクトを定義するロールが含まれます。 Azure Database for PostgreSQL では、オンプレミスで実行されている PostgreSQL と同じ認証および承認メカニズムが使用されます。

このユニットでは、新しく移行した Azure Database for PostgreSQL に接続するためにアプリケーションに対して行う必要がある更新プログラムについて説明します。

ユーザー ロールを手動で作成する

Azure Database Migration Service を使用して PostgreSQL データベースを Azure Database for PostgreSQL に転送する場合、ロールとロールの割り当てはコピーされません。 ターゲット データベース内のテーブルの管理者とユーザーに必要なロールとユーザー アカウントを手動で再作成する必要があります。 これらのタスクを実行するには、psql または pgAdmin ユーティリティを使用します。 CREATE ROLE コマンドを実行します。 GRANT コマンドを使用して、必要な特権をロールに割り当てます。 例えば次が挙げられます。

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

注

また、bash プロンプトから createuser コマンドを使用して PostgreSQL ロールを作成します。

オンプレミス データベース内の既存のロールを表示するには、次の SQL ステートメントを実行します。

SELECT rolname
FROM pg_roles;

psql ユーティリティの \du コマンドを使用して、ロールに割り当てられている特権を表示できます。

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

注

Azure Database for PostgreSQL では、独自のロールがいくつか追加されることに注意してください。 これらのロールには、サービスの作成時に指定した azure_pg_admin、 azure_superuser、および管理者ユーザーが含まれます。 管理者アカウントを使用してサインインしますが、他の 2 つのロールは Azure で使用するために予約されています。使用しないでください。

アプリケーションを再構成する

Azure Database for PostgreSQL に接続するようにアプリケーションを再構成するのは簡単なプロセスです。 ただし、移行アプリケーションの戦略を決定する方が重要です。

PostgreSQL アプリケーションを再構成するときの考慮事項

企業環境では、同じ PostgreSQL データベースに対して多数のアプリケーションが実行されている可能性があります。 多くのユーザーがこれらのアプリケーションを実行している可能性があります。 既存のシステムから Azure Database for PostgreSQL に切り替えると、システムは引き続き動作し、ユーザーはジョブを続行でき、ビジネスクリティカルな操作は引き続き動作します。 モジュール 1、レッスン 2、 移行に関する考慮事項では、一般的な用語で多くの問題について説明しました。 PostgreSQL データベースを Azure に移行する場合は、次の点に注意する必要があります。

• オフライン移行を実行している場合、元の PostgreSQL データベース内のデータと Azure で実行されている新しいデータベースは、古いデータベースがまだ使用されている場合、すぐに分岐し始めることができます。 オフライン移行は、しばらくの間、システムを完全に操作から外し、再び起動する前にすべてのアプリケーションを新しいシステムに切り替える場合に適しています。 この方法は、ビジネス クリティカルなシステムでは不可能な場合があります。 Azure 仮想マシンで実行されている PostgreSQL に移行する場合は、オンプレミス システムと Azure で実行されている PostgreSQL の間のレプリケーションを構成します。 ネイティブ PostgreSQL レプリケーションは一方向でのみ動作しますが、PostgreSQL サーバー間の双方向レプリケーションをサポートするサード パーティのソリューションを使用できます (これらのソリューションは Azure Database for PostgreSQL では機能しません)。
• オンライン移行を実行している場合、Azure Database for PostgreSQL サービスは、オンプレミス データベースから Azure で実行されているデータベースへのレプリケーションを設定します。 初期データ転送後、レプリケーションによって、オンプレミス データベースで行われたすべての変更が Azure のデータベースにコピーされるようになりますが、その逆は実行されません。

どちらの場合も、誤って上書きすることによってライブ データが失われないようにする必要があります。 たとえば、オンライン シナリオでは、Azure Database for PostgreSQL で実行されているデータベースに接続されているアプリケーションで、オンプレミス データベースを使用しているアプリケーションによって変更が盲目的に上書きされる可能性があります。 これを念頭に置いて、次のアプローチを検討する必要があります。

• ワークロードの種類に基づいてアプリケーションを移行する。 読み取り専用のデータにアクセスするアプリケーションは、Azure Database for PostgreSQL で実行されているデータベースに安全に移動でき、オンプレミス データベースを使用しているアプリケーションによって行われたすべての変更が表示されます。 読み取り専用アプリケーションが最新のデータを必要としない場合は、逆方向の方法を採用することもできます。
• ワークロードの種類に基づいてユーザーを移行する。 この方法は、前の方法と似ていますが、レポートのみを生成するユーザーがいて、他のユーザーがデータを変更する場合がある点が異なります。 同じアプリケーションが、ユーザーの要件に従って適切なデータベースに接続するように構成されている場合があります。
• 使用するデータセットに基づいてアプリケーションを移行する。 異なるアプリケーションがデータの異なるサブセットを利用する場合は、これらのアプリケーションを互いに独立して移行できる可能性があります。

アプリケーションを再構成する

アプリケーションを再構成するために、アプリケーションが新しいデータベースを指すように設定します。 ほとんどの適切に記述されたアプリケーションは接続ロジックを分離します。これは、変更を必要とするコードの唯一の部分である必要があります。 多くの場合、接続情報は構成情報として格納される可能性があります。その情報を更新するだけで済みます。

Azure Database for PostgreSQL サービスの接続情報は、Azure portal のサービスの [接続文字列 ] ページにあります。 Azure では、多くの一般的なプログラミング言語とフレームワークに関する情報を提供しています。

ネットワーク ポートを開く

このモジュールのレッスン 1 で説明したように、Azure Database for PostgreSQL は、ファイアウォールの背後で実行される保護されたサービスです。 クライアントは、その IP アドレスがサービスによって認識されない限り接続できません。 データベースに接続する必要があるアプリケーションを実行しているクライアントに対して、IP アドレスまたはアドレス ブロックの範囲を追加する必要があります。

アプリケーションをテストおよび検証する

アプリケーションとユーザーを新しいデータベースに切り替える前に、すべてが正しく構成されていることを確認することが重要です。

"ドライラン" アプリケーションから開始し、各ロールを接続して、適切な機能が使用可能であることを確認します。

次に、"ソーク テスト" を実行して、代表的なワークロードを一定期間同時に実行している一般的なユーザー数を模倣します。 システムを監視し、Azure Database for PostgreSQL サービスに十分なリソースが割り当てられていることを確認します。

この時点で、システムのユーザーへのロールアウトを開始できます。 ユーザーの小さなサブセットを予告なしに転送する、なんらかの形式の "カナリア テスト" を実装すると便利な場合があります。 これにより、新しいデータベースに対するユーザーの体験が、以前と同じ、より優れている、またはより悪いかどうかに関するバイアスのない意見が得られます。