Azure Site Recovery を用いた堅牢なDR戦略の構築

Tech

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

Azure Site Recovery を用いた堅牢なDR戦略の構築

ディザスターリカバリー (DR) は、事業継続性計画 (BCP) の重要な要素であり、ITインフラストラクチャが自然災害やサイバー攻撃などの予期せぬ障害から迅速に復旧するための戦略を指します。Microsoft Azureが提供するAzure Site Recovery (ASR) は、クラウドベースのDRソリューションとして、様々なワークロードのレプリケーション、フェールオーバー、フェールバックを簡素化し、堅牢なDR戦略を低コストで実現します。

1. アーキテクチャの概要

Azure Site Recovery は、オンプレミスの物理サーバーやVMware/Hyper-V仮想マシン、Azure VM間の災害復旧をサポートするサービスです。Recovery Services コンテナを中心として、選択したワークロードの継続的なデータレプリケーションを行い、障害発生時にはレプリケートされたデータを使用してDRサイトで迅速にサービスを再開できます。

主なサポートシナリオは以下の通りです。

  • Azure リージョン間の Azure VM のレプリケーション

  • オンプレミスの VMware VM または物理サーバーから Azure へのレプリケーション

  • オンプレミスの Hyper-V VM から Azure へのレプリケーション

ASRの基本的なレプリケーションフローを以下に示します。ここでは、Azure VMから別のAzureリージョンへのレプリケーションを想定しています。

flowchart LR
    subgraph Source_Region["ソース リージョン"]
        SVMA["ソース VM A"] --> |ディスクデータの継続レプリケーション| RSC["Recovery Services コンテナ"]
        SVMB["ソース VM B"] --> |ディスクデータの継続レプリケーション| RSC
    end

    RSC --> |レプリケーションポリシー適用| CS["キャッシュ ストレージアカウント"]
    CS --> |データ転送| TS["ターゲット ストレージアカウント"]

    subgraph Target_Region["ターゲット リージョン"]
        TS --> TVM["ターゲット VMディスク (フェールオーバー時のみプロビジョニング)"]
    end

    click RSC "https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-architecture"
    click CS "https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-architecture"
    click TS "https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-architecture"

図1: Azure VM間のAzure Site Recoveryレプリケーションフロー

この図は、ソースリージョンのVMからRecovery Services コンテナを経由して、ターゲットリージョンのストレージアカウントへデータが継続的にレプリケートされる流れを示しています。フェールオーバー時には、ターゲットストレージのデータから新しいVMがプロビジョニングされます。詳細は「Azure Site Recovery のアーキテクチャ」[1]で確認できます（2024年4月12日更新、Microsoft）。

2. 設定手順

ここでは、Azure VM間のレプリケーションをPowerShellで設定する具体的な手順を例示します。

2.1 Recovery Services コンテナの作成

まず、DR戦略の中心となるRecovery Services コンテナを作成します。

# 変数の定義

$ResourceGroupName = "my-dr-rg"
$Location = "japaneast" # ソースVMが存在するリージョン、またはコンテナを配置するリージョン
$VaultName = "my-asr-vault"

# リソースグループが存在しない場合は作成

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

# Recovery Services コンテナの作成

Write-Host "Recovery Services コンテナ '$VaultName' を作成中..."
$vault = New-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $ResourceGroupName -Location $Location
Write-Host "Recovery Services コンテナ '$VaultName' を作成しました。"

# コンテキストの設定 (ASR操作のために必要)

Set-AzRecoveryServicesAsrVaultContext -Vault $vault

2.2 レプリケーションポリシーの設定

レプリケーションの頻度や復旧ポイントの保持期間などを定義するレプリケーションポリシーを作成します。

# レプリケーションポリシーの作成

$policyName = "default-replication-policy"
$recoveryPointRetentionInHours = 24 # 復旧ポイント保持期間 (24時間)
$appConsistentFrequencyInMinutes = 60 # アプリケーション整合性スナップショット頻度 (60分)

