Super Slurper

Super Slurper を使うと、ほかのクラウドプロバイダーから選んだ R2 バケットへ、オブジェクトをすばやく簡単にコピーできます。

移行ジョブについて:

• ソースバケットのカスタムオブジェクトメタデータを保持し、R2 上の移行先オブジェクトへコピーします。
• ソースバケットからオブジェクトを削除しません。
• 安全で非公開なオブジェクト転送のため、HTTPS 接続上の TLS 暗号化を使います。

移行するクラウドストレージバケットが、主に 1 TB 未満のオブジェクトで構成されている場合、戦略の一部として Super Slurper を使うのは良い選択です。1 TB を超えるオブジェクトはスキップされ、別途コピーする必要があります。

上記の条件を満たさない移行では、rclone などのツールの利用を推奨します。

1. Cloudflare ダッシュボードで、R2 data migration ページを開きます。

   Data migration を開く ↗

2. Migrate files を選択します。

3. データの移行元となるソースクラウドストレージプロバイダーを選択します。

4. ソースバケット名と関連する認証情報を入力し、Next を選択します。

5. R2 バケット名と関連する認証情報を入力し、Next を選択します。

6. 移行の詳細を確認したら、Migrate files を選択します。

Data Migration ページで移行を選択すると、いつでも移行ジョブの状態を確認できます。

この設定は、オブジェクトのコピー元となるソースバケット内のプレフィックスを指定します。

この設定は、ソースストレージバケットからコピーするオブジェクトのパスが、宛先 R2 バケットの既存オブジェクトと一致した場合の動作を決めます。次の 2 つのオプションがあります。

• Overwrite（デフォルト）
• Skip

Cloudflare は現在、次のクラウドオブジェクトストレージプロバイダーから R2 へのデータコピーに対応しています。

• Amazon S3
• Cloudflare R2
• Google Cloud Storage (GCS)
• すべての S3 互換ストレージプロバイダー

次の S3 互換ストレージプロバイダーは、Super Slurper で動作することをテストおよび検証済みです。

• Backblaze B2
• DigitalOcean Spaces
• Scaleway Object Storage
• Wasabi Cloud Object Storage

Super Slurper は、すべての S3 互換ストレージプロバイダーからの転送に対応する想定ですが、上記は明示的にテスト済みです。

Amazon S3 からオブジェクトをコピーするには、Super Slurper に S3 バケットへのアクセス権限が必要です。正しい権限を持つ任意の AWS Identity and Access Management (IAM) ユーザー認証情報を使えますが、Cloudflare は権限を狭くしたユーザーの作成を推奨します。

正しい権限の認証情報を作成する手順は次のとおりです。

1. AWS IAM アカウントにログインします。
2. 次の形式のポリシーを作成し、<BUCKET_NAME> をアクセスを付与するバケットに置き換えます。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": ["s3:Get*", "s3:List*"],
			"Resource": ["arn:aws:s3:::<BUCKET_NAME>", "arn:aws:s3:::<BUCKET_NAME>/*"]
		}
	]
}

3. 新しいユーザーを作成し、作成したポリシーをそのユーザーにアタッチします。

これで、ソースバケットを定義するときに Access Key ID と Secret Access Key の両方を使えます。

Google Cloud Storage (GCS) からオブジェクトをコピーするには、Super Slurper に GCS バケットへのアクセス権限が必要です。Google Cloud の定義済み Storage Admin ロールを使えますが、Cloudflare は権限を狭くしたカスタムロールの作成を推奨します。

必要な権限を持つカスタムロールを作成する手順は次のとおりです。

1. Google Cloud コンソールにログインします。
2. IAM & Admin > Roles を開きます。
3. Storage Object Viewer ロールを見つけ、Create role from this role を選択します。
4. 新しいロールに名前を付けます。
5. Add permissions を選択し、storage.buckets.get 権限を追加します。
6. Create を選択します。

カスタムロールで認証情報を作成する手順は次のとおりです。

1. Google Cloud コンソールにログインします。
2. IAM & Admin > Service Accounts を開きます。
3. カスタムロールを付けたサービスアカウントを作成します。
4. 作成したサービスアカウントの Keys タブを開きます。
5. Add Key > Create a new key を選択し、JSON キーファイルをダウンロードします。

これで、Super Slurper を有効にするときに、この JSON キーファイルを使えます。

通常の運用では R2 の ETag 生成は S3 と互換ですが、Super Slurper でオブジェクトを移行した場合、ETag が等しいことは保証されません。 Super Slurper は、パフォーマンスとネットワーク使用量を最適化するため、移行時に使う操作を自律的に決めます。オブジェクトを複数パートで移行することがあり、その場合は ETag の計算 に影響します。

たとえば、S3 へ単一の PutObject 操作でアップロードした 320 MiB のオブジェクトを、マルチパート操作で R2 へ移行することがあります。この場合、R2 上の ETag は S3 上の ETag と一致しません。 同様に、もともとマルチパート操作で S3 へアップロードしたオブジェクトでも、Super Slurper が移行で選ぶパートサイズが元のアップロード時と異なると、R2 上の ETag が変わることがあります。

そのため、移行前後の ETag の一致に依存することはおすすめしません。

AWS S3 の アーカイブストレージクラス ↗ で保存されたオブジェクトはスキップされ、別途コピーする必要があります。具体的には次のとおりです。

• S3 Glacier 階層（Glacier Instant Retrieval を除く）で保存されたファイルはスキップされ、移行ログに記録されます。
• S3 Intelligent Tiering で保存され、Deep Archive 階層に置かれたファイルはスキップされ、移行ログに記録されます。