コンテンツにスキップ

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アクセスキーIDとシークレットアクセスキー（読み取りおよび書き込み権限付き）。詳細については、認証を参照してください。

ダッシュボードからSippyを有効にする

  1. Cloudflareダッシュボードから、サイドバーのR2を選択します。
  2. オブジェクトを移行したいバケットを選択します。
  3. 設定タブに切り替え、インクリメンタル移行カードまでスクロールします。
  4. 有効にするを選択し、オブジェクトを移行したいAWS / GCSバケットの詳細を入力します。入力する認証情報は、このバケットから読み取る権限を持っている必要があります。Cloudflareは、認証情報をこのバケットからの読み取りのみを許可するようにスコープを設定することを推奨しています。
  5. 有効にするを選択します。

WranglerからSippyを有効にする

Wranglerのセットアップ

まず、npm ↗をインストールします。その後、Wrangler、開発者プラットフォームCLIをインストールします。

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

wrangler loginコマンドを使用してWranglerにログインします。その後、r2 bucket sippy enableコマンドを実行します：

Terminal window
npx wrangler r2 bucket sippy enable <BUCKET_NAME>

これにより、サポートされているオブジェクトストレージプロバイダーの選択を促され、セットアップを進めることができます。

API経由でSippyを有効にする

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

移行メトリクスの表示

Sippyが有効になると、進行中の移行の進捗を理解するのに役立つメトリクスが公開されます。

メトリック

説明

Sippyによって提供されたリクエスト

一定期間内にR2によって提供された全体のリクエストの割合。
割合が高いほど、ソースバケットへのリクエストが少なくて済むことを示します。

Sippyによって移行されたデータ

一定期間内にソースバケットからR2にコピーされたデータの量。バイト単位で報告されます。

現在および過去のメトリクスを表示するには：

  1. Cloudflareダッシュボード ↗にログインし、アカウントを選択します。
  2. R2タブ ↗に移動し、バケットを選択します。
  3. メトリクスタブを選択します。

オプションで、クエリする時間ウィンドウを選択できます。デフォルトでは、過去24時間です。

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

ダッシュボード

  1. Cloudflareダッシュボードから、サイドバーのR2を選択します。
  2. Sippyを無効にしたいバケットを選択します。
  3. 設定タブに切り替え、インクリメンタル移行カードまでスクロールします。
  4. 無効にするを押します。

Wrangler

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

Terminal window
npx wrangler r2 bucket sippy disable <BUCKET_NAME>

API

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

サポートされているクラウドストレージプロバイダー

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

  • Amazon S3
  • Google Cloud Storage (GCS)

R2 APIとの相互作用

Sippyが有効になると、Workers、S3 APIおよびパブリックバケットにおけるR2バケットの特定のアクションの動作が変更されます。

アクション

新しい動作

GetObject

GetObjectへの呼び出しは、最初にR2バケットからオブジェクトを取得しようとします。オブジェクトが存在しない場合、オブジェクトはソースストレージバケットから提供され、同時に要求されたR2バケットにアップロードされます。



追加の考慮事項：

  • ソースバケット内のオブジェクトの変更は、初回コピー後にR2に反映されません。オブジェクトがR2に保存されると、それは再取得されて更新されることはありません。

  • HTTPレスポンス内の x-amz-meta-で始まるユーザー定義メタデータのみが移行されます。残りのメタデータは省略されます。

  • 大きなオブジェクトの場合、オブジェクトを完全にR2にコピーするために複数のGETリクエストが必要になる場合があります。

HeadObject

GetObjectと似た動作をしますが、オブジェクトメタデータのみを取得します。要求されたR2バケットにオブジェクトをコピーすることはありません。

PutObject

動作に変更はありません。PutObjectへの呼び出しは、要求されたR2バケットにオブジェクトを追加します。

DeleteObject

動作に変更はありません。DeleteObjectへの呼び出しは、要求されたR2バケット内のオブジェクトを削除します。



追加の考慮事項：

  • R2内のオブジェクトがソースストレージバケットでも削除されていない場合、以降のGetObjectリクエストはソースバケットからオブジェクトを取得し、R2にコピーされます。

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

ストレージプロバイダーのための認証情報を作成する

Amazon S3

Amazon S3からオブジェクトをコピーするには、Sippyはバケットへのアクセス権限を必要とします。正しい権限を持つ任意のAWSアイデンティティおよびアクセス管理（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>/*"]
    }
  ]
}
  1. 新しいユーザーを作成し、作成したポリシーをそのユーザーにアタッチします。

これで、Sippyを有効にする際にアクセスキーIDとシークレットアクセスキーの両方を使用できます。

Google Cloud Storage

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

正しい権限を持つ認証情報を作成するには：

  1. Google Cloudコンソールにログインします。
  2. IAM & Admin > サービスアカウントに移動します。
  3. 事前定義されたStorage Object Viewerロールを持つサービスアカウントを作成します。
  4. 作成したサービスアカウントのキータブに移動します。
  5. キーの追加 > 新しいキーを作成を選択し、JSONキーをダウンロードします。

これで、WranglerまたはAPIを介してSippyを有効にする際にこのJSONキーを使用できます。

注意事項

ETags

While R2’s ETag generation is compatible with S3’s during the regular course of operations, ETags are not guaranteed to be equal when an object is migrated using Sippy. Sippy makes autonomous decisions about the operations it uses when migrating objects to optimize for performance and network usage. It may choose to migrate an object in multiple parts, which affects ETag calculation.

For example, a 320 MiB object originally uploaded to S3 using a single PutObject operation might be migrated to R2 via multipart operations. In this case, its ETag on R2 will not be the same as its ETag on S3. Similarly, an object originally uploaded to S3 using multipart operations might also have a different ETag on R2 if the part sizes Sippy chooses for its migration differ from the part sizes this object was originally uploaded with.

Relying on matching ETags before and after the migration is therefore discouraged.

Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings