2026年7月7日時点で確認できるMicrosoftの公式情報では、Azure Site Recoveryの「Support 5x churn」が一般提供され、High Churn利用時のデータ変更率上限が、Azure VM 1台当たり従来の100 MB/sから最大500 MB/sへ引き上げられました。ただし、標準設定のNormal Churnは最大54 MB/sのままです。また、500 MB/sはすべての仮想マシンに自動適用されるわけではなく、メモリ容量、ディスク、OS、リージョン、Mobility serviceのバージョンなど複数の条件を満たす必要があります。(マイクロソフト アジュール)
対応を急ぐ必要があるのは、主にデータベースなどの書き込み量が多く、現在のAzure Site RecoveryでRPOの悪化やレプリケーション遅延が発生している環境です。現在のチャーンが54 MB/sを大きく下回り、レプリケーションの状態も正常であれば、GAになったという理由だけでHigh Churnへ変更する必要はありません。
なお、これは生成AIやAzure AIの更新ではありません。Azure VMの災害復旧性能を拡張するBCDR機能の更新です。そのため、確認すべき「データ境界」はAIへの入力データではなく、仮想マシンの変更データがどのリージョン、ストレージ、ネットワーク経路を通って複製されるかという点です。
Azure Site Recoveryの「5x churn」で何が変わったのか
今回の「5x」は、High Churnの従来上限である100 MB/sと比較した数値です。標準のNormal Churnと比較して5倍になったという意味ではありません。
| 項目 | 従来 | GA後 |
|---|---|---|
| Normal ChurnのVM単位上限 | 54 MB/s | 54 MB/s |
| High ChurnのVM単位上限 | 100 MB/s | 最大500 MB/s |
| 500 MB/s構成のディスク単位上限 | 対象外 | 最大250 MB/s |
| High Churnのキャッシュ | Premium Block Blob | Premium Block Blob |
| 500 MB/s拡張の提供段階 | プレビュー | 一般提供 |
チャーンとは、ソースVMのディスクで1秒間に変更されるデータ量です。ディスクの最大スループットやネットワーク帯域そのものではありません。
たとえば、アプリケーションが毎秒200 MBのデータを書き換えているのに、Azure Site Recoveryが毎秒100 MBまでしか処理できない場合、未送信データが蓄積します。その結果、最新の回復ポイントが遅れ、実際のRPOが悪化する可能性があります。今回の上限拡張は、このような書き込み負荷の高いAzure VMを保護しやすくするものです。
ただし、500 MB/sは保証値ではなく、サポートされる最大値です。VM単位とディスク単位の両方に上限があり、実際にはディスク容量、I/Oサイズ、アプリケーションの書き込みパターンのうち、最初に到達した制限が適用されます。(Microsoft Learn)
最大500 MB/sを利用するための条件
500 MB/sのHigh Churnを利用するには、次の条件を一つずつ確認する必要があります。
| 確認項目 | 最大500 MB/sの主な条件 | 実務上の判断ポイント |
|---|---|---|
| レプリケーション方式 | Azure VMから別のAzureリージョンへのAzure-to-Azure | オンプレミス、VMware、物理サーバー向けの上限拡張ではない |
| ソースディスク | マネージドディスク | アンマネージドディスクは500 MB/sの対象外 |
| ディスク種類 | Premium SSD v1、Premium SSD v2、Ultra Disk | Standard SSDやStandard HDDでは500 MB/sにならない |
| VMのメモリ | 256 GB以上 | 256 GB未満では最大100 MB/s以下 |
| Windows | Azure Site RecoveryでサポートされるWindows | VM、ディスク、リージョンなどの条件も必要 |
| Linux | RHEL 9、SLES 15、Ubuntu 24.04 | 100 MB/s超から500 MB/sまで対応するLinuxは限定される |
| リージョン | ソースとターゲットの両方が対象一覧に含まれること | Japan EastとJapan Westは対象一覧に含まれる |
| Mobility service | 9.66.7640.1以降 | 既存VMではアップグレードと再起動が必要になる場合がある |
| キャッシュストレージ | Premium Block Blob | StandardストレージではHigh Churnを利用できない |
| CPUとネットワーク | レプリケーション処理に必要な余力 | ASRによるCPU使用率はピーク時に18％へ達する可能性がある |
日本国内の代表的な構成では、Japan EastとJapan Westの間でレプリケーションする設計が候補になります。ただし、対象リージョンは変更される可能性があるため、構築時には最新のサポートマトリクスを再確認してください。(Microsoft Learn)
メモリ容量によって上限が変わる
High Churnを選択しただけでは、必ず500 MB/sになるわけではありません。VMのメモリ容量によって次の上限が適用されます。
| VMのメモリ | VM単位の最大チャーン | ディスク単位の最大チャーン |
|---|---|---|
| 32 GB未満 | 54 MB/s | 20 MB/s |
| 32 GB以上、256 GB未満 | 100 MB/s | 50 MB/s |
| 256 GB以上 | 500 MB/s | 最大250 MB/s |
Site Recoveryは、WindowsとLinuxの両方で最大6.25％のメモリを予約します。Windowsでは、High Churn時の予約量は最大16 GBに制限されます。256 GBの大規模VMで導入する場合でも、アプリケーションが利用できるメモリへの影響を負荷試験で確認する必要があります。(Microsoft Learn)
1台のディスクだけでは500 MB/sに到達しない
500 MB/sはVM全体の上限であり、ディスク1台当たりの上限は最大250 MB/sです。したがって、1台のディスクだけで500 MB/sのチャーンを処理する構成にはなりません。
さらに、ディスク単位の上限は容量と書き込みサイズによって変わります。公式の検証値では、たとえば次のような違いがあります。
| ソースディスクと書き込みパターン | サポートされるディスク単位チャーン |
|---|---|
| 128 GiB、8 KB書き込み | 3.9 MB/s |
| 128 GiB、256 KB以上の書き込み | 100 MB/s |
| 1 TiB、32 KB書き込み | 156.3 MB/s |
| 2 TiB、64 KB以上の書き込み | 250 MB/s |
| 8 TiB、16 KB以上の書き込み | 250 MB/s |
「高IOPSだから500 MB/sが必要」とは限りません。小さなランダム書き込みではIOPSが高くても、データ変更量は小さい場合があります。反対に、大きな連続書き込みではIOPSがそれほど高くなくても、チャーンが大きくなります。
判断にはIOPSだけでなく、書き込みバイト数、ディスク別チャーン、レプリケーションのアップロード速度を使用してください。(Microsoft Learn)
既存環境で対応が必要かを判断する
現在の構成によって、必要な対応は異なります。
| 現在の状態 | 推奨する対応 |
|---|---|
| Normal Churnで、ピーク時も54 MB/sを十分に下回る | 原則として変更不要。RPOとレプリケーション正常性の監視を継続する |
| Normal Churnで54 MB/s付近まで増加している | High Churnへの変更を検討する |
| Normal Churnで未送信データやRPO悪化が発生している | ディスク、メモリ、リージョン、コストを確認し、High Churnを試験する |
| 既にHigh Churnを利用している | Mobility serviceを9.66.7640.1以降へ更新する |
| 既存High Churnで、ポータルから再起動を求められた | 再起動して対応カーネルドライバーを読み込む |
| 新しくAzure Site Recoveryを設定する | 条件を満たすVMでHigh Churnを選択すれば、500 MB/s上限が自動適用される |
| Premium SSD v2またはUltra Diskを利用している | High Churnが必要。PowerShell利用時もPremiumキャッシュを指定する |
| オンプレミスやVMwareからAzureへ複製している | 今回の500 MB/s拡張の対象外 |
既にHigh Churnで保護しているVMは、条件を満たしたうえでMobility serviceを更新すれば、500 MB/sの上限を利用できます。
一方、Normal ChurnからHigh Churnへ変更する場合は、保護中の設定を直接切り替えられません。一度レプリケーションを無効化し、High Churnを指定して再度有効化する必要があります。再構成と初期レプリケーションの間はDR保護状態に影響するため、通常の設定変更ではなく、業務システムの変更作業として計画してください。(Microsoft Learn)
High Churnを有効にする手順
High Churnは、レプリケーションを有効にする際に設定します。
- 対象VMのチャーン、RPO、レプリケーション正常性を確認します。
- VMのメモリ、OS、ディスク種類、ソースリージョン、ターゲットリージョンをサポートマトリクスと照合します。
- ソースVMと同じリージョンにPremium Block Blobのキャッシュストレージを用意します。
- Recovery Services vaultで対象のソースVMを選択し、レプリケーション設定を開きます。
Replication SettingsのStorageから、View/edit storage configurationを選択します。Churn for the VMでHigh Churnを選択します。- キャッシュストレージとしてPremium Block Blobアカウントを指定します。
- その他のターゲット設定を確認し、レプリケーションを開始します。
- 初期レプリケーション完了後、レプリケーション正常性、RPO、データアップロード速度を確認します。
- 本番適用前にテストフェールオーバーを実行します。
VMの画面から設定する場合は、Virtual machines、対象VM、Operations、Disaster recovery、Advanced settings、Storage settingsの順に進み、High Churnを選択します。(Microsoft Learn)
データ境界はソース、キャッシュ、ターゲットを一体で確認する
Azure Site Recoveryでは、ソースVMのディスク変更が、そのままターゲットリージョンへ直接書き込まれるわけではありません。
データは次の順序で処理されます。
- ソースVM上のディスク書き込みをMobility serviceが追跡する
- 変更データをソースVMと同じリージョンのキャッシュストレージへ送る
- キャッシュ内のデータを処理する
- ターゲットリージョンのレプリカマネージドディスクへ送る
- ターゲット側で回復ポイントを生成する
キャッシュストレージは、保護対象VMと同じリージョンに配置する必要があります。ターゲットリージョンにはレプリカディスクと回復ポイントが作成されます。Recovery Services vaultにも配置リージョンがあり、標準的なAzure-to-Azure構成ではソースリージョン以外に作成します。(Microsoft Learn)
個人情報、機密情報、医療情報などを含むVMを保護する場合は、少なくとも次の配置先をデータ境界の確認対象に含めます。
- ソースVMとソースディスク
- ソースリージョンのキャッシュストレージ
- ターゲットリージョンのレプリカディスク
- Recovery Services vault
- 診断ログを送るLog Analyticsワークスペース
- 暗号鍵を管理するKey VaultやDisk Encryption Set
Japan EastとJapan Westを組み合わせれば、レプリケーション対象データを日本国内のAzureリージョンに配置する設計は可能です。ただし、組織のデータ分類規程では、業務データだけでなく、ログ、メタデータ、暗号鍵の配置先まで確認してください。
通信はTLS 1.2で保護される
Azure Site Recoveryは、転送中のデータをTLSで保護し、現在はTLS 1.2を使用します。また、ソースとターゲットのデータ転送時にはチェックサムを使用して整合性を確認します。(Microsoft Learn)
Azure-to-Azureのレプリケーションでは、エンドポイントがパブリックであっても、既定の経路ではレプリケーショントラフィックがインターネットを通過しないとMicrosoftは説明しています。ただし、ユーザー定義ルートで通信をオンプレミス側へ迂回させる構成は推奨されていません。(Microsoft Learn)
Private Linkを利用する場合の注意点
Azure Site Recoveryは、Recovery Services vaultへのPrivate Endpointをサポートしています。Private Endpointを作成すると、対象のvaultはPrivate Endpointが存在するネットワークからのみアクセスできる構成にできます。
ただし、Private Endpointは原則として、まだ保護対象が登録されていない新しいvaultに対して作成する必要があります。既存vaultを後から完全閉域化できるとは限らないため、ネットワーク設計の初期段階で決めておく必要があります。(Microsoft Learn)
また、公式のPrivate Endpoint手順には、ストレージ側のPrivate EndpointはGPv2ストレージアカウントで作成するという記載があります。一方、High ChurnはPremium Block Blobのキャッシュを必要とします。
High Churnとストレージを含む完全閉域化を同時に採用する場合は、記事執筆時点のドキュメントだけで組み合わせを断定せず、構築時の最新情報またはMicrosoft Supportでサポート可否を確認するのが安全です。(Microsoft Learn)
カスタマーマネージドキーを使う場合
CMKで暗号化されたマネージドディスクを保護する場合は、レプリケーションを有効にする前に、ターゲットリージョン側へDisk Encryption Setを用意します。
Azure Site Recoveryで保護している間の暗号鍵ローテーションには制約があり、鍵を変更した場合はレプリケーションの無効化と再有効化が必要になることがあります。High Churnへの変更と鍵ローテーションを同じタイミングで行うと作業範囲が大きくなるため、別々の変更として計画した方が安全です。(Microsoft Learn)
管理者が設定すべきアクセス制御
Azure Site Recoveryには、役割分担に利用できる3つの組み込みロールがあります。
| ロール | 主な権限 | 推奨する担当者 |
|---|---|---|
| Site Recovery Contributor | レプリケーションの有効化、無効化、設定管理など | DR設計・管理担当者 |
| Site Recovery Operator | フェールオーバー、再保護、フェールバックの実行 | DR訓練・障害対応担当者 |
| Site Recovery Reader | 設定と状態の参照 | 監視担当者、監査担当者 |
Site Recovery Contributorは、Recovery Services vault内のSite Recovery操作を管理できますが、vaultの作成・削除や他のユーザーへの権限付与はできません。
Site Recovery Operatorは、フェールオーバーやフェールバックを実行できますが、レプリケーションの有効化や無効化はできません。そのため、日常の構成変更担当者と、実災害時に切り替えを実行する担当者を分離できます。(Microsoft Learn)
実務では、次のように分離すると誤操作を抑えやすくなります。
- インフラ管理者にはSite Recovery Contributor
- DR訓練と障害対応の実行者にはSite Recovery Operator
- 監視センターや監査担当者にはSite Recovery Reader
- vault作成やRBAC変更は、さらに限定したサブスクリプション管理者
Azure Policyによる一括適用には制約がある
Azure Policyを使うと、サブスクリプションやリソースグループ内の新しいVMへAzure Site Recoveryを自動的に有効化できます。既存VMについても修復タスクによる適用が可能です。
ただし、公式のAzure Policyサポート表では、Ultra Disk、Private Endpoint、CMK対応ディスク、クロスサブスクリプションなどが未サポートとされています。また、組み込みポリシーの設定項目にはHigh Churnを明示的に選択するパラメーターが示されていません。
そのため、500 MB/sを必要とする高チャーンVMを、一般的なVMと同じAzure Policyで一括保護する運用は避けた方がよいでしょう。通常VMと高チャーンVMをタグやリソースグループで分け、高チャーンVMは個別の設計レビューを通す方法が現実的です。(Microsoft Learn)
構成自動化ではAzure PowerShellとREST APIがサポートされています。一方、Azure-to-Azureの公式サポートマトリクスでは、Azure CLIは現時点で未サポートとされています。既存のCI/CDパイプラインがAzure CLI前提の場合は、PowerShellまたはREST APIへの切り替えを検討してください。(Microsoft Learn)
RPOとチャーンを継続的に監視する
500 MB/sへ上限を引き上げても、監視を行わなければレプリケーション遅延を早期に検知できません。
Recovery Services vaultの診断設定から、Azure Site Recovery関連ログをLog Analyticsへ送信すると、次の情報を確認できます。
- レプリケーション正常性
- 保護対象VMのRPO
- ディスク単位のデータ変更率
- レプリケーションデータのアップロード速度
- 回復ポイントの生成状況
- テストフェールオーバーの結果
- Site Recoveryジョブの成功・失敗
ログを有効にする際は、診断設定でAzureSiteRecoveryから始まるログカテゴリーを選択し、Log Analyticsワークスペースへ送信します。(Microsoft Learn)
判断には瞬間的な最大値だけでなく、月末処理、バックアップ時間帯、バッチ実行、データ投入、繁忙時間帯を含む期間を使います。平常時の平均値が20 MB/sでも、月末処理で120 MB/sまで上がるならNormal Churnでは不十分です。
Azure Site Recoveryには、レプリケーション正常性の重大化、フェールオーバー失敗、エージェント期限切れなどの組み込みアラートがあります。通知をメール、Webhook、Logic Appsなどへ送るには、Azure Monitorでアラート処理ルールとアクショングループを設定します。(Microsoft Learn)
業務や開発でHigh Churnが向いているケース
High Churnの500 MB/s対応が特に有効なのは、Azure VM上で稼働するステートフルかつ書き込み量の多いシステムです。
導入効果を得やすいケース
- Azure VM上の大規模なリレーショナルデータベース
- トランザクションログの書き込みが多い基幹システム
- 大量のデータを継続的に取り込むデータ処理サーバー
- 書き込み負荷の高いファイル処理基盤
- 複数のPremium SSDやUltra Diskへ並列書き込みするVM
- 従来の100 MB/s上限に達し、RPOが悪化していたVM
- 256 GB以上のメモリを持つ大規模な統合サーバー
- リージョン障害時にも短いRPOが求められる業務システム
優先度が低いケース
- チャーンが54 MB/sを十分に下回るVM
- 現在のRPOとレプリケーション正常性に問題がないVM
- 障害時にIaCから短時間で再構築できるステートレスなアプリケーションサーバー
- 一時データだけを扱うCI/CDエージェント
- 小容量ディスク1台だけで構成されたVM
- 100 MB/sを超えるHigh Churnに未対応のLinuxディストリビューション
- オンプレミスやVMwareからAzureへ複製する環境
500 MB/sという数値だけで導入対象を決めるのではなく、「現在の書き込み量が既存上限を超えているか」「RPOに実害があるか」「VM全体を複製することが適切か」で判断してください。
コストと失敗しやすいポイント
High ChurnではPremium Block Blobのキャッシュストレージを使用するため、Normal Churnで使うStandardストレージよりコストが高くなる可能性があります。変更データ量が増えれば、レプリケーションに伴うネットワーク関連コストも増える可能性があります。(Microsoft Learn)
特に注意したいのは次の点です。
- 500 MB/sが必要か確認せず、すべてのVMをHigh Churnにする
- VMに256 GB以上のメモリがないのに500 MB/sを想定する
- 1台のディスクで500 MB/sを処理できると誤解する
- 小さな書き込みサイズによるディスク単位制限を確認しない
- Premium Block Blobの料金とトランザクションを見積もらない
- ソースVMのCPUやネットワーク余力を確認しない
- Normal Churnから直接切り替えられると思い込む
- Mobility serviceを更新しても、必要な再起動を実施しない
- ターゲットリージョンのVMクォータや対象SKUを確保しない
- 設定変更後にテストフェールオーバーを実行しない
また、RPOを短縮できても、フェールオーバー後にアプリケーションが正常起動するとは限りません。DNS、ロードバランサー、秘密情報、外部接続先、認証基盤などを含むDR手順を整備し、定期的にテストする必要があります。
対応要否を判断するための最終チェック
今回の更新に対応すべきか迷う場合は、次の順序で判断します。
- Azure MonitorまたはLog Analyticsで現在のチャーンを測定する
- 平均値ではなく、業務ピーク時と定期処理時の値を確認する
- 現在のRPOと未送信データ量を確認する
- 54 MB/s以内ならNormal Churnを継続する
- 54 MB/sを超えるならHigh Churnを検討する
- 100 MB/sを超えるなら500 MB/sのサポート条件と照合する
- 代表VM1台でHigh Churnを試験する
- コスト、CPU、メモリ、ネットワークへの影響を確認する
- テストフェールオーバーを実施する
- 結果を確認してから対象VMを拡大する
今回のGAは、高IOPS・高書き込みのAzure VMにとって重要な更新です。一方で、最大500 MB/sという数値は、単純な設定変更だけで得られる性能ではありません。
まず行うべきことはHigh Churnの一括有効化ではなく、現在のチャーンとRPOの計測です。既存上限が問題になっているVMだけを抽出し、サポート条件、データ境界、コスト、管理権限を確認したうえで、1台ずつテストすることが安全な導入手順です。
コメント