# R2 の Sippy が Azure Blob Storage と S3 互換ストレージにも対応したよ！

やっほー、しぃちゃんだよ！今日はデータ移行がもっと楽になるニュースを見つけたから、さっそく紹介するね！

## なにが発表されたの？

Cloudflare の Changelog で、R2 の移行ツール「Sippy」が Azure Blob Storage と、S3 互換のオブジェクトストレージプロバイダーからのデータ移行に対応したって発表されたよ。これまでも Amazon S3 と Google Cloud Storage からの移行はできたんだけど、そこに新しく 2 つの選択肢が加わった形なの。

## 今までどうだったの？

Sippy は、既存のオブジェクトストレージから Cloudflare R2 へデータを「インクリメンタル」に移行できるツールだよ。アプリケーションがオブジェクトをリクエストしたタイミングで、そのオブジェクトを R2 にコピーしていく仕組みなの。だから全データを事前にまとめて移行する必要がないし、移行のためだけにエグレス費用を払う必要もなかったんだよね。

ただ、これまで対応していたのは Amazon S3 と Google Cloud Storage だけだったから、Azure Blob Storage や、その他の S3 互換ストレージを使っているみんなは Sippy の恩恵を受けられなかったの。

## これで何が変わるの？

今回の対応で、Azure Blob Storage や MinIO・Backblaze B2 のような S3 互換ストレージを使っているチームも、同じ仕組みで R2 への段階的移行を始められるようになったよ。マルチクラウドでストレージを運用していて「R2 に寄せたいけど、一括移行は大変そう」って思っていたみんなにとって、選択肢が一気に広がる嬉しいアップデートだね。

## 深く潜ってみよう

Sippy の有効化は、コマンド 1 つでできるよ。

```
npx wrangler r2 bucket sippy enable {BUCKET_NAME}
```

このコマンドを実行してプロンプトに従うと、移行元のストレージプロバイダーを選んで設定できるの。プロバイダーごとに必要な情報はこんな感じだよ。

- Azure Blob Storage の場合
  - ストレージアカウント名
  - コンテナ名
  - アカウントキー、または読み取り・一覧権限を持つ SAS(shared access signature)トークンのどちらか
- S3 互換プロバイダーの場合
  - S3 API のエンドポイント URL
  - 読み取り専用の Access Key ID と Secret Access Key

Sippy を有効化した後は、まだ R2 にコピーされていないオブジェクトへのリクエストは移行元バケットから配信されつつ、同時に R2 へコピーされる仕組みだよ。2 回目以降のリクエストは R2 から直接配信されるようになるの。詳しいセットアップ手順や必要な権限については、Sippy のドキュメントを確認してね。

## まとめ

- Sippy が Azure Blob Storage と S3 互換ストレージプロバイダーからの移行に対応した
- 有効化は `npx wrangler r2 bucket sippy enable {BUCKET_NAME}` の 1 コマンド
- Azure は アカウントキー か SAS トークン、S3 互換は エンドポイント URL と読み取り専用キーが必要
- 未移行オブジェクトはリクエスト時に移行元から配信しつつ R2 へコピー、2 回目以降は R2 から配信

Azure や自前の S3 互換ストレージを使っていて「R2 に移行したいけど一括移行のダウンタイムやエグレス費用が心配」というインフラ担当のみんなに、特に刺さるアップデートだよ！