Write-Host "レプリケーションポリシー '$policyName' を作成中..."
$policy = New-AzRecoveryServicesAsrPolicy -Name $policyName `
    -RecoveryPointRetentionInHours $recoveryPointRetentionInHours `
    -AppConsistentFrequencyInMinutes $appConsistentFrequencyInMinutes `
    -ReplicationIntervalInSeconds 300 # デフォルトは300秒 (5分)
Write-Host "レプリケーションポリシー '$policyName' を作成しました。"

2.3 Azure VMのレプリケーションの有効化

保護したいAzure VMを選択し、レプリケーションを有効にします。

# レプリケーション対象のVM情報を取得

$vmName = "my-source-vm"
$sourceRG = "my-source-rg" # ソースVMのリソースグループ
$sourceVM = Get-AzVM -ResourceGroupName $sourceRG -Name $vmName

# ターゲットリージョンとターゲットリソースグループの定義

$targetLocation = "japanwest" # DRサイトのリージョン
$targetResourceGroupName = "my-dr-target-rg"
$targetVnetName = "my-dr-vnet"
$targetSubnetName = "default"
$targetStorageAccountName = "mydrstorage" # キャッシュストレージおよびレプリケーションデータ用

# ターゲットリソースグループが存在しない場合は作成

try {
    Get-AzResourceGroup -Name $targetResourceGroupName -ErrorAction Stop | Out-Null
    Write-Host "ターゲットリソースグループ '$targetResourceGroupName' は既に存在します。"
} catch {
    New-AzResourceGroup -Name $targetResourceGroupName -Location $targetLocation
    Write-Host "ターゲットリソースグループ '$targetResourceGroupName' を作成しました。"
}

# ターゲットVNetの作成 (既存VNetを使用する場合はスキップ)

try {
    Get-AzVirtualNetwork -ResourceGroupName $targetResourceGroupName -Name $targetVnetName -ErrorAction Stop | Out-Null
    Write-Host "ターゲットVNet '$targetVnetName' は既に存在します。"
} catch {
    New-AzVirtualNetwork -ResourceGroupName $targetResourceGroupName -Name $targetVnetName -Location $targetLocation `
        -AddressPrefix "10.0.0.0/16"
    Add-AzVirtualNetworkSubnetConfig -Name $targetSubnetName -AddressPrefix "10.0.0.0/24" `
        -VirtualNetwork (Get-AzVirtualNetwork -ResourceGroupName $targetResourceGroupName -Name $targetVnetName) | Set-AzVirtualNetwork
    Write-Host "ターゲットVNet '$targetVnetName' を作成しました。"
}

# ターゲットストレージアカウントの作成 (キャッシュストレージおよびレプリケーションデータ用)

try {
    Get-AzStorageAccount -ResourceGroupName $targetResourceGroupName -Name $targetStorageAccountName -ErrorAction Stop | Out-Null
    Write-Host "ターゲットストレージアカウント '$targetStorageAccountName' は既に存在します。"
} catch {
    New-AzStorageAccount -ResourceGroupName $targetResourceGroupName -Name $targetStorageAccountName -Location $targetLocation `
        -SkuName Standard_LRS -Kind StorageV2
    Write-Host "ターゲットストレージアカウント '$targetStorageAccountName' を作成しました。"
}

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


# ここでは、Managed DiskのVMをAzure Managed Diskにレプリケートする例

