Azure Site RecoveryによるDR戦略

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Site RecoveryによるDR戦略

クラウド環境における災害復旧（Disaster Recovery: DR）は、事業継続計画（Business Continuity Plan: BCP）の要となる重要な要素です。Microsoft Azureが提供するAzure Site Recovery (ASR) は、オンプレミスまたはAzure上のワークロードを別のAzureリージョンにレプリケートし、災害発生時に迅速なフェールオーバーを可能にするサービスです。本記事では、Azure Site Recoveryを活用した堅牢なDR戦略について、アーキテクチャ、設定手順、運用監視、セキュリティ、コスト最適化、および潜在的な落とし穴までをクラウドアーキテクトの視点から解説します。

1. アーキテクチャ

Azure Site Recoveryは、様々なシナリオに対応したDRソリューションを提供します。主なサポートシナリオは以下の通りです [S2]:

  • Azure VM間のDR: AzureリージョンAのVMをAzureリージョンBにレプリケートします。

  • VMware VM/物理サーバーからAzureへのDR: オンプレミスのVMware仮想マシンや物理サーバーをAzureにレプリケートします。

  • Hyper-V VMからAzureへのDR: オンプレミスのHyper-V仮想マシンをAzureにレプリケートします。

ASRの核となるコンポーネントは「Recovery Services コンテナー」です。これはレプリケーション設定、リカバリーポイント、リカバリープランなどを管理するための一元的なハブとなります [S1]。レプリケーションは、ソース環境からターゲット環境（通常は別のAzureリージョン）のキャッシュストレージを経由して管理ディスクに継続的に行われます。これにより、RPO (Recovery Point Objective) を最小限に抑えることが可能です [S1]。

以下に、Azure VM間でのDRにおけるASRのアーキテクチャ概要をフローチャートで示します。

flowchart TD
    subgraph プライマリリージョン
        A["Primary VM"] --> |変更追跡エージェント| B("Replication Appliance");
    end

    subgraph Azure Site Recoveryサービス
        B --> |セキュアなデータ転送 (HTTPS)| C["Recovery Services コンテナー"];
        C --> |設定/監視API| D("Azure Portal / PowerShell");
    end

    subgraph DRリージョン (セカンダリ)
        C --> |キャッシュストレージへ転送| E["Cache Storage (Standard)"];
        E --> |管理ディスクへ書き込み| F["Managed Disks(\"レプリカ\")"];
        F -- フェールオーバー時 --> G["DR VM(\"起動時\")"];
    end

    D -- リカバリープラン実行指示 --> H["フェールオーバープロセス"];
    H -- DR VM起動 --> G;
    G -- アプリケーション利用可能 --> I["DRアプリケーション"];

    subgraph Azure Entra ID
        J["DR管理者ユーザー/SPN"] --> |RBACによるアクセス制御| D;
    end

このアーキテクチャでは、プライマリリージョンのVMにインストールされたReplication ApplianceがVMの変更を追跡し、Recovery Services コンテナーを介してDRリージョンのキャッシュストレージにデータを転送します。その後、データはDRリージョンの管理ディスクに書き込まれ、レプリカが維持されます。災害時には、リカバリープランに従ってDRリージョンのVMが起動され、サービスが継続されます [S1]。

2. 設定手順

ASRのデプロイには、Azure Portalを利用する手動設定の他、PowerShellやAzure Resource Manager (ARM) テンプレートを用いたInfrastructure as Code (IaC) による自動化が推奨されます [S4]。ここでは、PowerShellによるAzure VM間のDR設定例を提示します。

前提条件:

  • Azure PowerShellモジュールがインストールされ、認証済みであること。

  • DR対象のソースVMが稼働していること。

  • DRリージョンにターゲットとなるリソースグループ、仮想ネットワーク、サブネットが作成済みであること。

  • Recovery Services コンテナーが未作成の場合、新規作成されます。

  • レプリケーションポリシーは、既存のデフォルトポリシー（例: Default-AzureToAzurePolicy）を利用することを想定しています。

# Azure Site Recovery の設定手順 (Azure VM間のDR)


# このスクリプトは、指定されたAzure VMをDRリージョンにレプリケートする設定を行います。

#


# 前提条件：


#   - Azure PowerShellモジュールがインストールされ、認証済みであること。


#   - DR対象のソースVMが稼働していること。


#   - DRリージョンにターゲットとなるリソースグループ、仮想ネットワーク、サブネットが作成済みであること。


#   - Recovery Services コンテナーが未作成の場合、新規作成されます。


#   - レプリケーションポリシーは、既存のデフォルトポリシーを利用することを想定しています。

#


# 処理概要：


#   1. 変数を定義します。


#   2. Azureサブスクリプションに接続します。


#   3. Recovery Services コンテナーを作成または取得します。


