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

Azure Site RecoveryによるDR計画

クラウド環境における事業継続性（BC）および災害復旧（DR）計画は、サービスの可用性を維持し、ビジネスの中断を最小限に抑える上で不可欠です。Azure Site Recovery（ASR）は、オンプレミス環境（VMware、Hyper-V、物理サーバー）やAzure仮想マシン（VM）を別のAzureリージョンにレプリケートすることで、信頼性の高いDRソリューションを提供します。本稿では、ASRを用いたDR計画のアーキテクチャ、設定手順、運用監視、セキュリティ、コスト最適化、そして一般的な落とし穴についてクラウドアーキテクトの視点から解説します。

アーキテクチャ
設定手順
運用監視
セキュリティ
コスト
落とし穴
まとめ

アーキテクチャ

Azure Site Recoveryは、Recovery Servicesコンテナーを中心に構成され、ソース環境（オンプレミスまたはAzure）からターゲットAzureリージョンへの仮想マシンのレプリケーションとオーケストレーションを管理します。レプリケーション方式は、VMのOS種別やソース環境によって異なりますが、一般的には、継続的なデータ同期を行い、災害発生時に設定された目標復旧時点（RPO）と目標復旧時間（RTO）で復旧できる状態を維持します。

Azure-to-Azureレプリケーションの概念図:

flowchart TD
    subgraph Source_Region["ソース Azure リージョン"]
        A["Azure VM(#quot;ソース#quot;)"] --> B("ASRレプリケーションエージェント")
    end

    subgraph Target_Region["ターゲット Azure リージョン"]
        C("ASRレプリケーションサービス") --> D["ストレージアカウント"]
        D --> E["レプリカ VM(#quot;電源オフ#quot;)"]
    end

    subgraph Management_Plane["管理プレーン"]
        F["Recovery Services コンテナー"]
        G["レプリケーションポリシー"]
        H["復旧計画"]
    end

    B -->|"データの継続的なレプリケーション"| C
    F -->|"管理対象"| B
    F -->|"構成とオーケストレーション"| G
    F -->|"復旧指示"| H
    G -->|"レプリケーション設定"| B
    H -->|"フェールオーバーと復旧順序"| E

レプリケーションされたデータは、ターゲットリージョンのストレージアカウントに格納され、フェールオーバー時に新しいVMインスタンスとして起動されます。レプリケーションは、デフォルトでTCP 443ポートを使用し、暗号化されて転送されます[1]。

設定手順

ASRのデプロイは、Recovery Servicesコンテナーの作成から始まり、レプリケーションの有効化、そして復旧計画の定義へと進みます。ここでは、Azure VM間レプリケーションの主要なPowerShellコマンドレットを示します。

Recovery Servicesコンテナーの作成:

# リソースグループとリージョンの定義

$ResourceGroupName = "my-asr-rg"
$Location = "japaneast" # ソースVMと同じリージョンかDR先のリージョン
$VaultName = "my-rsvault"

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

New-AzResourceGroup -Name $ResourceGroupName -Location $Location

# Recovery Services コンテナーの作成

$Vault = New-AzRecoveryServicesVault -Name $VaultName -ResourceGroupName $ResourceGroupName -Location $Location -StorageMode "Azure"

# 作成したコンテナーのコンテキストを設定

Set-AzRecoveryServicesVaultContext -Vault $Vault

（参照：Microsoft Learn, 2024年6月12日更新[4]）

レプリケーションポリシーの作成と適用:

# レプリケーションポリシーのパラメータ定義

$PolicyName = "my-replication-policy"
$RecoveryPointRetentionInHours = 24 # 復旧ポイントの保持期間 (時間)
$ApplicationConsistentSnapshotFrequencyInHours = 4 # アプリケーション整合性スナップショットの頻度 (時間)

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

$Policy = New-AzSiteRecoveryPolicy -Name $PolicyName `
                                -RecoveryPointRetentionInHours $RecoveryPointRetentionInHours `
                                -ApplicationConsistentSnapshotFrequencyInHours $ApplicationConsistentSnapshotFrequencyInHours

# 仮想マシンへのレプリケーション有効化 (例: Azure VMからAzure VMへ)


# 事前にSet-AzSiteRecoveryFabric、Get-AzSiteRecoveryProtectionContainerで環境を準備


# ...


# New-AzSiteRecoveryReplicationProtectedItem -AzureToAzureVM ...

