Sippy

Sippy はデータ移行サービスです。大量データの移動に通常かかる不要なクラウドエグレス料金を払わずに、リクエストされたデータだけをほかのクラウドプロバイダーから R2 へコピーできます。

移行専用のエグレス料金は、アプリケーションの流れの中ですでに支払っているエグレス料金が発生するリクエストを活用し、同時にオブジェクトを R2 へコピーすることで削減します。

仕組み

R2 バケットで有効にすると、Sippy は Workers、S3 API、パブリックバケット全体で次の移行戦略を実装します。

オブジェクトがリクエストされると、R2 バケットにあればそこから提供します。
オブジェクトが R2 にない場合、ソースストレージバケットから同時に返し、R2 へコピーします。
put や delete を含むほかの操作は、通常どおり動きます。

Sippy が便利なとき

移行戦略の一部として Sippy を使うのが良い選択になるのは、次の場合です。

データの移行を始めたいが、一度にすべてのデータを移すための前払いエグレス料金を避けたい。
データ移行に時間をかけずに、よくアクセスされるオブジェクトを R2 から提供してエグレス料金をなくす実験をしたい。
頻繁に変わるデータがあり、ダウンタイムを避けながら移行したい。Sippy でリクエストを処理しつつ、Super Slurper で残りのデータを移行できます。

既存のクラウドプロバイダーから R2 へ一度にすべてのデータを移行したい場合は、Super Slurper を推奨します。

Sippy を始める

始める前に、次が必要です。

既存の R2 バケット。ない場合はバケットを作成するを参照してください。
ソースオブジェクトストレージバケットの API 資格情報。
（Wrangler のみ）読み取りと書き込み権限を持つ Cloudflare R2 Access Key ID と Secret Access Key。詳細は認証を参照してください。

Dashboard で Sippy を有効にする

Cloudflare dashboard で R2 object storage ページを開きます。
Overview を開く ↗
オブジェクトの移行先にしたいバケットを選びます。
Settings タブに切り替え、On Demand Migration カードまでスクロールします。
Enable を選び、オブジェクトの移行元バケットの詳細を入力します。入力する資格情報には、このバケットからの読み取り権限が必要です。Cloudflare は、このバケットからの読み取りだけを許可するよう資格情報の範囲を限定することも推奨します。
Enable を選びます。

Wrangler で Sippy を有効にする

Wrangler をセットアップする

まず npm ↗ をインストールします。次に Developer Platform CLI の Wrangler をインストールします。

R2 バケットで Sippy を有効にする

wrangler login コマンドで Wrangler にログインします。次に r2 bucket sippy enable コマンドを実行します。

npx wrangler r2 bucket sippy enable "<BUCKET_NAME>"

対応するオブジェクトストレージプロバイダーの選択とセットアップが案内されます。

API で Sippy を有効にする

必要なパラメーターと Sippy を有効にする例は、API ドキュメントを参照してください。Cloudflare API の始め方は API 呼び出しを行うを参照してください。

移行メトリクスを表示する

有効にすると、Sippy は進行中の移行の進捗を把握するためのメトリクスを公開します。

Metric	Description
Requests served by Sippy	一定期間における、R2 が提供したリクエスト全体の割合です。割合が高いほど、ソースバケットへのリクエストが少なくて済むことを示します。
Data migrated by Sippy	一定期間にソースバケットから R2 へコピーされたデータ量です。バイト単位で報告されます。

現在と過去のメトリクスを表示する手順は次のとおりです。

Cloudflare dashboard で R2 object storage ページを開きます。
Overview を開く ↗
バケットを選びます。
Metrics タブを選びます。

任意でクエリする時間窓を選べます。デフォルトは過去 24 時間です。

R2 バケットで Sippy を無効にする

Dashboard

Cloudflare dashboard で R2 object storage ページを開きます。
Overview を開く ↗
Sippy を無効にしたいバケットを選びます。
Settings タブに切り替え、On Demand Migration カードまでスクロールします。
Disable を押します。

Wrangler

Sippy を無効にするには、r2 bucket sippy disable コマンドを実行します。

npx wrangler r2 bucket sippy disable "<BUCKET_NAME>"

API

Sippy を無効にするために必要なパラメーターと例は、API ドキュメントを参照してください。

対応クラウドストレージプロバイダー

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

Amazon S3
Google Cloud Storage (GCS)
Azure Blob Storage
S3 互換ストレージプロバイダー

R2 API の相互作用