#   4. 既存のレプリケーションポリシーを取得します（通常、Azure-to-AzureではポータルでVMを保護した際にデフォルトが作成されます）。


#   5. ソースVMとターゲットネットワークの情報を取得します。


#   6. VMのレプリケーションを有効化します。

# --- 入力変数定義 ---


# Azure サブスクリプションID (例: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")

$SubscriptionId = "YOUR_SUBSCRIPTION_ID" # 適切なサブスクリプションIDに置換してください

# Recovery Services コンテナーが存在するリソースグループ名

$VaultResourceGroupName = "ASR-DR-Vault-RG"

# Recovery Services コンテナー名

$VaultName = "ASR-RecoveryServicesVault-JPN"

# プライマリリージョン (ソースVMが存在するリージョン)

$PrimaryLocation = "japaneast"

# セカンダリリージョン (DRリージョン、レプリカが作成されるリージョン)

$DRLocation = "japanwest"

# DR対象のソースVM情報

$SourceVMResourceGroupName = "Production-WebApp-RG"
$SourceVMName = "WebApp-VM01"

# DRリージョンで作成されるリソースグループ名 (存在しない場合は作成されます)

$DRResourceGroupName = "DR-WebApp-RG"

# DRリージョンで利用する仮想ネットワーク名 (事前に作成しておく必要があります)

$DRVirtualNetworkName = "DR-WebApp-VNet"

# DRリージョンで利用するサブネット名 (DRVirtualNetworkName内に存在する必要があります)

$DRSubnetName = "default"

# レプリケーションポリシー名 (Azure PortalでAzure-to-Azureレプリケーションを有効化した際に作成されるデフォルトポリシーを想定)

$ReplicationPolicyName = "Default-AzureToAzurePolicy"

# --- 変数定義ここまで ---

# --- 事前準備 ---


# Azureに接続

Write-Host "Azureアカウントに接続しています..."
Connect-AzAccount -SubscriptionId $SubscriptionId -ErrorAction Stop
Write-Host "Azureアカウントに接続しました。"

# DRリージョンのリソースグループを作成 (存在しない場合)

Write-Host "DRリソースグループ '$DRResourceGroupName' を確認/作成しています..."
try {
    Get-AzResourceGroup -Name $DRResourceGroupName -ErrorAction Stop | Out-Null
    Write-Host "DRリソースグループ '$DRResourceGroupName' は既に存在します。"
} catch {
    New-AzResourceGroup -Name $DRResourceGroupName -Location $DRLocation -ErrorAction Stop | Out-Null
    Write-Host "DRリソースグループ '$DRResourceGroupName' を '$DRLocation' に作成しました。"
}

# --- Recovery Services コンテナーの作成または取得 ---


# 計算量: O(1) - Azure API呼び出し


# メモリ条件: 最小限


# 入力: VaultResourceGroupName, VaultName, PrimaryLocation


# 出力: $vaultオブジェクト

Write-Host "Recovery Services コンテナー '$VaultName' を確認/作成しています..."
$vault = Get-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $VaultResourceGroupName -ErrorAction SilentlyContinue
if (-not $vault) {
    Write-Host "Recovery Services コンテナー '$VaultName' は存在しません。新規作成します。"
    $vault = New-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $VaultResourceGroupName -Location $PrimaryLocation -ErrorAction Stop
    Set-AzRecoveryServicesAsrVaultSettings -Vault $vault -ErrorAction Stop
    Write-Host "Recovery Services コンテナー '$VaultName' を作成し、ASR設定を初期化しました。"
} else {
    Write-Host "Recovery Services コンテナー '$VaultName' は既に存在します。"
    Set-AzRecoveryServicesAsrVaultSettings -Vault $vault -ErrorAction Stop # 既存コンテナーでもASR設定を初期化
}

# --- レプリケーションポリシーの取得 ---


# 計算量: O(1) - Azure API呼び出し


# メモリ条件: 最小限


# 入力: ReplicationPolicyName


# 出力: $replicationPolicyオブジェクト

Write-Host "レプリケーションポリシー '$ReplicationPolicyName' を取得しています..."

# Azure-to-Azureシナリオでは、通常ポータルでVMを初めて保護した際にデフォルトポリシーが作成されます。


# PowerShellでAzure-to-Azure用のポリシーを新規作成する直接的なコマンドレットは提供されていません。


# 既存のポリシーを利用するか、ポータルで一度VMを保護して作成されたポリシー名を確認して使用してください。

$replicationPolicy = Get-AzRecoveryServicesAsrPolicy -Name $ReplicationPolicyName -ErrorAction SilentlyContinue
if (-not $replicationPolicy) {
    Write-Error "レプリケーションポリシー '$ReplicationPolicyName' が見つかりません。Azure PortalでAzure to Azureレプリケーションを有効化した際に作成されるデフォルトポリシーの名前を確認し、スクリプトを更新してください。"
    Write-Error "処理を中断します。"
    exit 1
}
Write-Host "レプリケーションポリシー '$($replicationPolicy.Name)' を取得しました。"

