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 ミリ秒未満でした | ✅ |