クラウド ワークロードを別のリージョンに移行する
再配置の移行ステップでは、ワークロードを新しいリージョンに移動します。 ワークロードによっては、準備する技術面の要件がいくつかある場合がありますが、ワークロードの再配置戦略は明確にする必要があります。 再配置を実行する準備をしておく必要があります。
準備
ワークロードを再配置する前に、ターゲット リージョンを準備する必要があります。 必要に応じて、次の手順に従って、再配置前にワークロード環境を準備します。 これにより、リージョン ハブや(必要に応じて)クロスプレミス接続などのコア リージョン ネットワークを確実に構築できます。
ランディング ゾーンを確立します。 移動を計画するとき、Azure ランディング ゾーンのスコープを拡大するかどうかを評価します。 拡張が必要な場合、基本的な手順として Azure ランディング ゾーンのガイダンスを参照してください。 この手順により、アプローチが定着されているベスト プラクティスと一致することを保証します。 詳細については、「既存の Azure ランディング ゾーンに新しいリージョンの追加」を参照してください。 新しいランディング ゾーンを設定する際に重要な考慮事項は次のとおりです。
- ネットワーク: 新しいリージョンのランディング ゾーンのネットワーク構造、ルーティング パス、接続要件を評価します。
- 統合: 新しいランディング ゾーンをソース リージョンのランディング ゾーンと統合する必要があるかどうかを判断します。
- リソースの選択的な再配置: すべてのリソースが新しいリージョンに移動するかどうかを決定します。 一部のリソースが元の場所に残る場合、持続可能なリージョン間ネットワーク トポロジを計画し、これらの分散リソースを効果的に管理します。
必要な場合にのみ、新しいサブスクリプションを作成します。 関連するサービスとリソースを再構築する必要がある場合にのみ、新しいサブスクリプションを作成します。 新しいサブスクリプションを作成すると複雑さが増すため、できる限りワークロードを既存のサブスクリプションに維持してください。 サブスクリプションは、予算、ポリシー、ロールベースのアクセス制御 (RBAC) の境界として機能します。 新しいサブスクリプションの場合は、予算、ポリシー、RBAC を検証する必要があります。 サブスクリプション内のすべてのリソースを移動しない場合は、リソースのより小さなグループ化と一致するように ID とセキュリティのポリシーのスコープを再設定する必要があります。 新しいサブスクリプションを作成するには、ターゲット サブスクリプションに必要な Azure ポリシーと RBAC ロールを作成、スコープ設定、実装する必要があります。 目標は、ガバナンスとセキュリティ態勢を維持することです。
必要に応じて、新しいドメイン名を構成します。 ワークロードのカスタム ドメインに変更がある場合は、新しいドメイン名を構成する必要があります。 新しいホスト名を作成し、アプリケーションまたはサービスに割り当ててから、名前解決を検証します。 また、有効期間 (TTL) を下げて構成し、自動有効期限の一括移行ステージに設定することも計画できます。 詳細については、カスタム ドメインの追加と App Service プランへの DNS 名のマップに関するページを参照してください。
必要に応じて、新しい SSL/TLS 証明書を作成します。 新しいドメイン名に対して新しい SSL/TLS 証明書 (X.509) を作成する必要があります。 これらの証明書を使用すると、公開秘密キーの暗号化とセキュリティで保護されたネットワーク通信 (HTTPS) が有効になります。 Azure Key Vault を使用して、X.509 証明書を作成またはインポートします。 詳細については、Azure Key Vault 証明書に関するページと「証明書の作成方法」を参照してください
Azure Key Vault を再配置します。 ワークロードを移動する前に、Azure Key Vault を再配置する必要があります。 アプリケーション環境ごとに 1 つのキー コンテナーが必要です。また、機密性を確保するために、キー コンテナーではリージョンを超えてシークレットを共有しないでください。 このガイダンスに合わせて、新しいターゲット リージョンに新しいキー コンテナーを作成する必要がある場合があります。
新しい Log Analytics ワークスペースを作成します。 リージョンごとに個別の Log Analytics ワークスペースが必要です。 ターゲット リージョンで新しいワークスペースを作成します。 Log Analytics ワークスペースを別のリージョンに移動できないため、ターゲット リージョンに新しい Log Analytics ワークスペースを作成する必要があります。 元のワークスペースでデータを保持するために 2 つのオプションがあります。 データが不要になるまで現在のワークスペースを保持し、データを読み取り専用として扱うことができます。 新しいターゲットの Azure リージョンのストレージ アカウントにワークスペース データをエクスポートすることもできます。
サービスを移行する
ワークロード内のサービスの移行を開始できます。 実行については、選択した再配置の自動化について利用可能なガイダンスに従ってください。 Azure Resource Mover と Azure Site Recovery には、サービスを再配置するためのステップ バイ ステップのチュートリアルがあります。 詳細については、以下を参照してください:
移動できないリソースにコードとしてのインフラストラクチャ テンプレートまたはスクリプトを作成できます。 Azure portal で手動で展開を実行することもできます。 具体的な手順は、使用する Azure サービスとその構成によって異なります。 詳細については、コードとしてのインフラストラクチャの概要に関するページを参照してください。
データの移行
このステージは、ワークロードでデータ移行が必要な場合にのみ関連します。 選択した自動化を使用してデータ移行を実行します。 ターゲット リージョンのワークロードへの一括移行の前に、関連データがソース リージョンと同期されていることを確認する必要があります。 データの整合性は、注意が必要な重要な側面です。 ワークロード データを移行するためのガイダンスは次のとおりです。
ソース リージョン データを移行します。 ソース リージョン データを移行する方法は、ワークロード サービスの再配置方法に従う必要があります。 ホット、コールド、ウォームの方法はそれぞれ、ソース リージョン内のデータを管理するためのプロセスが異なります。
データを同期します。 同期手法は、ワークロードのアーキテクチャとアプリケーションの要求によって異なります。 たとえば、オンデマンド同期では、データに初めてアクセスしたときに変更がプルされます。 変更のプルとマージは、最後と現在のアプリケーション アクセスの間に違いがある場合にのみ発生します。
同期の競合を解決します。 ソースとターゲットの場所のデータが同期されていることを確認し、データの競合があれば解決します。 ユーザーが使用可能なデータにのみアクセスするようにする必要があります。 たとえば、Azure Cosmos DB を使用すると、同時書き込みをシリアル化して、データの一貫性を確保できます。
接続文字列を更新する
接続文字列の構成は、アプリケーションが接続するサービスによって異なります。 Microsoft のドキュメント ページで "接続文字列" を検索して、サービス固有のガイダンスを見つけ、そのガイダンスを使用して接続文字列を更新できます。 詳細については、技術ドキュメントを参照してください。
マネージド ID
システム割り当てマネージド ID には、Azure リソースにバインドされたライフサイクルがあります。 そのため、Azure リソースの再配置戦略によって、システム割り当てマネージド ID の処理方法が決まります。 リソースの新しいインスタンスがターゲットに作成された場合は、新しいシステム割り当てマネージド ID に、ソース リージョンのシステム割り当てマネージド ID と同じアクセス許可を付与する必要があります。
一方、ユーザー割り当てマネージド ID には独立したライフサイクルがあり、ユーザー割り当てマネージド ID をターゲット リージョンの新しいリソースにマップできます。 詳細については、マネージド ID の概要に関するページを参照してください。
次のステップ
ワークロード サービスとデータを移行しました。 次は、一括移行を使用して再配置を完了する必要があります。