Azure Blob Storage Geo Priority Replication は、Azure BLOB ユーザーの厳格なコンプライアンスとビジネス継続性の要件を満たすように設計されています。 この機能は、geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) が有効になっているストレージ アカウントの BLOB データのレプリケーションに優先順位を付けます。 この優先順位付けにより、これらの geo 冗長アカウントのプライマリ リージョンとセカンダリ リージョン間のデータ レプリケーションが高速化されます。
サポートされているワークロードの場合、サービス レベル アグリーメント (SLA) は geo 優先度レプリケーションもバックし、geo 優先度レプリケーションが有効になっているすべてのアカウントに適用されます。 これにより、アカウントのブロック BLOB データの最終同期時刻 (LST) が、請求月の 99.0% で 15 分以下遅れたままであることが保証されます。 この機能には、優先順位付けされたレプリケーション トラフィックに加えて、強化された監視と詳細なテレメトリが含まれます。
資格要件の包括的な一覧については、公式の SLA 条件 を参照してください。
Geo優先度レプリケーションの利点
geo 優先度レプリケーションを使用する利点は多数ありますが、次のようなシナリオでは特に便利です。
- ストレージ データに対して厳密な回復ポイント目標 (RPO) を必要とするコンプライアンス規則を満たす。
- 同期時間の保証により、データの持続性と可用性に関する信頼度が得られます。特に、予期しない障害が発生し、プライマリ リージョンで 計画外のフェールオーバー が必要な場合です。
SLA の適格性と除外
Geo Priority Replication には、Azure Blob Storage の SLA に基づく機能が導入されていますが、いくつかの重要な除外が用意されています。 ユーザーは、Geo 優先度レプリケーションが有効になっている間に、優先順位付けされたレプリケーションの恩恵を受け、BLOB Geo ラグの可視性が向上します。 ただし、ユーザーが geo 優先レプリケーションのサービス レベル アグリーメントの対象にならないワークロードと期間があります。 次のような制限です。
- ページ BLOB や追加 BLOB など、他の BLOB の種類。
SLA はブロック BLOB データにのみ適用されます。 これらのサポートされていない BLOB の種類が geo ラグの影響を受ける場合、影響を受ける時間枠は SLA の対象から除外されます。 - 過去 30 日以内に追加またはページ BLOB API 呼び出しが行われたストレージ アカウント。
これは、追加またはページ BLOB を作成する機能をアカウントで有効にしているユーザーに影響する可能性があります。 たとえば、Azure Monitor の変更フィード、オブジェクト レプリケーション、リソース ログなどです。 - Geo 優先度レプリケーションの有効化中に、最終同期時間が 15 分を超えるストレージ アカウントが遅れています。
データ レプリケーションの優先順位付けは、機能を有効にした直後に開始されますが、この初期同期期間中は SLA が適用されない場合があります。 この期間中にアカウントの最終同期時間が 15 分を超えた場合、最終同期時間が一貫して 15 分以下になるまで SLA は適用されません。 お客様は、Azure で提供されているメトリックとダッシュボードを使用して 、LST とレプリケーションの状態を監視できます。 - 次に該当する期間:
- ストレージ アカウントのデータ転送速度が 1 ギガビット/秒 (Gbps) を超え、結果として生じる書き込みのバック ログがレプリケートされます。
- ストレージ アカウントが 1 秒あたり 100 CopyBlob 要求を超え、結果の書き込みのバック ログがレプリケートされます
これらの制限は、SLA が適用される方法とタイミングを理解するうえで重要であり、Azure には詳細なテレメトリとメトリックが用意されており、お客様が請求月を通じて適格性を監視するのに役立ちます。 これらの間隔では、データのレプリケーションの優先順位は維持されますが、アカウントは SLA の適格性から一時的に除外されます。 資格要件の包括的な一覧については、公式の SLA 条件 を参照してください。
Important
一部の運用シナリオでは、SLA カバレッジが中断される可能性もあります。 たとえば、計画外のフェールオーバーでは Geo Priority Replication が自動的に無効になり、geo 冗長が復元された後に機能を手動で再度有効にする必要があります。 これに対し、GRS と geo ゾーン冗長ストレージ (GZRS) 間の計画されたフェールオーバーとアカウント変換は、アカウントがガードレール内に留まらない限り、SLA の適格性には影響しません。
コンプライアンスの監視
透明性を確保し、Geo 優先度レプリケーションのパフォーマンスを追跡できるようにするために、Azure には、Azure Monitor メトリックに直接統合された新しい監視ツールが用意されています。 geo 優先度レプリケーションを有効にすると、アカウントごとに BLOB データの新しい Geo BLOB ラグ メトリック (プレビュー) を表示できます。 [ 冗長性 ] ウィンドウと [メトリック] ウィンドウを使用して、1 か月間の "geo BLOB ラグ" のパフォーマンスを確認できます。 Geo Blob Lag メトリック (プレビュー) を使用すると、ブロック BLOB データのラグ (プライマリリージョンとセカンダリ リージョン間の最後の完全なデータ コピーからの秒数) を監視できます。 このメトリックを使用すると、パフォーマンスの傾向を評価し、アカウントの潜在的な SLA 違反を特定できます。
geo 優先度レプリケーションを有効にし、Geo BLOB ラグ メトリック (プレビュー) に登録すると、新しいメトリックを表示できます。
Geo-Redundant Storage レプリケーションを有効または無効にする
Geo Priority Replication の有効化と無効化は簡単で、Azure portal、PowerShell、または Azure CLI を使用して完了できます。 新しいアカウントを作成するプロセス中に有効にすることも、既存のアカウントで有効または無効にすることもできます。
新しいアカウントの作成時にレプリケーションを有効にする
新しいストレージ アカウントの作成時に Geo Priority Replication を有効にするには、次の手順を実行します。
Azure portal に移動し、新しいストレージ アカウントを作成します。
次のスクリーンショットに示すように、[ 基本 ] タブで、地理的優先レプリケーションのチェックボックスをオンにします。
既存のアカウントのレプリケーションを有効または無効にする
既存のストレージ アカウントに対して Geo Priority Replication を有効または無効にするには、次の手順を実行します。
Azure portal に移動し、ストレージ アカウントを選択します。
データ管理グループで、[冗長性] を選択して、ストレージ アカウントの冗長性オプションを表示します。
この機能を有効にするには、次のスクリーンショットに示すように Geo 優先度レプリケーション (BLOB のみ) チェック ボックスをオンにし、[保存] を選択 します。
この機能を無効にするには、次のスクリーンショットに示すように Geo 優先度レプリケーション (BLOB のみ) チェック ボックスをオフにして、[保存] を選択 します。
設定が正常に保存されていることを確認します。
この機能を有効にした場合は、 Geo 優先度レプリケーション の状態が選択されていること、および次のスクリーンショットに示すように、[ メトリックの表示] リンクが使用可能で有効になっていることを確認します。
この機能を無効にした場合は、 Geo 優先度レプリケーション の状態が選択されていないこと、および次のスクリーンショットに示すように 、[ メトリックの表示] リンクが使用できないかどうかを確認します。
機能の価格
地理的優先レプリケーションの課金は、2026年1月1日に開始されます。 geo 優先度レプリケーションが有効になっている既存のすべてのアカウントと、この機能を有効にする新しいアカウントは、2026 年 1 月 1 日の時点で課金されます。 geo 優先度レプリケーションの有効化には GB 単位のコストが伴います。詳細な価格情報については、 Azure Storage の価格に関するページを参照してください。
Important
Geo Priority Replication を無効にすると、アカウントは機能が無効になった日付から 30 日間課金されます。
