移行のフェーズと考慮事項

8 分

移行が成功すると、いくつかのフェーズで考慮事項のバランスが取られます。

移行フェーズ

移行は複数のフェーズで行われます。まず、移行スコープを計画します。データベースリソースの検出と評価、ダウンタイムなどのビジネス要件、移行が失敗した場合のフォールバック計画を行います。次に、適切なリソースをプロビジョニングし、ソース環境とターゲット環境間の接続を設定して、移行を準備します。移行アプローチが設定され、リソースの準備ができたら、通常はステージング環境でドライランを実行して、運用環境への移行前に問題を特定します。最後に、最終的な移行を実行し、進行状況を確認しながら、正常に完了したかどうかを検証します。

このモジュールでは、準備 (2) フェーズと最終的な移行 (4、5) フェーズに焦点を当てます。

移行に関する注意事項

アプリケーションのダウンタイム、バージョンの互換性、ネットワークとセキュリティ、パフォーマンス、コスト、ビジネス継続性の要件を評価する必要があります。

アプリケーションダウンタイム

最初に考慮すべき点の 1 つは、ビジネスシナリオでどれだけのダウンタイムを許容できるかということです。その答えは、使用可能な移行オプションを強く制限します。

望ましいダウンタイムは、ユーザーが気付かない程度のダウンタイムです。実際には、移行は複雑な手順であり、このモジュールで扱う考慮事項をどのように決定するかに応じて、必要なダウンタイムが決まります。トレードオフには、可用性と移行のコストやリスクが含まれます。ダウンタイムを数分または数秒に短縮することには複雑さが伴うため、前提条件をテストし、どれほどの移行ダウンタイムを許容できるか判断することは重要です。

オフライン移行

オフラインの移行では、アプリケーションをシャットダウンしてデータベースを移動する必要があります。これにより、移行中にデータに変更が加えられることはありません。ただし、この方法では、データエクスポートを完了するためにデータベースを停止する必要があります。少なくとも、データの転送にかかる時間だけダウンタイムが長くなります。オフライン移行には、以下が含まれます。

ソースデータベースからすべてのアプリを切断する。
ソースデータベースの内容をエクスポートする。
ソースデータをターゲットデータベースにインポートする。
インポートが完了した後で、アプリケーションをターゲットデータベースに再接続する。

一部のアプリケーションでは、トラフィックが少ない時間帯に予定メンテナンス期間がスケジュールされています。そのような時間が、オフライン移行を実行するのに最適なタイミングです。

増分オフライン移行では、アプリケーションをオフラインにする前に、データの大部分を移動することでダウンタイムが短縮されます。まず、データベースの完全バックアップを以降します。次に、前回の移行以降に発生した変更をデータベースに移行します。これらの新しい変更の移行に必要な時間が許容されるダウンタイム内に収まる場合は、アプリケーションをオフラインにしてデータが変更されないようにして、移行を完了します。特に、長期間のデータを持つデータベースの場合、1 回の増分移行で、ダウンタイムを 1 桁以上短縮できる場合があります。大規模で稼働率の高いデータベースの場合、許容できるダウンタイムを達成するために、複数回に分けて増分移行しなければならないこともあります。

オンライン移行

オンライン移行では、移行中にソースサーバーからターゲットサーバーに変更をレプリケートし、レプリケーションが完全に同期されたときにターゲットサーバーに切り替えることで、ダウンタイムの必要性を大幅に削減または排除できます。

ダウンタイムが望ましくない、または許容できない長さになる可能性もあります。この場合、アプリケーションをオフにしてデータベースの状態を "固定" することはできません。代わりに、通常通り稼働しながら、ソースデータベースがターゲットデータベースにレプリケートされます。ターゲットとソースの内容が完全に一致すると、アプリケーションはターゲットデータベースでの稼働を開始します。

オンライン移行では、次のことが必要です。

ソースデータベースのターゲットデータベースへのレプリケートを開始します。
ターゲットデータベースが追い付いたら、アプリケーションを一時停止するか、読み取り専用モードを有効にして強制的に書き込みを失敗させることで、ソースデータベースを固定します。
ターゲットデータベースに変更が 100% 反映されたら、ターゲットのレプリケーションをオフにします。
すべてのクライアントをターゲットデータベースにリダイレクトし、稼働を再開します。
レガシソースデータベースをシャットダウンします。

オンラインとオフラインの移行を比較する

