Azure で移行デプロイをテストする

ワークロードをレプリケートまたはステージングし、サポートサービスが使用可能であることを確認したら、移行テストを開始できます。移行テストでは、主に次の 2 つの領域に重点を置いています。

ビジネステストとは異なり、移行テストは IT アクティビティに重点を置いています。

問題を特定する際に、修復計画に問題を追加できます。すべての問題に対処したら、ワークロードのリリースに進むことができます。

テスト移行を実行

リソースをレプリケートした後、分離された環境でテスト移行を実行して、運用環境のワークロードに影響を与えないようにすることができます。

テスト移行はツールによって異なりますが、通常は、ライブシステムと並列に実行されるソースシステムのレプリカを作成します。これらのセカンダリシステムでテストを実行します。テストを完了すると、永続的な変更を加えることなく、レプリケートされたリソースをクリーンアップできます。

テストを実行するには、次のものが必要です。

フェールオーバーをテストする分離されたネットワーク。ネットワーク構成を、可能な限り目的の移行ネットワーク構成と一致させます。
ポイント対サイト VPN、ジャンプボックス、Azure Bastion など、ソースからの分離されたネットワークアクセス。
テスト環境に対して認証を行う認証メカニズム。テスト環境は分離されているため、ランディングゾーンの ID プロバイダーを使用することはできません。

テスト移行リソースを使用してテスト環境にデプロイするテスト移行ドメインコントローラーを使用できます。テスト後、リソースを使用してドメインコントローラーをクリーンアップします。

または、分離されたネットワークにテストドメインコントローラーが含まれる場合もあります。ネットワークをピアリングして、Active Directory トラフィックのレプリケーションを許可します。 Azure でドメインコントローラーのスナップショットを取得し、テスト目的でピアを削除してネットワークを分離できます。必要な役割を強制し、テストを完了したときに状態を復元して、ライブ ID プロバイダーに変更を加えないようにすることができます。

移行ツールには、テスト移行を実行し、テスト計画を実行した後にクリーンアップする手順が必要です。

ヒント

このテスト環境をビジネステストに使用することもできます。

テストを行った後、次のことを確認します。

移行プロジェクトのテスト計画出力の基本的な例を次に示します。

テスト	成功/失敗	Note
仮想マシンのデプロイ	✅
管理者は仮想マシンにログインできます	✅
インターネットインフォメーションサービス (IIS) Web サービスが開始します	✅
サービス 1 を開始します	✅
サービス 2 を開始します	❌	サービスを手動で開始する必要があります
Web サイトアクセス	✅
SQL サービスを開始します	✅
データベースアクセス	✅
Web サイト間の負荷分散が機能します	✅
Azure Application Gateway からのイングレスが機能します	❌	Application Gateway に証明書の問題があります
テストトランザクションの合計時間が 5 ミリ秒未満でした	✅