# --- ソースVMとターゲットネットワークの情報を取得 ---


# 計算量: O(1) - Azure API呼び出し


# メモリ条件: 最小限


# 入力: SourceVMResourceGroupName, SourceVMName, DRResourceGroupName, DRVirtualNetworkName, DRSubnetName


# 出力: $sourceVm, $drVirtualNetwork, $drSubnetオブジェクト

Write-Host "ソースVM '$SourceVMName' の情報を取得しています..."
$sourceVm = Get-AzVM -Name $SourceVMName -ResourceGroupName $SourceVMResourceGroupName -ErrorAction Stop
Write-Host "ソースVM '$($sourceVm.Name)' の情報を取得しました。"

Write-Host "DR仮想ネットワーク '$DRVirtualNetworkName' の情報を取得しています..."
$drVirtualNetwork = Get-AzVirtualNetwork -Name $DRVirtualNetworkName -ResourceGroupName $DRResourceGroupName -ErrorAction Stop
$drSubnet = $drVirtualNetwork.Subnets | Where-Object {$_.Name -eq $DRSubnetName}
if (-not $drSubnet) {
    Write-Error "DR仮想ネットワーク '$DRVirtualNetworkName' 内にサブネット '$DRSubnetName' が見つかりません。処理を中断します。"
    exit 1
}
Write-Host "DR仮想ネットワーク '$($drVirtualNetwork.Name)' とサブネット '$($drSubnet.Name)' の情報を取得しました。"

# --- VMのレプリケーションを有効化 ---


# 計算量: O(1) - Azure API呼び出し (非同期ジョブ開始)


# メモリ条件: 最小限


# 入力: replicationPolicy, sourceVm, vault, DRLocation, DRResourceGroupName, drVirtualNetwork, drSubnet


# 出力: レプリケーション有効化ジョブ

Write-Host "VM '$SourceVMName' のレプリケーションを有効化しています..."

# コメント: このコマンドレットは、ソースVMをDRリージョンへレプリケートするように設定し、


# コメント: Recovery Servicesコンテナーに登録して初期レプリケーションを開始します。


# コメント: マネージドディスクの場合、キャッシュストレージアカウントは自動的に作成または割り当てられます。


# コメント: 顧客管理キー (CMK) を使用しない場合、-TargetDiskEncryptionSetId は $null のままにします。

try {
    Enable-AzRecoveryServicesAsrReplication -AzureToAzure `
        -ReplicationPolicy $replicationPolicy `
        -ResourceGroupName $SourceVMResourceGroupName `
        -Name $SourceVMName `
        -Vault $vault `
        -TargetLocation $DRLocation `
        -TargetResourceGroupName $DRResourceGroupName `
        -TargetVirtualNetworkId $drVirtualNetwork.Id `
        -TargetSubnetId $drSubnet.Id `
        -TargetDiskEncryptionSetId $null `
        -ErrorAction Stop | Out-Null
    Write-Host "VM '$SourceVMName' のレプリケーション有効化ジョブが開始されました。進行状況はAzureポータルで確認してください。"
} catch {
    Write-Error "VMレプリケーションの有効化中にエラーが発生しました: $($_.Exception.Message)"
    exit 1
}

Write-Host "スクリプト実行完了。"

このスクリプトは、必要なAzureリソースの作成とレプリケーションの有効化を自動化します。リカバリープランは、フェールオーバー時のVM起動順序やスクリプト実行を定義する重要な要素であり、サービスを多層的に構成している場合に不可欠です。

3. 運用監視

ASRのDR戦略を成功させるには、継続的な運用監視とテストが不可欠です。

  • 監視ダッシュボード: Recovery Services コンテナーには、レプリケーションの健全性、状態、RPOなどの主要メトリックを視覚的に表示する監視ダッシュボードが用意されています [S7]。

  • Azure Monitorとの統合: ASRはAzure Monitor Logs (Log Analytics) と統合でき、レプリケーションイベント、エラー、警告などの詳細なログを収集・分析できます。これにより、カスタムアラートを設定し、レプリケーション問題が発生した際に即座に通知を受け取ることが可能です [S7]。

  • DR訓練 (ドリル): 定期的なDR訓練（テストフェールオーバー）は、RPO/RTO目標が達成可能か、リカバリープランが機能するかを確認するために極めて重要です。テストフェールオーバーは本番環境に影響を与えずに行うことができ、計画の検証と改善に役立ちます。訓練は少なくとも年に一度、あるいはシステム変更があるたびに実施することを推奨します。

4. セキュリティ

