オンプレミスの MySQL を Azure Database for MySQL に移行する: 評価

適用対象: Azure Database for MySQL - 単一サーバー Azure Database for MySQL - フレキシブル サーバー

前提条件

代表的なユース ケース

概要

MySQL ワークロードの移行に進む前に、多くのことについて評価を行う必要があります。 これには、データ、ホスティング環境、アプリケーションのワークロードを分析し、間もなく移行されるワークロードをホストするために Azure ランディング ゾーンの構成と準備が適切に行われていることを検証することが含まれます。

制限事項

Azure Database for MySQLは、サービスとしてのプラットフォームとして実行される MySQL コミュニティ エディションの完全にサポートされているバージョンです。 ただし、初期評価を行うときによく理解しておく必要のあるいくつかの制限があります。

最も重要なものは次のとおりです。

• InnoDB と Memory だけであるストレージ エンジンのサポート

• 制限されている Privilege のサポート (DBA、SUPER、DEFINER)

• 無効なデータ操作ステートメント (SELECT ... INTO OUTFILE、LOAD DATA INFILE)

• 大がかりな自動データベース移行 (5.6 から 5.7、5.7 から 8.0)

• MySQL Server User-Defined Function (UDF) を使用する場合、実行可能なホスティング オプションは Azure ホステッド VM のみです。so または dll コンポーネントを Azure Database for MySQL にアップロードする機能はありません。

その他の項目の多くは、運用データのワークロード ライフサイクル管理の一環として管理者が理解する必要がある運用に関する事柄です。 このガイドでは、このような運用に関する事柄の多くは、「移行後の管理」セクションで説明されています。

MySQL のバージョン

MySQL には、1995 年から始まる長い歴史があります。 それ以降、広く使用されるデータベース管理システムとして進化してきました。 Azure Database for MySQL は、MySQL バージョン 5.6 のサポートから開始し、5.7 を経て、最近は 8.0 になっています。 最新の Azure Database for MySQL バージョンのサポートについては、「サポートされている Azure Database for MySQL サーバー バージョン」を参照してください。「移行後の管理」セクションでは、アップグレード (5.7.20 から 5.7.21 など) が Azure の MySQL インスタンスにどのように適用されるのかを確認します。

移行元の MySQL のバージョンを知ることは不可欠です。 このシステムを使用するアプリケーションは、そのバージョンに固有のデータベース オブジェクトと機能を使用している可能性があります。 データベースを下位のバージョンに移行すると、互換性の問題が発生したり機能が失われたりする可能性があります。 また、新しいバージョンに移行する前に、データとアプリケーション インスタンスを十分にテストすることもお勧めします。導入された機能によって、アプリケーションが破損する可能性があります。

移行パスとバージョンに影響を与える可能性がある例を以下に示します。

• 5.6: ミリ秒を正しく格納するための TIMESTAMP 列と、フルテキスト検索

• 5.7: ネイティブ JSON データ型のサポート

• 8.0: NoSQL ドキュメント ストア、アトミック、クラッシュ セーフな DDL および JSON テーブル関数のサポート

  注意

  2021 年 2 月以降、MySQL 5.6 は一般的にサポートされなくなります。 MySQL ワークロードは、MySQL バージョン 5.7 以降に移行する必要があります。

MySQL サーバーのバージョンを確認するには:

SHOW VARIABLES LIKE "%version%";

データベース ストレージ エンジン

Azure Database for MySQL でサポートされているデータベース ストレージ エンジンは、InnoDB と Memory のみです。 MyISAM などの他のストレージ エンジンは、サポートされているストレージ エンジンに移行する必要があります。 MyISAM と InnoDB の違いは、運用機能とパフォーマンス出力です。 上位レベルのテーブルとスキーマの構造は通常、エンジンごとに変化しませんが、インデックスとテーブル列の型は、ストレージとパフォーマンス上の理由で変化する可能性があります。 InnoDB は大きなデータ ファイル サイズを持つことで知られていますが、これらのストレージの詳細は Azure Database for MySQL サービスによって管理されます。

MyISAM から InnoDB へ移行する

MyISAM のデータベースとテーブルは、InnoDB のテーブルに変換する必要があります。 変換後、アプリケーションで互換性とパフォーマンスをテストする必要があります。 テストするには、ほとんどの場合、DDL ステートメントを使用して、テーブルを再作成し、ターゲット ストレージ エンジンを変更する必要があります。 この変更は、Azure ターゲットでのスキーマ作成の間に行われるので、移行の間に実行する必要はほとんどありません。 詳細については、MySQL の Web サイトでテーブルの変換に関する開発者向けドキュメントを参照してください。