オフライン移行にはダウンタイムが必要ですが、前述の増分移行手法を使用すると、ダウンタイムが大幅に短縮されます。複数回に増分を分けると、最終的な移行を 1 日分のデータまたはそれ以下に縮小できます。 Azure DMS などの自動化されたサービスは、一連の小規模な移行を実行することでダウンタイムを最小限に抑えます。ネットワーク設定によって自動化が妨げられる場合は、オフラインの増分移行を手動で実行することもできます。

オンライン移行では、データベースチームとアプリケーションチームの間で調整を図り、細心の注意を払って作業します。クライアントアプリケーションは、移行中のデータ損失を回避するために、書き込みエラーが発生した場合に、適切に対応するツールを備えておく必要があります。クライアントは、ユーザーエクスペリエンスを中断することなく、新しいデータベースサーバーへの接続もサポートする必要があります。このようなアプリケーションツールがない場合は、ビルドに非常にコストがかかる可能性があります。

バージョン互換性

ほとんどのアプリケーション操作は、MySQL のアップグレードと互換性があります。ただし場合によっては、アプリケーションコンポーネントまたはデータベースの使用が特定の MySQL バージョンでのみ機能する場合があります。

すべてのアプリケーションコンポーネントがターゲットデータベースのバージョンと互換性があることをご確認ください。データベースを再配置または再構成する移行から、バージョンアップグレードを分けて実行ることを検討してください。たとえば、オンプレミスの MySQL 5.7 から、MySQL 8.0 を実行する Azure Database for MySQL フレキシブルサーバーに移行する場合は、オンプレミスから MySQL 5.7 を実行する Azure Database for MySQL フレキシブルサーバーに移行してから、5.7 から 8.0 にインプレースでアップグレードすることを検討してください。

ネットワークとセキュリティ

データベースの移行では、ソースデータベースからターゲットにデータを転送する必要があります。これがどのように、どのくらいの速さで行われるかは、2 つのネットワーク間の接続に大きく依存します。ソースからターゲットへのライブ接続を確立できない場合は、物理データファイルを別の方法 (中間ワークステーションまたはサーバー経由など) で転送する必要があります。その場合は、プロセスの各段階でスナップショットを保存するために十分なディスク容量が各システムにあることをご確認ください。

また、移行中にセキュリティ要件を考慮することも重要です。ソースデータベースとターゲットデータベースに対する適切な認証とアクセス許可が必要です。移行手順の一部またはすべてを実行するサービスアカウントを作成し、完了時にアクセス権を削除することもできます。

ソースデータベースがオンプレミスであるか、別のクラウドプロバイダーにあるかにかかわらず、通常、ネットワーク設定では外部接続は許可されません。 Azure との接続を許可するようにネットワークを構成する必要があります。

ソースデータベースがオンプレミスにあり、またデータボリュームが大きい場合、通常のインターネット接続を介してテラバイト単位のデータを移動すると、実用的ではないほど遅くなる可能性があります。このシナリオでは、ネットワークと Azure の間で Azure ExpressRoute 接続を設定することを検討してください。

ExpressRoute を使用している場合でも、その接続が他のトラフィックも処理し、両者が相互に干渉する可能性があります。競合の程度によっては、既存のアプリケーションと移行プロセスへのパフォーマンスの影響が大きくなる可能性があります。

パフォーマンス

データベースの移行は、インフラストラクチャのサイズを変更することで、容量を増やす優れた機会となります。データベースの使用状況によっては、CPU、RAM、または I/O リソースを増やすことでメリットが得られる可能性があります。

ターゲットサーバーをプロビジョニングする前に、現在のデータベースの使用状況を考慮してください。 CPU 使用率などのパフォーマンス指標を監視し、将来の成長予測や SLA と合わせて、より大きなコンピューティングサイズを割り当てる必要があるかどうかを判断します。逆に、容量が割り当て超過しており、ダウンサイズによってコストを削減できることに気付くこともあるかもしれません。

コスト

Azure に移行すると、透過的な価格を利用できます。 Azure 料金計算ツールで選択した SKU とその他のパラメーター (冗長性や高可用性など) を使用することで、計画中に移行後のコストを見積もることができます。また、計算機を使用して、可用性とコストなどのトレードオフを通知することもできます。

ビジネス継続性

データベースの移行は、ビジネス継続性の指標と目標を見直すのに適したタイミングです。バックアップ保持ポリシーを変更するか、地理的冗長バックアップまたは高可用性に切り替えることが適切な場合があります。過去のアップタイムと SLA、および障害復旧時間を考慮してください。移行では、物理データファイルから新しいデータベースを立ち上げる実際の例も提供され、ディザスターリカバリー計画を立てるのに役立ちます。