クラウド ワークロードの再配置戦略を選択する
ワークロードを別のリージョンに移行する前に、再配置戦略を計画する必要があります。 この戦略には、再配置方法、サービス再配置の自動化、データ再配置の自動化が含まれます。 この記事では、各戦略コンポーネントのオプションを示し、決定に向けてガイドします。 最終的にどの選択を行うかは、サービスとワークロードの重要度によって異なります。
再配置方法を選択する
ワークロードの再配置には、主に 3 つの方法があります。 選択する再配置方法は、ワークロード内のサービスと、重要なビジネス機能にとってワークロードがどれほど重要かによって異なります。 稼働環境と非稼働環境に異なる再配置方法を検討できます。 コールド再配置は必須ではないワークロード向けです。 ホットとウォーム再配置はミッション クリティカル向けです。 再配置方法の選択は、ワークロードの再配置に使用するサービスおよびデータ再配置ツールに影響します。 次の再配置デシジョン ツリーを使用して、適切な再配置方法の一般的な概念を把握して、3 つの再配置方法の概要を読んでご自分の決定を検証してください。
コールド再配置
コールド再配置は、ダウンタイムに耐えられるワークロード向けです。 再配置中に環境を複製しないため、これは再配置に対する最もコスト効率の高いアプローチです。 次にコールド再配置プロセスの概要を示します。
- ワークロード データを新しいターゲット リージョンにバックアップします。
- ソース リージョンをオフラインにして、サービスをシャットダウンします。
- クラウド サービスを新しいターゲット リージョンにデプロイします。
- ワークロード データを復元します。
サービスの数とデータの量によっては、コールド再配置には数分から数日かかる場合があります。
ホット再配置
ホット再配置方法は、ダウンタイムを最小限 (秒、分) からゼロにする必要があるワークロード用です。 クリティカルなワークロードの場合は、ウォーム アプローチを試す前に、サービスがホット再配置をサポートしているかどうかを確認する必要があります。 ホット再配置は、一括移行後のデータ差分を最小限に抑えるのに役立ちます。 ホット再配置は、サービスで同期データ レプリケーションがサポートされている場合にのみ可能です。 一部のサービスにはこの機能がないため、代わりにウォーム再配置のアプローチを使用する必要があります。 ホット再配置プロセスを次に示します。
- 新しいターゲット リージョンでサービス レプリケーションを実行します。
- ソース リージョンでワークロードを実行したままにします。
- 同期データ レプリケーションを開始します。
- データが同期されたら、エンドポイントをアクティブにして検証します。
- データ同期を停止します。
- ソース リージョンでサービスをシャットダウンします。
ウォーム再配置
ウォーム再配置は、ホット再配置をサポートしていないクリティカルなワークロード用です。 ウォーム再配置では、非同期データ レプリケーションと環境レプリケーションが使用されます。 ウォーム再配置プロセスを次に示します。
- 新しいターゲット リージョンでサービス レプリケーションを実行します。
- ソース リージョンでワークロードを実行したままにします。
- ソース データのバックアップを作成します。 オフピークの時間帯にバックアップを作成することをお勧めします。 また、データイン レプリケーションを有効にして、データを同期し、データ差分を最小限に抑える必要があります。
- 新しいターゲット リージョンのデータを復元します。
- エンドポイントを切り替えて検証します。
- ソース リージョンのワークロードをシャットダウンします。
サービスの数とデータの量によっては、ウォーム再配置には数分から 1 時間かかる場合があります。
サービス再配置の自動化を選択する
サービス再配置には、主に 3 つのアプローチがあります。 以降の段落で、それぞれの概要と詳細なガイダンスへのリンクを示します。 コードとしてのインフラストラクチャ(IaC)の自動化を使用してワークロードを移動する場合、別のデータ再配置アプローチを見つける必要があります。 各サービス再配置ツールの機能を確認し、ご自分のニーズに最適なツールを選択する必要があります。
Azure Resource Mover: Azure Resource Mover は、リージョン、サブスクリプション、リソース グループ間で Azure リソースを移動できる組み込みの Azure サービスです。 Azure Resource Mover を使用すると、移動前にリソースを分析して準備して、サポートされている Azure リソースとその依存関係を移動できます。 詳細については、Azure Resource Mover の概要に関するページを参照してください。
Azure Site Recovery: Azure Site Recovery を使用すると、Azure でサポートされている仮想マシンで実行されている任意のアプリケーションをレプリケートできます。 これは設計上はディザスター リカバリー ツールですが、ワークロードの再配置にも使用できます。 Site Recovery では、Azure Backup と同様に Recovery Services コンテナーが使用されており、サービスをすばやく移動できます。 これはディザスター リカバリー ツールであるため、再配置後にいくつかのクリーンアップ手順が必要です。 詳細については、次を参照してください。
コードとしてのインフラストラクチャ(IaC): IaC を使用すると、Azure サービスをコピーして再展開できるようになります。 ソース リージョンのサービスには、Azure Resource Manager、Bicep、Terraform テンプレートを使用できます。 お好みの IaC ツールにより、新しいターゲット リージョンのテンプレートを使用して展開できます。 ステートフル サービスの場合は、ワークロード データを再配置するための別のツールが必要です。 詳細については、コードとしてのインフラストラクチャの概要に関するページを参照してください。
IaC を使用して Azure サービスの新しいインスタンスを展開するとき、リソースの複数コピーを並列に展開できます。 複数コピーを使用すると、一括移行の手法を 1 つ使用し、新しいターゲット リージョンのワークロードに接続をリダイレクトできます。
データ再配置の自動化を選択する
サービス再配置の自動化でデータが移動されない場合は、データ再配置の自動化も選択する必要があります。 データの再配置では、データを移動する前に、ターゲット リージョンでサービスを実行する必要があります。 再配置方法を確認して、シーケンスを理解します。 データの再配置に使用できる自動化ツールのリストを次に示します。 リストはホット再配置ツールから始まり、コールドで終了します。 これは優先順位ではありません。 各自動化ツールを評価し、ご自分のワークロードに適したものを選択します。
同期データ レプリケーション: 同期データ レプリケーションでは、リージョン間でデータがほぼリアルタイムでレプリケートされます。 これは、一括移行後のダウンタイムとデータ差分移行を制限するため、ホット再配置に適したデータ再配置アプローチです。 この機能は、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 などのサービスでワークロードがゲートウェイ ルーティング パターンを使用すれば、多くの場合はリージョン移行の一括移行を実行できます。 それらのバックエンド ターゲットとルーティングルール機能を使用します。
次のステップ
再配置方法とワークロードを再配置するツールを選択しました。 移行ステップに進み、これらのツールを使用して再配置を実行します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示