ブロック BLOB のオブジェクト レプリケーション

オブジェクト レプリケーションを使用すると、ソース ストレージ アカウントと宛先アカウントの間でブロック BLOB を非同期にコピーできます。 オブジェクト レプリケーションでサポートされるシナリオには次のものがあります。

• 待機時間の最小化。 オブジェクト レプリケーションでは、クライアントが物理的に近いリージョンのデータを使用できるようにすることで、読み取り要求の待機時間を短縮できます。
• コンピューティング ワークロードの効率を向上させる。 オブジェクト レプリケーションでは、コンピューティングワークロードが同じブロック BLOB セットを複数のリージョンで処理できます。
• データ分散の最適化。 データを 1 つの場所で処理または分析し、その結果のみを別のリージョンにレプリケートできます。
• コストの最適化。 データがレプリケートされた後に、ライフ サイクル管理ポリシーを使用してデータをアーカイブ層に移動することで、コストを削減できます。

次の図は、オブジェクト レプリケーションによって、あるリージョンのソース ストレージ アカウントから別の 2 つのリージョンの宛先アカウントにブロック BLOB がレプリケートされる様子を示しています。

オブジェクト レプリケーションを構成する方法については、「オブジェクト レプリケーションの構成」をご覧ください。

オブジェクト レプリケーションの前提条件と注意事項

オブジェクト レプリケーションを使用するには、次の Azure Storage 機能が有効になっている必要もあります。

• 変更フィード:ソース アカウントで有効になっている必要があります。 変更フィードを有効にする方法については、「変更フィードを有効または無効にする」をご覧ください。
• BLOB のバージョン管理:ソース アカウントと宛先アカウントの両方で有効にする必要があります。 BLOB のバージョン管理を有効にする方法については、「BLOB のバージョン管理を有効にして管理する」をご覧ください。

変更フィードと BLOB バージョン管理を有効にすると、追加のコストが発生する場合があります。 詳細については、Azure Storage の価格に関するページを参照してください。

オブジェクト レプリケーションは、汎用 v2 ストレージ アカウントおよび Premium ブロック BLOB アカウントでサポートされています。 ソース アカウントと宛先アカウントは両方とも、汎用 v2 アカウントまたは Premium ブロック BLOB アカウントのいずれかでなければなりません。 オブジェクト レプリケーションは、ブロック BLOB のみをサポートします。追加 BLOB とページ BLOB はサポートされていません。

オブジェクト レプリケーションは、Microsoft マネージド キーまたはカスタマー マネージド キーのいずれかを使って暗号化されているアカウントでサポートされています。 カスタマー マネージド キーの詳細については、「Azure Storage の暗号化のためのカスタマー マネージド キー」を参照してください。

オブジェクト レプリケーションは、お客様が指定したキーで暗号化されたソース アカウントの BLOB ではサポートされません。 カスタマー指定のキーの詳細については、「BLOB ストレージに対する要求で暗号化キーを指定する」を参照してください。

お客様が管理するフェールオーバーは、オブジェクト レプリケーション ポリシーのソース アカウントまたは宛先アカウントのいずれでもサポートされていません。

オブジェクト レプリケーションは、Data Lake Storage API を使用してアップロードされる BLOB ではサポートされていません。

オブジェクト レプリケーションのしくみ

オブジェクト レプリケーションは、構成したルールに従って、コンテナー内のブロック BLOB を非同期にコピーします。 BLOB の内容、BLOB に関連付けられているすべてのバージョン、BLOB のメタデータとプロパティはすべて、ソース コンテナーから宛先コンテナーにコピーされます。

重要

ブロック BLOB データは非同期にレプリケートされるため、ソース アカウントと宛先アカウントはすぐには同期されません。現在、宛先アカウントにデータをレプリケートするための所要時間に関する SLA はありません。 レプリケーションが完了しているかどうかを確認するには、ソース BLOB のレプリケーションの状態を確認します。 詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。

