Amazon Web Services ブログ
Amazon S3 で削除マーカーレプリケーションを管理する
お客様は、同じ AWS リージョン内または別の AWS リージョン内にデータのコピーを作成して、コンプライアンス、レイテンシーの短縮、またはアカウント間でのデータの共有を実現するために、Amazon S3 レプリケーションを使用します。データが絶えず変化している環境では、多くのお客様が、削除されるオブジェクトに対するレプリケーションのニーズが異なります。このブログでは、V1 と V2 の 2 つの設定のレプリケーション動作、および特定のコンプライアンスとガバナンスのニーズを満たす設定を選択する方法について説明します。
S3 レプリケーションの概要
S3 レプリケーションは、あらゆる Amazon S3 ストレージクラスに、低コストで伸縮自在なフルマネージド型のエンタープライズ対応レプリケーション機能を提供し、誤った削除から保護するとともに、異なるリージョンにまたがってデータを保護します。Amazon S3 レプリケーションを使用すると、同じまたは異なる AWS リージョン内のバケット間でデータを自動的かつ非同期にレプリケートできます。
Same-Region Replication (SRR) および Cross-Region Replication (CRR) を使用して、さまざまなユースケースに対応できます。たとえば、CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のレプリケーションを設定し、データ主権の要件を満たすために使用できます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットにレプリケートします。オプションで、レプリケートされるオブジェクトを制御するために、プレフィックスとタグを使用してオブジェクトのサブセットをレプリケートできます。
ソフト削除操作と削除マーカー
S3 レプリケーションでは、ソースバケットと宛先バケットの両方でバージョニングを有効にする必要があります。バージョニングされているバケットについて、バージョン ID を指定せずにオブジェクトを削除する場合、この削除操作は、一般に「論理削除」と呼ばれます。 論理削除の結果、「削除マーカー」と呼ばれる新しい null オブジェクトバージョンが生成されます。
オブジェクトは、ライフサイクルの有効期限ポリシーのために削除される場合もあることに留意してください。現在のオブジェクトバージョンが期限切れになると、削除マーカーが追加されます。対照的に、最新でないオブジェクトのバージョンが期限切れになると、永久に削除されます。
ここで興味深い質問が頭に浮かぶことでしょう。すなわち、オブジェクトが論理削除されたときのレプリケーション動作はどうなるのか、ということです。 この場合、2 つの結果があり得ます。
- 削除マーカーがレプリケートされます (V1 設定)。ソースバケットと宛先バケットの両方で削除されたオブジェクトに対する後続の GET リクエストは、オブジェクトを返しません。
- 削除マーカーはレプリケートされません (V2 設定)。削除されたオブジェクトに対する後続の GET リクエストは、宛先バケット内でのみ、オブジェクトを返します。
コンソールから S3 レプリケーションを有効にすると、デフォルトで V2 設定が有効になります。しかし、レプリケートされたオブジェクトをソースバケットから削除するたびにユースケースで削除する必要がある場合は、V1 設定が必要です。V1 レプリケーション設定で対処されるいくつかの一般的なシナリオは次のとおりです。
- GDPR などの標準を遵守する必要がある。V1 レプリケーション設定をソースおよび宛先バケットの適切なライフサイクル設定と一緒に使用して、削除されたオブジェクトが永久に期限切れになるようにすることができます。
- ソースバケットが頻繁に更新され、アプリケーションワークフローではソースバケットと宛先バケットが同期している必要がある。
V1 または V2 の S3 レプリケーションを設定する方法:
Amazon S3 コンソール、AWS コマンドラインインターフェイス (AWS CLI)、および AWS SDK を使用して S3 レプリケーションを設定できます。この例では、AWS CLI を使用して、同じアカウントのバケットのレプリケーションを設定しています。CLI の指示に従って、レプリケーションをセットアップします。ソースバケットと宛先バケットを作成し、それらのバージョニングを有効にし、オブジェクトをレプリケートするための Amazon S3 アクセス許可を付与する IAM ロールを作成し、レプリケーション設定をソースバケットに追加します。
V1 レプリケーション設定の場合 (削除マーカーをレプリケートするため):
{
"Role": " IAM-role-ARN ",
"Rules": [
{
"ID": "Replication V1 Rule",
"Prefix": "",
"Status": "Enabled",
"Destination": {
"Bucket": "arn:aws:s3:::<destination-bucket>"
}
}
]
}
レプリケーション設定で「プレフィックス」フィールドを使用することは、これが V1 設定であることを示します。V1 レプリケーション設定は、デフォルトで削除マーカーをレプリケートします。「プレフィックス」フィールドは V2 ではサポートされていません。
このレプリケーション設定をテストするには、設定を s3_replication_rule_v1.json として保存して適用します。
$ aws s3api put-bucket-replication --bucket <sourcebucket> --replication-configuration file://s3_replication_rule_v1.json
V2 レプリケーション設定の場合 (これは削除マーカーをレプリケートしません):
{
"Role": "IAM-role-ARN",
"Rules": [
{
"ID": "Replication V2 Rule",
"Priority": 1,
"Filter": {},
"Status": "Enabled",
"Destination": {
"Bucket": "arn:aws:s3:::<destination-bucket>"
},
"DeleteMarkerReplication": {
"Status": "Disabled"
}
}
]
}
レプリケーション設定で「フィルター」フィールドを使用することは、これが V2 設定であることを示します。V1 にはこのフィールドはありません。
注意: V2 設定では「DeleteMarkerReplication」フィールドを省略できません。また、「無効」以外に設定することはできません。
このレプリケーション設定をテストするには、設定を s3_replication_rule_v2.json として保存して適用します。
$ aws s3api put-bucket-replication --bucket <sourcebucket> --replication-configuration file://s3_replication_rule_v2.json
次のコマンドを使用して、使用しているレプリケーション設定 (ある場合) を確認できます。
aws s3api get-bucket-replication --bucket <sourcebucket>
有効なレプリケーション設定を使用して、別のアカウントが所有するバケットにレプリケートできます。詳細な手順については、このレプリケーションドキュメントをご覧ください。
ここで示される例は、ソースバケット内のすべてのオブジェクトをレプリケートする必要がある最も一般的なユースケースに対応しています。指定されたプレフィックスまたはタグを持つオブジェクトのみを選択的にレプリケートするために使用できる詳細な設定については、ドキュメントを参照してください。タグベースのフィルタリングや Replication Time Control (RTC) などの特定のレプリケーション機能は、V2 設定でのみ使用できることに留意してください。
まとめ
Amazon S3 は、レプリケーション設定における削除の動作を制御する機能を提供します。この柔軟性により、お客様は災害復旧および規制の要件を満たすことができます。ここでは、V1 と V2 という 2 つの一般的なレプリケーション設定を取り上げました。V1 設定では宛先バケットのレプリケートされたオブジェクトが論理削除されますが、V2 設定では削除されません。このブログ投稿では、レプリケーションを有効にするときにユースケースにどの設定を選択するかを決定する際の指針となる基準を概説しました。
質問や提案がある場合は、コメント欄にフィードバックを残してください。災害復旧とコンプライアンスについてさらに支援が必要な場合は、AWS アカウントチームまたは信頼できる APN パートナーにお問い合わせください。
詳細については、AWS レプリケーション設定ページをご覧ください。