Azure DocumentDBの「Graceful failover with zero data loss guarantee」は、計画的なリージョン切り替えをデータ損失ゼロで実行するための一般提供機能です。これまで使えた強制昇格は、障害時に素早く切り替えられる一方で、非同期レプリケーションの遅延分が失われる可能性がありました。今回のGraceful promotionでは、プライマリへの書き込みを一時停止し、レプリケーションキューを排出してからレプリカを昇格するため、計画メンテナンス、DR訓練、恒久的なリージョン移行で使いやすくなります。(Microsoft Learn)
重要なのは、この機能が「すべての障害でデータ損失ゼロを保証する自動フェールオーバー」ではない点です。Graceful promotionは、プライマリクラスターに到達できる状態で実行する計画切り替え向けの機能です。すでにプライマリリージョンが利用不能な場合は、強制昇格またはサービス管理フェールオーバーを使う必要があります。(Microsoft Learn)
Azure DocumentDBのGraceful failoverで何が変わるのか
Azure DocumentDBでは、クロスリージョンまたは同一リージョンのレプリケーションにより、プライマリクラスターのデータをレプリカクラスターへ継続的に複製できます。レプリケーションは非同期で行われるため、通常の書き込み処理ではレプリカ側への反映完了を待たずに成功応答を返します。これにより書き込み遅延を抑えられますが、障害時の切り替えではレプリケーションラグが問題になります。(Microsoft Learn)
今回一般提供されたGraceful promotionは、このラグを解消してから切り替える仕組みです。Azure DocumentDBはプライマリクラスターへの書き込みを一時的に停止し、レプリケーションキューが空になるまで待機したうえで、対象のレプリカクラスターを読み書き可能な新しいプライマリへ昇格します。(Microsoft Learn)
つまり、従来の「すぐ切り替えるが未複製データを失う可能性がある」運用に加えて、「短時間の書き込み停止を許容し、データ損失ゼロを優先する」選択肢が正式に使えるようになりました。
変更点の要約
| 項目 | これまでの主な対応 | Graceful promotion一般提供後 |
|---|---|---|
| 計画的なリージョン切り替え | 強制昇格を使うとデータ損失リスクがあった | レプリケーションを追いつかせてから切り替え可能 |
| データ損失リスク | 非同期レプリケーションの遅延分が失われる可能性 | 計画切り替えではゼロデータ損失を狙える |
| 書き込み可用性 | 即時性を優先しやすい | 切り替え中は一時的な書き込みエラーが発生し得る |
| 主な用途 | 障害時の緊急切り替え | メンテナンス、DR訓練、計画移行 |
| 前提条件 | プライマリ停止後でも実行しやすい | プライマリに到達できる必要がある |
対象サービスはAzure DocumentDB
対象は、Microsoft AzureのMongoDB互換NoSQLデータベースサービスであるAzure DocumentDBです。Azure DocumentDBは、MongoDB互換のワイヤープロトコルを使い、既存のMongoDB向けツールやドライバーとの互換性を重視したフルマネージドサービスとして提供されています。(Microsoft Learn)
今回の更新は、Azure全体のフェールオーバー機能すべてに一律で適用されるものではありません。Azure Cosmos DB、Azure SQL Database、Azure Database for PostgreSQLなど、他のデータベースサービスのDR機能とは仕様が異なります。運用手順書や障害対応フローに反映する際は、対象リソースがAzure DocumentDBクラスターであることを確認してください。
Graceful promotion、Forced promotion、Service-managed failoverの違い
Azure DocumentDBのクロスリージョン切り替えには、主に3つのモードがあります。混同しやすいため、最初に使い分けを整理しておくことが重要です。
| モード | 実行主体 | 主な用途 | データ損失リスク | 向いている場面 |
|---|---|---|---|---|
| Graceful promotion | 管理者が手動実行 | 計画的な切り替え | ゼロデータ損失を前提に実行 | メンテナンス、DR訓練、リージョン移行 |
| Forced promotion | 管理者が手動実行 | 緊急時の切り替え | レプリケーションラグ分の損失可能性あり | プライマリが不安定、または到達不能 |
| Service-managed failover | Azureが自動実行 | リージョン障害時の自動復旧 | レプリケーションラグ分の損失可能性あり | 無人での障害復旧を重視する本番環境 |
Microsoft Learnでも、計画的なリージョン切り替えにはGraceful promotion、リージョン障害時の自動復旧にはService-managed failover、管理者が直接タイミングを制御したい緊急時にはForced promotionを使う整理が示されています。(Microsoft Learn)
Graceful promotionは「計画切り替え」のための機能
Graceful promotionは、レプリケーションが追いつくまで待ってから書き込みロールを切り替えるため、データ保全を優先できます。一方で、切り替え中は書き込み要求が一時的なエラーを返す可能性があります。アプリケーション側では、リトライ処理、タイムアウト設定、メンテナンス画面への誘導などを事前に設計しておく必要があります。(Microsoft Learn)
たとえばECサイトで決済直前の注文データを扱う場合、切り替え中に書き込みが失敗したリクエストをユーザーに再送させるだけでは、二重注文や決済状態の不一致が起きる可能性があります。アプリケーション側で冪等性キーを使い、同じ注文リクエストを安全に再実行できるようにしておくと、計画切り替え時の事故を減らせます。
Forced promotionは「復旧速度」を優先する選択肢
Forced promotionは、任意のタイミングでレプリカを読み書き可能なクラスターへ昇格できます。ただし、Azure DocumentDBのクロスリージョンレプリケーションは非同期であるため、プライマリ側で成功していた書き込みがレプリカに届いていない場合、そのデータは新しいプライマリに存在しません。(Microsoft Learn)
そのため、Forced promotionは「数秒〜数分の未反映データよりもサービス復旧を優先する」場面で使うべきです。売上、契約、医療、金融、監査ログのようにデータ欠損の影響が大きいシステムでは、Forced promotionを許容する条件を事前に明文化しておく必要があります。
Service-managed failoverは「自動復旧」の安全網
Service-managed failoverは、Azure DocumentDBがプライマリリージョンの障害を検出した際に、レプリカクラスターを自動的に昇格する機能です。管理者の操作なしに復旧できる点が強みですが、こちらも計画切り替えではないため、レプリケーションラグによるデータ損失の可能性があります。(Microsoft Learn)
Graceful promotionとService-managed failoverは排他的ではありません。普段はService-managed failoverを有効にしてリージョン障害への備えとし、計画メンテナンスやDR訓練ではGraceful promotionを使う、という組み合わせが現実的です。(Microsoft Learn)
影響を受ける利用者とシステム
今回の更新で特に確認すべきなのは、Azure DocumentDBを本番用途で使い、クロスリージョンレプリケーションを構成している組織です。単一リージョンの検証環境や、レプリカクラスターを作成していない環境では、すぐに運用が変わるわけではありません。
影響が大きいケース
次のようなシステムでは、Graceful promotionを運用手順に組み込む価値があります。
- リージョン障害に備えてAzure DocumentDBのレプリカクラスターを構成している
- DR訓練を定期的に実施している
- プライマリリージョンを計画的に移行する可能性がある
- 書き込みデータの欠損を許容しにくい
- グローバル展開や国内外リージョン分散を行っている
- メンテナンス時の切り替え手順を手動運用している
特に、注文、予約、在庫、決済、利用履歴、監査ログなどを扱うアプリケーションでは、「切り替えられるか」だけでなく「切り替え後にデータ整合性を保てるか」が重要です。Graceful promotionは、この観点で管理者が選べる安全な切り替え手段になります。
影響が限定的なケース
一方で、次の環境では優先度は高くありません。
- 開発環境や検証環境のみで利用している
- レプリカクラスターを作成していない
- 単一リージョン構成でDR要件がない
- 書き込み停止を許容できず、常に即時復旧を優先する
- アプリケーション側で接続文字列の切り替えやリトライに未対応
ただし、現在は単一リージョンでも、将来的に本番化やDR対応を予定している場合は、早い段階で接続文字列やリトライ設計を見直しておくと移行が楽になります。
管理者が確認すべき設定
Graceful promotionを使う前に、Azure管理者はAzure portal上でレプリケーション構成、接続文字列、HA、ネットワーク設定を確認する必要があります。とくに見落としやすいのは、レプリカクラスター側のネットワーク設定と、昇格後のHA設定です。
レプリカクラスターが作成されているか
Graceful promotionは、昇格対象となるレプリカクラスターが必要です。Azure DocumentDBでは、新規クラスター作成時のGlobal distributionタブでレプリカを有効化するか、既存クラスターのGlobal distributionから新しい読み取りレプリカを追加できます。(Microsoft Learn)
確認する項目は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| レプリカの有無 | OverviewまたはGlobal distributionでRead region / Write regionを確認 |
| レプリカリージョン | DR要件に合ったリージョンか |
| レプリケーション状態 | 遅延が大きくないか |
| レプリカの性能 | 本番書き込みを一時的に受けられるサイズか |
| ネットワーク | firewall rules、private endpointが設定済みか |
| 認証 | アプリケーションや運用端末から接続できるか |
グローバル読み書き接続文字列を使っているか
Azure DocumentDBでは、グローバル読み書き接続文字列が、現在書き込み可能なクラスターを指すように更新されます。Graceful promotion中も、切り替え後は新しいプライマリを指すようになります。(Microsoft Learn)
アプリケーションが旧プライマリのself connection stringを使って書き込んでいる場合、昇格後に書き込み先を新しいプライマリへ変更する必要があります。これは運用上の大きな落とし穴です。
おすすめは、書き込み処理では可能な限りグローバル読み書き接続文字列を使い、特定リージョンのself connection stringは読み取り用途や限定的な管理用途に分けることです。
HA設定を再確認する
強制昇格後の注意点として、Microsoft Learnでは、プライマリ側で高可用性が有効だった場合でも、昇格後のレプリカクラスターでHAを再度有効化する必要があると説明されています。(Microsoft Learn)
Graceful promotionを含む切り替え運用でも、昇格後のクラスターが本番の可用性要件を満たしているか確認してください。Azure DocumentDBでは、HAを有効化したクラスターで99.99%の月間可用性SLA、HAとクロスリージョンレプリケーションの組み合わせで99.995%のSLAが示されています。(Microsoft Learn)
レプリカ側のネットワーク設定を確認する
レプリカ作成時、プライマリクラスターのネットワーク設定がそのまま継承されるとは限りません。Microsoft Learnでは、レプリカを読み取り操作に使うには、public accessのファイアウォールルールやprivate endpointを個別に構成する必要があると説明されています。(Microsoft Learn)
本番障害時やDR訓練時に「昇格は成功したがアプリケーションから接続できない」という失敗は珍しくありません。切り替え手順だけでなく、ネットワーク疎通、DNS、Private Link、NSG、ルーティング、名前解決まで含めて事前検証しましょう。
開発者が確認すべきアプリケーション側の対応
Graceful promotionはデータベース側の機能ですが、実際の安定運用にはアプリケーション側の設計が欠かせません。特に、切り替え中の一時的な書き込みエラーをどう扱うかが重要です。
一時的な書き込みエラーを前提にする
Graceful promotionの実行中、書き込み要求は切り替え完了まで一時的なエラーを返す可能性があります。(Microsoft Learn)
アプリケーション側では、次のような対応を入れておきましょう。
| 対応 | 実装のポイント |
|---|---|
| リトライ処理 | 短い間隔で無制限に再試行せず、指数バックオフを使う |
| 冪等性 | 注文、決済、登録処理には一意なリクエストIDを付与する |
| タイムアウト | 切り替え時間を考慮し、短すぎるDBタイムアウトを避ける |
| ユーザー通知 | メンテナンス中の一時エラーを分かりやすく表示する |
| ログ出力 | 切り替え中の失敗と通常障害を区別できるようにする |
「リトライを入れる」だけでは不十分です。たとえば決済APIの呼び出し後にDB書き込みが失敗した場合、再試行で二重決済が起きる可能性があります。DB処理、外部API、メッセージキューをまたぐ処理では、冪等性と補償処理をセットで設計してください。
接続文字列をコードに直書きしない
Graceful promotion後に接続先が変わる可能性を考えると、接続文字列をアプリケーションコードへ直接埋め込む運用は避けるべきです。Azure Key Vault、アプリケーション設定、環境変数、構成管理ツールなどを使い、切り替えやロールバック時に安全に変更できる形にしておきます。
特に注意したいのは、バッチ、管理ツール、社内運用スクリプトです。Webアプリ本体はグローバル読み書き接続文字列を使っていても、夜間バッチだけ旧プライマリのself connection stringを参照しているケースがあります。
読み取りと書き込みの接続先を整理する
レプリカクラスターは読み取りにも利用できます。読み取り負荷の分散や、ユーザーに近いリージョンでの低遅延読み取りに活用できます。(Microsoft Learn)
ただし、読み取り用と書き込み用の接続先が混在していると、昇格後にどの処理がどのクラスターへ向いているか分かりにくくなります。アプリケーション設定では、少なくとも次のように役割を分けて管理するのがおすすめです。
| 接続用途 | 推奨する管理方法 |
|---|---|
| 書き込み | グローバル読み書き接続文字列を使う |
| 通常読み取り | 要件に応じてプライマリまたはレプリカを選択 |
| 分析・重い参照 | レプリカ側へ逃がす |
| 管理スクリプト | 接続先と権限を明示し、昇格後の確認手順に含める |
Graceful promotionの実行手順
Azure portalでGraceful promotionを実行する基本的な流れはシンプルです。Microsoft Learnでは、レプリカクラスターを選択し、Settings配下のGlobal distributionからGraceful Promoteを選び、警告を確認して実行する手順が示されています。(Microsoft Learn)
実務では、ボタンを押す前後の確認が重要です。以下の手順で進めると、切り替え失敗や想定外の停止を減らせます。
実行前チェック
| 手順 | 確認内容 |
|---|---|
| メンテナンス時間を決める | 書き込みが少ない時間帯を選ぶ |
| レプリケーションラグを確認する | ラグが大きい場合は延期またはスケール検討 |
| アプリケーションのリトライを確認する | 一時的な書き込みエラーを処理できるか |
| 接続文字列を確認する | 書き込みがグローバル読み書き接続文字列を使っているか |
| レプリカのネットワークを確認する | private endpoint、ファイアウォール、DNSを確認 |
| 監視を準備する | エラー率、レイテンシ、書き込み失敗、接続数を見る |
| ロールバック方針を決める | 旧リージョンへ戻す条件と手順を明確にする |
実行中に見るべき項目
Graceful promotion中は、書き込み要求の一時エラー、アプリケーションのリトライ状況、接続先の変化、ユーザー影響を監視します。切り替えが想定より長く続く場合、レプリケーションキューが排出されるまで待っている可能性があります。Microsoft Learnでも、Graceful promotionの所要時間は現在のレプリケーションラグや書き込み負荷に依存すると説明されています。(Microsoft Learn)
書き込みが多い時間帯に実行すると、キューがなかなか空にならず、メンテナンス時間が延びる可能性があります。事前に書き込みを抑制できる業務であれば、アプリケーションをメンテナンスモードにしてから実行するほうが安全です。
実行後チェック
切り替え後は、次の順に確認します。
| 確認項目 | 判断基準 |
|---|---|
| 新プライマリ | レプリカだったクラスターが読み書き可能になっている |
| 旧プライマリ | 読み取り専用側に切り替わっている |
| 接続文字列 | グローバル読み書き接続文字列が新プライマリを指している |
| アプリケーション | 書き込み、読み取り、バッチが正常に動く |
| データ整合性 | 重要コレクションの件数や最新データを確認 |
| 監視 | エラー率とレイテンシが平常値に戻っている |
| HA/DR設定 | 昇格後の可用性設定が要件を満たしている |
移行・展開時の注意点
Graceful promotionは便利な機能ですが、導入時にいくつかの落とし穴があります。特に「ゼロデータ損失」という言葉だけで判断すると、運用設計を誤りやすくなります。
「ゼロデータ損失」は計画切り替え時の話
Graceful promotionは、プライマリに到達でき、レプリケーションキューを排出できることが前提です。プライマリリージョンがすでに停止している場合は、キューを排出できないためGraceful promotionは使えません。その場合はForced promotionまたはService-managed failoverを検討する必要があります。(Microsoft Learn)
障害対応手順書では、次のように判断基準を分けてください。
| 状況 | 推奨判断 |
|---|---|
| プライマリが正常、計画メンテナンスを行う | Graceful promotion |
| プライマリが正常、リージョン移行を行う | Graceful promotion |
| プライマリが不安定だが到達できる | 状況に応じてGraceful promotionまたはForced promotion |
| プライマリが到達不能 | Forced promotionまたはService-managed failover |
| 無人でリージョン障害に備えたい | Service-managed failoverを有効化 |
レプリケーションラグが大きいと切り替えに時間がかかる
Graceful promotionはレプリケーションキューを排出してから昇格するため、ラグが大きい環境では完了まで時間がかかります。Microsoft Learnでは、ラグが高い場合は低書き込み時間帯に実行する、レプリカクラスターのメトリックでラグを確認する、必要に応じてレプリカをスケールアップする、といった対策が示されています。(Microsoft Learn)
書き込みが多い本番環境では、DR訓練のたびに「どの程度のラグなら許容できるか」を記録しておくと、次回以降の判断が速くなります。
アプリケーションのリトライが強すぎると逆効果
切り替え中に全アプリケーションが短間隔で一斉にリトライすると、昇格後の新プライマリに負荷が集中します。いわゆるリトライストームです。
対策として、指数バックオフ、ジッター、最大リトライ回数、キューイングを組み合わせます。ユーザー操作系の処理では、何度も自動再送するよりも「処理中です」「時間を置いて再試行してください」と表示するほうが安全な場合もあります。
監視項目を切り替え前提に更新する
Graceful promotionを導入したら、監視ダッシュボードも更新しましょう。見るべき項目は、CPUやメモリだけではありません。
- レプリケーションラグ
- 書き込みエラー率
- 接続エラー
- タイムアウト数
- アプリケーション側リトライ回数
- グローバル読み書き接続文字列の接続先
- 新旧クラスターのロール
- バッチ処理の失敗数
- キュー滞留数
切り替え時だけアラートを一時的に抑止する場合も、完全に無効化するのではなく、メンテナンス中に許容するアラートと、即時対応が必要なアラートを分けると安全です。
どう導入判断すべきか
Graceful promotionは、Azure DocumentDBを本番で使うすべての組織がすぐ実行すべき機能ではありません。しかし、クロスリージョンレプリケーションを構成しているなら、DR設計の標準手順に入れる価値があります。
導入を優先したいシステム
次の条件に当てはまる場合は、早めに検証環境で試すべきです。
- RPOをできるだけゼロに近づけたい
- リージョン移行やDR訓練を計画している
- Forced promotionのデータ損失リスクを避けたい
- 書き込み停止の短時間発生を業務上許容できる
- グローバル読み書き接続文字列へ移行できる
- アプリケーションにリトライと冪等性を実装できる
慎重に進めるべきシステム
次の環境では、機能を有効に使う前に設計見直しが必要です。
- 接続文字列が複数箇所に散らばっている
- バッチや外部連携が旧プライマリを直接参照している
- 書き込み失敗時の再実行仕様が曖昧
- レプリカクラスターの性能が本番負荷に足りない
- Private LinkやDNS設定が手動管理で属人化している
- DR訓練を実施したことがない
この状態で本番切り替えを行うと、データベース側は正常に昇格しても、アプリケーションやネットワーク側で停止が長引く可能性があります。
管理者・開発者向けチェックリスト
最後に、実際に確認すべき項目をチェックリストとして整理します。
| 役割 | 確認項目 | 完了の目安 |
|---|---|---|
| Azure管理者 | レプリカクラスターの有無 | Global distributionで確認済み |
| Azure管理者 | レプリケーションラグ | メトリックで平常時の値を把握済み |
| Azure管理者 | Graceful Promoteの実行権限 | 必要なRBAC権限を確認済み |
| Azure管理者 | ネットワーク設定 | レプリカ側の接続経路を検証済み |
| Azure管理者 | HA設定 | 昇格後の可用性要件を確認済み |
| 開発者 | 書き込み接続文字列 | グローバル読み書き接続文字列を利用 |
| 開発者 | リトライ処理 | 指数バックオフと上限を実装済み |
| 開発者 | 冪等性 | 注文・決済・登録処理で再実行対策済み |
| SRE/運用 | 監視 | 切り替え中のエラーと通常障害を区別可能 |
| SRE/運用 | 手順書 | Graceful、Forced、Service-managedの判断基準を記載済み |
Azure DocumentDBのDR運用は「切り替え方の選択」が重要になる
Azure DocumentDBのGraceful failover with zero data loss guaranteeにより、管理者は計画的なリージョン切り替えをデータ損失ゼロで実行しやすくなりました。特に、メンテナンス、DR訓練、リージョン移行のようにタイミングを選べる場面では、Forced promotionよりも安全な選択肢になります。
ただし、Graceful promotionは万能な障害復旧機能ではありません。プライマリに到達できること、レプリケーションキューを排出できること、切り替え中の一時的な書き込みエラーをアプリケーションが処理できることが前提です。
まずは検証環境で、レプリカ作成、Graceful Promote、接続文字列の切り替わり、アプリケーションのリトライ、昇格後のHAとネットワークを一通り確認してください。そのうえで、本番のDR手順書に「計画切り替えはGraceful promotion」「緊急時はForced promotionまたはService-managed failover」と明記すると、障害時の判断がぶれにくくなります。
コメント