クロスアカウントのクロスリージョンレプリケーション - Object Storage Service

クロスリージョンレプリケーション (CRR) は、ソースバケットのオブジェクトを、別の Alibaba Cloud アカウントの、別リージョンにある送信先バケットへ、自動的かつ非同期的にコピーします。クロスアカウントの CRR は、ディザスタリカバリ、分離されたバックアップの作成、またはデータレジデンシーのコンプライアンス要件を満たすために使用できます。

クロスアカウントレプリケーションの設定には、ソースアカウントと送信先アカウントの両方での操作が必要で、次の 3 つの手順で構成されます。

ソースアカウント：データレプリケーション用の RAM ロールを作成し、ソースバケットからデータを読み取るために必要な最小権限を付与します。
送信先アカウント：送信先バケットのバケットポリシーを変更し、ソースアカウントの RAM ロールに書き込み権限を付与します。
ソースアカウント：ソースアカウントに戻り、ソースバケットと送信先バケットを関連付け、レプリケーションタスクを開始するためのクロスリージョンレプリケーション (CRR) ルールを作成します。

手順1：RAM ロールの作成と権限付与

RAM ロールを作成します。[Create Role] ページに移動します。[信頼プリンシパルタイプ] を [クラウドサービス] に、[信頼プリンシパル名] を [OSS] に設定します。
ソースバケットにアクセスするための権限を RAM ロールに付与するには、レプリケーションのためにソースバケットからデータを読み取る際に必要な権限のみを含むカスタムポリシーを作成します。
1. [Create Policy] ページで [JSON] タブをクリックします。次のポリシーをポリシーエディターに貼り付け、src-bucket をソースバケット名に置き換えます。
```
{
   "Version": "1",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "oss:ReplicateList",
            "oss:ReplicateGet"
         ],
         "Resource": [
            "acs:oss:*:*:src-bucket",
            "acs:oss:*:*:src-bucket/*"
         ]
      }
   ]
}
```
2. ポリシーを作成したら、[Roles] ページに移動し、作成したロールを見つけて [Grant Permission] をクリックします。表示されたパネルでは、プリンシパルが自動入力されます。[Policy] で、前の手順で作成したカスタムポリシーを選択し、[Confirm Grant] をクリックします。
(オプション) Key Management Service (KMS) にアクセスする権限を RAM ロールに付与します。送信先バケットでレプリケートされたデータの暗号化に KMS を使用する場合は、RAM ロールに KMS へのアクセス権限を付与します。
[ロール] ページで、作成したロールを見つけて [権限付与] をクリックします。表示されるパネルで、プリンシパルは自動的に入力されます。[ポリシー] には AliyunKMSCryptoUserAccess を選択し、[許可の確認] をクリックします。
ロール ARN を記録します。[ロール] ページで、作成した RAM ロールを見つけ、その[基本情報]ページに移動し、ロール ARN をコピーします。ARN は acs:ram::{source-account-uid}:role/{role-name} の形式です。

手順2：RAM ロールの承認とリソースの準備

送信先バケットにデータを書き込むために RAM ロールを承認するには、送信先アカウントで送信先バケットのバケットポリシーを変更し、ソースアカウントの RAM ロールに書き込みアクセスを付与します。
1. 送信先アカウントにログインし、[Buckets] ページに移動します。送信先バケットをクリックします。
2. 左側メニューで、[アクセスコントロール] > [バケットポリシー] を選択します。
3. [Add in GUI] タブをクリックし、[Receive Objects to Replicate] をクリックします。
4. 表示されたパネルで、次のパラメーターを設定します。
  - Obtain UID and RAM Role From：[Source RAM role ARN for replication] を選択します。
  - Source RAM Role ARN for Replication：手順1で記録した、ソースアカウントの RAM ロールの ARN を入力します。
  - Purpose：[Cross-account replication] を選択します。
5. [Generate Policy] をクリックし、[Save] をクリックします。
(オプション) 送信先アカウントで KMS キーを準備します。KMS で暗号化されたオブジェクトをレプリケートするには、事前に送信先アカウントで KMS キーを作成する必要があります。
1. KMS コンソールにログインし、[Instance Management] ページに移動します。送信先バケットと同じリージョンで、KMS インスタンスを購入して有効化します。KMS インスタンスを購入する際は、[Access Management Quantity] が 2 以上であることを確認します。その他のパラメーターはデフォルト設定のままにします。
  説明
  KMS で暗号化されたオブジェクトのクロスアカウントレプリケーションは KMS に依存します。この機能をサポートするリージョンは、KMS が利用可能なリージョンに限定されます。KMS をサポートするリージョンの詳細については、「Supported regions and endpoints for software key management」をご参照ください。
2. KMS インスタンスで、ソフトウェアキーを作成します。キータイプはデフォルトキー以外である必要があります (ソフトウェアキーを推奨します)。キーを作成したら、レプリケーションルールの作成時に使用するため、[Basic Information] セクションからキー ARN を記録します。
3. 作成したキーにキーポリシーを設定します。ポリシーを設定する際は、[その他のアカウントユーザー] に、ソースアカウントが作成した RAM ロールの ARN、つまり前の手順で取得したロール ARN を指定します。詳細については、「Set a key policy」をご参照ください。
  デフォルトでは、この操作はロールに、復号 (kms:Decrypt) やデータキーの生成 (kms:GenerateDataKey) などの必要な権限を付与します。これにより、ロールはこのキーを使用して宛先バケットに暗号化されたオブジェクトを作成できます。コンソールウィザードには通常、必要な権限が含まれていますが、API を使用してカスタムキーポリシーを設定する場合は、これらの権限が正しく追加されていることを手動で確認する必要があります。

手順3：クロスリージョンレプリケーションルールの作成

必要な権限を付与した後、ソースアカウントのコンソールに戻ってレプリケーションルールを作成し、タスクを開始します。

ソースアカウントにログインし、[Buckets] ページに移動します。ソースバケットをクリックします。
左側メニューで、[Data Management] > [Cross-Region Replication] を選択します。
[Cross-Region Replication] をクリックします。表示されたダイアログボックスで、次のパラメーターを設定します。
1. Configure Destination Bucket：[Specify a bucket that belongs to another Alibaba Cloud account] を選択し、送信先バケットが存在するリージョンを選択して、その名前を入力します。
  - Objects to Replicate：[すべてのファイルの同期] または [プレフィックスを指定する] を選択します。ソースバケット内で指定したプレフィックスを持つオブジェクトは、送信先バケットにレプリケートされます。デフォルトでは最大 10 個のプレフィックスを追加できます。この上限を 100 に増やすには、にお問い合わせください。
  - [オブジェクトのタグ付け]：
    説明
    このパラメーターを設定するには、次の条件を満たす必要があります。
    オブジェクトタグを設定済みであること。
    [Replicate delete markers] と [Replicate permanent deletions of specific versions] のチェックボックスが選択されていないこと。
    [ルールの設定] チェックボックスを選択して、特定のタグを持つオブジェクトを送信先バケットにレプリケートします。最大 10 個のタグ (キーと値のペア) を追加できます。タグを追加した後、次のいずれかのフィルターポリシーを選択できます。
    - [すべてのタグを含む]：OSS は、オブジェクトのすべてのタグがフィルタールールで指定したタグと一致する場合にのみ、そのオブジェクトをレプリケートします。
    - [いずれかのタグを含む]：OSS は、オブジェクトのタグのうち少なくとも1つがフィルタールールで指定したタグと一致する場合に、そのオブジェクトをレプリケートします。
  - Replicate KMS Encrypted Objects：ソースオブジェクトが KMS で暗号化されており、送信先でも暗号化を維持する場合は、[Replicate] を選択し、手順2で準備した送信先アカウントの KMS キーの ARN を指定します。[Do not replicate] を選択した場合、KMS で暗号化されたオブジェクトは送信先バケットにレプリケートされません。
    説明
    ソースオブジェクトと宛先バケットの暗号化ステータスは、それぞれHeadObject 操作と GetBucketEncryption 操作を呼び出すことで照会できます。
  - RAM Role：ドロップダウンリストから、手順1でソースアカウントに作成した RAM ロールを選択します。
2. Configure Replication Policy：
  - Replicate Delete Operations (ソースバケットでバージョニングが無効な場合に表示されます)：ソースバケット内のオブジェクト削除を送信先バケットに同期するかどうかを選択します。
    - Yes：作成、変更、削除の操作を同期して、送信先バケットをソースバケットと一致させます。このオプションは、同じデータセットを共有してアクセスする必要があるマルチユーザー環境やアプリケーション環境に適しています。ただし、このポリシーでは、ソースバケット内のオブジェクトが手動またはライフサイクルルールによって自動的に削除されると、送信先バケット内の対応するオブジェクトも削除され、復元できません。
    - No：新規作成および変更されたオブジェクトを同期します。ソースバケットでの削除は送信先バケットに影響しません。ディザスタリカバリのシナリオでは、ソースバケットでの誤削除がバックアップバケットにレプリケートされないようにするため、[No] を選択します。これにより、データセキュリティが向上します。
  - Replicate Historical Data：ルールが有効になる前にソースバケットに存在していたデータをレプリケートするかどうかを選択します。この操作により、送信先バケット内の同名のオブジェクトは上書きされます。データ損失を防ぐため、ソースバケットと送信先バケットの両方でバージョニングを有効にすることを推奨します。
  - Replicate delete markers (ソースバケットでバージョニングが有効な場合に表示されます)：ソースバケットの削除マーカーを送信先バケットにレプリケートするかどうかを選択します。
    - Replicate：バージョンIDを指定せずにソースバケットからオブジェクトを削除すると、OSS はソースバケットの削除マーカーを送信先バケットに同期します。このオプションは、ソースバケットと送信先バケット間のデータ整合性を確保するために、同じデータセットの共有とアクセスが必要なシナリオに適しています。
      重要
      このポリシーを設定すると、ソースバケット内のオブジェクトが手動またはライフサイクルルールによって自動的に削除された場合、削除マーカーも送信先バケットに同期され、送信先バケット内のデータにアクセスできなくなります。
    - Do not replicate (ディザスタリカバリのシナリオでは推奨)：ソースバケットで作成された削除マーカーは送信先バケットにレプリケートされません。これにより、ソースバケットでの誤削除やライフサイクルルールによる自動削除によって送信先バケットでデータ損失が発生することを効果的に防止できます。
  - Replicate permanent deletions of specific versions (ソースバケットでバージョニングが有効な場合に表示されます)：ソースバケットから特定バージョンのオブジェクトを完全に削除した操作を送信先バケットにレプリケートするかどうかを選択します。
    - Replicate：現在バージョンと非現在バージョンを含む、ソースオブジェクトの特定バージョンを完全に削除すると、OSS は送信先バケットの対応するバージョンも完全に削除します。このオプションは、ソースバケットと送信先バケット間で完全なデータ整合性を確保する必要があるシナリオに適しています。
      重要
      このポリシーを設定すると、ソースバケットで完全に削除されたオブジェクトバージョンは送信先バケットで復元できません。このオプションは慎重に使用してください。
    - Do not replicate (ディザスタリカバリのシナリオでは推奨)：ソースオブジェクトの特定バージョンを完全に削除しても、送信先バケットの対応するバージョンの削除は同期されません。これにより、ソースバケットでの完全削除操作が送信先バケットのデータセキュリティに影響することを防止できます。
3. (オプション) レプリケーションアクセラレーションの設定：
  - 転送アクセラレーション：レプリケーションタスクに中国本土内外のリージョンが含まれる場合、この機能を有効にしてデータ転送速度を向上できます。この機能を使用すると、追加の転送アクセラレーション料金が発生します。
  - レプリケーションタイムコントロール (RTC)：有効にすると、RTC はほとんどの増分データのレプリケーションレイテンシーを 10 分以内に維持します。この機能は特定のリージョン間でのみサポートされ、追加のクロスリージョンレプリケーション RTC 料金が発生します。詳細については、「RTC overview」をご参照ください。

説明

CRR ルールは作成後に変更または削除できません。[OK] をクリックする前に、すべての設定を慎重に確認してください。レプリケーションを終了するには、レプリケーションタスクを無効化してデータ同期を停止できます。

すべての設定が正しいことを確認したら、[OK] をクリックし、次に [Confirm Enable] をクリックします。
ルールの作成後、数分以内にレプリケーションタスクが開始されます。データレプリケーションは非同期プロセスです。所要時間は、オブジェクトサイズ、オブジェクト数、クロスリージョンのネットワークレイテンシーに依存し、数分から数時間まで幅があります。レプリケーションの進捗 (既存データと増分データの同期ステータスなど) は、ソースバケットの [Cross-Region Replication] タブで確認できます。

よくある質問

ストレージクラスまたはアクセス時刻の変更がレプリケートされないのはなぜですか？

データレプリケーションは、オブジェクトの作成、削除、または変更など、オブジェクトコンテンツの変更によってのみトリガーされます。ライフサイクルルールまたは CopyObject オペレーションによるストレージクラスの変更、および最終アクセス時刻 (LastAccessTime) の更新は、新しいオブジェクトコンテンツの書き込みを伴いません。したがって、これらのアクションは新しいレプリケーションタスクをトリガーせず、OSS は宛先バケットのオブジェクトレプリカを更新しません。

解決策：

ストレージクラスの同期：送信先バケットに同一のライフサイクルルールを設定し、同じストレージクラス移行が行われるようにします。
LastAccessTime の更新: 宛先オブジェクトの最終アクセス時刻を更新するには、宛先バケット内のオブジェクトに直接アクセスして (たとえば、 GetObject リクエストを実行するなど)、その LastAccessTime の更新をトリガーします。

マルチパートアップロードでアップロードされたオブジェクトはレプリケートされますか？

マルチパートアップロードを使用してオブジェクトをアップロードすると、OSS は各パートを送信先バケットにレプリケートします。CompleteMultipartUpload 操作によってソースバケット内でパートがマージされた後、OSS は完全なオブジェクトを1つのエンティティとして送信先バケットにレプリケートします。

RAM ロールの簡易承認

はい。迅速な承認を行うには、作成した RAM ロールに Alibaba Cloud が提供する AliyunOSSFullAccess システムポリシーを直接付与できます。ただし、このポリシーは、アカウント配下のすべての OSS リソースに対するすべての権限を付与します。スコープが広範であるため、このポリシーを本番環境で使用することは推奨されません。

JSON ポリシーによる権限付与

はい。送信先バケットのバケットポリシーページで、より柔軟に設定するために [Add Rule by Syntax] を選択できます。JSON ポリシーを使用する場合は、次の点に注意してください。

新しいポリシーは既存のバケットポリシーを上書きします。新しいポリシーに必要な承認ルールがすべて含まれていることを確認してください。
ポリシーの Principal フィールドには、ソースアカウントの RAM ロールの ARN を含める必要があります。
ロール名に大文字が含まれている場合、ポリシーでは小文字に変換する必要があります。たとえば、ロール AliyunOssDrsRole は、ポリシーに aliyunossdrsrole と記述する必要があります。
ソースアカウントの UID、送信先バケット名、送信先アカウントの UID を正確に入力する必要があります。

次のコードはポリシー例です。

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": [
                "arn:sts::{source-account-uid}:assumed-role/{role-name}/*"
            ],
            "Resource":[
                "acs:oss:*:{destination-account-uid}:{destination-bucket-name}",
                "acs:oss:*:{destination-account-uid}:{destination-bucket-name}/*"
            ]
        }
    ]
}

クロスアカウントレプリケーションルール作成失敗のトラブルシューティング

デフォルトのサービスロールまたはカスタム RAM ロールを使用してクロスアカウントレプリケーションルールを作成できない場合、その失敗は通常、ロール自体が原因ではありません。ほとんどの場合、宛先バケットの [バケットポリシー] の Principal フィールドが、ソースアカウントの RAM ロールの STS が引き受けたロールの ARN に設定されていません。その結果、宛先アカウントは実際にはそのロールを承認していません。 Principal が arn:sts::{source-account-uid}:assumed-role/{role-name}/* フォーマットを使用しているかどうかを確認してください。

よくある誤り：

ソースアカウント UID の誤り：UID は送信先アカウントではなく、ソースアカウントのものである必要があります。
ロール名の不一致：ロール名は、手順1で作成した RAM ロールと完全に一致する必要があります。ロール名に大文字が含まれている場合は、小文字に変換してください。
不正な ARN タイプ: Principal には、arn:sts:: で始まる STS の assumed-role ARN が必要です。acs:ram: または arn:ram: で始まる RAM ロール ARN は使用できません。

JSON ポリシーを手動で記述する際のエラーを回避するには、送信先バケットの [バケットポリシー] ページで [Add in GUI] タブをクリックし、[Receive Objects to Replicate] をクリックして、コンソールにポリシーを生成させてください。