BLOB バージョン管理

オブジェクトのレプリケーションでは、ソース アカウントと宛先アカウントの両方で BLOB のバージョン管理が有効になっている必要があります。 ソース アカウントのレプリケート対象 BLOB が変更されると、変更前の BLOB の状態を反映する新しいバージョンの BLOB がソース アカウントに作成されます。 ソース アカウントの現在のバージョンには、最新の更新が反映されています。 現在のバージョンといずれかの以前のバージョンの両方が、宛先アカウントにレプリケートされます。 書き込み操作が BLOB のバージョンに与える影響の詳細については、「書き込み操作でのバージョン管理」を参照してください。

ストレージ アカウントでオブジェクト レプリケーション ポリシーが有効になっている場合、そのアカウントの BLOB バージョン管理は無効にできません。 BLOB バージョン管理を無効にする前に、アカウントのオブジェクト レプリケーション ポリシーを削除する必要があります。

Note

コピー先には BLOB のみがコピーされます。 BLOB のバージョン ID はコピーされません。 コピー先の場所に配置された BLOB には、新しいバージョン ID が割り当てられます。

ソース アカウントでの BLOB 削除

ソース アカウントの BLOB が削除されると、現在のバージョンの BLOB が以前のバージョンになり、現行のバージョンはなくなります。 既存の以前のバージョンの BLOB はすべて保持されます。 この状態は、宛先アカウントにレプリケートされます。 削除操作が BLOB のバージョンに与える影響の詳細については、「削除操作でのバージョン管理」を参照してください。

スナップショット

オブジェクト レプリケーションでは、BLOB のスナップショットはサポートされていません。 ソース アカウントの BLOB のスナップショットは、宛先アカウントにレプリケートされません。

BLOB インデックス タグ

オブジェクト レプリケーションでは、ソース BLOB のインデックス タグはコピー先 BLOB にコピーされません。

BLOB の階層

オブジェクトのレプリケーションは、ソース アカウントと宛先アカウントがホット層またはクール層にある場合にサポートされます。 ソース アカウントと宛先アカウントが異なる層に存在していてもかまいません。 ただし、ソース アカウントまたは宛先アカウントのどちらかで BLOB がアーカイブ層に移動されている場合、オブジェクトのレプリケーションは失敗します。 BLOB 層の詳細については、「BLOB データのアクセス層」を参照してください。

不変 BLOB

Azure Blob Storage の不変性ポリシーには、時間ベースの保持ポリシーと訴訟ホールドが含まれています。 宛先アカウントで不変性ポリシーが有効な場合、オブジェクト レプリケーションが影響を受ける可能性があります。 不変ポリシーの詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。

宛先アカウント内のコンテナーに対してコンテナー レベルの不変性ポリシーが有効で、ソース コンテナー内のオブジェクトが更新または削除された場合、ソース コンテナーに対する操作は成功する可能性がありますが、その操作の宛先コンテナーへのレプリケーションは失敗します。 コンテナーを対象にした不変性ポリシーで禁止されている操作の詳細については、「コンテナー レベルのスコープを持つシナリオ」を参照してください。

宛先アカウントの BLOB バージョンに対してバージョン レベルの不変性ポリシーが有効で、ソース コンテナー内の BLOB バージョンに対して削除または更新操作が実行された場合、ソース オブジェクトに対する操作は成功する可能性がありますが、コピー先オブジェクトへのその操作のレプリケーションは失敗します。 コンテナーを対象にした不変性ポリシーで禁止されている操作の詳細については、「バージョン レベルのスコープを使用するシナリオ」を参照してください。

オブジェクト レプリケーションのポリシーとルール

オブジェクト レプリケーションを構成するときに、ソース ストレージ アカウントと宛先アカウントを指定するレプリケーション ポリシーを作成します。 レプリケーション ポリシーには、ソース コンテナーと宛先コンテナーを指定し、レプリケートするソース コンテナー内のブロック BLOB を示す 1 つ以上のルールが含まれます。

