クラウド ワークロードの再配置戦略を選択する
ワークロードを別のリージョンに移行する前に、再配置戦略を計画する必要があります。 この戦略には、再配置方法、サービス再配置の自動化、データ再配置の自動化が含まれます。 この記事では、各戦略コンポーネントのオプションを示し、決定に向けてガイドします。 最終的にどの選択を行うかは、サービスとワークロードの重要度によって異なります。
再配置方法を選択する
ワークロードの再配置には、主に 3 つの方法があります。 選択する再配置方法は、ワークロード内のサービスと、重要なビジネス機能にとってワークロードがどれほど重要かによって異なります。 稼働環境と非稼働環境に異なる再配置方法を検討できます。 コールド再配置は必須ではないワークロード向けです。 ホットとウォーム再配置はミッション クリティカル向けです。 再配置方法の選択は、ワークロードの再配置に使用するサービスおよびデータ再配置ツールに影響します。 次の再配置デシジョン ツリーを使用して、適切な再配置方法の一般的な概念を把握して、3 つの再配置方法の概要を読んでご自分の決定を検証してください。
コールド再配置
コールド再配置は、ダウンタイムに耐えられるワークロード向けです。 再配置中に環境を複製しないため、これは再配置に対する最もコスト効率の高いアプローチです。 次にコールド再配置プロセスの概要を示します。
- ワークロード データを新しいターゲット リージョンにバックアップします。
- ソース リージョンをオフラインにして、サービスをシャットダウンします。
- クラウド サービスを新しいターゲット リージョンにデプロイします。
- ワークロード データを復元します。
サービスの数とデータの量によっては、コールド再配置には数分から数日かかる場合があります。
ホット再配置
ホット再配置方法は、ダウンタイムを最小限 (秒、分) からゼロにする必要があるワークロード用です。 クリティカルなワークロードの場合は、ウォーム アプローチを試す前に、サービスがホット再配置をサポートしているかどうかを確認する必要があります。 ホット再配置は、一括移行後のデータ差分を最小限に抑えるのに役立ちます。 ホット再配置は、サービスで同期データ レプリケーションがサポートされている場合にのみ可能です。 一部のサービスにはこの機能がないため、代わりにウォーム再配置のアプローチを使用する必要があります。 ホット再配置プロセスを次に示します。
- 新しいターゲット リージョンでサービス レプリケーションを実行します。
- ソース リージョンでワークロードを実行したままにします。
- 同期データ レプリケーションを開始します。
- データが同期されたら、エンドポイントをアクティブにして検証します。
- データ同期を停止します。
- ソース リージョンでサービスをシャットダウンします。
ウォーム再配置
ウォーム再配置は、ホット再配置をサポートしていないクリティカルなワークロード用です。 ウォーム再配置では、非同期データ レプリケーションと環境レプリケーションが使用されます。 ウォーム再配置プロセスを次に示します。
- 新しいターゲット リージョンでサービス レプリケーションを実行します。
- ソース リージョンでワークロードを実行したままにします。
- ソース データのバックアップを作成します。 オフピークの時間帯にバックアップを作成することをお勧めします。 また、データイン レプリケーションを有効にして、データを同期し、データ差分を最小限に抑える必要があります。
- 新しいターゲット リージョンのデータを復元します。
- エンドポイントを切り替えて検証します。
- ソース リージョンのワークロードをシャットダウンします。
サービスの数とデータの量によっては、ウォーム再配置には数分から 1 時間かかる場合があります。
サービス再配置の自動化を選択する
サービス再配置の自動化には、コードとしてのインフラストラクチャ (IaC) と Azure Resource Mover の、主に 2 つの方法があります。 各 Azure サービスでは、一方または両方の自動化アプローチがサポートされています。 「Azure サービスの再配置ガイダンス」を使用して、各 Azure サービスでサポートされている自動化の方法と再配置の詳細な手順を確認できます。 サービス再配置ガイダンスで用いられている自動化の概要は次のとおりです。
コードとしてのインフラストラクチャ (IaC): IaC は、すべての Azure サービスを再配置できます。 既存の Azure サービスの Azure Resource Manager (ARM) テンプレート (JSON) をエクスポートします。 必要に応じてテンプレートを変更し、新しいリージョンにテンプレートを再デプロイします。 Visual Studio Code に JSON を貼り付けることで、ARM テンプレートを Bicep テンプレートに変換できます。 IaC を使用して Azure サービスの新しいインスタンスを展開するとき、リソースの複数コピーを並列に展開できます。 複数コピーを使用すると、一括移行の手法を 1 つ使用し、新しいターゲット リージョンのワークロードに接続をリダイレクトできます。 コードとしてのインフラストラクチャ (IaC) は、データの再配置は行いません。 データの再配置には、ターゲット リージョンで新しくデプロイされたリソースにデータを移行するための追加の手順が必要になります。 詳細については、「データ再配置の自動化ガイダンス」を使用してください。
Azure Resource Mover: Azure Resource Mover を使用すると、リージョン、サブスクリプション、リソース グループ間に依存関係を持つ、サポートされている Azure リソースの一部を移行できます。
データ再配置の自動化を選択する
IaC を使用してステートフル Azure サービスを再配置した場合、データ再配置の自動化方法を使用してデータを再配置する必要があります。 データの再配置では、データを移動する前に、ターゲット リージョンで Azure サービスを実行する必要があります。 再配置方法を確認して、再配置シーケンスとデータ再配置に適した状態を理解します。 データの再配置に使用できる自動化ツールのリストは次のとおりです。
同期データ レプリケーション: 同期データ レプリケーションでは、リージョン間でデータがほぼリアルタイムでレプリケートされます。 これは、一括移行後のダウンタイムとデータ差分移行を制限するため、ホット再配置に適したデータ再配置アプローチです。 この機能は、Azure SQL データベース のデータ同期など、一部の Azure サービスに組み込まれています。 ワークロード内の各サービスで同期データ レプリケーションがサポートされているかどうかを確認する必要があります。
geo レプリケーション: geo レプリケーションは、それをサポートする Azure サービスにとって便利なデータ再配置ツールになる可能性があります。 geo レプリケーション機能でのデータと基になるサービス インスタンスの処理方法は、サポートされている Azure サービスによって異なります。 データ再配置に geo レプリケーションを使用する前に、再配置する特定のサービスの geo レプリケーション機能を理解しておく必要があります。 例については、Azure SQL と Cosmos DB に関するページを参照してください。
Azure Site Recovery: Azure Site Recovery を使用すると、サービスとデータを再配置できます。 コールドとウォーム再配置がサポートされています。 詳しくは、Azure Site Recovery の概要に関するページをご覧ください。
AzCopy: AzCopy は、Azure Storage との間のデータ移動を自動化するコマンドライン ユーティリティです。 ツールをダウンロードしてから、Microsoft Entra ID または Shared Access Signature (SAS) トークンを使用して移動を承認する必要があります。 詳細については、AzCopy の概要と AzCopy の使用に関するページを参照してください
Azure Data Factory または Synapse Analytics のパイプラインとアクティビティ: Azure Data Factory は、データの移動と変換を調整および自動化するフル マネージドのクラウドベースのデータ統合サービスです。 Azure Data Factory パイプラインを使用すると、データ レイクとウェアハウスを移動できます。 Synapse Analytics のコピー アクティビティでも、データを移動できます。 詳細については、サポートされているターゲットとソースとデータのコピー ツールに関するページを参照してください。
Azure Storage Explorer: Azure Storage Explorer は、Azure Storage データを再配置できるスタンドアロン アプリです。 詳細については、Storage Explorer の使用方法に関するページを参照してください。
Azure Backup: Azure Backup を使用すると、別のリージョンでデータをバックアップおよび復元できます。 必須ではないコールドとウォーム再配置には、最初に Azure Backup を試す必要があります。 Azure Backup では、仮想マシンに対してアプリケーション整合性、ファイル システム整合性、クラッシュ整合性のバックアップが用意されています。 また、マネージド ディスク、ファイル共有、BLOB もサポートされています。 既存のバックアップ復元ポイントを新しいターゲット リージョンに転送することはできません。 バックアップが不要になるまで、コンテナーをソース リージョンに保持することを検討してください。 詳細については、Azure Backup の概要に関するページを参照してください。
手動バックアップと復元: ここでのバックアップと復元は、特定のツールではなくプロセスを指します。 Azure の多くのサービスには、別のリージョンにデータをバックアップし、手動で復元できる冗長性オプションが用意されています。 Azure Key Vault などの特定のサービスに対して手動でのバックアップと復元を実行する必要があります。 詳細については、Key Vault を別のリージョンに移動するに関するページを参照してください。
| ツール | 再配置方法 |
|---|---|
| 同期データ レプリケーション | ホット、ウォーム |
| geo レプリケーション | ホット、ウォーム |
| Azure Site Recovery | ウォーム、コールド |
| AzCopy | ウォーム、コールド |
| Azure Data Factory または Synapse Workspace のパイプラインとアクティビティ | ウォーム、コールド |
| Azure Storage Explorer | ウォーム、コールド |
| Azure Backup | アイス |
| 手動バックアップと復元 | アイス |
一括移行アプローチを選択する
一括移行とは、古いワークロードから新しいワークロードに移行することです。 トラフィックをターゲット リージョン内のワークロードに誘導し、ソース リージョンには送信されなくなります。 ドメイン ネーム システム (DNS) は、このリダイレクトの中心です。 DNS は、応答を取得する場所をブラウザーと API クライアントに通知します。 ドメイン名が IP アドレスに解決されます。 すべてのドメインには、それを管理するためのドメイン ホストが必要です。 Azure DNS は、Azure ドメイン ホスト サービスです。 ワークロードの一括移行にはさまざまなアプローチがあり、実行するアプローチはワークロード内のサービスによって異なります。 次に例をいくつか示します。
Azure DNS: Azure DNS でホストされているドメインの場合は、CNAME を切り替えて手動一括移行を実行できます。 このアプローチは、一括移行で機能するビジネス継続性のフェールオーバー プロセスです。 詳細については、Azure DNS を使用した一括移行に関するページを参照してください。
Traffic Manager: また、Traffic Manager などのルーティング サービスを一括移行に使用して、ワークロード トラフィックを別のエンドポイントにルーティングすることもできます。 Traffic Manager は、DNS ベースのルーティング サービスです。 詳細については、Traffic Manager を使用して DNS 名を構成するに関するページを参照してください。
App Service: Azure App Service などのアプリケーション層サービスには、ドメイン名を更新できる機能があります。 詳細については、「アクティブな DNS 名を Azure App Service に移行する」を参照してください。
ゲートウェイ ルーティング: Azure Front Door、Application Gateway、Azure API Management などのサービスでワークロードがゲートウェイ ルーティング パターンを使用すれば、多くの場合はリージョン移行の一括移行を実行できます。 それらのバックエンド ターゲットとルーティングルール機能を使用します。
次のステップ
再配置方法とワークロードを再配置するツールを選択しました。 移行ステップに進み、これらのツールを使用して再配置を実行します。