ASRを用いたDR戦略では、セキュリティも重要な考慮事項です。

  • Azure Entra ID (旧 Azure Active Directory) とRBAC: Azure Entra IDとロールベースのアクセス制御 (RBAC) を用いて、ASRリソースへのアクセスを厳密に管理します。たとえば、「Site Recovery Contributor」ロールはレプリケーション設定の管理を許可し、「Site Recovery Operator」ロールはフェールオーバーやテストフェールオーバーの実行を許可しますが、設定変更はできません [S6]。最小権限の原則に基づき、必要なアクセス権のみを付与することが重要です。

  • データ暗号化: ASRは、転送中のデータ（HTTPS経由）と保存データ（Azure Storage Service Encryptionおよび顧客管理キーCMKの利用）の両方を暗号化することで、データの機密性を保護します [S5]。

  • ネットワークセキュリティ: Azure仮想ネットワークのネットワークセキュリティグループ (NSG) を利用して、レプリケーションデータの流れやフェールオーバー後のDR VMへのアクセスを制御します。必要に応じてAzure Private Linkを使用して、インターネット経由ではないプライベート接続でASRサービスエンドポイントにアクセスすることも可能です [S5]。

  • Azure Defender for Cloud (旧 Azure Security Center): ASRはAzure Defender for Cloudと統合されており、DR環境全体のセキュリティ体制を評価し、脅威検出や脆弱性管理を強化できます [S5]。

5. コスト

ASRのコストは、複数の要素によって構成されます [S3, S8]。

  • ASRサービス料金: 保護対象となるVMまたはサーバーのインスタンス数と期間に基づいて課金されます。最初の31日間は無料で利用可能です [S3]。

  • ストレージコスト: レプリケート先の管理ディスク（Premium SSD, Standard SSD, Standard HDDなど）およびキャッシュストレージ（通常はStandardストレージ）にかかる費用です [S8]。

  • データ転送コスト: プライマリリージョンからDRリージョンへのデータ転送量に応じて課金されます。

  • フェールオーバー後のVM稼働費用: 災害発生時にDRリージョンでVMが起動・稼働した場合、そのVMのコンピューティング料金が別途発生します。

コスト最適化戦略:

  • 最初の31日間無料期間の活用: 初期導入時のテストや検証に活用し、コストを抑えられます [S3]。

  • ストレージタイプの最適化: DRリージョンでのレプリカディスクには、RTO/RPO要件に応じて最適なストレージタイプ（例: プライマリはPremium SSD、DRはStandard SSDなど）を選択することでコストを削減できます [S8]。

  • DR VMのサイズ最適化: フェールオーバー後に起動するVMは、本番環境と全く同じサイズである必要がない場合もあります。DR時の最低限の機能を提供できる適切なサイズのVMを選択することで、コストを抑えることができます [S8]。

  • 予約インスタンス (Reserved Instances): フェールオーバー後のVM稼働費用を削減するために、DRリージョンで起動する可能性のあるVMに対して予約インスタンスを検討することが有効です [S8]。

  • IPアドレスの考慮: フェールオーバー時に新しいIPアドレスを割り当てるか、既存のIPアドレスを維持するかによって、費用や複雑さが変わります。

6. 落とし穴

ASR導入時の一般的な落とし穴と対策を以下に示します。

  • リカバリープランの未テスト: 最も重要な落とし穴の一つです。計画があってもテストされていなければ、いざという時に機能しない可能性があります。定期的なテストフェールオーバーを必須とします。

  • DNS/IPアドレスの管理不足: フェールオーバー後のDR環境でアプリケーションが正しく動作するためには、DNSレコードの更新やDRサイトでのIPアドレス管理が不可欠です。これらをリカバリープランに組み込む必要があります。

  • アプリケーション依存関係の考慮不足: 複数のVMやサービスが連携している場合、起動順序や依存関係を正確に把握し、リカバリープランに反映させないと、フェールオーバー後にアプリケーションが正常に起動しない可能性があります。

  • RPO/RTO目標と現実のギャップ: 設定したレプリケーションポリシーがRPO要件を満たしているか、またリカバリープランの実行時間がRTO要件に収まるかを確認し、必要に応じて設定を見直す必要があります。

  • コストの見積もり不足: レプリケーションデータ量、ストレージタイプ、フェールオーバー後のVM稼働時間などを正確に予測しないと、想定外のコストが発生する可能性があります。

7. まとめ

Azure Site Recoveryは、堅牢かつ柔軟な災害復旧戦略をAzure上で実現するための強力なツールです。本記事では、2024年5月24日時点の情報に基づき、そのアーキテクチャから設定、運用監視、セキュリティ、コスト最適化、そして潜在的な落とし穴までを網羅的に解説しました。計画的な導入と継続的な運用を通じて、ビジネスの継続性を確保し、予期せぬ災害リスクからワークロードを保護することが可能です。

参考文献

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました