アプリケーションの移行

  • 6 分

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

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

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

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

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

Azure Database Migration Service を使用して MySQL データベースを Azure Database for MySQL に転送する場合、ユーザーはコピーされません。 ターゲット データベースのテーブルの管理者とユーザーに必要なユーザー アカウントを手動で作成し直す必要があります。 これらのタスクを実行するには、SQL 言語または MySQL Workbench などのユーティリティを使用します。 CREATE USER コマンドを実行します。 GRANT コマンドを使用して、必要な特権をユーザーに割り当てます。 次に例を示します。

CREATE USER 'myuseraccount'@'%' IDENTIFIED BY 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE [Database Name].* TO myuseraccount;
FLUSH PRIVILEGES;

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

USE [Database Name];

SHOW GRANTS FOR 'myuseraccount'@'%';;

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

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

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

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

MySQL データベースを Azure に移行する際には、考慮する必要があるいくつかの詳細があります。

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

どちらの場合も、誤って上書きすることによってライブ データが失われないようにする必要があります。 たとえば、オンライン シナリオでは、Azure Database for MySQL で実行されているデータベースに接続されているアプリケーションによる変更が、依然としてオンプレミス データベースを使用しているアプリケーションによって無条件に上書きされる場合があります。 したがって、次の方法を検討する必要があります。

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

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

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

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

Image showing the Connection strings page for Azure Database for MySQL item in the Azure portal

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

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

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

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

アプリケーションの "リハーサル" から開始し、各ロールとして接続して、正しい機能が使用可能であることを確認します。

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

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