オブジェクト レプリケーションを構成すると、Azure Storage によってソース アカウントの変更フィードが定期的にチェックされ、書き込みまたは削除操作が宛先アカウントに非同期にレプリケートされます。 レプリケーションの待機時間は、レプリケートされるブロック BLOB のサイズによって異なります。

レプリケーション ポリシー

オブジェクト レプリケーションを構成する際に、Azure Storage リソース プロバイダー経由で宛先アカウントにレプリケーション ポリシーを作成します。 レプリケーション ポリシーが作成されると、Azure Storage でポリシー ID が割り当てられます。 その後、このポリシー ID を使用して、そのレプリケーション ポリシーをソース アカウントに関連付ける必要があります。 レプリケーションを実行するには、ソース アカウントと宛先アカウントのポリシー ID が同じである必要があります。

ソース アカウントは、宛先アカウントごとに 1 つのポリシーを使用して、2 つまでの宛先アカウントにレプリケートできます。 同様に、1 つのアカウントを 2 つまでのレプリケーション ポリシーの宛先アカウントにすることができます。

ソース アカウントと宛先アカウントが同じリージョンに存在していても、異なるリージョンに存在していてもかまいません。 また、これらは同じサブスクリプションに存在していても、異なるサブスクリプションに存在していてもかまいません。 必要に応じて、ソースと宛先のアカウントを異なる Microsoft Entra テナントに配置できます。 ソース アカウントと宛先アカウントのペアごとに作成できるレプリケーション ポリシーは、1 つのみです。

レプリケーション ルール

レプリケーション ルールでは、Azure Storage がソース コンテナーから宛先コンテナーにどのように BLOB をレプリケートするかを指定します。 レプリケーション ポリシーごとに最大 1,000 個のレプリケーション ルールを指定できます 各レプリケーション ルールによって単一のソースおよび宛先コンテナーが定義され、ソースと宛先の各コンテナーは 1 つのルールの中でのみ使用できます。つまり、1 つのレプリケーション ポリシーには、最大 1,000 個のソース コンテナーと 1,000 個の宛先コンテナーを参加させることができます。

レプリケーション ルールを作成すると、既定では、その後にソース コンテナーに追加された新しいブロック BLOB のみがコピーされます。 新しいブロック BLOB と既存のブロック BLOB の両方がコピーされるように指定することも、指定した時間以降に作成されたブロック BLOB をコピーするカスタム コピー スコープを定義することもできます。

また、レプリケーション ルールの一部として 1 つ以上のフィルターを指定して、ブロック BLOB をプレフィックスでフィルター処理することもできます。 プレフィックスを指定すると、ソース コンテナー内のそのプレフィックスと一致する BLOB のみが宛先コンテナーにコピーされます。

ルールでソースと宛先のコンテナーを指定する前に、それらの両方が存在している必要があります。 レプリケーション ポリシーを作成した後、宛先コンテナーへの書き込み操作は許可されません。 宛先コンテナーへの書き込みを試みると、エラー コード 409 (競合) で失敗します。 レプリケーション ルールが構成されている宛先コンテナーに書き込むには、そのコンテナーに対して構成されているルールを削除するか、レプリケーション ポリシーを削除する必要があります。 レプリケーション ポリシーがアクティブになっている場合、宛先コンテナーに対する読み取りおよび削除操作は許可されます。

宛先コンテナーの BLOB で Set Blob Tier 操作を呼び出して、それをアーカイブ層に移動できます。 アーカイブ アクセス層の詳細については、「BLOB データのアクセス層」を参照してください。

Note

ソース アカウント内の BLOB のアクセス層を変更しても、宛先アカウント内の BLOB のアクセス層は変更されません。

ポリシー定義ファイル

