Azure Site Recovery（ASR）で、Azure VMあたりのサポート対象チャーンが最大500 MB/秒へ引き上げられました。従来のHigh Churnは最大100 MB/秒だったため、上限は5倍になります。2026年7月7日にAzure Updatesで一般提供として案内された更新であり、書き込み量の多いデータベースや業務システムのRPO改善が期待できます。(Microsoft Azure)
ただし、すべてのAzure VMが自動的に500 MB/秒へ対応するわけではありません。Azure間レプリケーション、256 GB以上のメモリ、対応ディスク、対応リージョン、所定のMobility Serviceなど、複数の条件を満たす必要があります。
結論として、現在のチャーンが100 MB/秒を超えている、またはデータ変更量の増加によってRPOが悪化している環境は対応を検討すべきです。一方、通常時もピーク時も54 MB/秒以内で安定しているVMは、急いでHigh Churnへ切り替える必要はありません。
なお、今回の更新はAI機能の追加ではなく、Azure VMのディザスターリカバリーにおけるレプリケーション性能の拡張です。
Azure Site Recoveryの500 MB/秒対応で何が変わるのか
Azure Site Recoveryにおける「チャーン」とは、ソースVMのディスク上で1秒間に変更されるデータ量です。
チャーンは、単純なディスクIOPSやネットワーク速度とは異なります。読み取り中心でIOPSが高いシステムは、チャーンが小さいことがあります。反対に、ログやトランザクションを大量に書き込むシステムでは、IOPSが同程度でもチャーンが大きくなります。
今回変更されたのは、High Churnを選択したAzure VMについて、条件を満たせばVMあたり最大500 MB/秒までのデータ変更をサポートできる点です。既定のNormal Churnは、引き続きVMあたり最大54 MB/秒です。(Microsoft Learn)
| 構成 | VMあたりの最大チャーン | ディスクあたりの最大チャーン | キャッシュストレージ |
|---|---|---|---|
| Normal Churn | 54 MB/秒 | 20 MB/秒 | Standardストレージ |
| High Churn・メモリ32 GB以上256 GB未満 | 100 MB/秒 | 50 MB/秒 | Premium Block Blob |
| High Churn・メモリ256 GB以上 | 500 MB/秒 | 最大250 MB/秒 | Premium Block Blob |
500 MB/秒は保証される実効速度ではなく、サポート上限です。実際に処理できるチャーンは、VMサイズ、ディスク構成、書き込みサイズ、ネットワーク帯域、CPU使用率などのうち、最も低い上限に制約されます。
RPO改善につながる理由
従来の上限を超える変更データが発生すると、レプリケーション処理が追い付かず、未送信データが蓄積します。その結果、最新の復旧ポイントと現在時刻との差が広がり、RPOが悪化しやすくなります。
500 MB/秒対応によって、これまでAzure Site Recoveryだけでは追随しにくかった高書き込みワークロードでも、変更データをより速くターゲットリージョンへ送信できる可能性が高まります。
ただし、上限の引き上げだけで目標RPOが保証されるわけではありません。ピーク時のチャーン、ネットワーク、ディスク性能、キャッシュ、アプリケーション整合性を含めて検証する必要があります。
VMあたり500 MB/秒を利用するための条件
最大500 MB/秒を利用するには、次の条件をすべて確認します。1つでも満たしていない場合、上限が100 MB/秒または54 MB/秒に制限される可能性があります。(Microsoft Learn)
| 確認項目 | 500 MB/秒利用時の要件 |
|---|---|
| レプリケーション方式 | Azure VMから別のAzureリージョンへのAzure-to-Azure構成 |
| ソースディスク | マネージドディスク |
| ディスク種類 | Premium SSD v1、Premium SSD v2、Ultra Disk |
| VMメモリ | 256 GB以上 |
| Windows | Azure Site Recoveryのサポート対象Windows |
| Linux | RHEL 9、SLES 15、Ubuntu 24.04 |
| リージョン | ソースとターゲットの両方が500 MB/秒対応リージョン |
| Mobility Service | 9.66.7640.1以降 |
| キャッシュ | Premium Block Blobストレージアカウント |
| CPU・ネットワーク | レプリケーション処理に必要な余力があること |
日本リージョンは東日本と西日本が対象
公式の対応リージョンには、Japan EastとJapan Westの両方が含まれています。
ただし、ソースだけでなくターゲットも対応リージョンであることが必要です。たとえば東日本から西日本へのレプリケーションでは両方が対象ですが、片方に未対応リージョンを選ぶと500 MB/秒の要件を満たせません。
対応リージョンは今後変更される可能性があるため、新規構築や構成変更の直前にも公式のサポートマトリックスを確認してください。(Microsoft Learn)
Linuxはディストリビューションに注意する
Azure Site RecoveryがサポートするLinuxであっても、すべてが500 MB/秒に対応するわけではありません。
100 MB/秒までであれば、Azure Site Recoveryのサポート対象となる複数のLinuxディストリビューションを利用できます。一方、100 MB/秒を超えて500 MB/秒まで利用できるのは、RHEL 9、SLES 15、Ubuntu 24.04に限定されています。
OS名だけでなく、カーネルとMobility Serviceの対応状況も確認が必要です。特にLinuxのカーネルを更新した直後は、Mobility Serviceとの互換性を確認してから本番運用へ反映します。
VMのCPUとネットワークにも余力が必要
Microsoftのドキュメントでは、Site RecoveryによるピークCPU使用率が18%に達する可能性があるとされています。業務処理でCPUを常時使い切っているVMでは、レプリケーション性能だけでなく、アプリケーション側の応答時間にも影響する可能性があります。(Microsoft Learn)
また、500 MB/秒はビット換算すると約4 Gbpsです。これは通信オーバーヘッドを含まない単純換算であるため、VMサイズごとのネットワーク帯域上限や、同一VM上の他の通信も考慮する必要があります。
500 MB/秒はディスク構成によって到達できないことがある
VM全体の上限が500 MB/秒でも、1台のディスクが処理できるチャーンは最大250 MB/秒です。さらに、ディスク容量とアプリケーションの書き込みサイズによって、ディスク単位の上限が変わります。
公式の検証値から代表的な構成を抜粋すると、次のようになります。実環境ではI/Oの混在状況によって結果が変わります。(Microsoft Learn)
| ソースディスク容量 | 8 KB書き込み | 32 KB書き込み | 64 KB書き込み | 256 KB以上 |
|---|---|---|---|---|
| 128 GiB | 3.9 MB/秒 | 11.5 MB/秒 | 33.1 MB/秒 | 100 MB/秒 |
| 1,024 GiB | 39.1 MB/秒 | 156.3 MB/秒 | 200 MB/秒 | 200 MB/秒 |
| 2,048 GiB | 58.6 MB/秒 | 234.4 MB/秒 | 250 MB/秒 | 250 MB/秒 |
| 8,192 GiB | 125 MB/秒 | 250 MB/秒 | 250 MB/秒 | 250 MB/秒 |
たとえば、2 TiBのディスク1台だけで構成されたVMは、ディスク単位の上限が250 MB/秒であるため、VM全体の500 MB/秒には到達できません。
500 MB/秒に近いチャーンを処理するには、複数ディスクへ書き込みが分散され、それぞれのディスクサイズとI/Oサイズが十分な条件を満たしている必要があります。単に大容量VMへサイズ変更するだけでは不十分です。
自社環境で対応が必要か判断する基準
High Churnは、対象となるすべてのVMへ一律に適用する機能ではありません。まず現在のデータ変更率とRPOを確認し、問題が起きているVMだけを候補にします。
| 現在の状況 | 推奨する対応 |
|---|---|
| ピーク時も54 MB/秒未満で、RPOが安定している | Normal Churnを継続 |
| 54～100 MB/秒の変更が発生する | High Churnを検討。500 MB/秒対応は必須ではない |
| 100 MB/秒を超え、RPO悪化や警告がある | 500 MB/秒対応の要件を確認 |
| 1ディスクで250 MB/秒を超える | ディスク分割やアプリケーション構成の見直しが必要 |
| VM全体で500 MB/秒を継続的に超える | Azure Site Recovery以外の複製方式も含めて再設計 |
| IOPSは高いがチャーンを測定していない | 切り替えず、最初に変更データ量を測定 |
Azure Site Recoveryは、サポート上限を超えるデータ変更を検出すると、「Data change rate beyond supported limits」に相当するイベントを生成します。Azureポータルでは、対象VMの「Replicated items」から「Events – last 72 hours」を確認できます。(Microsoft Learn)
平均値だけでなく、次の時間帯を含めて確認することが重要です。
- 月末・年度末処理
- 夜間バッチ
- 大量データの取り込み
- インデックス再構築
- ログローテーション
- リリースやデータ移行
- 性能試験
日中の平均チャーンが低くても、バッチ処理中だけ上限を超えているケースがあります。
新規VMと既存VMでは適用方法が異なる
新しく保護するVM
新規にレプリケーションを設定する場合は、ストレージ設定の「Churn for the VM」でHigh Churnを選択します。
Recovery Servicesコンテナーから設定する場合は、次の順序です。
- レプリケーション対象のAzure VMを選択する
- 「Replication Settings」の「Storage」を開く
- 「View/edit storage configuration」を選択する
- 「Churn for the VM」でHigh Churnを選択する
- Premium Block Blobのキャッシュストレージを指定する
- 他のターゲット設定を確認し、レプリケーションを開始する
Azure VMの画面から設定する場合は、「Operations」から「Disaster recovery」を開き、「Advanced settings」のストレージ設定でHigh Churnを選択します。(Microsoft Learn)
すでにHigh Churnで保護しているVM
すでにHigh Churnを選択しているVMは、ほかの要件を満たしたうえでMobility Serviceを9.66.7640.1以降へ更新します。
Azureポータルのエージェント更新タスクで再起動を求められた場合は、VMを再起動して対応するカーネルドライバーを読み込ませます。業務影響があるため、再起動は保守時間帯に実施してください。(Microsoft Learn)
Normal Churnから切り替えるVM
既存の保護VMについて、Normal ChurnからHigh Churnへ設定だけを変更することはできません。
一度レプリケーションを無効化し、High Churnを選択して再度有効化する必要があります。再構成に伴って初期レプリケーションや再同期が発生し、作業中は従来の保護状態が維持されない時間が生じる可能性があります。変更前に、作業手順、保護空白時間、ロールバック方法を整理しておく必要があります。(Microsoft Learn)
レプリケーションデータの境界を確認する
Azure Site Recoveryを導入する際は、性能だけでなく、どのデータがどのリージョンへ移動するかを確認します。
Azure-to-Azure構成では、VMのディスク変更がソースリージョン内のキャッシュストレージへ一時保存され、その後ターゲットリージョンのレプリカディスクへ送信されます。High Churnでは、このキャッシュとしてPremium Block Blobストレージアカウントを使用します。(Microsoft Learn)
| データの種類 | 保存・転送先 | 管理上の確認点 |
|---|---|---|
| VMの変更データ | ソースVMからソースリージョンのキャッシュへ送信 | キャッシュのリージョン、種類、アクセス制御 |
| レプリケーションデータ | キャッシュからターゲットリージョンへ送信 | データ所在地、転送コスト、暗号化 |
| レプリカディスク | ターゲットリージョン | ディスク暗号化、容量、冗長性 |
| Site Recoveryの制御情報 | Recovery Servicesコンテナー | メタデータの所在地とアクセス権 |
| 監視ログ | 選択したLog Analyticsワークスペース | ワークスペースのリージョンと保持期間 |
Microsoftは、実際の顧客データを選択したソースリージョンとターゲットリージョンの外へ移動・保存しないと説明しています。Recovery Servicesコンテナーを別の第3リージョンに配置することもできますが、コンテナーが保持するのはレプリケーションやフェールオーバーを制御するメタデータであり、実際のVMデータではありません。(Microsoft Learn)
暗号化と鍵管理
Azure-to-Azure Site Recoveryでは、通信にTLS 1.2が使用され、Azure上の保存データについても暗号化がサポートされています。(Microsoft Learn)
カスタマーマネージドキーで暗号化されたマネージドディスクを複製する場合は、レプリケーションを有効化する前にターゲットリージョンへDisk Encryption Setを作成します。
また、保護中の暗号化VMについて、Azure Site Recoveryはキーのローテーションをそのままサポートしていません。キーを変更する場合は、レプリケーションの無効化と再有効化が必要です。(Microsoft Learn)
監視ログのリージョンもデータ境界に含める
診断設定を有効にすると、レプリケーションの状態、RPO、チャーン、ジョブ履歴などをLog Analyticsへ送信できます。
この場合、運用ログは選択したLog Analyticsワークスペースに保存されます。VMデータのレプリケーション先だけでなく、ワークスペースのリージョン、保持期間、アクセス権も社内のデータ所在地ルールに適合させる必要があります。(Microsoft Learn)
Private Endpointを利用する場合の注意点
Azure Site Recoveryは、Recovery ServicesコンテナーへのPrivate Endpointを利用できます。ただし、Private Endpointは保護対象がまだ登録されていない新しいコンテナーに対して事前に作成する必要があります。既存の本番コンテナーへ後から追加する前提で設計しないようにしてください。(Microsoft Learn)
また、公式のPrivate Endpoint手順では、ストレージ用Private Endpointの対象をGeneral Purpose v2としています。一方、High ChurnのキャッシュにはPremium Block Blobが必要です。(Microsoft Learn)
キャッシュを含むすべての経路をPrivate Linkに限定することが必須の組織では、両要件の適合状況を構築時点の公式資料で再確認し、事前検証またはMicrosoftサポートへの確認を行うのが安全です。
管理者が設定すべきアクセス制御
Azure Site Recoveryには、役割分担に利用できる3つの組み込みロールがあります。全担当者へOwnerやContributorを付与するのではなく、操作内容に応じて最小権限を割り当てます。(Microsoft Learn)
| ロール | 主な権限 | 適した担当者 |
|---|---|---|
| Site Recovery Contributor | レプリケーションの有効化、構成、管理 | DR基盤管理者 |
| Site Recovery Operator | フェールオーバー、再保護、フェールバック | 障害対応オペレーター |
| Site Recovery Reader | 状態やジョブの参照 | 監視担当者、監査担当者 |
Site Recovery ContributorはSite Recoveryの管理操作を実行できますが、Recovery Servicesコンテナーの作成・削除や、他ユーザーへのアクセス権付与はできません。
Site Recovery Operatorはフェールオーバーやフェールバックを実行できますが、レプリケーションの有効化・無効化はできません。この違いを利用すると、平常時の構成変更と緊急時の復旧操作を分離できます。
実務で推奨する管理体制
本番環境では、次のように役割を分けると誤操作を抑えやすくなります。
| 管理対象 | 推奨する担当 |
|---|---|
| High Churnの選定と構成変更 | DR基盤管理者 |
| Premium Block Blobの作成とネットワーク設定 | ストレージ・ネットワーク管理者 |
| Mobility Serviceの更新とVM再起動 | サーバー管理者、アプリケーション担当 |
| フェールオーバー判断 | 業務責任者、インシデント責任者 |
| フェールオーバー実行 | Site Recovery Operator |
| RPO・チャーン・ジョブ監視 | 監視担当者 |
| コスト確認 | クラウド管理者、FinOps担当 |
High Churnへの切り替え、レプリケーションの無効化、ターゲットリージョン変更は、通常の軽微な設定変更ではありません。作業申請、影響確認、承認、テストフェールオーバーまでを一連の変更管理として扱うべきです。
Azure Monitorで監視すべき項目
Azure Site Recoveryのリソースログは、診断設定を作成しない限りLog Analyticsへ保存されません。Recovery Servicesコンテナーの「Diagnostic settings」から、Azure Site Recovery関連のログをワークスペースへ送信します。(Microsoft Learn)
最低限、次の項目を監視します。
- レプリケーションの正常性
- 現在のRPO
- ディスクおよびVMのチャーン
- Mobility Serviceのバージョン
- Site Recoveryの警告とエラー
- レプリケーションジョブの失敗
- テストフェールオーバーの実施状況
500 MB/秒対応後も、上限近くで常時稼働させるのは望ましくありません。平常時の値だけでなく、ピーク値と増加傾向を監視し、余裕がなくなる前にディスク分割やシステム構成の見直しを行います。
業務や開発で有効な使いどころ
書き込みの多いデータベースVM
SQL Server、Oracle Database、PostgreSQLなどをAzure VM上で運用し、トランザクションログやデータファイルへの書き込みが多い環境は、有力な対象です。
特に次のような状況では効果が期待できます。
- 注文や決済を継続的に処理している
- 大量のログを短時間に記録する
- 夜間バッチで多数のレコードを更新する
- インデックス作成やデータロードが頻繁に行われる
- 従来の100 MB/秒上限によってRPOが悪化している
ただし、500 MB/秒対応はアプリケーション整合性を自動的に保証するものではありません。Azure Site Recoveryは既定でクラッシュ整合性の復旧ポイントを作成し、設定に応じてアプリケーション整合性の復旧ポイントも作成します。データベース固有の整合性や極めて短いRPOが必要な場合は、データベースネイティブのレプリケーション方式と比較してください。(Microsoft Learn)
ログ収集・データ取り込み基盤
センサー、Webアクセス、アプリケーションログなどをVMへ集約し、継続的にディスクへ書き込むシステムも対象になります。
ただし、保存先をAzureのマネージドサービスへ移行できる場合は、VM全体を複製するよりも、データ基盤自体を冗長化したほうが運用しやすいことがあります。High Churnの採用だけでなく、VM上に状態を持ち続ける必要があるかも検討します。
ERPや大規模バッチ処理
ERP、会計、在庫、製造管理など、特定時間帯に大量の更新が集中する業務システムでは、平均値ではなくピーク時のチャーンが問題になります。
月末処理や締め処理を含めて計測し、ピーク時も目標RPOを維持できるか確認してください。
開発・リリース基盤
一般的な開発用VMや使い捨てのビルドエージェントに、500 MB/秒対応は通常必要ありません。
一方、次のような状態を持つ共有基盤が停止するとリリース業務全体が止まる場合は、DRの対象になり得ます。
- 社内向け成果物リポジトリ
- リリース管理データベース
- 大規模テストデータの管理サーバー
- 自社運用のCI/CD制御サーバー
- 開発部門共通のライセンス・構成管理サーバー
再構築可能なサーバーまで一律に保護せず、停止時の業務影響と復旧コストで判断します。
High Churnが不要になりやすい構成
次のような環境では、Normal Churnのままで十分な可能性があります。
- ステートレスなWebサーバー
- 読み取り中心のアプリケーション
- イメージやコードから短時間で再構築できるVM
- ピーク時もチャーンが54 MB/秒未満のVM
- 重要データを外部のマネージドサービスへ保存しているVM
- 災害復旧の対象外である一時的な検証環境
コスト面で確認すべきポイント
High Churnでは、Normal ChurnのStandardストレージではなく、Premium Block Blobをキャッシュに使用します。このため、キャッシュストレージの料金が増える可能性があります。
加えて、ターゲット側のレプリカストレージ、ストレージトランザクション、リージョン間のデータ転送が課金対象になります。チャーンが大きいVMほど、差分レプリケーションで処理されるデータ量も増加します。(Microsoft Learn)
見落としやすいコストは次のとおりです。
- Premium Block Blobの容量とトランザクション
- ターゲットリージョンのレプリカディスク
- リージョン間データ転送
- 初期レプリケーションと再同期
- 256 GB以上のメモリを持つVMサイズ
- テストフェールオーバー中のVMコンピューティング料金
- Log Analyticsの取り込み量と保持期間
- Private Endpointを使用する場合の関連料金
500 MB/秒を使うためだけにVMを256 GB以上へ拡大する場合は、VM料金の増加も含めて比較します。アプリケーションを複数VMへ分割する、書き込み先を分散する、データベースのネイティブレプリケーションを使うといった代替案のほうが合理的な場合もあります。
導入時に失敗しやすいポイント
High IOPSだけを見て切り替える
High Churnが対象とするのは、読み書きを合わせたIOPSではなくデータ変更率です。読み取り負荷の高いVMにHigh Churnを適用しても、効果が得られない可能性があります。
500 MB/秒を保証値として扱う
500 MB/秒はVM単位の上限です。ディスク単位では最大250 MB/秒であり、小容量ディスクや小さい書き込みサイズではさらに低くなります。
エージェント更新だけで切り替わると思う
すでにHigh ChurnのVMであれば、Mobility Serviceの更新によって新上限を利用できる可能性があります。
Normal Churnの既存VMは、エージェントを更新するだけではHigh Churnになりません。レプリケーションを無効化し、High Churnを選択して再度有効化する必要があります。
本番負荷を再現せずに完了とする
初期レプリケーションが完了しただけでは、ピーク時のRPOを維持できるか判断できません。夜間バッチやデータ取り込みを含む負荷条件で確認します。
DRとバックアップを同じものとして扱う
Azure Site Recoveryは、リージョン障害などに備えてシステムを別の場所で起動するためのDR機能です。
長期保管、法定保存、誤削除対策、過去データの個別復元といった要件を、Site Recoveryの復旧ポイントだけで満たせるとは限りません。バックアップの保持要件は別に設計してください。
実際に対応する手順
| 手順 | 実施内容 | 完了の判断基準 |
|---|---|---|
| 現状測定 | RPO、チャーン、警告を確認 | 通常時とピーク時の値を把握できている |
| 対象選定 | 100 MB/秒超過やRPO悪化のあるVMを抽出 | 適用理由をVM単位で説明できる |
| 要件確認 | RAM、OS、ディスク、リージョン、エージェントを確認 | 500 MB/秒の全要件を満たしている |
| 性能確認 | VMネットワーク、CPU、ディスク上限を確認 | ボトルネック候補を把握している |
| 境界確認 | キャッシュ、ターゲット、ログのリージョンを確認 | 社内のデータ所在地ルールに適合している |
| コスト試算 | Premiumキャッシュ、転送、レプリカ、VM料金を試算 | 予算と費用対効果を承認済み |
| 設定変更 | High Churnを選択し、必要なら再保護 | レプリケーションが正常に開始している |
| エージェント更新 | 9.66.7640.1以降へ更新 | 対象バージョンを確認できている |
| 負荷検証 | 業務ピークを含めてRPOとCPUを確認 | 社内RPOと性能基準を満たしている |
| DR訓練 | テストフェールオーバーを実施 | アプリケーションを復旧・確認できる |
| 運用監視 | ログ、アラート、定期レビューを設定 | 異常を自動検知できる |
まず実施すべきこと
Azure Site Recoveryの500 MB/秒対応は、書き込み量の多いAzure VMにとって重要な更新です。ただし、Normal Churnで問題のないVMまで一律に変更すると、Premiumストレージのコストや構成管理の負担が増えます。
最初に行うべきことは、対象VMのチャーンとRPOを測定することです。そのうえで、次の順序で判断します。
- 100 MB/秒を超えているか
- RPO悪化の原因がチャーンにあるか
- メモリ、ディスク、OS、リージョンの要件を満たすか
- Premium Block Blobとデータ転送のコストを許容できるか
- データ境界とアクセス制御の要件を満たすか
- ピーク負荷とテストフェールオーバーで効果を確認できるか
すでにHigh Churnを利用している場合は、Mobility Serviceのバージョン確認を優先します。Normal Churnを利用している場合は、レプリケーションの再構成が必要になるため、保護の空白時間を含めた変更計画を作成してから実施してください。
コメント