復旧計画の作成: 復旧計画は、フェールオーバー時のVM起動順序、スクリプト実行、手動アクションなどを定義します。

# 復旧計画のパラメータ定義

$RecoveryPlanName = "my-dr-plan"
$TargetLocation = "japanwest" # DR先のリージョン
$SourceVMs = @(

    # ここにレプリケート対象のVM情報（VMIDや名前）を配列で指定


    # 例: Get-AzVM -ResourceGroupName "source-rg" -Name "webserver-01"

)

# 復旧計画の作成

New-AzSiteRecoveryRecoveryPlan -Name $RecoveryPlanName `
                               -FabricName "Azure" `
                               -PrimaryZone $Location `
                               -RecoveryZone $TargetLocation `
                               -VMs $SourceVMs

復旧計画は、複数の仮想マシンをグループ化し、計画的なフェールオーバーやDRドリルをオーケストレーションするために使用されます[5]。

運用監視

DR計画の運用において、ASRの健全性を継続的に監視し、定期的なDRドリルを実施することが極めて重要です。

可観測性: Azure Site Recoveryの管理はAzure Monitorと統合されており、レプリケーションの健全性、状態、RPOの逸脱などを監視できます。Azure Activity Logを通じて、ASR関連の操作履歴も確認可能です[6]。
ログ: Recovery Servicesコンテナーの診断設定を構成し、レプリケーションイベント、エラー、警告などのログをLog Analyticsワークスペースに送信することで、詳細な分析とカスタムアラートの設定が可能になります。
SLA/RPO/RTO: レプリケーションポリシーで設定したRPOが遵守されているか、Azure Monitorで確認します。目標RTOを達成するためには、フェールオーバー後のVM起動時間、ネットワーク構成、アプリケーション起動時間を含めた綿密な復旧計画と、それに基づく定期的なDRドリルの実施が不可欠です[5]。
バックアップとの連携: Azure Backupとは異なる独立したサービスですが、ASRは事業継続の側面を担い、Azure Backupはデータ保護の側面を担います。両者を組み合わせることで、より堅牢なBCDR戦略を構築できます。

セキュリティ

Azure Site Recoveryのセキュリティは、Azureのネイティブ機能と連携して強化されます。

アイデンティティと権限境界:
- Azure Entra ID: ASRの操作を行うユーザーやサービスプリンシパルは、Azure Entra IDによって認証されます。
- Azure ロールベースのアクセス制御 (RBAC): Recovery Servicesコンテナーへのアクセスは、最小権限の原則に基づき、特定のRBACロールを割り当てて制御します。
  - Site Recovery Contributor：レプリケーション操作や復旧計画の管理。
  - Site Recovery Reader：ASRの状態と設定の閲覧。
  - 管理者は Contributor または Owner ロールで、Recovery Servicesコンテナーを含むリソースグループを管理します[2]。
- マネージドID: ASRサービスがAzureリソース（ストレージアカウントなど）にアクセスする際に、マネージドIDを使用することで、資格情報の管理負担を軽減し、セキュリティを向上させます。
- 条件付きアクセス (CA): ASRの管理コンソールへのアクセスに対して、多要素認証（MFA）や特定のネットワークロケーションからのアクセス要求などの条件付きアクセスポリシーを適用することで、管理者の認証セキュリティを強化できます。
データ暗号化: レプリケーション中のデータは、TLS 1.2以上で暗号化されて転送されます。ターゲットリージョンに格納されるデータは、Azure Storage Service Encryptionによって保存時に暗号化されます。
ネットワークセキュリティ: Azure Private Linkを使用して、ASRトラフィックをプライベートネットワーク経由でルーティングすることで、インターネット経由のデータ漏洩リスクを低減できます[2]。
Azure Defender for Servers: フェールオーバー後に起動されるVMには、Azure Defender for Serversを適用し、脅威検出と脆弱性管理を継続的に行うことで、セキュリティ体制を維持します。

コスト

Azure Site Recoveryのコストは、主に以下の要素で構成されます[3]。

