既存の Azure Cosmos DB アカウントを Western Europe から Germany West Central など別リージョンへ「移したい」。最短ルートは、対象アカウントをマルチリージョン化して手動フェールオーバー、旧リージョン削除という三手です。この記事では「高い需要により一時利用不可」と出た場合の現実的な対処、移行しない選択のメリット・デメリット、コストと運用の落とし穴まで実務視点で詳説します。
目次
Azure Cosmos DB アカウントを別リージョンへ移行したい（実務ガイド）
最初に押さえるべきポイント（要約）
- 既存アカウントのリージョンを切り替える最短手順は「新リージョン追加 → 手動フェールオーバー → 旧リージョン削除」。
- この方法はアカウントを一時的にマルチリージョンにするため、その間は両リージョン分の課金が発生します。
- ポータルで新リージョンが「高い需要により一時利用不可」なら、近隣リージョンでの一時運用や新規アカウント＋データ移行など代替策を即検討。
- アプリ側は SDK のPreferred Regions設定で無停止切替を実現。Private Endpoint・ファイアウォール・DNS などネットワーク層の差し替えも忘れずに。
- シングルリージョン要件や Serverless の場合は、新規アカウント作成＋データコピー（Data Migration Tool／Change Feed 同期）が確実です。
背景と用語整理
- 書き込みリージョン／読み取りリージョン：Cosmos DB は一つの「書き込み」（Single-Write）と複数の「読み取り」を持てます（Multi-Write を有効化する設計も可）。
- 手動フェールオーバー：意図的に書き込みリージョンを切り替える操作。SDK のマルチホーミング・再試行により、適切に組んでいればアプリ無停止で切替可能。
- 課金モデル：スループット（RU/s）はリージョンごとに課金。ストレージもレプリカ分増えます。移行中は実質二重コスト。
- Serverless について：Serverless は（執筆時点で）単一リージョン前提。本記事のフェールオーバー手順はプロビジョンドスループット（手動／Autoscale）向けです。
推奨手順（ポータル操作）
ポータルのナビゲーションは「Replicate data globally（データのグローバル レプリケーション）」が中心になります。
| 手順 | 内容 | 補足 |
|---|---|---|
| 1. 新しいリージョンを追加 | Azure ポータル → 対象アカウント → Replicate data globally → 追加したいリージョン（例：Germany West Central）を選択 | この時点でマルチリージョン構成。両リージョン分の課金が発生 |
| 2. 手動フェールオーバー | 旧リージョンが書き込みリージョンなら、同画面から手動フェールオーバーを実行し、新リージョンを書き込みリージョンへ | SDK の再試行・Preferred Regions 設定があれば無停止切替が可能 |
| 3. 旧リージョンを削除 | フェールオーバー完了後、不要になったリージョンを削除 | 削除実行の瞬間からそのリージョンの課金が停止 |
前提チェックリスト（着手前に必ず確認）
| 項目 | 確認ポイント | 影響／対処 |
|---|---|---|
| パーティションキー | ホットパーティションがないか、スループットの偏りは許容内か | 移行中は RU 消費が増えやすい。必要なら Autoscale を一時的に引き上げる |
| Unique Key | 新規コンテナー作成時しか設定不可 | 新規アカウント移行パスでは先に Unique Key を定義 |
| TTL・インデックス | 不要データは事前に TTL で整理／インデックス削減 | ストレージ＆ RU を圧縮し、複製コストを抑える |
| バックアップ モード | 定期／連続（PITR）などの設定を把握 | 切替後も要件を満たすか確認。復旧テスト計画を用意 |
| ネットワーク | Private Endpoint／Firewall／Private DNS | 新リージョン分の Private Endpoint を追加作成。DNS ゾーンの A レコード更新も忘れずに |
| アプリ接続 | SDK／ドライバのバージョンと Preferred Regions | グローバル エンドポイント＋ Preferred Regions 推奨。リージョン固定のエンドポイントは避ける |
アプリ側の準備（Preferred Regions 設定例）
SDK の「優先リージョン」設定に新リージョン（例：Germany West Central）を先頭に置くと、切替直後の接続収束が早まります。
// .NET (Azure.Cosmos)
var client = new CosmosClient(
connectionString,
new CosmosClientOptions {
ApplicationPreferredRegions = new List<string> {
"Germany West Central", "West Europe" // Western Europe (= West Europe)
},
EnableTcpConnectionEndpointRediscovery = true
}
);// Java
CosmosAsyncClient client = new CosmosClientBuilder()
.endpoint(endpoint)
.key(key)
.preferredRegions(Arrays.asList("Germany West Central", "West Europe"))
.buildAsyncClient();// Node.js
const { CosmosClient } = require("@azure/cosmos");
const client = new CosmosClient({
endpoint,
key,
preferredRegions: ["Germany West Central", "West Europe"]
});- 再試行ポリシー（タイムアウト／接続再確立）はデフォルトで良いが、遅延を短くしたい場合はフェールオーバー実施時間帯だけ待機時間を微調整。
- アプリがグローバル エンドポイント（
https://<account>.documents.azure.com/）を使っていれば、接続文字列の変更は原則不要。
移行当日のオペレーション手順（無停止を実現するコツ）
- 低トラフィック時間帯を選定（バッチやピークを避ける）。
- 必要に応じて一時的に RU を増やす（Autoscale を利用して上限を広げる）。
- 新リージョン追加後、レプリケーションの遅延が収束するまで少し待つ（メトリクス：Replicated Data Latency / Pending Replication）。
- 手動フェールオーバーを実行。SDK の Preferred Regions 設定により、クライアントは自動的に新リージョンへ収束。
- アプリの監視（P95/P99 レイテンシ、エラー率、依存サービスの疎通）を確認。
- 旧リージョン削除を実行。Private Endpoint と DNS、Firewall の設定も整理。
適切に構成されたアプリであれば、ユーザー影響は体感しにくいレベルに抑えられます。直後はコネクションの張り直しでレイテンシが一瞬だけ上がる可能性があるため、APM で確認できる体制を整えておくと安心です。
「高い需要により一時利用不可」の対処戦略
Germany West Central などで追加ボタンが無効化されることがあります。選べないときの現実的な選択肢です。
| 選択肢 | やること | 向いているケース |
|---|---|---|
| 待つ（再開を待機） | アラート運用しつつ、一定期間後に再トライ | 緊急性が低い。現状のレイテンシ／主権要件を満たしている |
| 近隣リージョンを採用 | North Europe / France Central などを一時的に採用 | レイテンシ要件が厳しく、EU 域内・近接性を保ちたい |
| 一時中継 → 後日切替 | 近隣で運用開始 → 需要が落ち着いたら希望リージョンに再移行 | 納期優先。柔軟に二段階移行できる |
| 新規アカウント＋データコピー | 希望リージョンに新規作成（可能なら）→ Data Migration Tool や Change Feed 同期 | シングルリージョン要件、Serverless 利用、権限や設計を見直したい |
| サポートへ相談 | 業務影響が大きい場合はサポートに状況を共有 | SLA／コンプライアンス要件が厳格で、代替が難しい |
「移行しない」判断のメリット／デメリット
| 観点 | 移行する場合 | 移行しない場合 |
|---|---|---|
| レイテンシ | 利用者に近いリージョンへ寄せれば改善 | 現状維持。要件を満たしていれば問題なし |
| データ主権 | 国・地域内に限定可能（例：Germany 内） | Western Europe の取り扱い方針に準拠 |
| コスト | 移行期間は二重コスト。定常は要件次第 | 追加コストなし。最適化の自由度は下がる |
| 運用負荷 | 一時的に上がる（検証／ネットワーク変更など） | 変わらず。将来の要件変更時に再検討 |
シングルリージョン要件や Serverless の場合：新規アカウント＋データ移行
マルチリージョン化できない場合、ターゲット側に新規 Cosmos DB アカウントを作成し、データをコピーするのが堅実です。
アプローチ A：Azure Cosmos DB Data Migration Tool（ワンショット）
- ターゲットに同じデータベース／コンテナー構造を用意（パーティションキー・Unique Key・インデックスを先に設計）。
- Data Migration Tool でソース（Western Europe）→ ターゲット（Germany West Central）へ一括コピー。
- メンテナンス時間にアプリの書き込みを一時停止し、最終差分をコピーして切替。
アプローチ B：Change Feed 同期（段階移行）
- バックグラウンドで Change Feed を購読（Functions／Worker／ADF）し、ターゲットへ継続反映。
- 差分が追いついたら短時間の凍結（書き込み停止）を行い、最終スイッチ。
二段階移行はダウンタイム最小化に有効ですが、重複書き込み対策（冪等処理・再試行時の一意性担保）が必要です。
コストの考え方（簡易モデル）
移行中はスループットとストレージがリージョン数ぶん増えます。目安計算は以下を参考にします。
| 項目 | 計算の考え方 | メモ |
|---|---|---|
| スループット（RU/s） | （プロビジョンド RU/s）×（リージョン数） | Autoscale は上限 RU/s を基準。必要に応じて一時的に下げて追加→切替後に戻す |
| ストレージ | （データサイズ）×（リージョン数） | 削除したリージョン分は即時に課金停止 |
| オペレーション | レプリケーションと再同期で通常より RU 消費増 | ピーク回避・時間帯調整で最小化 |
- 不要データの整理（TTL）とインデックス簡素化は、移行コスト削減に直結します。
- 長期的に利用が確定している RU は予約系プランの検討余地があります（要件と契約方針に応じて）。
ネットワークとセキュリティの落とし穴
- Private Endpoint はリージョン単位：新リージョンごとに作成が必要。VNet／サブネットの設計、Private DNS ゾーンの A レコードの追加・更新も忘れずに。
- Firewall 許可 IP：新リージョンのクライアント経路（NAT／プロキシ）を許可。IP 範囲が変わる構成では事前に追加。
- 接続先の固定禁止：リージョン固有エンドポイントをハードコードしていると切替で落ちます。グローバル エンドポイント＋Preferred Regionsに統一。
- 可観測性：切替前後のメトリクス（レイテンシ・スロットリング・失敗率）とログ（429／503 等）をダッシュボード化。
整合性・可用性の観点（設計判断）
- 一貫性レベル：Strong／Bounded Staleness／Session／Consistent Prefix／Eventual を要件に合わせて選定。レイテンシと RU に影響します。
- Multi‑Write の是非：複数リージョンで書き込みが必要なら有効化。ただし競合解決（Last Write Wins 等）とアプリの整合性要件を事前検証。
- フェールオーバー優先度：ポータルで順位を定義。災害対策（DR）としての整合も合わせて考える。
実践チェックリスト（抜粋）
| タイミング | チェック | 合格基準 |
|---|---|---|
| 事前 | SDK と接続先がグローバル エンドポイント＋Preferred Regions になっている | コード・設定を確認し、リージョン固定参照がない |
| 事前 | Private Endpoint／DNS／Firewall の新リージョン分の準備 | 疎通テスト（nslookup/ping 相当）とアプリの接続検証を実施 |
| 切替直前 | メトリクス上のレプリケーション遅延が収束 | 許容値（自社基準）内に入っている |
| 切替直後 | P95/P99 レイテンシ・エラー率に異常がない | しきい値内。必要に応じて RU を一時的に引き上げる |
| 完了 | 旧リージョン削除と不要リソース（PE/DNS/IP）撤去 | 二重コストが停止し、監視も新構成に更新済み |
ロールバック戦略
- 切替後に問題が判明した場合、手動フェールオーバーで旧リージョンへ戻す（旧リージョンを削除していない前提）。
- 根本原因を是正後、再度フェールオーバー。安定を確認してから旧リージョンを削除。
- 新規アカウント移行パスの場合は、DNS／接続情報の切替を元に戻す手順書（踏み石）を用意しておく。
ケーススタディ（EU 内での移行シナリオ）
EU 圏ユーザー向けサービスで Western Europe に置いていた Cosmos DB を Germany West Central へ寄せる例です。
- 目的：データ主権の強化・法令準拠、ドイツ国内のレイテンシ改善。
- 計画：平日深夜 2 時台に切替。事前に TTL で古いイベントを削除し、インデックスを簡素化。
- 実施：Germany West Central を追加 → レプリケーション収束 → 手動フェールオーバー → 監視正常 → Western Europe 削除。
- 結果：P95 レイテンシが 15–25% 改善。二週間で二重コスト期間を解消。
よくある質問（FAQ）
Q. 切替にダウンタイムは発生しますか？
適切に SDK を設定（Preferred Regions／自動再試行）し、ネットワークも新リージョン対応済みなら、ユーザー影響は極小にできます。わずかな接続張り直しの揺らぎに備え、低トラフィックで行うのが現実解です。
Q. どれくらい時間がかかりますか？
データ量・変更頻度・RU/s に左右されます。大容量ではレプリケーション収束に時間を見込み、ピークを避けて計画しましょう。
Q. Serverless を使っています。どうすれば？
Serverless は単一リージョン前提です。新規アカウント＋データコピー（ワンショットまたは Change Feed 同期）での移行が適しています。
Q. 近接リージョンの選び方は？
ユーザーの居場所・ネットワーク経路・他コンポーネント（App Service／Functions／Storage）との同居を考慮します。アプリが複数リージョンにまたがるほど、間の通信遅延が性能に響きます。
Q. 旧リージョンを削除するタイミングは？
メトリクスが安定し、復旧ポイントや監視・バックアップが新体制で機能していることを確認してから。削除した瞬間に課金停止になるため、目標日時を決めて実施します。
まとめ（実務の勘所）
- 三手で完了：新リージョン追加 → 手動フェールオーバー → 旧リージョン削除。
- アプリは事前整備：グローバル エンドポイント＋Preferred Regions、再試行＆タイムアウトを適切に。
- ネットワークを忘れない：Private Endpoint／DNS／Firewall を新リージョン分準備。
- 「利用不可」でも慌てない：近隣リージョン・二段階移行・新規アカウント＋コピーで回避。
- コストは設計で決まる：TTL・インデックス最適化、短期二重コストを計画的に圧縮。
参考手順（詳細版：スクリーンなしでも迷わない）
- Azure ポータルでアカウントを開き、左メニューからReplicate data globally を選択。
- Add region をクリックし、Germany West Central（または希望リージョン）を追加。表示が「高い需要で一時利用不可」の場合は近隣を選択するか、後述の代替策へ。
- レプリケーションが進む間、アプリのメトリクスを監視。エラー率やスロットリングが増えるなら一時的に RU を引き上げる。
- 同画面のManual failover で書き込みリージョンを新リージョンへ切替。
- 数分〜十数分の観察期間を取り、APM と Cosmos DB メトリクス（レイテンシ、サーバー側エラー、スロットリング）を確認。
- 問題なければ旧リージョンの「×」をクリックして削除。Private Endpoint／DNS／Firewall の旧設定も片付け、二重構成を解消。
トラブルシュートのヒント
- フェールオーバーが進まない：アカウントの状態（保護／ポリシー）や依存するネットワーク設定を確認。直前に大規模書き込みがあると収束に時間がかかるため、少し間を置く。
- アプリでタイムアウト：SDK を最新化し、Preferred Regions に新リージョンが含まれているか確認。接続プールのアイドル時間・DNS キャッシュの影響も点検。
- 想定よりコスト増：コピーやレプリケーションで RU が跳ねやすい。インデックスの一時簡素化やバルクロード、バッチ間隔の最適化で抑制。
補足・注意点（依頼内容への回答を補強）
リージョンが選択不可の場合の具体策
- 利用再開を待つスケジュールが許容できないなら、North Europe / France Central など近接リージョンを候補に。
- 中継リージョンで運用開始 → 需要が落ち着いたら本命へ再移行。二段階移行で納期と主権要件の両立を図る。
- 新規アカウント作成が可能なら、Data Migration Tool でワンショット移行、またはChange Feed + Functions/Worker で段階移行。
移行しない場合の影響
- Western Europe で性能・コスト・コンプライアンス要件を満たすなら、無理に動かす必要はありません。
- 一方、データ主権（ドイツ国内保管）やレイテンシに明確な要求があるなら、移行を再検討。
コスト管理のベストプラクティス
- 移行期間は二重課金（RU／ストレージ）。切替が終わったらすぐに不要リージョンを削除してコスト最適化。
- 事前にデータを整理（TTL・アーカイブ）。インデックスを軽量化し、コピーやレプリケーションの RU を節約。
- Autoscale の上限を一時的に上げてピーク時のスロットリングを回避しつつ、完了後は元に戻して固定費を抑制。
サンプル運用テンプレート（コピペして使える）
変更申請・メンテナンス通知のひな形
[変更目的]
Cosmos DB の書き込みリージョンを Western Europe から Germany West Central へ切替し、データ主権とレイテンシを最適化する。
[影響]
アプリは無停止想定。切替直後に接続再確立による一時的なレイテンシ上昇の可能性あり。
[手順]
1. 新リージョン追加
2. レプリケーション収束確認
3. 手動フェールオーバー
4. 監視で安定性確認
5. 旧リージョン削除／ネットワーク設定整理
[ロールバック]
同手順で旧リージョンを再度書き込みに昇格。安定確認後に再トライ。監視しきい値の例
| 指標 | 観点 | しきい値の例 |
|---|---|---|
| P95 レイテンシ | ユーザー体感に直結 | 平常値＋20% を超えたら要注意 |
| 429（スロットリング） | RU 不足の兆候 | 急増したら RU／インデックス／バルク処理を見直す |
| サーバーエラー率 | 安定性 | しきい値超過でロールバック検討 |
結び
Cosmos DB のリージョン移行は、正しい順序と下準備さえ整えば、短期間・低リスクで完遂できます。新リージョン追加 → 手動フェールオーバー → 旧リージョン削除というシンプルな三手を軸に、SDK 設定・ネットワーク・監視・コストの四点を丁寧に押さえましょう。「高い需要で一時利用不可」に遭遇しても、近隣リージョン採用や新規アカウント＋データコピーなど複数の回避策があります。要件・納期・コストのバランスを取りながら、最適な移行計画を描いてください。
コメント