オブジェクト レプリケーション ポリシーは、JSON ファイルによって定義されます。 ポリシー定義ファイルは、既存のオブジェクト レプリケーション ポリシーから取得できます。 また、ポリシー定義ファイルをアップロードして、オブジェクト レプリケーション ポリシーを作成できます。

ポリシー定義ファイルの例

次の例では、プレフィックス b が一致する 1 つのルールを使用して宛先アカウントにレプリケーション ポリシーを定義し、レプリケート対象の BLOB に最小作成時間を設定しています。 山かっこ内の値は、実際の値に置き換えてください。

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-028T00:00:00Z"
        }
      }
    ]
  }
}

ソース アカウントと宛先アカウントの完全なリソース ID を指定する

ポリシー定義ファイルを作成するときは、前のセクションの例に示されているように、sourceAccount と destinationAccount のエントリに完全な Azure Resource Manager リソース ID を指定します。 ストレージ アカウントのリソース ID を見つける方法については、「ストレージ アカウントのリソース ID を取得する」を参照してください。

完全なリソース ID は、次の形式になります。

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

ポリシー定義ファイルでは、以前はストレージ アカウントの完全なリソース ID ではなく、アカウント名のみが必要でした。 Azure Storage リソース プロバイダー REST API のバージョン 2021-02-01 での AllowCrossTenantReplication セキュリティ プロパティの導入により、レプリケーション ポリシーに参加しているストレージ アカウントのテナント間レプリケーションが禁止される場合に作成されるすべてのオブジェクト レプリケーション ポリシーに、完全なリソース ID を指定することが必要になりました。 Azure Storage は、ソース アカウントと宛先アカウントが同じテナント内に存在するかどうかを確認するために、完全なリソース ID を使用します。 テナント間レプリケーション ポリシーを禁止する方法の詳細については、「Microsoft Entra テナント間でのレプリケーションを防止する」を参照してください。

ストレージ アカウントのテナント間レプリケーションが許可されている場合は、アカウント名のみを指定することが依然としてサポートされていますが、ベストプラクティスとして、常に完全なリソース ID を指定することをお勧めします。 Azure Storage リソース プロバイダー REST API の以前のすべてのバージョンでは、オブジェクト レプリケーション ポリシーで完全なリソース ID のパスを使用することがサポートされています。

次の表では、ストレージ アカウントのテナント間レプリケーションが許可または禁止されたシナリオで、レプリケーション ポリシーを作成するときに完全なリソース ID を指定した場合とアカウント名を指定した場合の動作が対比的に説明されています。

ポリシー定義のストレージ アカウント識別子	テナント間レプリケーションが許可されている場合	テナント間レプリケーションが禁止されている場合
完全なリソース ID	同一テナントポリシーを作成できます。 テナント間ポリシーを作成できます。	同一テナントポリシーを作成できます。 テナント間ポリシーを作成することはできません。
アカウント名のみ	同一テナントポリシーを作成できます。 テナント間ポリシーを作成できます。	同一テナント ポリシーもテナント間ポリシーも作成できません。 ソース アカウントと宛先アカウントが同じテナント内にあることが Azure Storage で確認できないため、エラーが発生します。 このエラーは、ポリシー定義ファイルの sourceAccount および destinationAccount のエントリに完全なリソース ID を指定する必要があることを示しています。

ポリシーとルールの ID を指定する

次の表は、各シナリオでポリシー定義ファイル内の policyId と ruleId のエントリに使用される値をまとめたものです。

ポリシー定義ファイルを作成する対象のアカウント...	ポリシー ID をこの値に設定します	ルール ID をこの値に設定します
宛先アカウント	文字列の既定値。 Azure Storage によって自動的にポリシー ID 値が作成されます。	空の文字列。 Azure Storage によって自動的にルール ID 値が作成されます。
ソース アカウント	宛先アカウントのポリシー定義ファイルをダウンロードしたときに返されるポリシー ID の値。	宛先アカウントのポリシー定義ファイルをダウンロードしたときに返されるルール ID の値。

