アプリケーションの移行
オンプレミスから 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 portal のサービスの [接続文字列] ページで、Azure Database for PostgreSQL サービスの接続情報が見つかります。 Azure では、多くの一般的なプログラミング言語とフレームワークに関する情報を提供しています。
ネットワーク ポートを開く
このモジュールのレッスン 1 で説明したように、Azure Database for PostgreSQL は、ファイアウォールの内側で実行される保護されたサービスです。 クライアントの接続は、その IP アドレスがサービスによって認識されていない限りできません。 データベースに接続する必要があるアプリケーションを実行しているクライアントに対して、IP アドレスまたはアドレス ブロックの範囲を追加する必要があります。
アプリケーションのテストと検証
アプリケーションとユーザーを新しいデータベースに切り替える前に、すべてが正しく構成されていることを確認することが重要です。
アプリケーションの "リハーサル" から開始し、各ロールを接続して、正しい機能が使用可能であることを確認します。
次に、"ソークテスト" を実行して、特定の期間にわたって代表的なワークロードを実行する典型的なユーザー数を模倣します。 システムを監視し、Azure Database for PostgreSQL サービスに十分なリソースが割り当てられていることを確認します。
この時点で、ユーザーへのシステムのロールアウトを開始できます。 ごく一部のユーザーを予告なしに転送する、何らかの形式の "カナリアテスト" を実装すると便利な場合があります。 これにより、新しいデータベースに対するユーザーの体験が、以前と同じ、より優れている、またはより悪いかどうかに関するバイアスのない意見が得られます。