Azure Cosmos DBのPer-partition automatic failover（PPAF）は、単一書き込みリージョン構成の可用性を高めるための重要な更新です。従来のようにアカウント全体をフェールオーバーするのではなく、障害の影響を受けたパーティションだけを別リージョンへ自動的に切り替えられるようになりました。結論から言うと、Azure Cosmos DB for NoSQLでミッションクリティカルなアプリを運用している管理者・開発者は、SDKバージョン、複数リージョン構成、整合性レベル、監視メトリックを優先して確認すべきです。
Microsoftは2026年6月に、Azure Cosmos DB NoSQL API向けのPer Partition Automatic Failoverを一般提供（GA）として発表しました。PPAFにより、影響を受けたパーティションの書き込みをセカンダリリージョンへ自動的にフェールオーバーし、P99で3分以内の復旧を目指せるとされています。アプリケーション側は、対応SDKへ更新して機能を有効化すれば、基本的に追加のフェールオーバー制御ロジックを持たずに利用できます。(Microsoft for Developers)
Azure Cosmos DBのPPAFとは何か
Per-partition automatic failover（PPAF）は、Azure Cosmos DBのデータベースアカウント全体ではなく、物理パーティション単位で書き込み先リージョンを切り替える可用性機能です。
Azure Cosmos DBは内部的にデータを複数のパーティションへ分散して保持します。従来のアカウント単位のフェールオーバーでは、書き込みリージョンに障害があると、アカウント配下の全パーティションをまとめて別リージョンへ切り替える必要がありました。PPAFでは、障害が発生したパーティションだけが別リージョンへ移動し、正常なパーティションは元の書き込みリージョンで処理を続けます。(Microsoft Learn)
この違いは、特に「一部の基盤障害」「ネットワーク問題」「部分的なリージョン影響」が起きたときに効きます。すべての書き込みを一斉に別リージョンへ寄せるのではなく、影響範囲を小さく保てるため、アプリ全体の停止リスクを下げやすくなります。
今回の一般提供で何が変わったのか
今回のGAで重要なのは、PPAFがプレビュー段階の検証機能から、運用環境で検討しやすい正式機能になった点です。Microsoftの発表では、GAにあわせて整合性レベルの対応範囲、SDK対応、監視、耐障害性の既定動作、カオスシミュレーションなどが整理されています。(Microsoft for Developers)
| 観点 | 従来のアカウント単位フェールオーバー | PPAF |
|---|---|---|
| フェールオーバー単位 | アカウント全体 | 影響を受けたパーティション |
| トリガー | 手動またはアカウント単位のサービス管理 | パーティションごとに自動検知・自動実行 |
| 影響範囲 | 全パーティションに及ぶ可能性 | 障害パーティションに限定しやすい |
| 典型的な復旧目標 | 障害状況により15〜30分以上の場合がある | パーティション単位でP99 3分未満 |
| フェールバック | 手動対応や同期を伴う | 自動検知・自動調整 |
| アプリ側対応 | フェールオーバー設計の考慮が必要 | 対応SDKへの更新が中心 |
PPAFは「障害時に何もしなくてよくなる魔法の機能」ではありません。正しく使うには、サポート対象のアカウント構成にすること、アプリ側のSDKを対応バージョンにすること、障害時のメトリックを監視できるようにすることが前提です。
対象になるAzure Cosmos DBアカウント
PPAFは、すべてのAzure Cosmos DBアカウントで自動的に使えるわけではありません。対象はAzure Cosmos DB for NoSQLの単一書き込みリージョンアカウントで、少なくとも1つの読み取りリージョンを持つ複数リージョン構成が必要です。対応する整合性レベルはStrong、Session、Consistent Prefix、Eventualで、Bounded Stalenessは今後の対応予定とされています。(Microsoft Learn)
| 確認項目 | 要件・確認ポイント |
|---|---|
| API | Core（SQL）API、つまりAzure Cosmos DB for NoSQL |
| リージョン構成 | 単一書き込みリージョン + 1つ以上の読み取りリージョン |
| 整合性レベル | Strong、Session、Consistent Prefix、Eventual |
| 未対応の整合性 | Bounded Stalenessは現時点では未対応 |
| スループット | サーバーレスではなく、プロビジョニング済みスループットまたはAutoscaleが必要 |
| リージョン | グローバルAzureリージョン |
| 料金 | Business Criticalサービス階層の一部として課金 |
| SDK | PPAF対応バージョンへの更新が必要 |
サーバーレス構成、Bounded Staleness、Synapse Link、アカウント内復元など、PPAF有効時に使えない、または制約を受ける機能があります。Partition MergeやRegion offlineを実行する場合も、PPAFを無効化してから操作し、完了後に再度有効化する必要があります。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者が最初に見るべきなのは、「PPAFを有効化できる状態か」ではなく、「有効化しても運用上の矛盾が出ない状態か」です。特に、整合性レベル、リージョン優先順位、SDK更新状況、監視設計は事前にそろえておく必要があります。
複数リージョン構成になっているか
PPAFは、障害パーティションの書き込み先を別リージョンへ切り替える機能です。そのため、単一リージョン構成のままでは前提を満たせません。
確認すべきポイントは次の通りです。
- 書き込みリージョン以外に、少なくとも1つの読み取りリージョンがあるか
- セカンダリリージョンの容量・レイテンシ・データ所在要件に問題がないか
- フェールオーバー優先順位が、業務上の優先度と一致しているか
- アプリケーションの配置リージョンとCosmos DBのリージョン設計がずれていないか
たとえば、日本向けサービスで東日本リージョンを主系にしている場合、単に「別リージョンを追加すればよい」のではなく、復旧時にユーザー体験、ネットワーク経路、規制要件、コストが許容範囲に収まるかを確認する必要があります。
整合性レベルが対応範囲に入っているか
PPAFはGA時点でStrong、Session、Consistent Prefix、Eventualをサポートしています。Strong整合性では、PPAFフェールオーバー中もRPO=0を維持できるとされています。一方、Session、Consistent Prefix、Eventualでは、障害直前の書き込み状況によってはデータの差異が発生する可能性があり、PPAFは既定でLast Writer Winsに基づく自動調整を行います。(Microsoft Learn)
実務では、整合性レベルごとに判断が変わります。
| 整合性レベル | PPAF導入時の見方 |
|---|---|
| Strong | 金融、台帳、在庫など、読み書きの厳密性を重視する用途で有力 |
| Session | 多くのWebアプリで現実的。ユーザー単位の読み取り一貫性を重視する場合に向く |
| Consistent Prefix | イベント順序の破綻を避けたいが、厳密なStrongまでは不要な用途に向く |
| Eventual | 高可用性・低遅延を重視するが、最終的な整合で許容できる用途に向く |
| Bounded Staleness | 現時点ではPPAF対象外のため、導入前に設計見直しが必要 |
注意すべきなのは、PPAFがアプリケーション固有の競合解決ルールまで理解するわけではない点です。カウンター、在庫数、ポイント残高、予約枠のように「最後に書いた値が常に正しい」と言えないデータでは、競合フィードを使った独自調整が必要になる可能性があります。
Business Critical階層のコストを見積もる
PPAFはBusiness Criticalサービス階層の一部として提供され、課金もそれに従います。可用性向上のための機能なので、単純に「有効化すれば安くなる」ものではありません。(Microsoft Learn)
コスト判断では、次の観点で比較すると現実的です。
| 比較対象 | 判断基準 |
|---|---|
| PPAFを使う | 単一書き込みリージョンの設計を保ちつつ、書き込み停止時間を短くしたい |
| マルチ書き込みを使う | 複数リージョンで常時書き込みを受け付けたい。競合解決設計を受け入れられる |
| 従来構成のまま | 短時間の書き込み停止を許容でき、コストを優先したい |
| アプリ側で代替制御 | 特殊な業務要件があり、DB側の自動フェールオーバーだけでは足りない |
ECサイトの注文、決済、ゲームのリアルタイム処理、IoTデータ取り込みのように、数分の書き込み停止が売上やユーザー体験に直結する場合は、Business Critical階層の費用をBCP対策費として評価しやすくなります。
開発者が確認すべきアプリケーション側の対応
PPAFでは、ほとんどのアプリケーションで必要な変更は対応SDKへのアップグレードです。PPAF有効後、Azure Cosmos DB SDKはパーティション単位のルーティングを扱い、障害パーティションへの書き込みを新しい書き込みリージョンへ透過的にリダイレクトします。(Microsoft Learn)
対応SDKバージョンを確認する
GA時点で示されている対応SDKは次の通りです。運用中のアプリケーションが複数ある場合は、全インスタンス・全サービスのSDKを棚卸ししてください。1つでも古いSDKのまま残っていると、フェールオーバー時に一部アプリだけ書き込み失敗や想定外のリトライを起こす可能性があります。(Microsoft Learn)
| 言語・SDK | 必要バージョン |
|---|---|
| .NET SDK v3 | v3.60.0以降 |
| Java SDK | v4.79.0以降 |
| Python SDK | v4.16.0以降 |
| Node.js SDK | v4.7.0以降 |
特に注意したいのは、バッチ処理、管理ツール、社内向けAPI、古いワーカーなど「普段は目立たないクライアント」です。WebフロントのAPIだけを更新しても、裏側の処理が古いSDKで書き込み続けていれば、障害時の復旧性は期待通りになりません。
リトライ前提の実装になっているか
PPAFでは、フェールオーバー中やフェールバック中に一時的な遅延やリトライが発生する可能性があります。SDKはこれらを自動的に扱いますが、アプリケーション側も一時的な失敗を前提にした設計が必要です。
実装面では、次を確認してください。
- 書き込み処理が冪等性を持っているか
- タイムアウト値が短すぎないか
- SDKのリトライを妨げる独自例外処理を入れていないか
- 同じ注文、決済、登録処理が二重実行されても破綻しないか
- 障害時にユーザーへ即エラーを返すのではなく、再試行や保留状態を扱えるか
たとえば注文APIでは、orderIdのような業務キーを使って重複作成を防ぐ設計が重要です。PPAFでDB側の可用性が上がっても、アプリ側がリトライに弱いと、ユーザーから見ると「注文が二重になった」「完了したのか分からない」という障害になります。
PreferredRegionsやApplicationRegionは不要になるが、設計上は確認する
PPAFでは、SDKがアカウントのフェールオーバー優先順位を使ってルーティングできます。そのため、ApplicationPreferredRegionsやApplicationRegionの設定は必須ではなくなります。ただし、Microsoftはこれらを引き続きベストプラクティスとして扱っています。(Microsoft Learn)
理由は単純で、フェールオーバーはDBだけの問題ではないからです。アプリケーションがどのリージョンに配置され、どのリージョンのCosmos DBへ近いかによって、通常時のレイテンシや障害時のユーザー体験が変わります。PPAFを有効化しても、アプリ配置とリージョン優先順位の設計は見直すべきです。
PPAFを有効化する手順
PPAFはAzure portal、Azure CLI、Azure PowerShellから有効化できます。管理者が最初に試すなら、Azure portalのFeaturesブレードから有効化する方法が分かりやすいでしょう。Microsoft Learnでは、Azure Cosmos DBアカウントのSettings配下にあるFeaturesから「Per-partition automatic failover」を選び、前提条件を確認してEnable PPAFへ切り替える手順が案内されています。(Microsoft Learn)
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状確認 | API種別、リージョン、整合性、スループット、SDKを棚卸し | 古いバッチ処理や管理ツールのSDKを見落とす |
| SDK更新 | 対応バージョン以上へ更新 | SDK更新後の接続・リトライ挙動を検証しない |
| リージョン確認 | セカンダリリージョンと優先順位を確認 | コストやデータ所在要件を後回しにする |
| 機能有効化 | portal、CLI、PowerShellでPPAFを有効化 | 本番でいきなり有効化する |
| 障害シミュレーション | パーティション障害を注入して挙動を確認 | メトリックを見ず、アプリの成功/失敗だけで判断する |
| 本番展開 | 段階的に有効化し、監視・アラートを整備 | 全アカウントへ一括展開して切り戻しが難しくなる |
本番導入では、まず開発・検証環境でSDK更新とPPAF有効化を行い、その後ステージング環境で障害シミュレーションを実施する流れが安全です。いきなり本番で有効化するのではなく、監視と切り戻し条件を決めてから展開してください。
障害シミュレーションと監視で確認すべきこと
PPAFを有効化しただけでは、期待通りに動くか判断できません。Microsoftは、PPAF対応アカウント向けにパーティション障害のシミュレーション機能を用意しており、PowerShellスクリプトで障害の有効化・無効化を実行できます。シミュレーションは指定コンテナーの一部パーティションに適用され、反映や停止に最大15分かかる場合があります。(Microsoft Learn)
検証では、次の観点を確認します。
| 確認対象 | 見るべき内容 |
|---|---|
| アプリの書き込み | 障害中も重要トランザクションが完了するか |
| レイテンシ | フェールオーバー中に許容範囲を超えないか |
| リトライ | SDKのリトライで回復しているか、アプリ側で握りつぶしていないか |
| リージョン別リクエスト | セカンダリリージョンへ書き込みが流れているか |
| PartitionWriteGlobalStatus | どのリージョンに書き込みパーティションが存在するか |
| フェールバック | 元リージョン復旧後に自動で戻るか |
PPAFでは、新しいサーバー側メトリックとしてPartitionWriteGlobalStatusが導入されています。このメトリックは、各リージョンで書き込みを受けているパーティション数を示し、フェールオーバー発生、移動したパーティション数、フェールバックの進行状況を確認するために使えます。(Microsoft Learn)
Azure Monitorでは、PartitionWriteGlobalStatusだけでなく、リージョン別のTotal Requests、可用性、リクエスト単位（RU）消費、レイテンシ、429/5xx系エラーもあわせて見てください。PPAFの目的は「完全に無音で障害を消すこと」ではなく、「影響範囲を小さくし、復旧を速くし、状況を観測可能にすること」です。
PPAF導入で影響を受ける運用ルール
PPAFを入れると、障害対応手順も変わります。従来は「書き込みリージョン障害なら、アカウント単位のフェールオーバーやリージョンオフラインを検討する」という運用になりがちでした。PPAF有効時は、まず自動フェールオーバーを前提に、メトリックで状況を確認する運用へ変える必要があります。
障害時にすぐ手動操作しない
PPAFは自動的にパーティション単位のフェールオーバーとフェールバックを行うよう設計されています。通常の数分〜数時間の障害では、手動介入よりもPPAFの自動処理を見守り、PartitionWriteGlobalStatusやアプリケーションメトリックで確認するのが基本です。(Microsoft Learn)
ただし、長時間のリージョン障害や、すでに多数のパーティションがセカンダリへ移っている場合は、手動で書き込みリージョンを変更して運用を整理する選択肢もあります。重要なのは、事前に「どの条件なら手動切り替えするか」を決めておくことです。
Region offlineやPartition Mergeの手順を更新する
PPAF有効中は、Region offlineやPartition Mergeをそのまま実行できません。必要な場合はPPAFを無効化し、対象操作を完了させてから再度有効化します。(Microsoft Learn)
この制約は、日常運用よりも変更作業・移行作業で問題になりやすい部分です。たとえば、リージョン構成を見直す作業、パーティション統合、災害復旧訓練、コスト最適化のための構成変更を行う場合は、PPAFの有効状態を事前チェックリストに入れておくべきです。
バックアップや復元の代替ではない
PPAFは可用性を高める機能であり、誤削除、データ破損、アプリケーションバグによる不正更新を元に戻す機能ではありません。データ復旧には、継続的バックアップやポイントインタイムリストアなど、別のバックアップ戦略が必要です。
障害対策を考えるときは、次のように役割を分けると整理しやすくなります。
| 目的 | 主に使う機能 |
|---|---|
| リージョン障害時の書き込み可用性 | PPAF、マルチリージョン構成 |
| 読み取り可用性 | Preferred regions、複数読み取りリージョン |
| データ誤削除からの復旧 | バックアップ、ポイントインタイムリストア |
| アプリ障害の切り離し | リトライ、サーキットブレーカー、キューイング |
| ユーザー流入制御 | Azure Front Door、Traffic Manager、アプリ側ヘルスチェック |
PPAFを導入しても、バックアップ、監視、アプリケーションの冪等性、トラフィック制御は引き続き必要です。
PPAFが向いているワークロード
PPAFは、特に「単一書き込みリージョンの設計は維持したいが、書き込み停止時間は短くしたい」ワークロードに向いています。
代表例は次の通りです。
| ワークロード | PPAFが効く理由 |
|---|---|
| 決済・注文管理 | 数分の書き込み停止が売上や問い合わせ増につながる |
| 在庫・予約管理 | Strong整合性を保ちつつ高可用性を高めたい |
| リアルタイムゲーム | 一部パーティション障害で全ユーザーを巻き込みたくない |
| IoTデータ取り込み | 継続的な書き込みが止まるとデータ欠損や遅延が発生する |
| 配車・配送・位置情報 | 地域的な障害でも書き込みを継続したい |
一方で、単一リージョンで十分な社内向けアプリ、短時間停止を許容できる管理画面、コスト優先の検証環境では、PPAFの導入効果が費用や運用変更に見合わない可能性があります。
導入前チェックリスト
PPAFを本番導入する前に、最低限次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| API | Azure Cosmos DB for NoSQLか |
| リージョン | 単一書き込み + 1つ以上の読み取りリージョンか |
| 優先順位 | フェールオーバー優先順位が業務要件と一致しているか |
| 整合性 | Strong、Session、Consistent Prefix、Eventualのいずれかか |
| スループット | サーバーレスではなく、プロビジョニング済みまたはAutoscaleか |
| SDK | 全アプリ・全ワーカーが対応SDK以上か |
| 競合解決 | Last Writer Winsで問題ないか |
| 監視 | PartitionWriteGlobalStatusを監視できるか |
| テスト | 障害シミュレーションで重要処理を検証したか |
| 運用手順 | 手動介入、切り戻し、連絡フローが更新されているか |
| コスト | Business Critical階層の費用を見積もったか |
| 制約 | Synapse Link、in-account restore、Partition Mergeなどの制約を確認したか |
このチェックリストで1つでも曖昧な項目がある場合、本番有効化の前に検証環境で確認してください。PPAFは可用性を高める強力な機能ですが、未対応SDKや誤った整合性設計のまま有効化すると、障害時に期待した効果が出ない可能性があります。
よくある誤解と注意点
PPAFを有効化すればマルチリージョン設計は不要になるのか
不要にはなりません。PPAFは、あくまで複数リージョン構成を前提に、パーティション単位のフェールオーバーを自動化する機能です。セカンダリリージョンの選定、フェールオーバー優先順位、アプリ配置、監視設計は引き続き必要です。
すべての障害でアプリが完全に無停止になるのか
完全無停止を保証するものではありません。フェールオーバー中、影響を受けたパーティションへの書き込みでは一時的なエラーや遅延が発生する可能性があります。SDKは自動的にリトライしますが、アプリ側もリトライや冪等性を前提にしておくべきです。(Microsoft Learn)
データモデルやパーティションキー設計は見直さなくてよいのか
PPAFはデータモデルやパーティションキーを変更しません。ホットパーティション、偏ったRU消費、非効率なクエリがある場合、それらはPPAF導入後も残ります。可用性対策とあわせて、パーティションキー設計やクエリ設計も定期的に見直すべきです。
AI/Copilot系の更新なのか
今回のPPAFは、AIやCopilotそのものの機能追加ではありません。Azure Cosmos DBはAIアプリやエージェント向けの更新も増えていますが、PPAFの本質はミッションクリティカルなアプリケーションの可用性と障害復旧を改善する運用基盤の強化です。AIアプリでCosmos DBをメモリストアやベクトル検索基盤として使う場合も、基盤の書き込み可用性を高める意味で重要な更新といえます。
まず取るべき行動
Azure Cosmos DBで本番ワークロードを運用しているなら、まず対象アカウントの棚卸しから始めてください。特に、Azure Cosmos DB for NoSQL、単一書き込みリージョン、複数リージョン構成、書き込み停止に弱い業務処理を持つアカウントは、PPAF導入候補になります。
次に、全アプリケーションのSDKバージョンを確認し、対応バージョンへ更新します。そのうえで、検証環境でPPAFを有効化し、障害シミュレーション、PartitionWriteGlobalStatusの監視、重要トランザクションのリトライ挙動を確認します。
PPAFは、Azure Cosmos DBの可用性設計を「アカウント全体の大きな切り替え」から「影響パーティションだけの細かな自動復旧」へ進める更新です。導入の成否は、機能をオンにすることではなく、SDK、リージョン、整合性、監視、運用手順をそろえたうえで本番へ展開できるかにかかっています。
コメント