本記事は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 mermaid_group_1["プライマリリージョン"]
A["Primary VM"] -->|"変更追跡エージェント"| B("Replication Appliance")
end
subgraph mermaid_group_5["Azure Site Recoveryサービス"]
B -->|"セキュアなデータ転送 (HTTPS)"| C["Recovery Services コンテナー"]
C -->|"設定/監視API"| D("Azure Portal / PowerShell")
end
subgraph mermaid_group_10["DRリージョン (セカンダリ)"]
C -->|"キャッシュストレージへ転送"| E["Cache Storage (Standard)"]
E -->|"管理ディスクへ書き込み"| F["Managed Disks(#quot;レプリカ#quot;)"]
F -->|"フェールオーバー時"| G["DR VM(#quot;起動時#quot;)"]
end
D -->|"リカバリープラン実行指示"| H["フェールオーバープロセス"]
H -->|"DR VM起動"| G
G -->|"アプリケーション利用可能"| I["DRアプリケーション"]
subgraph mermaid_group_20["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日時点の情報に基づき、そのアーキテクチャから設定、運用監視、セキュリティ、コスト最適化、そして潜在的な落とし穴までを網羅的に解説しました。計画的な導入と継続的な運用を通じて、ビジネスの継続性を確保し、予期せぬ災害リスクからワークロードを保護することが可能です。
参考文献
[S1] Azure Site Recovery のアーキテクチャ. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-architecture
[S2] Azure Site Recovery の概要. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-overview
[S3] Azure Site Recovery の価格. Microsoft Azure. https://azure.microsoft.com/ja-jp/pricing/details/site-recovery/
[S4] Azure Resource Manager テンプレートを使用して Azure Site Recovery をデプロイする. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-automation
[S5] Azure Site Recovery のセキュリティ機能. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-security
[S6] Azure Site Recovery でのアクセス制御の構成. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-role-based-access-control
[S7] Azure Site Recovery の監視. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-monitor-on-premises-to-azure
[S8] Azure Site Recovery のコスト管理と最適化. Microsoft Learn. 更新日: 2024年5月10日. https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-site-recovery-cost-management