ASRライセンス料: 保護するインスタンス（VM）ごとに月額料金が発生します。オンプレミスからAzureへのレプリケーションの場合、最初の31日間は無料です。
ストレージコスト: ターゲットリージョンにレプリケーションされるデータの格納に必要なストレージ（マネージドディスクまたはストレージアカウント）のコスト。ディスクの種類（Standard HDD/SSD, Premium SSD）やデータ量に依存します。
ネットワークコスト: レプリケーションデータ転送に伴うアウトバウンドデータ転送コスト（ソースリージョンからターゲットリージョンへ）。リージョン間のデータ転送は通常、費用が発生します。
フェールオーバー後のVMコスト: フェールオーバーを実行し、ターゲットリージョンでVMが起動された時点から、通常のVM実行コストが発生します。

コスト最適化の戦略:

適切なRPO/RTOの設定: 厳密すぎるRPO要件は、より高価なストレージやより頻繁なレプリケーションを引き起こす可能性があります。ビジネス要件に基づき、適切なバランスを見つけることが重要です。
ストレージの最適化: レプリケーション先のストレージを、Standard HDD/SSDなど、必要最低限のパフォーマンスを持つSKUに設定することでコストを削減できます。ただし、フェールオーバー後のパフォーマンス要件も考慮が必要です。
レプリケーションのスケジューリング: Azure VM間のレプリケーションでは継続的なレプリケーションが一般的ですが、オンプレミス環境からのレプリケーションでは、帯域幅の利用を最適化するスケジューリングを検討できます。
Reserved Instancesの活用: フェールオーバー後に常時稼働する可能性のある重要なワークロードのVMについては、ターゲットリージョンでAzure Reserved Virtual Machine Instancesを事前に購入することで、VM実行コストを大幅に削減できます。

落とし穴

ASRを用いたDR計画では、いくつかの一般的な落とし穴に注意が必要です。

ネットワーク構成の不備: フェールオーバー先のVNet、サブネット、IPアドレス、DNS設定が正しく構成されていないと、復旧したVMにアクセスできない、またはアプリケーションが正常に動作しないといった問題が発生します。特にVNetピアリングやExpressRouteのルーティング設定は慎重な確認が必要です。
DRドリルの不足: 定期的なテストフェールオーバーを実施しないと、実際の災害時に計画通りに復旧できないリスクが高まります。年1回以上のDRドリルは必須であり、計画の見直しを行う必要があります。
容量計画の不甘: ターゲットリージョンでフェールオーバーに必要なVMインスタンスタイプや、ストレージ、ネットワーク帯域の容量が不足していると、大規模障害時に復旧が遅延する可能性があります。
アプリケーション整合性の欠如: アプリケーション整合性スナップショットの取得が適切に行われていない場合、フェールオーバー後のアプリケーションデータが整合性の取れていない状態となり、手動での復旧作業が必要になることがあります。
RPO/RTOの誤解: ビジネス部門が求めるRPO/RTOと、ASRで実現可能なRPO/RTOに乖離がある場合、期待値管理に問題が生じます。合意形成が重要です。

まとめ

Azure Site Recoveryは、複雑なDR計画を簡素化し、Azureの堅牢なインフラストラクチャを活用して、高い可用性を提供します。本稿で述べたアーキテクチャ、設定、運用監視、セキュリティ、コスト最適化の側面を理解し、計画的かつ継続的な運用を行うことで、ビジネスのレジリエンスを大幅に向上させることができます。DR計画は一度作成したら終わりではなく、環境の変化に合わせて定期的に見直し、DRドリルを通じて検証し続けることが成功の鍵となります。

参考文献: [1] Microsoft Learn. “Azure Site Recovery のアーキテクチャ”. 最終更新日: 2024年5月10日. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-architecture [2] Microsoft Learn. “Azure Site Recovery のセキュリティに関するベストプラクティス”. 最終更新日: 2024年4月18日. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-security [3] Azure Pricing. “Azure Site Recovery の価格”. 最終更新日: 2024年7月1日. URL: https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/ [4] Microsoft Learn. “Azure Site Recovery での Recovery Services コンテナーの作成と構成”. 最終更新日: 2024年6月12日. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-quickstart [5] Microsoft Learn. “Azure Site Recovery を使用した DR ドリルの実施”. 最終更新日: 2024年5月22日. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-test-failover [6] Microsoft Learn. “Azure Site Recovery の監視とアラート”. 最終更新日: 2024年3月28日. URL: https://learn.microsoft.com/ja-jp/azure/site-recovery/monitor-azure-site-recovery

文書情報

記事タイトル: Azure Site RecoveryによるDR計画
作成日: 2025.10.31
更新日: 2026.09.04
Source URL: https://papanda925.com/?p=3732

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。利用ポリシー