オブジェクトの複製
レプリケーションでは、 アカウント のソースバケットからターゲットバケットへ、オブジェクトを自動的に非同期でコピーするルールを定義することができます。 また、 アカウント で、バケツから別のバケツにオブジェクトをコピーすることもできます。
複製とは?
レプリケーションは、新しく作成されたオブジェクトとオブジェクトの更新を、ソースバケットからターゲットバケットにコピーします。
- 新しいオブジェクト、または既存のオブジェクトの新しいバージョン(レプリケーションルールがバケットに追加された後に作成されたもの)のみが、ターゲットバケットにコピーされます。 既存のオブジェクトを 自分自身にコピーすることで、 複製された新しいバージョンを作ることができる。
- ソース・オブジェクトのメタデータがレプリケートされたオブジェクトに適用される。
- 2つのバケット間で双方向レプリケーションを行うには、両方のバケットでルールが有効になっている必要があります。
- フィルタ(プレフィックスやタグで構成)を使って、レプリケーションルールをオブジェクトのサブセットだけに適用するようにスコープすることができます。 1つのポリシーに複数のルールを定義することができ、これらのルールは異なる宛先を指定することができる。 このようにして、同じバケット内の異なるオブジェクトを異なる宛先にレプリケートすることができる。
なぜレプリケーションを使うのか?
- 異なる地理的な場所にあるバケットにデータのコピーを保管する。
- 許可された場所にのみレプリカを保存するレプリケーション・ルールを定義することで、データ主権に関するコンプライアンス規制を満たすことができます。
- レプリケーションでは、最終更新時刻やバージョンIDなどのオブジェクト・メタデータが保持されるため、本番データとテストデータの同期を保つことができます。
- ターゲットバケットに異なるストレージクラスやライフサイクルルールを定義することで、ソースに依存しないレプリケートされたオブジェクトのストレージクラスやライフサイクルポリシーを管理します。 同様に、バケット内のレプリカを別のサービスインスタンスや、 IBM Cloud アカウント保存し、レプリカへのアクセスを独自に制御することもできます。
レプリケーションを始める
始めるにあたって、いくつかの前提条件を満たしておく必要がある:
- ソースバケットに
WriterまたはManagerプラットフォームロール、あるいは適切なレプリケーションアクションを持つカスタムロール(cloud-object-storage.bucket.put_replicationなど)を設定します。 - ターゲットバケットへのアクセス権は必要ありませんが、ソースバケットからターゲットバケットへの書き込みを許可する 新しい IAM ポリシーを 作成するための十分なプラットフォームロールが必要です。
- ターゲットバケットは、レガシーバケットファイアウォールを有効にしてはいけませんが、 コンテキストベースの制限を 使うことができます。
- SSE-Cを使用して 暗号化されたオブジェクトはレプリケートできないが、 Key Protect のようなマネージド暗号化(SSE-KMS )はレプリケーションと完全に互換性がある。
- アーカイブ状態のオブジェクトはレプリケートできない。
- ソースバケットとターゲットバケットが異なる IBM アカウントある場合は、必ずそれぞれのアカウントバケットを作成してください。
- ソースバケットとターゲットバケットの両方で バージョン管理を 有効にする。
バージョニングはレプリケーションの要件であるため、 Immutable Object Storage ポリシーで 設定されたバケット内のオブジェクトをレプリケートすることはできません。
IBM アカウント使用
同じ IBM アカウントバケット間でオブジェクトを複製するには、以下のようにします:
- 選択したソースバケットに移動したら、 Configuration タブをクリックします。
- Bucket replicationを探し、 Setup replication ボタンをクリックする。
- 「 レプリケーションのソース 」を選択し、「 次へ 」をクリックします。
- ドロップダウンメニューからインスタンスとバケットを選択します。 または、ラジオボタンを 「いいえ」に切り替え、対象のバケツの CRN を貼り付けます。
- チェック権限ボタンをクリックします。
ここで、ソースバケットにターゲットバケットの Writer パーミッションを付与する必要があります。 これにはいくつかの方法があるが、最も簡単なのは IBM Cloud Shell と IBM Cloud CLI を使うことである。
- IBM Cloud Shell を新しいウィンドウまたはタブで開きます。
- Object storageコンソールに表示されている IBM Cloud CLIコマンドをコピーし、新しいシェルに貼り付ける。
- バケツ設定ウィンドウまたはタブに戻り、 Check permissions ボタンをもう一度クリックします。
次にレプリケーション・ルールを作成する。
- ルールステータスのラジオボタンが[ Enabled] に設定されていることを確認します。
- ルールの名前と優先度、およびレプリケーションルールの対象となるオブジェクトを制限するプレフィックスまたはタグフィルタを指定します。
- 「完了 (Done)」 をクリックします。
IBM アカウント使い分け
異なる IBM アカウントバケット間でオブジェクトを複製するには、以下のようにします:
- 宛先の IBM アカウント IAM ポリシーを設定する。 IAMポリシーの作成については、 IAMポリシーとは何か、誰が割り当てることができるかを 参照してください。
- アカウント IDとサービスインスタンスIDをバケット設定ページでCRN形式で検索します。
- 宛先アカウント IBM Cloud UI を使用して、 Manage>Access**(IAM)** をクリックします。
- 左のパネルで「 認証 」をクリックする。
- [ 作成 ] をクリックして、新しい IAM ポリシーを作成します。
- サービス認可ページの設定を許可する。 これは、新しいIAMポリシーを作成した後に表示されるページです。
- 別のアカウント を選択し、ソースアカウント アカウント IDを入力します。
- サービスアクセスを提供する Cloud Object Storage.
- アクセス範囲]で[ 特定のリソース ]を選択します。
- Source Service Instance を選択し、ソースバケットのサービスインスタンスIDを入力します。
- ターゲット]で、ソースバケットへのアクセスに Cloud Object Storage を選択する。
- Target Scopeで Specific resources> Service** Instanceを選択する。
- ドロップダウンメニューから宛先アカウントサービスインスタンスIDを選択します。
- 必要に応じて、 オブジェクト・ライター またはライターの役割を選択してください。
レプリケーションを有効にするには、 オブジェクト・ライターの役割だけで十分です。
用語
ソースバケット :レプリケーションポリシーが設定されているバケット。 複製されたオブジェクトのソースである。
ターゲットバケット :ソースバケットレプリケーションポリシーでデスティネーションとして定義されているバケット。 複製されたオブジェクトのターゲットである。 デスティネーション」バケットとも呼ばれる。
レプリカ :ソースバケットへのリクエストによってターゲットバケットに作成される新しいオブジェクト。
何が複製されるのか?
CopyObject, PutObject, CompleteMultipartUpload によって作成された新しいオブジェクトは、ソースバケットからターゲットバケットにレプリケートされます。 複製されたオブジェクトは、ソースオブジェクトから以下のメタデータフィールドを継承する: Etag Last Modified Time、 Version ID、
user-attributes、 Tags。
削除マーカーは、レプリケーション・ポリシーで設定されていればレプリケートされる。
バージョンのタグの更新は、ソースバケットからターゲットバケットにレプリケートされます。
以下は複製されない:
- ライフサイクルイベントによって開始されるアクション
- アーカイブに直接書き込まれたオブジェクト
- アーカイブ層からリストアされたオブジェクト
- SSE-Cで暗号化されたオブジェクト
- オブジェクトACL
事業継続と災害復旧のためのレプリケーションの活用
レプリケーションは、障害発生時にサービスの継続性を提供するために使用できる:
- ソースバケットとターゲットバケットが異なる場所にあることを確認する。
- 両方のバケット間でオブジェクトの最新バージョンが同期されていることを確認する。 のようなツールが便利である。
Rclone(rclone checkコマンド)は、コマンドラインからシンクロニシティをチェックするのに便利である。 - 障害が発生した場合、アプリケーションのトラフィックをターゲットバケットにリダイレクトすることができる。
一貫性とデータの完全性
IBM Cloud Object Storage はすべてのデータIO操作に対して強力な一貫性を提供するが、バケット構成は最終的に一貫性を失う。 バケットで初めてレプリケーションルールを有効にした後、設定がシステム全体に伝わり、新しいオブジェクトがレプリケートされ始めるまで、しばらく時間がかかることがあります。
例外処理
レプリケーションの失敗は、バケットの設定ミス、サービスの停止、宛先バケットに対するユーザーの操作など、さまざまな理由(これらに限定されない)によって発生する可能性があります。
COSには、レプリケーションの障害に対処するための耐障害性が組み込まれています。 障害が発生した場合、COSは最大30日間、再試行を行うことができます。 再試行の頻度は、障害の性質によって異なる場合があります。 たとえば、まれに発生するI/Oエラーによる障害については数時間以内に再試行が行われる一方、ユーザーのバケット設定ミスによる障害については1日1回のみ再試行が行われる場合があります。 障害が30日以内に解消されない場合、システムによる自動再試行は行われなくなります。 すべての長期的な障害は、以下を通じて一覧表示できます ListBucketReplicationFailures を通じて一覧表示できます。
30日以上経過した「古い」失敗を再試行したい場合は、 PutBucketReplicationFailureReattempt を使用して再試行をトリガーできます。
故障の原因
ListBucketReplicationFailures APIのレスポンスでは、各失敗要素に対して SyncFailureCause が提供され、失敗の最後に判明した原因が記載されています。 以下の表に、考えられる原因をまとめました:
| 原因 | 説明 |
|---|---|
| 宛先バケットでバージョン管理が無効になっています | 宛先のバケットではバージョン管理が有効になっていません。 ユーザーは、レプリケーションの設定後にバージョン管理を無効にした可能性があります。 |
| ターゲットバケットではレプリケーション操作が許可されていません | COS サービスには、ユーザーに代わってターゲットバケットを変更する権限がありません。 IAM において、ソースバケットリソースとターゲットバケットリソースの間に、サービス間認証が依然として有効であるかどうかを確認してください。 |
| リモートバケットが見つかりません | 宛先バケットが見つかりませんでした。 ユーザーが宛先のバケットを削除した可能性があります。 宛先のバケットがまだ存在するかどうかを確認してください。 |
| ソース/リモートバケットが見つからないか、無効になっています | バケットが見つからないか、使用できない状態です。 バケットがまだ存在するかどうかを確認してください。 その場合は、 お客様 サポートまでご連絡ください。 |
| 目的のオブジェクトが見つかりません | メタデータの変更(タグやオブジェクトのロックなど)を再現しようとしましたが、対象のオブジェクトが存在しません。 変更がレプリケートされる前に、ユーザーが宛先バケット上のオブジェクトを削除してしまった可能性があります。 |
| ローカルオブジェクトが見つかりません | レプリケーションを実行しようとした際、ソースオブジェクトが見つかりませんでした。 ユーザーは、そのソースオブジェクトを作成または変更した直後に削除した可能性が高いです。 |
| 宛先バケットではオブジェクトロックが有効になっていません | オブジェクトに対してオブジェクトロックの設定を複製しようとしましたが、宛先のバケットではオブジェクトロックが有効になっていませんでした。 |
| 暗号化キーが有効になっていないか、削除されています | COSは Key Protect から暗号化キーを取得しようとしましたが(ソースバケットにはSSE-KP/SSE-HPCSが設定されています)、キーが削除されていました。 |
| KMSインスタンスのエンドポイント情報が欠落しています | 暗号化キーを読み取るために必要なキー管理サービスのエンドポイントを取得できませんでした。 それでもエラーが解消されない場合は、 お客様 サポートまでご連絡ください。 |
| KMSエンドポイント情報を照会するための権限が不足しています | ソースバケットリソースには、暗号化キーを読み取るために必要なKey Management Serviceエンドポイントを照会する権限がありません。 IAMのサービス間認証ポリシーを確認してください。 |
| 内部エラー | レプリケーションを妨げているさまざまな内部的な問題。 お客様サポートに連絡してください。 |
IAM アクション
レプリケーションに関連する新しいIAMアクションがある。
| IAM アクション | 役割 |
|---|---|
cloud-object-storage.bucket.get_replication |
管理者、ライター、リーダー |
cloud-object-storage.bucket.put_replication |
管理者、ライター |
cloud-object-storage.bucket.delete_replication |
管理者、ライター |
cloud-object-storage.bucket.get_replication_failures |
管理者、ライター、リーダー |
cloud-object-storage.bucket.put_replication_reattempt |
管理者、ライター |
Activity Tracker イベント
複製によって追加イベントが生成されます。
| イベント・アクション | 生成元 | 説明 |
|---|---|---|
| cloud-object-storage.bucket-replication.create | ソース・バケット | ユーザーが PutBucketReplication へのAPIリクエストを行うと |
| cloud-object-storage.bucket-replication.read | ソース・バケット | ユーザーが GetBucketReplication へのAPIリクエストを行うと |
| cloud-object-storage.bucket-replication.delete | ソース・バケット | ユーザーが DeleteBucketReplication へのAPIリクエストを行うと |
| cloud-object-storage.bucket-replication-failures.list | ソース・バケット | ユーザーが ListBucketReplicationFailures へのAPIリクエストを行うと |
| cloud-object-storage.bucket-replication-failures.update | ソース・バケット | ユーザーが PutReplicationFailureReattempt へのAPIリクエストを行うと |
| cloud-object-storage.object-replication.sync | ソース・バケット | COSがソースバケットからオブジェクトを複製するとき |
| cloud-object-storage.object-replication.create | ターゲット・バケット | COSがターゲットバケットに新しいレプリカバージョンを作成するとき |
| cloud-object-storage.object-replication.update | ターゲット・バケット | COSがターゲットバケット上の既存のレプリカに対してメタデータの更新を複製する場合 |
| cloud-object-storage.object-replication.delete | ターゲット・バケット | COSがターゲットバケット上の削除マーカーを複製する場合 |
cloud-object-storage.bucket-replication.create イベントの場合、以下のフィールドに追加情報が示されます。
| フィールド | 説明 |
|---|---|
requestData.replication.num_sync_remote_buckets |
バケット複製ルールで指定されたターゲット・バケットの数。 |
requestData.replication.failed_remote_sync |
複製チェックに不合格になったバケットの CRN。 |
複製がアクティブな場合、オブジェクトに対する操作により、以下の追加情報が生成されることがあります。
| フィールド | 説明 |
|---|---|
requestData.replication.replication_throttled |
スロットル・メカニズムが原因で、ソース上でオブジェクトの複製が遅延したかどうかを示します。 |
requestData.replication.destination_bucket_id |
ターゲット・バケットの CRN。 |
requestData.replication.sync_type |
- content は、オブジェクト_データと_メタデータがターゲットに書き込まれたことを示す。- tag は、オブジェクトタグが複製されたことを示す。- retention は、オブジェクトロックの保持設定が複製されたことを示す。- legal_hold は、オブジェクトロックの法的保持設定が複製されたことを示す。- delete は、削除マーカーがターゲットに書き込まれたことを示す。 |
responseData.replication.source_bucket_id |
ソース・バケットの CRN。 |
responseData.replication.result |
値は、 success、 failure (サーバー・エラーを示す)、 user (ユーザー・エラーを示す) のいずれかです。 |
responseData.replication.message |
HTTP レスポンスメッセージ( OK など)。 |
オブジェクトがソースに書き込まれてからターゲットに書き込まれるまで、オブジェクトをトレースすることができます。 オブジェクト書き込みに関連付けられた要求 ID を検索すると、以下の 3 つのイベントが表示されます。
- 元の
PUT。 - ソースからの同期要求。
- ターゲット上の
PUT要求。
これら 3 つのいずれかが欠落している場合は、障害を示します。
使用量とアカウンティング
すべてのレプリカはオブジェクト自体であり、他のデータと同様に 使用法を提供 します。 複製が成功すると、複製プロセスで消費された帯域幅は請求されませんが、 PUT、 GET、および HEAD の各要求が請求可能になります。
レプリケーションは、 IBM Cloud Monitoring で使用する追加のメトリクスを生成します:
ibm_cos_bucket_replication_sync_requests_issuedibm_cos_bucket_replication_sync_requests_received
インタラクション
バージョン管理
複製を有効にするには、バージョン管理が必須です。 ソース・バケットとターゲット・バケットの両方で バージョン管理を有効に し、ソース・バケットで複製を構成すると、以下の問題が発生する場合があります。
- ソース・バケットのバージョン管理を無効にしようとすると、 Object Storage からエラーが返されます。 ソース・バケットのバージョン管理を無効にするには、複製構成を削除する必要があります。
- ターゲット・バケットのバージョン管理を無効にすると、複製は失敗します。
オブジェクト・ロック
レプリケーションが有効になっているバケットでは、オブジェクトロックを有効にできる場合があります。 ソースオブジェクトがObject Lock(保存期間および/または法的保存)を設定して作成された場合、または既存のオブジェクトに対してObject Lockが更新された場合、その設定は宛先へレプリケートされます。
オブジェクトロックは、宛先のバケットでオブジェクトロックが有効になっている場合にのみレプリケートされます。 したがって、ソースバケットでオブジェクトロックが有効になっている場合は、宛先バケットでもオブジェクトロックを有効にすることをお勧めします。
以下の表は、ソースバケットと宛先バケットのオブジェクトロックの設定が異なる場合の動作の概要を示しています
| ソースオブジェクトのロック | 宛先オブジェクトのロック | 動作 |
|---|---|---|
| 有効 | 有効 | ソース側のすべてのオブジェクトロック状態が、宛先へレプリケートされます。 ソースオブジェクトがオブジェクトロックなしで作成された場合、レプリカには宛先バケットのデフォルトの保存期間が適用される可能性があります。 オブジェクト・ロック・レプリケーションは、 S3 のオブジェクト・ロックに関するすべての制限事項に従います。 たとえば、ユーザーが宛先で独自に変更を加えた場合、 _コンプライアンスモード_ではレプリカの保持期間を短縮することはできません。 |
| 無効 | 有効 | ソースオブジェクトにはオブジェクトロックを設定できないため、オブジェクトロックの状態がソースから宛先へ伝播することはありません。 宛先のバケットにデフォルトの保存期間が設定されている場合、その設定は新しく作成されるレプリカに適用されます。 |
| 有効 | 無効 | Object Lock を使用して作成されたソースオブジェクトは、レプリケーションに失敗します。 これらの失敗はCOSによって 再試行 され、宛先バケットでオブジェクトロックが有効になっている場合は、レプリケーションが可能になります。 また、既存のオブジェクトに対するオブジェクトロックの保持期間設定や法的保存措置の更新についても、宛先でオブジェクトロックが有効になるまではレプリケーションされません。 オブジェクトロックなしで作成されたソースオブジェクトも、レプリケーションの対象となります。 |
Key Protect 暗号化
ソース・オブジェクトは、ソース・バケットの ルート・キーを使用して暗号化 され、レプリカはターゲット・バケットのルート・キーを使用して暗号化されます。
ライフサイクル構成
ターゲット・バケットで ライフサイクル・ポリシー が有効になっている場合、ライフサイクル・アクションは、ターゲット・バケットでレプリカが使用可能になる時刻ではなく、ソースでのオブジェクトの元の作成時刻に基づきます。
Immutable Object Storage
バージョン管理が有効になっている バケットでは保存ポリシーを使用できません。バージョン管理は複製の要件であるため、Immutable Object Storage が有効になっているバケットとの間でオブジェクトを複製することはできません。
レガシー・バケット・ファイアウォール
IP アドレスに基づいてアクセスを制限するためにレガシー・ファイアウォールを使用するバケット は、複製を使用できません。オブジェクトを複製するバックグラウンド・サービスには固定 IP アドレスがなく、ファイアウォールを渡すことができないためです。
ネットワーク情報に基づいてアクセスを制御する場合は、代わりに コンテキストベースの制限を使用する ことをお勧めします。
Cloud Functions および Code Engine
複製を構成しても、現時点では Cloud Functions のトリガー イベントも Code Engine イベントも提供されませんが、オブジェクトの書き込みと削除により、ソースとターゲットの両方のバケットに対して Object:Write 通知と Object:Delete 通知が作成されます。 これらのイベントには、イベントが同期をトリガーしたか、同期によってトリガーされたかを示す
notifications.replication_type フィールドの注釈が付けられます。
既存のオブジェクトの複製
複製ルールは、ルールが構成されてバケットに適用された 後 に書き込まれたオブジェクトに対してのみ動作できます。 複製する必要がある既存のオブジェクトがバケット内にある場合は、オブジェクトの存在を複製プロセスに認識させる必要があります。 これは、 PUT copy 操作を使用してオブジェクトをそれ自体にコピーすることによって簡単に行うことができます。
このプロセスにより、作成タイム・スタンプを含む一部のオブジェクト・メタデータがリセットされます。 これは、ライフサイクル・ポリシー、および作成タイム・スタンプまたは変更タイム・スタンプを使用するその他のサービス (コンテンツ配信ネットワークなど) に影響します。 オブジェクト・メタデータのリセットによって生じる可能性のある中断が適切に処理されていることを確認してください。
このプロセスには以下が含まれます
- 複製ルールの対象となるバケット内のすべてのオブジェクトのリストを作成する
- そのリストを反復処理し、ソースが要求のターゲットと同一である各オブジェクトに対して
PUT copy操作を実行します。
この例では、 PUT copy 要求によって作成されたオブジェクトの新規バージョンのみを複製します。 オブジェクトのすべてのバージョンを複製するには、個々のバージョンもコピーする必要があります。
以下の例は Pythonで作成されていますが、アルゴリズムは任意のプログラミング言語またはコンテキストで適用できます。
import os
import sys
import ibm_boto3
from ibm_botocore.config import Config
# Create client connection
cos = ibm_boto3.client("s3",
ibm_api_key_id=os.environ.get('IBMCLOUD_API_KEY'),
ibm_service_instance_id=os.environ['SERVICE_INSTANCE_ID'],
config=Config(signature_version="oauth"),
endpoint_url=os.environ['US_GEO']
)
# Define the bucket with existing objects for replication
bucket = os.environ['BUCKET']
def copy_in_place(BUCKET_NAME):
print("Priming existing objects in " + bucket + " for replication...")
paginator = cos.get_paginator('list_objects_v2')
pages = paginator.paginate(Bucket=bucket)
for page in pages:
for obj in page['Contents']:
key = obj['Key']
print(" * Copying " + key + " in place...")
try:
headers = cos.head_object(
Bucket=bucket,
Key=key
)
md = headers["Metadata"]
cos.copy_object(
CopySource={
'Bucket': bucket,
'Key': key
},
Bucket=bucket,
Key=key,
TaggingDirective='COPY',
MetadataDirective='REPLACE',
Metadata=md
)
print(" Success!")
except Exception as e:
print(" Unable to copy object: {0}".format(e))
print("Existing objects in " + bucket + " are now subject to replication rules.")
copy_in_place(bucket)
REST API の例
以下の例では、使いやすさのために cURL を使用しています。 環境変数は、 $BUCKET、 $TOKEN、および $REGION などのユーザー固有のエレメントを表すために使用されます。 $REGION にはネットワーク・タイプの指定も含まれるため、プライベート・ネットワークを使用して us-south のバケットに要求を送信するには、この変数を
private.us-south に設定する必要があることに注意してください。
バケットでの複製の有効化
複製構成は、要求の本体で XML として提供されます。 新規要求により、バケットに存在する既存の複製規則が上書きされます。
複製構成には少なくとも 1 つの規則を含める必要があり、最大 1,000 個を含めることができます。 各ルールは、ソース・バケット内のオブジェクトをフィルタリングすることによって、複製するオブジェクトのサブセットを識別します。 複製するオブジェクトの追加サブセットを選択するには、サブセットごとにルールを追加します。
複製規則を適用するソース・バケット内のオブジェクトのサブセットを指定するには、 Rule エレメントの子として Filter エレメントを追加します。 オブジェクト・キー接頭部、1 つ以上のオブジェクト・タグ、またはその両方に基づいてオブジェクトをフィルターに掛けることができます。 構成に Filter エレメントを追加する場合は、 DeleteMarkerReplication、
Status、および Priority エレメントも追加する必要があります。
オプション・ヘッダー
| ヘッダー | タイプ | 説明 |
|---|---|---|
Content-MD5 |
ストリング | base64 は、ペイロードの128ビット MD5 ハッシュ値をエンコードしたもので、これは転送中にペイロードが改ざんされていないことを確認するための整合性チェックとして使用されます。 |
x-amz-checksum-crc32 |
ストリング | このヘッダーは、 Base64 エンコードされた、オブジェクトの32ビット CRC32 チェックサムである。 |
x-amz-checksum-crc32c |
ストリング | このヘッダーは、 Base64 エンコードされた、オブジェクトの32ビット CRC32C チェックサムである。 |
x-amz-checksum-crc64nvme |
ストリング | このヘッダーは、 Base64 エンコードされた、オブジェクトの64ビット CRC64NVME チェックサムである。 CRC64NVME チェックサムは常にフルオブジェクトチェックサムである。 |
x-amz-checksum-sha1 |
ストリング | このヘッダーは、 Base64 エンコードされた、オブジェクトの160ビット SHA1 ダイジェストである。 |
x-amz-checksum-sha256 |
ストリング | このヘッダーは、 Base64 エンコードされた、オブジェクトの256ビット SHA256 ダイジェストである。 |
ペイロードの完全性チェックとして、 Content-MD5 ヘッダーまたは checksum ヘッダー( x-amz-checksum-crc32、 x-amz-checksum-crc32c、 x-amz-checksum-crc64nvme、 x-amz-checksum-sha1、または x-amz-checksum-sha256 を含む)が必要である。 要求の本体には、以下のスキーマの XML ブロックが含まれている必要があります。
| エレメント | タイプ | 子 | 上位 | 制約 |
|---|---|---|---|---|
ReplicationConfiguration |
コンテナー | Rule |
なし | 限度 1。 |
Rule |
コンテナー | ID, Status, Filter, DeleteMarkerReplication, Destination, Priority |
ReplicationConfiguration |
限度 1000。 |
ID |
ストリング | なし | Rule |
(a-z,A-Z0-9 )および以下の記号で構成されていなければなりません: ! _ . * ' ( ) - |
Destination |
コンテナー | Bucket |
Rule |
限度 1。 |
Bucket |
ストリング | なし | Destination |
ターゲット・バケットの CRN。 |
Priority |
整数 | なし | Rule |
優先順位は各ルールに関連付けられます。 アップロードされるオブジェクトに複数のルールが適用される場合があります。 このような場合、オブジェクト・ストレージは、そのオブジェクトを複製するときに、より高い優先順位を持つ適用可能なルールを適用します。 したがって、オブジェクトに一致する複製ポリシー内の規則の数に関係なく、どのオブジェクトにも適用できる複製規則は 1 つだけです。 数値が大きいほど、優先順位が高いことに注意してください。 |
Status |
ストリング | なし | Rule |
このルールが有効かどうかを指定します。 有効な値は Enabled または Disabledです。 |
DeleteMarkerReplication |
コンテナー | Status |
Rule |
限度 1。 |
Status |
ストリング | なし | DeleteMarkerReplication |
オブジェクト・ストレージが削除マーカーを複製するかどうかを指定します。 有効な値は Enabled または Disabledです。 |
Filter |
ストリング | Prefix, Tag, AND |
Rule |
複製規則が適用されるオブジェクトのサブセットを識別するフィルター。 Filter は、厳密に 1 つの Prefix、 Tag、または And 子エレメントを指定する必要があります。 |
Prefix |
ストリング | なし | Filter |
規則が適用されるオブジェクトのサブセットを識別するオブジェクト・キー名の接頭部。 |
Tag |
ストリング | なし | Filter |
タグのキーと値を指定するためのコンテナー。 この規則は、タグ・セット内にタグがあるオブジェクトにのみ適用されます。 |
And |
ストリング | なし | Filter |
ルール・フィルターを指定するためのコンテナー。 フィルターは、規則が適用されるオブジェクトのサブセットを決定します。 このエレメントは、複数のフィルターを指定する場合にのみ必要です。 |
Key |
ストリング | なし | Tag |
タグ・キー。 |
Value |
ストリング | なし | Tag |
タグの値。 |
この例では、すべての新規オブジェクトを複製しますが、削除マーカーは複製しません。
curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
-H 'Authorization: bearer $TOKEN' \
-H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
-H 'Content-Type: text/plain; charset=utf-8' \
-d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Rule>
<ID>SimpleReplication</ID>
<Priority>1</Priority>
<Status>Enabled</Status>
<DeleteMarkerReplication>
<Status>Disabled</Status>
</DeleteMarkerReplication>
<Filter/>
<Destination>
<Bucket>$DESTINATION_CRN</Bucket>
</Destination>
</Rule>
</ReplicationConfiguration>'
この例では、 project_a/ で始まるキー (名前) を持つすべてのオブジェクトを $DESTINATION_CRN_A で識別されるバケットに複製し、 project_b/ で始まるキー (名前) を持つすべてのオブジェクトを $DESTINATION_CRN_B で識別されるバケットに複製し、キー Client と値 ACME を持つすべてのオブジェクトを $DESTINATION_CRN_C で識別される 3 番目のバケットに複製します。すべてのケースで削除マーカーを複製します。
以下の 4 つのオブジェクトがソース・バケットに追加されるとします。 以下で説明するように、ターゲット・バケットに複製されます。
project_a/foo.mp4project_a/bar.mp4project_b/baz.pdfproject_b/acme.pdfこの 4 番目のオブジェクトには、キーClientと値ACMEを持つオブジェクト・タグもあります。
以下の規則により、オブジェクト 1 および 2 は $DESTINATION_CRN_A に複製されます。 オブジェクト 3 は $DESTINATION_CRN_B に複製されます。 オブジェクト 4 は $DESTINATION_CRN_C にのみ複製されます。これは、ID AcmeCorp のルールの優先順位の値が ID ProjectB のルールの優先順位の値より高く、両方のルールの要件を満たしている場合にのみ、前者のルールに従うためです。
curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
-H 'Authorization: bearer $TOKEN' \
-H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
-H 'Content-Type: text/plain; charset=utf-8' \
-d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Rule>
<ID>ProjectA</ID>
<Priority>10</Priority>
<Status>Enabled</Status>
<DeleteMarkerReplication>
<Status>Enabled</Status>
</DeleteMarkerReplication>
<Filter>
<Prefix>project_a/</prefix>
</Filter>
<Destination>
<Bucket>$DESTINATION_CRN_A</Bucket>
</Destination>
</Rule>
<Rule>
<ID>ProjectB</ID>
<Priority>5</Priority>
<Status>Enabled</Status>
<DeleteMarkerReplication>
<Status>Enabled</Status>
</DeleteMarkerReplication>
<Filter>
<Prefix>project_b/</prefix>
</Filter>
<Destination>
<Bucket>$DESTINATION_CRN_B</Bucket>
</Destination>
</Rule>
<Rule>
<ID>AcmeCorp</ID>
<Priority>20</Priority>
<Status>Enabled</Status>
<DeleteMarkerReplication>
<Status>Enabled</Status>
</DeleteMarkerReplication>
<Filter>
<Tag>
<Key>Client</Key>
<Value>ACME</Value>
</Tag>
</Filter>
<Destination>
<Bucket>$DESTINATION_CRN_C</Bucket>
</Destination>
</Rule>
</ReplicationConfiguration>'
要求が成功すると、 200 応答が返されます。
バケットの複製構成の表示
curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
-H 'Authorization: bearer $TOKEN'
これにより、適切なスキーマを持つ XML 応答本体が返されます。
<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Rule>
<ID>SimpleReplication</ID>
<Status>ENABLED</Status>
<DeleteMarkerReplication>
<Status>DISABLED</Status>
</DeleteMarkerReplication>
<Destination>
<Bucket>crn:v1:bluemix:public:cloud-object-storage:global:a/9978e07eXXXXXXXX66c89c428028654:ef1c725e-XXXX-4967-bcc1-734c03a2b846:bucket:replication-destination</Bucket>
</Destination>
<Priority>1</Priority>
<Filter/>
</Rule>
</ReplicationConfiguration>
バケットのレプリケーション設定を削除する
curl -X "DELETE" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
-H 'Authorization: bearer $TOKEN'
要求が成功すると、 204 応答が返されます。
バケットごとのレプリケーションの失敗を一覧表示する
以下の例を用いたリクエスト curl
curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-failures" \
-H 'Authorization: bearer $TOKEN'
オプションの照会パラメーター
| 名前 | タイプ | 説明 |
|---|---|---|
| エンコーディング種別 | ストリング | オブジェクト名にXMLでサポートされていないUnicode文字が使用されている場合、このパラメータを「url」に設定することで、レスポンスを適切にエンコードすることができます。 |
| max-keys | ストリング | レスポンスに表示される失敗件数を制限します。 デフォルトおよび最大は 1,000 です。 |
| 最初の同期試行日時 | ストリング | リストの表示を開始するタイムスタンプを、新しい順で指定します。 この時刻は、レプリケーションが最初にトリガーされた時刻に対応します(
|
| 継続トークン | ストリング | リストの表示を開始する失敗を、新しい順に指定します。 これは、前回の一覧取得リクエストで返されたエントリの後に、さらにエントリが存在する場合に、ページネーションを行うために使用されます。 |
応答の例
<ListReplicationFailureResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Name>example</Name>
<FirstSyncAttemptedBefore>2025-12-15T00:00:00.000Z</FirstSyncAttemptedBefore>
<MaxKeys>10</MaxKeys>
<IsTruncated>false</IsTruncated>
<EncodingType>false</EncodingType>
<KeyCount>2</KeyCount>
<Contents>
<Key>test-obj+*1765434016787</Key>
<VersionId>00000000-0000-0000-0000-019b0c114413</VersionId>
<SyncType>Content</SyncType>
<FirstSyncAttempted>2025-12-11T06:20:16.787Z</FirstSyncAttempted>
<LastSyncAttempted>2025-12-11T06:20:16.787Z</LastSyncAttempted>
<SyncFailureCause>Versioning disabled on destination bucket</SyncFailureCause>
</Contents>
<Contents>
<Key>test-obj+*1765434016786</Key>
<VersionId>00000000-0000-0000-0000-019b0c114412</VersionId>
<SyncType>Content</SyncType>
<FirstSyncAttempted>2025-12-11T06:20:16.786Z</FirstSyncAttempted>
<LastSyncAttempted>2025-12-11T06:20:16.786Z</LastSyncAttempted>
<SyncFailureCause>Replication operation not authorized on target bucket</SyncFailureCause>
</Contents>
</ListReplicationFailureResult>
レスポンス要素
| 名前 | タイプ | 説明 |
|---|---|---|
ListReplicationFailureResult |
コンテナー | ルートレベルのタグ |
Name |
ストリング | 一覧表示されているバケットの名前。 |
FirstSyncAttemptedBefore |
ストリング | ISO-8601 リクエストされた日付・タイムスタンプ ?first-sync-attempted-before |
MaxKeys |
数値 | この出品に対してリクエストされたキーの最大数。 |
IsTruncated |
ブール値 | 現在のリストが切り詰められているかどうか(つまり、このリストで返された最後の要素の後に、さらに失敗があるかどうか)。 true の場合、 NextContinuationToken は常に指定されます。 |
EncodingType |
ストリング | この出品で指定されたエンコード形式。 |
KeyCount |
数値 | このリストで返された不良要素の数。 |
ContinuationToken |
ストリング | この掲載に対して指定された継続トークン。 |
NextContinuationToken |
ストリング | 現在のリストが切り詰められていた場合に、ページングに使用する次の継続トークン。 |
バケット内の古いレプリケーション障害の再試行をスケジュールする
これにより、すべてのレプリケーションの失敗について再試行がスケジュールされます。これには、30日以上経過しており、システムによる自動再試行の対象外となっている「古い」失敗も含まれます。 長期にわたるレプリケーションの失敗は、24時間サイクルで処理されます。 このリクエストを発行すると、GMTの翌日の午前0時から始まるサイクルにおいて、期限切れの失敗に対する再試行がスケジュールされます。 たとえば、 2026-01-01T01:00:00Z に対してリクエストが送信された場合、これらの障害が処理される最も早い時刻は
2026-01-02T00:00:00Z となります。 リクエストが成功した場合、このタイムスタンプはレスポンスヘッダー x-ibm-replication-reattempt-scheduled-time にも含まれます。 GMTで同じ日に到着した複数のリクエスト(つまり、同じスケジュール時間が割り当てられるもの)は、冪等です。
タイムアウトした失敗については、ベストエフォート方式で1回再試行されます。これらは実行されますが、実行のタイミングについては保証されません。
以下の例を用いたリクエスト curl
curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-reattempt" \
-H 'Authorization: bearer $TOKEN'
応答の例
HTTP/1.1 204 No Content
Connection: close
...
x-ibm-replication-reattempt-scheduled-time: Fri, 12 Dec 2025 00:00:00 GMT
SDK の例
以下の例では、 IBM COS SDK for Python および Node.jsを使用していますが、オブジェクト・バージョン管理の実装は、カスタム・エンドポイントの設定を可能にする S3-compatible ライブラリーまたはツールと完全に互換性がなければなりません。 サード・パーティー・ツールを使用するには、 AWS V4 署名を計算するための HMAC 資格情報が必要です。 HMAC 資格情報について詳しくは、 資料を参照してください。
Python
IBM COS SDK for Python を使用したバージョン管理は、 低レベル・クライアント 構文を使用して行うことができます。
クライアントの使用:
#!/usr/bin/env python3
import ibm_boto3
from ibm_botocore.config import Config
from ibm_botocore.exceptions import ClientError
# Define constants
API_KEY = os.environ.get('IBMCLOUD_API_KEY')
SERVICE_INSTANCE = os.environ.get('SERVICE_INSTANCE_ID')
ENDPOINT = os.environ.get('ENDPOINT')
BUCKET = "my-replication-bucket" # The bucket that will enable replication.
# Create resource client with configuration info pulled from environment variables.
cosClient = ibm_boto3.client("s3",
ibm_api_key_id=API_KEY,
ibm_service_instance_id=SERVICE_INSTANCE,
config=Config(signature_version="oauth"),
endpoint_url=ENDPOINT
)
response = cosClient.put_bucket_versioning(
Bucket=BUCKET,
ReplicationConfiguration={
'Rules': [
{
'ID': 'string',
'Priority': 123,
'Filter': {
'Prefix': 'string',
'Tag': {
'Key': 'string',
'Value': 'string'
},
'And': {
'Prefix': 'string',
'Tags': [
{
'Key': 'string',
'Value': 'string'
},
]
}
},
'Status': 'Enabled'|'Disabled',
'Destination': {
'Bucket': 'string',
},
'DeleteMarkerReplication': {
'Status': 'Enabled'|'Disabled'
}
},
]
}
)
同じクライアントを使用するオブジェクトのバージョンをリストします。
resp = cosClient.list_object_versions(Prefix='some-prefix', Bucket=BUCKET)
Python API は非常に柔軟であり、同じタスクを実行するためのさまざまな方法があることに注意してください。
Node.js
IBM COS SDK for Node.js を使用したバージョン管理の有効化:
const IBM = require('ibm-cos-sdk');
var config = {
endpoint: '<endpoint>',
apiKeyId: '<api-key>',
serviceInstanceId: '<resource-instance-id>',
};
var cos = new IBM.S3(config);
var params = {
Bucket: 'STRING_VALUE', /* required */
ReplicationConfiguration: { /* required */
Role: 'STRING_VALUE', /* required */
Rules: [ /* required */
{
Destination: { /* required */
Bucket: 'STRING_VALUE', /* required */
},
Status: Enabled | Disabled, /* required */
Filter: {
And: {
Prefix: 'STRING_VALUE',
Tags: [
{
Key: 'STRING_VALUE', /* required */
Value: 'STRING_VALUE' /* required */
},
/* more items */
]
},
Prefix: 'STRING_VALUE',
Tag: {
Key: 'STRING_VALUE', /* required */
Value: 'STRING_VALUE' /* required */
}
},
ID: 'STRING_VALUE',
Prefix: 'STRING_VALUE',
Priority: 'NUMBER_VALUE',
}
}
]
},
ContentMD5: 'STRING_VALUE',
};
cos.putBucketReplication(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});