Write-Host "VM '$vmName' のレプリケーションを有効化中..."
$replicationJob = New-AzRecoveryServicesAsrReplicationProtection `
    -AzureToAzure `
    -ResourceGroupName $sourceRG `
    -VirtualMachine $sourceVM `
    -RecoveryVault $vault `
    -Policy $policy `
    -TargetLocation $targetLocation `
    -TargetResourceGroupId $targetResourceGroupName `
    -TargetAvailabilitySet $null ` # ターゲットアベイラビリティセットを使用する場合は指定
    -TargetVirtualNetworkId (Get-AzVirtualNetwork -ResourceGroupName $targetResourceGroupName -Name $targetVnetName).Id `
    -TargetSubnetName $targetSubnetName `
    -TargetRecoveryStorageAccountId (Get-AzStorageAccount -ResourceGroupName $targetResourceGroupName -Name $targetStorageAccountName).Id `
    -LogStorageAccountId (Get-AzStorageAccount -ResourceGroupName $targetResourceGroupName -Name $targetStorageAccountName).Id ` # キャッシュストレージとして利用
    -EnableManagedDiskReplication
Write-Host "VM '$vmName' のレプリケーション有効化ジョブが開始されました。ジョブID: $($replicationJob.ID)"

上記の手順は「Azure PowerShell を使用して Azure VM のディザスター リカバリーを設定する」[2]を参考に、2024年3月18日時点の情報に基づいています。

3. 運用監視

ASRのDR戦略を運用する上で、継続的な監視と定期的なテストは不可欠です。

  • ASR状態の監視: Recovery Services コンテナの概要ページから、レプリケーションの健全性、保護されたアイテムの数、エラーや警告を一覧で確認できます。Azure MonitorとLog Analyticsワークスペースを統合することで、より詳細なメトリック（RPO違反、レプリケーションスループットなど）とログを収集し、分析することが可能です。

  • アラートの設定: Azure Monitor を使用して、RPO目標の逸脱、レプリケーションエラー、保護されたVMの停止など、重要なイベントに対してアラートを設定し、関係者に通知することで迅速な対応を促します。

  • テストフェールオーバーの実施: 定期的なDRテストは、RTO (目標復旧時間) と RPO (目標復旧時点) 目標が達成可能であることを検証し、リカバリープランの欠陥を特定するために最も重要です。ASRでは、本番環境に影響を与えずにテストフェールオーバーを実行できます。これにより、ネットワーク構成、IPアドレス設定、アプリケーションの起動順序などを確認し、必要に応じてリカバリープランを更新できます。これは「Azure Site Recovery を監視する」[3]でも推奨されています（2024年4月12日更新、Microsoft）。

4. セキュリティと権限

DR戦略におけるセキュリティは、データの整合性とアクセス制御の観点から非常に重要です。

  • Azure Entra IDとRBAC: ASRへのアクセスはAzure Entra ID (旧 Azure Active Directory) を通じて認証され、Azure RBAC (ロールベースのアクセス制御) によって認可されます。最小限の特権の原則に基づき、以下の組み込みロールやカスタムロールを割り当てることが推奨されます。

    • Recovery Services Contributor: Recovery Services コンテナとその中のDR操作（レプリケーション、フェールオーバー、フェールバック）を行うための権限。

    • Recovery Services Operator: DR操作の監視と実行のみを許可し、コンテナの構成変更は許可しない権限。

    • カスタムロール: 特定のリソースや操作に限定した権限が必要な場合に作成します。

  • データ暗号化: ASRでレプリケートされるデータは、転送中および保存中の両方で暗号化されます。

    • 転送中: データは TLS 1.2 以上を使用して暗号化され、セキュアなチャネルで転送されます。

    • 保存中: Azure Storage Service Encryption (SSE) により、レプリケーション先のストレージアカウントに保存されるデータは既定で暗号化されます。

  • Microsoft Defender for Cloud: Defender for Cloudと連携させることで、保護されたVMのセキュリティ状態を監視し、潜在的な脅威や脆弱性を検出できます。これにより、DR環境自体のセキュリティ強化にも繋がります。

これらのセキュリティに関する考慮事項は「Azure Site Recovery のアクセス許可を管理する」[4]で詳細に解説されています（2024年1月25日更新、Microsoft）。

5. コスト最適化

ASRはDRソリューションですが、コストを最適化することでTCO (総所有コスト) を抑えることができます。

  • ASRの料金体系: ASRの基本的な料金は、保護されたインスタンス（VM）ごとに月額料金が発生します。最初の31日間は無料で、それ以降は保護対象のVM数に応じて課金されます。具体的な料金は、Azure Site Recovery の価格ページ[5]で確認できます（2024年5月1日最終更新、Microsoft Azure）。

  • ストレージコスト: レプリケーションデータが保存されるストレージアカウントには、容量に応じた料金が発生します。RPO要件に応じて、Standard HDD/SSD、Premium SSDなどの適切なストレージタイプを選択することが重要です。一般的に、DRサイトのストレージは、本番環境よりも低コストなオプションを選択できます。

  • コンピューティングコスト:

    • レプリケーション中: DRサイトのVMは通常シャットダウン状態であり、コンピューティングコストは発生しません。

    • テストフェールオーバー時: テストフェールオーバー中にDRサイトで起動されるVMに対しては、その期間のコンピューティングコストが発生します。定期的なテストのスケジュールを計画的に行うことで、このコストを管理できます。

    • 災害発生時（本番フェールオーバー時）: フェールオーバーが実行され、DRサイトのVMが起動された時点から、通常のAzure VMのコンピューティングコストが発生します。

  • ネットワーク転送コスト: ソースリージョンからターゲットリージョンへのデータ転送には、アウトバウンドデータ転送料金が発生する可能性があります。

  • リザーブドインスタンスとAzure Hybrid Benefitの活用: DRサイトのVMが継続的に稼働するようなシナリオ（例: DRサイトを開発/テスト環境としても利用する場合）では、Azure リザーブドインスタンスやAzure Hybrid Benefit (AHB) を適用することで、コンピューティングコストを大幅に削減できます。

6. 落とし穴とベストプラクティス

ASRを効果的に導入・運用するためには、いくつかの「落とし穴」を避け、ベストプラクティスに従うことが重要です。

  • ネットワーク設計の考慮: フェールオーバー後のDRサイトでのネットワーク接続性を確保するために、VNet、サブネット、IPアドレス範囲、DNS設定、VPN/ExpressRoute接続などを事前に詳細に計画する必要があります。IPアドレスの重複は避けるべきです。

  • アプリケーション依存関係の理解: 複数のVMで構成されるアプリケーションの場合、VM間の依存関係を理解し、Recovery Plan (復旧計画) で適切な起動順序と遅延を設定することが重要です。これにより、アプリケーション整合性の取れた状態での復旧が可能になります。

  • RPO/RTO目標の現実的な設定: RPO (Recovery Point Objective) と RTO (Recovery Time Objective) はビジネス要件に基づいて設定されますが、ASRの機能やネットワーク帯域幅などを考慮し、技術的に実現可能な目標を設定することが不可欠です。高すぎる目標は不必要なコスト増につながる可能性があります。

  • 定期的なDRテストの実施: 「運用監視」セクションでも触れた通り、DRテストは机上の計画が実用的であることを検証する唯一の方法です。少なくとも年に一度はテストフェールオーバーを実施し、その結果を文書化して、リカバリープランを継続的に改善していくべきです。これは「Azure-to-Azure ディザスター リカバリーのベスト プラクティス」[6]でも強調されています（2024年4月12日更新、Microsoft）。

  • ディスクタイプとパフォーマンス: ソースVMのディスクタイプ（Standard HDD/SSD、Premium SSD）とターゲットのストレージタイプがRPOに影響を与える可能性があります。特に高いI/Oを必要とするワークロードの場合、ターゲットストレージのパフォーマンスにも注意が必要です。

7. まとめ

Azure Site Recovery は、複雑なDR戦略をAzure上で効率的に実現するための強力なツールです。適切なアーキテクチャ設計、自動化された設定手順、厳格な運用監視、そして強固なセキュリティ対策を組み合わせることで、事業継続性を大幅に向上させることができます。コスト最適化の観点も忘れずに、定期的なDRテストを通じて常に最新の状態に保つことが、堅牢なDR戦略の鍵となります。

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

コメント

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