Microsoft Entra テナント間でのレプリケーションを防止する

Microsoft Entra テナントとは、ID およびアクセス管理の対象組織を表す Microsoft Entra ID の専用インスタンスです。 各 Azure サブスクリプションには、1 つのMicrosoft Entra テナントとの間に信頼関係があります。 ストレージ アカウントなどのサブスクリプション内のすべてのリソースは、同じ Microsoft Entra テナントに関連付けられています。 詳細については、「Microsoft Entra ID とは」を参照してください。

2023 年 12 月 15 日以降に作成される新しいアカウントでは、テナント間レプリケーションは既定で無効になります。 セキュリティ ポリシーで、オブジェクト レプリケーションを同じテナント内に存在するストレージ アカウントのみに制限する必要がある場合は、セキュリティ プロパティの AllowCrossTenantReplication プロパティ (プレビュー) を設定して、テナント間のレプリケーションを禁止することができます。 ストレージ アカウントのテナント間オブジェクト レプリケーションを禁止すると、ソースまたは宛先アカウントとしてそのストレージ アカウントで構成されているすべてのオブジェクト レプリケーション ポリシーに対して、Azure Storage は、ソースと宛先の両方のアカウントが同じ Microsoft Entra テナント内に存在することを要求します。 テナント間オブジェクト レプリケーションを禁止する方法の詳細については、「Microsoft Entra テナント間でのオブジェクト レプリケーションを防止する」を参照してください。

ストレージ アカウントのテナント間オブジェクト レプリケーションを禁止するには、AllowCrossTenantReplication プロパティを false に設定します。 現在、ストレージ アカウントがテナント間オブジェクト レプリケーション ポリシーに含まれていない場合、AllowCrossTenantReplication プロパティを false に設定すると、今後、テナント間オブジェクト レプリケーション ポリシーでこのストレージ アカウントをソースまたは宛先として使用するよう構成することができなくなります。

ストレージ アカウントが現在 1 つ以上のテナント間オブジェクト レプリケーション ポリシーに含まれている場合、AllowCrossTenantReplication プロパティを false に設定することはできません。 テナント間レプリケーションを禁止する前に、既存のテナント間ポリシーを削除する必要があります。

2023 年 12 月 15 日以降に作成されるストレージ アカウントでは、AllowCrossTenantReplication プロパティは既定で false に設定されます。 2023 年 12 月 15 日より前に作成されたストレージ アカウントでは、ストレージ アカウントの AllowCrossTenantReplication プロパティの値を null または true のすると、許可されているユーザーは、このアカウントをレプリケート元またはレプリケート先として、テナント間オブジェクト レプリケーション ポリシーを構成できます。 テナント間ポリシーを構成する方法の詳細については、「ブロック BLOB のオブジェクト レプリケーションを構成する」を参照してください。

Azure Policy を使用して、テナント間オブジェクト レプリケーションを防ぐように AllowCrossTenantReplication プロパティが設定されていることを確認するために一連のストレージ アカウントを監査することができます。 また、Azure Policy を使用して、一連のストレージ アカウントにガバナンスを適用することもできます。 たとえば、Deny 効果を持つポリシーを作成して、 AllowCrossTenantReplication プロパティが true に設定されている場合にユーザーがストレージ アカウントを作成することを防いだり、既存のストレージ アカウントを変更してプロパティ値を true に変更することを防いだりすることができます。

レプリケーションの状態

ソース アカウントの BLOB のレプリケーション状態を確認できます。 詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。

Note

レプリケーションの進行中に、レプリケートされたデータの割合を特定する方法はありません。

ソース アカウントの BLOB のレプリケーションの状態が失敗を示している場合は、次の考えられる原因を調査します。

