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

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

• アーキテクチャ: アーキテクチャをテストして、レプリケートされたリソースまたはステージングされたリソースで動作することを確認します。
• 管理ルーチン: 移行されたリソースの管理計画をテストして、それが機能していることを確認します。

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

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

テスト移行を実行

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

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

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

• フェールオーバーをテストする分離されたネットワーク。 ネットワーク構成を、可能な限り目的の移行ネットワーク構成と一致させます。

• ポイント対サイト VPN、ジャンプ ボックス、Azure Bastion など、ソースからの分離されたネットワーク アクセス。

• テスト環境に対して認証を行う認証メカニズム。 テスト環境は分離されているため、ランディング ゾーンの ID プロバイダーを使用することはできません。

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

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

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

テストの問題を修復する

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

• 修復計画に検出された問題を記録します。
• 重大度に基づいて問題をトリアージし、トリアージの一部として回避策を特定します。
• ドキュメントの回避策。 移行の一環として回避策を組み込むことができる場合は、問題を修復する必要がない場合があります。
• 回避策以外の項目から始めます。 最初に回避策なしで項目を修復することを検討してください。

テスト計画の例

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

次のステップ