Sippy が有効なとき、Workers、S3 API、パブリックバケット全体で、R2 バケット上の特定アクションの動作が変わります。

Action	New behavior
GetObject	GetObject の呼び出しは、まず R2 バケットからオブジェクトの取得を試みます。オブジェクトがない場合、ソースストレージバケットから提供し、同時にリクエストされた R2 バケットへアップロードします。追加の考慮事項: ソースバケット内のオブジェクトの変更は、最初のコピー後に R2 へ反映されません。オブジェクトが R2 に保存されると、再取得して更新されることはありません。 HTTP レスポンスで `x-amz-meta-` で始まるユーザー定義メタデータだけが移行されます。残りのメタデータは省略されます。より大きいオブジェクト（199 MiB 超）では、オブジェクトを R2 へ完全にコピーするために複数の GET リクエストが必要になることがあります。まだ R2 へ完全にコピーされていないオブジェクトに対する同時 GET リクエストが複数ある場合、Sippy はそれらのリクエストに応えるために、ソースストレージバケットからオブジェクトを複数回取得することがあります。
HeadObject	GetObject と似た動作ですが、オブジェクトメタデータだけを取得します。リクエストされた R2 バケットへオブジェクトをコピーしません。
PutObject	動作の変更はありません。PutObject の呼び出しは、リクエストされた R2 バケットにオブジェクトを追加します。
DeleteObject	動作の変更はありません。DeleteObject の呼び出しは、リクエストされた R2 バケット内のオブジェクトを削除します。追加の考慮事項: R2 内のオブジェクト削除がソースストレージバケットでも行われない場合、後続の GetObject リクエストはソースバケットからオブジェクトを取得し、R2 へコピーします。

上記にないアクションは動作が変わりません。詳細は Workers API リファレンスまたは S3 API 互換性を参照してください。

ストレージプロバイダーの資格情報を作成する

Amazon S3

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

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

AWS IAM アカウントにログインします。

次の形式のポリシーを作成し、<BUCKET_NAME> をアクセスを付与したいバケットに置き換えます。

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

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

Sippy を有効にするときに、Access Key ID と Secret Access Key の両方を使えます。

Google Cloud Storage

Google Cloud Storage (GCS) からオブジェクトをコピーするには、Sippy にバケットへのアクセス権限が必要です。Cloudflare は、Google Cloud の事前定義ロール Storage Object Viewer を使うことを推奨します。

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

Google Cloud console にログインします。
IAM & Admin > Service Accounts を開きます。
事前定義の Storage Object Viewer ロールでサービスアカウントを作成します。
作成したサービスアカウントの Keys タブを開きます。
Add Key > Create a new key を選び、JSON キーファイルをダウンロードします。

Wrangler または API で Sippy を有効にするときに、この JSON キーファイルを使えます。

Azure Blob Storage

Azure Blob Storage からオブジェクトをコピーするには、Sippy に Azure Storage アカウント名、コピー元のコンテナー、アカウントキーまたは shared access signature (SAS) トークンのいずれかが必要です。2 つの資格情報種類のうち、ちょうど 1 つを提供します。Sippy にはコンテナーに対する読み取りと一覧の権限が必要です。

アカウントキーを使う手順は次のとおりです。

Azure portal にログインし、ストレージアカウントを開きます。
Security + networking で Access keys を選びます。
ストレージアカウント名と、一覧されたキーの 1 つをコピーします。

代わりに SAS トークンを使う場合、Cloudflare は移行するコンテナーだけに範囲を限定することを推奨します。

Azure portal にログインし、ストレージアカウントを開きます。
Data storage で Containers を選び、移行元のコンテナーを開きます。
Shared access tokens を選び、Read と List 権限を付与してから Generate SAS token and URL を選びます。
生成された SAS トークンをコピーします。

Sippy を有効にするときに、アカウント名、コンテナー名、アカウントキーまたは SAS トークンのいずれかを使えます。

S3 互換ストレージ

S3 互換ストレージプロバイダーからオブジェクトをコピーするには、Sippy にバケットの S3 API エンドポイント URL と、そこから読み取れる Access Key ID と Secret Access Key が必要です。Cloudflare は、移行するバケットからの読み取りだけを許可するよう、これらの資格情報の範囲を限定することを推奨します。

バケットの S3 API エンドポイントと読み取り専用アクセス資格情報の作成方法は、ストレージプロバイダーのドキュメントを参照してください。

Sippy を有効にするときに、バケット URL、Access Key ID、Secret Access Key を使えます。

注意点

ETags

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

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

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