役に立つテーブル情報を見つけるには、次のクエリを使用します。

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

MyISAM から InnoDB にテーブルを変換するには、次のコマンドを実行します。

ALTER TABLE {table\_name} ENGINE=InnoDB;

代わりに、構造は同じでもストレージ エンジンが異なるテーブルを作成できます。 作成した後、新しいテーブルに行をコピーします。

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

データベースのデータとオブジェクト

データは、データベース移行の 1 つのコンポーネントです。 アプリケーションが確実に実行し続けるようにするには、データベース サポート オブジェクトを移行して検証する必要があります。

移行の前と後にインベントリを実行する必要がある項目の一覧を次に示します。

• テーブル (スキーマ)

• 主キー、外部キー

• Indexes

• 関数

• 手順

• トリガー

• ビュー

ユーザー定義関数

MySQL では、外部コードを呼び出す関数を使用できます。 残念ながら、外部コードでユーザー定義関数 (UDF) を使用するデータ ワークロードは、Azure Database for MySQL に移行できません。 これは、MySQL 関数のバックにある必要な so または dll のコードを、Azure サーバーにアップロードできないためです。

次のクエリを実行して、何らかの UDF がインストールされていないか検索します。

SELECT * FROM mysql.func;

移行元システム

移行の準備の量は、移行元システムとその場所によって異なる場合があります。 データベース オブジェクトに加えて、移行元システムから移行先システムにデータを取得する方法を検討します。 移行元と移行先の間にファイアウォールや他のネットワーク コンポーネントがある場合、データの移行が困難になる可能性があります。

さらに、インターネット経由でデータを移動すると、Azure への専用回線を使用するより遅くなる場合があります。 そのため、ギガバイト、テラバイト、ペタバイト単位のデータを大量に移動する場合は、移行元ネットワークと Azure ネットワークの間に ExpressRoute 接続を設定することを検討します。

ExpressRoute が既に存在する場合は、他のアプリケーションによって接続が使用されている可能性があります。 既存のルートで移行を実行すると、ネットワークのスループットに負荷がかかり、ネットワークを使用する移行と他のアプリケーションの両方で、パフォーマンスに大きく影響する可能性があります。

最後に、ディスク領域を評価する必要があります。 大きなデータベースをエクスポートするときは、データのサイズを考慮します。 ツールが実行されていて、最終的なエクスポートの場所であるシステムに、エクスポート操作を実行するのに十分なディスク領域があることを確認します。

クラウド プロバイダー

アマゾン ウェブ サービス (AWS) などのクラウド サービス プロバイダーからデータベースを移行するには、クラウドでホストされている MySQL インスタンスにアクセスするために、追加のネットワーク構成手順が必要になる場合があります。 Data Migration Services などの移行ツールは、外部の IP 範囲からのアクセス権を必要とし、そうでないとブロックされる可能性があります。

オンプレミス

クラウド プロバイダーと同様に、MySQL のデータ ワークロードがファイアウォールまたは他のネットワーク セキュリティ層の内側にある場合は、オンプレミスのインスタンスと Azure Database for MySQL の間にパスを作成する必要があります。

ツール

多くのツールと方法を使用して、MySQL のデータ ワークロードと環境を評価できます。 ツールごとに、提供されている評価と移行の機能のセットが異なります。 このガイドでは、MySQL のデータ ワークロードの評価に最もよく使用されるツールを確認します。

Azure Migrate

Azure Migrate では MySQL データベース ワークロードの直接的な移行はサポートされていませんが、仮想マシンまたはハードウェア ベースのコンピューターのどちらでホストされている場合でも、どのようなユーザーやアプリケーションがデータを使用しているのか管理者がわからない場合に使用できます。 依存関係の分析は、MySQL ワークロードがホストされているマシンに監視エージェントをインストールして実行することで実現できます。 エージェントにより、設定した期間 (1 か月など) についての情報が収集されます。 依存関係データを分析し、データベースに対して行われている不明な接続を見つけることができます。 接続データは、保留中の移行を通知する必要があるアプリケーションの所有者を特定するのに役立つことがあります。

アプリケーションとユーザー接続データの依存関係分析に加えて、Azure Migrate を使用すると、Hyper-V、VMware、または物理サーバーを分析し、適切な移行先環境を提案するのに役立つデータベース ワークロードの使用パターンを提供することもできます。

Linux 用 Telgraf

Linux ワークロードでは、Microsoft Monitoring Agent (MMA) を利用して、仮想マシンと物理コンピューター上のデータを収集できます。 さらに、Telegraf エージェントとその広範なプラグインを使用して、パフォーマンス メトリックを収集することを検討します。

