Azure DocumentDBの「Service-managed failover」が一般提供され、マルチリージョンクラスターでリージョン障害が発生した際に、Azure DocumentDBがレプリカクラスターを自動的に昇格できるようになりました。結論から言うと、これは障害時の手動フェールオーバー作業を減らせる重要なDR機能ですが、有効化は任意で、既定では無効です。また、非同期レプリケーションを前提とするため、障害直前に複製されていない書き込みが失われる可能性があります。(Microsoft for Developers)
本番環境でAzure DocumentDBを複数リージョン構成にしている管理者や開発者は、まず「クロスリージョンレプリカがあるか」「Service-managed failoverを有効化しているか」「アプリケーションがglobal read-write connection stringを使っているか」を確認してください。特に、ゼロデータロスが必要な計画切り替えにはGraceful promotion、リージョン障害時の自動復旧にはService-managed failover、と使い分けることが重要です。(Microsoft Learn)
Azure DocumentDBのService-managed failoverとは
Service-managed failoverは、Azure DocumentDBのプライマリリージョンにリージョン規模の障害が発生した場合に、Azure DocumentDB側が障害を検知し、セカンダリリージョンのレプリカクラスターを自動的に新しい書き込み可能クラスターへ昇格する機能です。Microsoftは、Azure DocumentDBのマルチリージョンクラスター向けにこの機能を一般提供したと発表しています。(Microsoft for Developers)
従来、Azure DocumentDBでリージョン障害に備える場合、運用者が監視、障害判断、レプリカの昇格判断、手動プロモーションを行う必要がありました。Service-managed failoverを有効にすると、このうち「障害を検知して、レプリカを昇格する」部分をサービス側に任せられます。(Microsoft for Developers)
ただし、これは単に「有効にすれば常に無停止・無損失になる」機能ではありません。ポイントは次の3つです。
| 確認項目 | 内容 |
|---|---|
| 対象 | Azure DocumentDBのマルチリージョンクラスター |
| 有効化 | プライマリクラスター側で明示的に有効化する必要がある |
| データ保護 | 非同期レプリケーションのため、未複製の書き込みは失われる可能性がある |
特に重要なのは、Service-managed failoverはリージョン障害時の復旧時間を短くするための機能であり、ゼロデータロスを保証する機能ではないという点です。
今回の一般提供で何が変わるのか
今回の変更で最も大きいのは、Azure DocumentDBのクロスリージョンDR構成において、リージョン障害時のフェールオーバーをAzure側で自動実行できる選択肢が正式に利用可能になったことです。
Azure DocumentDBでは、クロスリージョンレプリケーションを使うことで、プライマリクラスターのデータを別リージョンの読み取り専用レプリカへ非同期に複製できます。これまでも、障害時にはレプリカクラスターを昇格させて新しい読み書き可能クラスターにする運用が可能でしたが、Service-managed failoverではこの昇格をサービスが自動で行います。(Microsoft Learn)
管理者にとっての変更点
管理者にとっては、障害時のオペレーション設計が変わります。これまでは「監視アラートを受ける」「影響範囲を判断する」「手動でフェールオーバーする」といった判断と操作をランブックに組み込む必要がありました。
Service-managed failoverを有効化すると、リージョン障害が確認された際のレプリカ昇格はAzure DocumentDBが実行します。そのため、管理者はフェールオーバー操作そのものよりも、次の準備に重点を移すべきです。
| 管理者が確認すべきこと | 実務上の意味 |
|---|---|
| クロスリージョンレプリカの有無 | レプリカがなければService-managed failoverは機能しない |
| 有効化状態 | 既定では有効になっていないため、明示的な設定確認が必要 |
| 接続文字列の使い方 | アプリがglobal read-write connection stringを使っていないと、切り替え後に書き込み先更新が必要になる |
| データ損失許容度 | 未複製データが失われる可能性を業務側と合意しておく |
| 監視と通知 | 自動化されても、発生検知・影響確認・事後処理は必要 |
開発者にとっての変更点
開発者にとって重要なのは、フェールオーバー後にアプリケーションが新しいプライマリへ自然に接続できるようにしておくことです。
Azure DocumentDBでは、global read-write connection stringがアクティブな書き込み可能クラスターを指すように更新されます。Service-managed failoverやGraceful promotionの後も、アプリケーションがこの接続文字列を使っていれば、書き込み先の変更をアプリ側で直接管理しなくて済みます。(Microsoft Learn)
一方、旧プライマリのself connection stringをアプリケーションの書き込み先として固定している場合、昇格後に新しいプライマリへ向け直す必要があります。これを見落とすと、フェールオーバー自体は成功していても、アプリケーション側では書き込み失敗が続く可能性があります。(Microsoft Learn)
Service-managed failoverの仕組み
Service-managed failoverでは、Azure DocumentDBがプライマリリージョンの正常性を継続的に監視します。プライマリリージョンが利用できず、ゾーン内でのローカル復旧もできないと判断された場合、サービスがレプリカクラスターを自動的に昇格します。昇格後、global read-write connection stringは新しいプライマリを指すように更新されます。(Microsoft for Developers)
ただし、内部的には強制昇格に近い動作です。プライマリが到達不能な状態では、レプリケーションキューを完全に空にしてから切り替えることができません。そのため、プライマリ側ではコミット済みでも、セカンダリにまだ複製されていなかった書き込みは、新しいプライマリに存在しない可能性があります。(Microsoft for Developers)
つまり、Service-managed failoverは次のようなトレードオフを持ちます。
| 得られるメリット | 受け入れるべき制約 |
|---|---|
| リージョン障害時に人手なしで復旧を開始できる | 未複製の書き込みが失われる可能性がある |
| 手動判断による復旧遅延を減らせる | 障害発生後にさかのぼって有効化できない |
| アプリ側の接続先変更を減らせる | global read-write connection stringの利用が前提になる |
| DR運用の属人性を下げられる | 事後確認、整合性確認、業務影響判断は必要 |
3つのフェールオーバーモードの違い
Azure DocumentDBでは、クロスリージョンレプリカを新しい書き込み可能クラスターにする方法として、主に3つのフェールオーバーモードが用意されています。(Microsoft Learn)
| モード | 実行者 | 主な用途 | データ損失 | 自動化 |
|---|---|---|---|---|
| Forced promotion | 利用者 | 障害時の手動切り替え、DR訓練、任意タイミングの昇格 | 可能性あり | なし |
| Graceful promotion | 利用者 | 計画メンテナンス、リージョン移行、計画的な切り替え | ゼロデータロス | なし |
| Service-managed failover | Azure DocumentDB | リージョン障害時の自動復旧 | 可能性あり | あり |
Service-managed failoverを選ぶべきケース
Service-managed failoverは、リージョン障害時に運用者の判断を待たず、できるだけ早く復旧へ進みたいワークロードに向いています。
例えば、次のようなシステムでは検討価値が高いでしょう。
| ワークロード例 | 向いている理由 |
|---|---|
| ECサイトの商品閲覧・注文関連データ | 長時間の書き込み停止が売上に直結しやすい |
| SaaSの利用者設定・セッション周辺データ | 障害時の復旧速度が顧客体験に影響する |
| グローバル向けアプリの中核データベース | 単一リージョン停止の影響を抑えたい |
| 業務システムの高可用性構成 | 夜間・休日でも手動対応に依存しにくくなる |
ただし、金融取引、在庫引き当て、課金、監査ログなど、1件の欠損も許容しづらいデータでは、Service-managed failoverだけでなく、アプリケーション側の冪等性、補正処理、監査ログ、業務側の復旧手順まで含めて設計する必要があります。
Graceful promotionを選ぶべきケース
計画的にリージョンを切り替えるなら、Graceful promotionが適しています。Graceful promotionでは、新規書き込みを一時停止し、レプリケーションの未処理分をすべて反映してからレプリカを昇格するため、ゼロデータロスで切り替えられます。(Microsoft Learn)
利用シーンは次のようなものです。
| シーン | 推奨される理由 |
|---|---|
| 定期的なDR訓練 | データ損失なしで切り替え手順を検証できる |
| 計画メンテナンス | 業務影響を事前に通知しやすい |
| プライマリリージョンの恒久移行 | 安全に書き込みロールを移せる |
| コンプライアンス上データ欠損を避けたい切り替え | RPOゼロを重視できる |
ただし、Graceful promotionはプライマリクラスターが到達可能で、レプリケーションキューを排出できる状態でなければ使えません。すでにプライマリリージョンが利用不能な場合は、Forced promotionまたはService-managed failoverを使う必要があります。(Microsoft Learn)
Forced promotionを選ぶべきケース
Forced promotionは、管理者が明示的にレプリカを昇格する方法です。タイミングを完全に制御したい場合や、Service-managed failoverを有効化していない状態でプライマリリージョンが利用できなくなった場合に使います。(Microsoft Learn)
一方で、非同期レプリケーションの未反映分は失われる可能性があります。DR訓練や緊急時の手順として残しておくべきですが、ミッションクリティカルな本番環境では、Service-managed failoverやGraceful promotionとの使い分けを明確にしておくことが大切です。
有効化前に確認すべき前提条件
Service-managed failoverを利用するには、単に設定をオンにするだけでは不十分です。特に次の条件を確認してください。
| 確認項目 | 確認内容 | 見落とした場合のリスク |
|---|---|---|
| クロスリージョンレプリカ | 別Azureリージョンにアクティブなレプリカがあるか | フェールオーバー先が存在しない |
| 同一リージョンレプリカでないこと | クロスリージョンフェールオーバー対象は別リージョンのレプリカ | 想定したDR構成にならない |
| Service-managed failoverの有効化 | プライマリクラスターで有効化済みか | 障害時に自動昇格されない |
| 接続文字列 | アプリがglobal read-write connection stringを使っているか | 昇格後に書き込み先を手動変更する必要がある |
| レプリケーション遅延 | 通常時の遅延傾向を監視しているか | 障害時のデータ損失範囲を見積もれない |
| ネットワーク設定 | レプリカ側のFirewall、Private Endpointなどが設定済みか | 昇格後にアプリから到達できない |
| 認証・権限 | 利用者、マネージドID、認証方式を確認しているか | フェールオーバー後に接続エラーが起きる |
特に注意したいのは、Service-managed failoverは障害が起きてから後付けで有効化する機能ではない点です。Microsoft Learnでは、Service-managed failoverはプライマリクラスターで障害前に有効化しておく必要があり、障害中にさかのぼって有効化することはできないと説明されています。(Microsoft Learn)
管理者がすぐ確認すべき設定
Service-managed failoverの一般提供を受けて、Azure管理者は次の順に確認すると効率的です。
クロスリージョンレプリカの構成を確認する
Azure Portalで対象のAzure DocumentDBクラスターを開き、Global distribution関連の設定を確認します。既存クラスターでも、Global distributionから読み取りレプリカを追加できます。レプリカ作成時には、レプリカ名とリージョンを指定します。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 判断基準 |
|---|---|
| レプリカリージョン | プライマリと同時障害になりにくいリージョンを選んでいるか |
| ユーザーへの距離 | 読み取り用途でも使うなら、利用者に近いリージョンか |
| コスト | レプリカもvCoreとストレージの課金対象になることを考慮しているか |
| ネットワーク | プライベート接続、Firewall、名前解決がアプリから使えるか |
| 暗号化 | CMKなどの暗号化要件を満たしているか |
レプリカクラスターは、プライマリのネットワーク設定を自動継承しません。Microsoft Learnでは、レプリカを読み取り操作で利用するには、FirewallルールやPrivate Endpointなどをレプリカ側でも設定する必要があると説明されています。(Microsoft Learn)
Service-managed failoverを有効化しているか確認する
Service-managed failoverはオプトイン設定です。公式ブログでは、プライマリクラスターで有効化する必要があり、発表時点ではサポートチケット経由で有効化し、Azure Portalからの有効化は今後提供予定とされています。一方、Microsoft Learnの手順では、プライマリクラスターのGlobal distributionページからクラスター単位で構成できると説明されています。環境によって利用可能な操作画面が異なる可能性があるため、実際のポータル表示と最新ドキュメントを確認してください。(Microsoft for Developers)
運用上は、以下のどちらかを確認します。
| 状況 | 対応 |
|---|---|
| ポータルでService-managed failover設定が表示される | プライマリクラスターのGlobal distributionから有効化状態を確認 |
| ポータルに設定が見当たらない | Microsoftサポートまたは最新の公式ドキュメントで有効化方法を確認 |
| まだクロスリージョンレプリカがない | 先にレプリカを作成してDR構成を整える |
| 本番適用前 | ステージングまたは検証環境で接続、監視、手順を確認 |
global read-write connection stringを使っているか確認する
フェールオーバー後のアプリケーション継続性を左右するのが接続文字列です。global read-write connection stringは、書き込み可能なアクティブクラスターを指す接続文字列です。レプリカ昇格後は新しいプライマリを指すように更新されます。(Microsoft Learn)
アプリケーションの設定ファイル、シークレット管理、CI/CD変数、Kubernetes Secret、Azure App Configuration、Key Vaultなどを確認し、旧プライマリのself connection stringを固定していないかを点検してください。
| 設定パターン | フェールオーバー時の扱い |
|---|---|
| global read-write connection stringを使用 | 新プライマリへ追従しやすい |
| 旧プライマリのself connection stringを使用 | 昇格後に書き込み先変更が必要 |
| 読み取り専用用途でレプリカのself connection stringを使用 | 読み取り先としては利用可能だが、書き込み用途と混同しない |
| 接続文字列が複数箇所に分散 | 切り替え漏れが起きやすいため、設定管理を集約する |
開発チームには、「DB接続文字列はどこで定義され、どの環境変数名で渡され、どのアプリが利用しているか」を一覧化してもらうと、障害時の調査時間を大きく減らせます。
開発者が見直すべきアプリケーション設計
Service-managed failoverを有効化しても、アプリケーション側の耐障害性が不要になるわけではありません。特に、フェールオーバー中や直後には、一時的な接続失敗、書き込み遅延、再接続、データ整合性確認が発生し得ます。
リトライ処理を実装する
Graceful promotionでは切り替え中に一時的な書き込みエラーが返ることがあります。Service-managed failoverでも、障害検知から昇格、接続先更新、アプリ側の再接続までの間に一時的な失敗が発生する可能性があります。(Microsoft Learn)
リトライ処理では、単純に即時再試行を繰り返すのではなく、次の設計を推奨します。
| 実装ポイント | 理由 |
|---|---|
| 指数バックオフ | 障害中の過剰な再接続を避ける |
| 最大リトライ回数 | 無限ループやリソース枯渇を防ぐ |
| タイムアウト設定 | ユーザー操作やバッチ処理の待ち時間を制御する |
| エラー分類 | 一時エラーと恒久エラーを分けて扱う |
| ログ出力 | フェールオーバー時の影響範囲を後から追跡する |
書き込み処理を冪等にする
Service-managed failoverでは、障害直前の一部書き込みが新プライマリに存在しない可能性があります。アプリケーション側では、同じリクエストを再実行しても二重登録や二重課金にならないよう、冪等性を設計しておくべきです。
具体例として、注文処理なら注文ID、決済処理ならリクエストID、ジョブ実行ならジョブIDを一意キーとして扱い、同じIDの処理が再送されても結果が重複しないようにします。
| 処理 | 冪等性の設計例 |
|---|---|
| 注文作成 | クライアントまたはサーバーで生成した注文IDを一意にする |
| 決済要求 | 決済リクエストIDを保存し、同一IDの再処理を拒否または同じ結果で返す |
| メール送信 | 送信済みイベントIDを記録し、重複送信を防ぐ |
| バッチ更新 | 処理済みチェックポイントを保存する |
| キュー処理 | メッセージIDと処理状態を永続化する |
データ欠損を検知・補正する仕組みを持つ
Service-managed failoverは復旧時間を短縮する一方、未複製データの欠損可能性があります。そのため、重要データでは「欠損しない前提」ではなく、「欠損した場合に検知して補正できる前提」で設計することが現実的です。
実務では、次のような仕組みが役立ちます。
| 仕組み | 目的 |
|---|---|
| 監査ログ | 障害前後の操作履歴を追跡する |
| イベントログ | 外部システムとの処理差分を確認する |
| 再送キュー | 失敗した処理を後から再実行する |
| 整合性チェックバッチ | 注文、在庫、請求などの不一致を検出する |
| 業務向け確認画面 | 運用担当者が補正対象を確認できるようにする |
たとえばECシステムでは、DB上の注文データ、決済プロバイダーの取引履歴、メール送信履歴、在庫引当履歴を突き合わせることで、フェールオーバー前後の不整合を見つけやすくなります。
in-region HAとの違いと組み合わせ方
Service-managed failoverはリージョン障害に対応するための機能です。一方、in-region high availability、つまりリージョン内HAは、同じリージョン内のシャード障害などに対応する機能です。
Microsoft Learnでは、HAを有効化すると各シャードにスタンバイシャードが用意され、同期レプリケーションによりゼロデータロスでフェールオーバーできると説明されています。また、HA有効時には各クラスタシャードが99.99%の可用性SLA対象になります。(aka.ms)
Service-managed failoverとHAは競合するものではありません。Microsoftは、本番ワークロードではリージョン内HAとService-managed failoverを組み合わせる構成を推奨しています。(Microsoft for Developers)
| 障害の種類 | 主に効く機能 | データ損失 |
|---|---|---|
| 同一リージョン内のシャード障害 | in-region HA | ゼロデータロス |
| 可用性ゾーン内の障害 | in-region HA | ゼロデータロス |
| リージョン全体の障害 | Service-managed failover | 未複製書き込みの損失可能性あり |
| 計画的なリージョン切り替え | Graceful promotion | ゼロデータロス |
実務では、「HAを有効化しているからリージョン障害にも完全対応できる」と誤解しないことが重要です。HAはリージョン内の可用性を高めるもの、Service-managed failoverはリージョンをまたぐDRを自動化するもの、と役割を分けて考えましょう。
移行・展開時の注意点
Service-managed failoverを本番環境に展開する際は、いきなり有効化して終わりにしないことが大切です。DR機能は、平常時には効果が見えにくく、障害時に初めて設定漏れが表面化します。
既存環境へ追加する場合
既存のAzure DocumentDBクラスターにService-managed failoverを導入する場合は、次の順序で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 現在の構成を棚卸しする | リージョン、HA、レプリカ、接続文字列を確認 |
| 2 | クロスリージョンレプリカを作成する | 同一リージョンレプリカではDR要件を満たさない |
| 3 | レプリカのネットワーク設定を行う | Firewall、Private Endpoint、DNSを確認 |
| 4 | アプリの接続文字列を確認する | global read-write connection stringへ寄せる |
| 5 | Service-managed failoverを有効化する | プライマリクラスター単位で設定 |
| 6 | DR訓練を実施する | Graceful promotionや検証環境で手順を確認 |
| 7 | ランブックを更新する | 自動化後の確認作業、連絡、復旧後処理を明文化 |
新規環境で設計する場合
新規にAzure DocumentDBを採用する場合は、最初から可用性要件を決めておくと後戻りが少なくなります。
| 要件 | 推奨構成 |
|---|---|
| 開発・検証環境 | コスト重視。HAやクロスリージョンレプリカは必要性を個別判断 |
| 社内向け軽量アプリ | HAの要否を業務影響で判断 |
| 本番アプリ | in-region HAを基本検討 |
| リージョン障害に備える本番アプリ | クロスリージョンレプリカを作成 |
| 自動復旧が必要な本番アプリ | Service-managed failoverを有効化 |
| 計画切り替えでデータ損失不可 | Graceful promotionの手順を整備 |
なお、Microsoft Learnでは、本番クラスターや99.99% SLAが必要なクラスターではHAを有効化し、99.995% SLAが必要な場合はHAとレプリカクラスターを組み合わせる方針が示されています。(Microsoft Learn)
失敗しやすいポイント
Service-managed failoverの導入でよくある失敗は、「機能を有効にしたつもり」または「自動化される範囲を広く見積もりすぎる」ことです。
レプリカを作っただけで自動フェールオーバーされると思い込む
クロスリージョンレプリカを作成しても、それだけでService-managed failoverが有効になるとは限りません。Service-managed failoverはオプトインであり、プライマリクラスター側で明示的に有効化する必要があります。(Microsoft for Developers)
レプリカ作成後は、必ず「レプリカがある」だけでなく「Service-managed failoverが有効か」まで確認してください。
self connection stringを本番書き込みに使い続ける
アプリケーションが旧プライマリのself connection stringを使っていると、フェールオーバー後に書き込み先が自動追従しません。Microsoft Learnでは、self connection stringを使って書き込みを行っている場合、昇格後に新しいプライマリへ接続文字列を更新する必要があると説明されています。(Microsoft Learn)
本番の書き込み用途では、可能な限りglobal read-write connection stringを標準にしましょう。
データ損失リスクを業務部門に説明していない
Service-managed failoverは、ゼロデータロスを保証する機能ではありません。未複製の書き込みが失われる可能性があります。(Microsoft for Developers)
このリスクは、技術チームだけで判断すべきではありません。注文、決済、請求、在庫、会員情報など、業務影響が大きいデータについては、RPOの許容範囲を事前に合意しておく必要があります。
ネットワーク設定をレプリカ側で忘れる
レプリカクラスターは、プライマリのネットワーク設定を自動的に引き継ぎません。FirewallルールやPrivate Endpointをレプリカ側にも設定していないと、フェールオーバー後にアプリケーションから新プライマリへ到達できない可能性があります。(Microsoft Learn)
特にPrivate Endpointを使っている環境では、DNS、名前解決、VNet統合、接続元サブネット、NSG、ルートテーブルまで含めて確認してください。
自動フェールオーバー後の運用を決めていない
Service-managed failoverは、障害時のレプリカ昇格を自動化しますが、障害後の業務判断までは自動化しません。
フェールオーバー後には、次の確認が必要です。
| 事後確認 | 内容 |
|---|---|
| アプリ疎通 | 書き込み・読み取りが成功するか |
| データ整合性 | 障害直前の処理に欠損や重複がないか |
| 監視アラート | 旧プライマリ、新プライマリ、レプリカ状態を確認 |
| 業務影響 | 注文、決済、通知、バッチ処理への影響を確認 |
| 復旧後構成 | 旧リージョン復旧後のレプリカ再構成方針を決める |
導入判断の基準
Service-managed failoverを導入すべきかどうかは、「自動復旧のメリット」と「未複製データ損失のリスク」を比較して判断します。
| 判断軸 | 導入を強く検討すべきケース | 慎重に検討すべきケース |
|---|---|---|
| RTO | 復旧時間を短くしたい | 手動判断でも業務上許容できる |
| RPO | 数秒〜短時間の未複製データ損失を補正可能 | 1件のデータ損失も許容できない |
| 運用体制 | 24時間の即時対応が難しい | 常時対応できる専任運用がある |
| アプリ設計 | 冪等性、再送、整合性チェックがある | 書き込み失敗や重複に弱い |
| DR方針 | リージョン障害を想定している | 単一リージョン停止を許容する設計 |
実務的には、次のように考えると判断しやすくなります。
リージョン障害時に数分でも停止すると大きな損失が出るが、障害直前の一部データ欠損はログや外部システムから補正できるなら、Service-managed failoverは有力な選択肢です。
一方で、1件のデータ欠損も許されず、切り替えタイミングを制御できるなら、計画切り替えではGraceful promotionを優先すべきです。Service-managed failoverは、計画外のリージョン障害に備える安全網として位置付けるのが現実的です。
管理者・開発者向けチェックリスト
最後に、今回の一般提供を受けて確認すべき項目をまとめます。
| 対象 | チェック項目 |
|---|---|
| 管理者 | 対象クラスターがAzure DocumentDBのマルチリージョン構成か確認する |
| 管理者 | クロスリージョンレプリカが作成済みか確認する |
| 管理者 | Service-managed failoverがプライマリクラスターで有効化されているか確認する |
| 管理者 | in-region HAを有効化すべき本番環境か確認する |
| 管理者 | レプリカ側のFirewall、Private Endpoint、DNSを確認する |
| 管理者 | DRランブックをService-managed failover前提に更新する |
| 開発者 | 書き込み用途でglobal read-write connection stringを使っているか確認する |
| 開発者 | 一時エラーに対するリトライとタイムアウトを実装する |
| 開発者 | 注文、決済、ジョブ処理などを冪等にする |
| 開発者 | 障害前後のデータ欠損や重複を検知する仕組みを用意する |
| 開発者 | フェールオーバー後のアプリ再接続を検証する |
| 共通 | RTO、RPO、データ損失許容度を業務部門と合意する |
まとめ：Service-managed failoverはDR自動化の強力な選択肢。ただし事前設計が前提
Azure DocumentDBのService-managed failoverの一般提供により、マルチリージョンクラスターのリージョン障害対応を自動化しやすくなりました。これにより、障害時に運用者が手動でレプリカを昇格するまでの時間を削減でき、DR運用の属人性も下げられます。
一方で、Service-managed failoverはオプトインであり、クロスリージョンレプリカが必要です。また、非同期レプリケーションの性質上、未複製の書き込みが失われる可能性があります。ゼロデータロスが必要な計画切り替えではGraceful promotionを使い、リージョン障害時の自動復旧にはService-managed failoverを使う、という役割分担が現実的です。
まずは本番クラスターについて、クロスリージョンレプリカ、Service-managed failoverの有効化状態、global read-write connection stringの利用状況、レプリカ側ネットワーク設定を確認しましょう。そのうえで、リトライ、冪等性、データ整合性チェック、DRランブックを整えれば、Azure DocumentDBの可用性設計を一段引き上げられます。
コメント