• 宛先アカウントに対してオブジェクト レプリケーション ポリシーが構成されていることを確認します。
• 宛先アカウントがまだ存在することを確認します。
• 宛先コンテナーがまだ存在することを確認します。
• 移行先コンテナーが削除中でない、または削除されてすぐではないことを確認します。 コンテナーの削除には、最大で 30 秒ほどかかる場合があります。
• 宛先コンテナーがオブジェクト レプリケーション ポリシーにまだ参加していることを確認します。
• 書き込み操作の一部としてカスタマー指定のキーでソース BLOB が暗号化されている場合、オブジェクトのレプリケーションは失敗します。 カスタマー指定のキーの詳細については、「BLOB ストレージに対する要求で暗号化キーを指定する」を参照してください。
• ソースまたは宛先の BLOB がアーカイブ アクセス層に移動されているかどうかを確認します。 アーカイブされた BLOB を、オブジェクト レプリケーションを使用してレプリケートすることはできません。 アーカイブ アクセス層の詳細については、「BLOB データのアクセス層」を参照してください。
• 宛先コンテナーまたは BLOB が不変ポリシーによって保護されていないことを確認します。 コンテナーまたは BLOB には、その親から不変ポリシーを継承できることに注意してください。 不変ポリシーの詳細については、BLOB データの不変ストレージの概要に関するページを参照してください。

機能サポート

Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。 これらの機能のいずれかを有効にしている場合は、「Azure Storage アカウントでの Blob Storage 機能のサポート」 を参照して、この機能のサポートを評価してください。

課金

オブジェクト レプリケーションの構成にコストはかかりません。 これには、変更フィードの有効化、バージョン管理の有効化、レプリケーション ポリシーの追加のタスクが含まれます。 ただし、オブジェクト レプリケーションでは、ソース アカウントと宛先アカウントに対する読み取りと書き込みトランザクションにコストが発生します。また、ソース アカウントから宛先アカウントへのデータのレプリケーションを行うためのエグレス料金と、変更フィードを処理するための読み取り料金も発生します。

コストの内訳を次に示します。 各コスト コンポーネントの価格を確認するには、「Azure Blob Storage 価格」を参照してください。

ソース アカウントの BLOB を更新するためのコスト	コピー先アカウントのデータをレプリケートするためのコスト
書き込み操作のトランザクション コスト	変更フィード レコードを読み取るトランザクション コスト
BLOB と各 BLOB バージョン 1 のストレージ コスト	BLOB と BLOB のバージョン 2 を読み取るトランザクション コスト
変更フィード レコードを追加するためのコスト	BLOB と BLOB のバージョン 2 を書き込むトランザクション コスト
	BLOB と各 BLOB バージョン 1 のストレージ コスト
	ネットワーク エグレスのコスト3

¹ ソース アカウントで、BLOB またはバージョンの層を変更していない場合は、その BLOB、そのバージョンにわたるデータの一意のブロックに対して課金されます。 「BLOB のバージョン管理」の「価格と課金」を参照してください。 宛先アカウントでは、1 つのバージョンで、ブロックが一意であるかどうかに関係なく、バージョンのすべてのブロックに対して課金されます。

² これには、最後のレプリケーションの完了後に作成された BLOB バージョンのみが含まれます。

³ オブジェクト レプリケーションでは、(バージョンの一意のブロックだけでなく) バージョン全体が宛先にコピーされます。 この転送には、ネットワーク エグレスのコストがかかります。 「帯域幅の価格」を参照してください。

ヒント

予期しない請求が発生するリスクを軽減するには、オブジェクト数が少ないアカウントでオブジェクトのレプリケーションを有効にします。 次に、運用環境の設定で機能を有効にする前に、コストへの影響を測定します。

次のステップ

• オブジェクト レプリケーションの構成
• Microsoft Entra テナント間でのオブジェクト レプリケーションを防止する
• BLOB バージョン管理
• Azure Blob Storage の変更フィードのサポート