サービス階層

移行ユーザーは、評価情報 (CPU、メモリ、ストレージなど) を入手した後、使用を開始する Azure Database for MySQL の価格レベルを決定します。

現在は、次の 3 つのレベルがあります。

• Basic: 低負荷なコンピューティングと I/O パフォーマンスを必要とするワークロード。

• General Purpose: バランスのとれたコンピューティングおよびメモリとスケーラブルな I/O スループットが必要なほとんどのビジネス ワークロード。

• メモリ最適化: トランザクション処理時間の短縮とコンカレンシーの向上のためにインメモリ パフォーマンスが必要なハイパフォーマンス データベース ワークロード。

レベルの決定は、データ ワークロードの RTO と RPO の要件によって影響を受ける可能性があります。 データ ワークロードで 4 TB を超えるストレージが必要な場合は、追加の手順が必要です。 最大 16 TB のストレージをサポートするリージョンを確認して選択します。

通常、意思決定を行うときは、ストレージと IOPS (1 秒あたりの入力/出力操作数) のニーズに注目します。 したがって、移行先システムには、常に、少なくとも移行元システムと同量のストレージが必要です。 さらに、IOPS の割り当ては 3/GB なので、IOPS のニーズを最終的なストレージ サイズに合わせることが重要です。

コスト

WWI MySQL データ ワークロード全体を評価した後、WWI は少なくとも 4 つの仮想コアと 20 GB のメモリ、および IOP 容量 450 IOPS を備えた 100 GB 以上のストレージ スペースが必要であると判断しました。 450 IOPS の要件と、Azure Database for MySQL の IOPS 割り当て方法により、150 GB 以上のストレージを割り当てる必要があります。また、バックアップ ストレージと 1 つの読み取りレプリカとして、プロビジョニングされたサーバー ストレージの少なくとも 100% が必要です。 5 GB を超える送信エグレスは想定されていません。

Azure Database for MySQL 料金計算ツールを使用することで、WWI は Azure Database for MySQL インスタンスのコストを判断できました。 2020 年 9 月現在の WWI Conference データベースの総保有コスト (TCO) を次の表に示します。

初期コストを確認した後、WWI の CIO は、3 年よりはるかに長い期間 Azure を使用することを確認しました。 年間で最大 4,000 ドルをさらに節約するため、3 年間の予約インスタンスを使用することを決定しました。

上の表に示すように、総保有コスト (TCO) ではバックアップ、ネットワーク エグレス、読み取りレプリカを考慮する必要があります。 追加されるデータベースが多いほど、ストレージと生成されるネットワーク トラフィックだけが、考慮すべき追加のコストベースの要因になります。

アプリケーションへの影響

Azure Database for MySQL に移行する場合、Secure Sockets Layer (SSL) ベースの通信への変換は、アプリケーションにとって最も重要な変更の 1 つになる可能性があります。 Azure Database for MySQL では SSL は既定で有効になり、オンプレミスのアプリケーションとデータ ワークロードは、SSL を使用して MySQL に接続するように設定されていない可能性があります。 SSL を有効にして使用すると余分な処理オーバーヘッドが増加するので、監視する必要があります。

この強力な認証パスをサポートするようにアプリケーションを再構成するには、「Azure Database for MySQL に安全に接続するためにアプリケーションで SSL 接続を構成する」のアクティビティに従います。

最後に、アプリケーションの接続文字列でサーバー名を変更するか、新しい Azure Database for MySQL サーバーを指すように DNS を切り替えます。

WWI のシナリオ

WWI は、次の表に示すように、MySQL のデータ資産に関する情報を収集することで評価を開始しました。

各データベース所有者は、許容されるダウンタイム期間の決定を求められました。 許容されるデータベースのダウンタイムに基づいて、計画と、移行方法の選択が行われました。

最初のフェーズでは、WWI は ConferenceDB データベースのみに焦点を当てました。 チームには、進められるデータ ワークロードの移行に役立つ移行の経験が必要でした。 ConferenceDB データベースが選択されたのは、データベースの構造が単純で、許容されるダウンタイムが大きいためです。 そのデータベースを移行した後、チームは、セキュリティで保護された Azure ランディング ゾーンへのアプリケーションの移行に注目しました。

評価チェックリスト

• 移行先システムでワークロードが正常に実行されることをテストします。

• 移行のための適切なネットワーク コンポーネントがあることを確認します。

• データ ワークロードのリソース要件を把握します。

• 総コストを見積もります。

• ダウンタイムの要件を把握します。

• アプリケーションの変更に対応します。

次のステップ