Zenn
💭

Cloudflare R2についてことはじめ

2023/12/03に公開
VR
S3
Cloudflare
#
adventcalendar
R2
tech

はじめに

今回はCloudflare R2について今更ながら解説します。
この記事はHIKKYアドベントカレンダー3日目の記事です。
3日目の夜に書いてます。なんでや。
https://qiita.com/advent-calendar/2023/hikky
色々な記事が出る予定ですので是非ご覧ください。

2日目はSakamotoさんによるメタバースイベントサイト開発、Webアプリケーション開発、個人開発で得た、Nuxt3の「わがった！」と「わがんない」です。良ければこちらもご確認くださいませ
また明日はFukuroさんによる「爆速デプロイ！？Cerebriumについて」についてです。こちらもお楽しみに。

Cloudflare R2について

要は「S3互換システム」のうちの一つで、Cloudflareがサービスを提供しているものです。S3互換システムを名乗っていることもあって、コマンドのほとんどの部分がS3クライアントと互換性があります。
https://www.cloudflare.com/ja-jp/developer-platform/r2/

小噺: 語源について

Cloudflare R2の「R2」は下の様に一つ前の文字・数字をそれぞれ使用しています。
S -> R
3 -> 2
これで「S3よりもより先を行っているよ！」というイメージを出すためにR2という名前にしたそうです（R2ローンチ時にそんなことを言っていた記憶があります）。

当社での利活用について

当社では「AWS CloudFront + S3」構成をしているシステムが古くからあります。そのうち、特に
バーチャルマーケットの動画について、このCloudflare R2 へ転用しています。

理由としてはR2のページにも記載されている「エグレス料金ゼロ」が最も大きいです。
CloudFront + S3構成の場合、CloudFrontからエンドユーザに転送する
「エグレス」に対し転送量に対し課金が発生します。
この料金が丸々ゼロになります。映像データは特にこのエグレスが大きかったため、
費用対効果でかなりのメリットがあることからCloudflare R2へ移行しています。

費用面

https://developers.cloudflare.com/r2/pricing/
ここを読めば一通り書いてますがざっくりと。

  • 「容量」
  • 「クラスA処理: 書き込み処理(と、一覧を確認する処理)」
  • 「クラスB処理: 読み込み処理」
    この三種類で課金されます。削除・中止系の処理は一切課金されないです（DeleteObject / DeleteBucket / AbortMultipartUpload）

それぞれについて

  • 「容量」: 10GB /月無料。それ以上は「1ヵ月1GB確保した状態に対して」0.015ドル
    例: 最初の11日は10GB、その後の20日は13GB使っていた場合、 2/3 * 0.015の 0.01ドル課金
  • 「クラスA処理」: 月に1milion(100万)リクエストまで無料。それ以降は100万リクエスト当たり4.5ドル
  • 「クラスB処理」: 月に10milion(1000万)リクエストまで無料。それ以降は100万リクエスト当たり0.36ドル

クラスA処理

リスト処理、アップロード処理など主にファイル操作や一覧性を持った読み込み処理についてはクラスAになっているそうです。

  • ListBuckets
  • PutBucket
  • ListObjects
  • PutObject
  • CopyObject
  • CompleteMultipartUpload
  • CreateMultipartUpload
  • ListMultipartUploads
  • UploadPart
  • UploadPartCopy
  • ListParts
  • PutBucketEncryption
  • PutBucketCors
  • PutBucketLifecycleConfiguration

クラスB処理

オブジェクトの読み取り関連です。
一般的にエンドユーザから読んでもらう場合はこちらになります。

  • HeadBucket
  • HeadObject
  • GetObject
  • UsageSummary
  • GetBucketEncryption
  • GetBucketLocation
  • GetBucketCors
  • GetBucketLifecycleConfiguration

作成

作成方法は単純で、R2画面から「Create Bucket」で作成するだけです。

基本的にはワールドワイドですが、位置情報のヒントを指定することもできます。
HIKKYでは基本的に「APAC」に指定しています。

因みに、もし特定の圏内にデータを置かなければならない！といった事情がある方向けに「管轄を指定する」こともできます。といってもEUしかないですが。絶対例の法律対策ですね……

利用者に使わせる際のR2のキー発行

Manage R2 API Tokens (R2 APIトークンの管理) から飛べます。

Create API tokenより作成します。以下の情報をザクザクと決めます:

  • Token name: 任意です。基本的にはユーザやバゲットの名前を入れてます
  • Permissions: 今回はObject Read & Writeまで持ってればOKです
  • Specify bucket(s): Apply to specific buckets only からバゲットを選択しましょう。複数バゲットも選択可です
  • TTL: 基本的には年限を設定することをお勧めしますが、作成が終わった後すぐ消す、もしくは人に渡して別途管理ツールで管理する場合などはForeverでもいいかもです
  • Client IP Address Filtering: IPアドレス単位で制限ができます。「会社のVPN経由じゃないと使えないようにしたい」等あればこちらで設定できます。移行するときは空です。

発行したら以下の情報が渡されます。使用者にはAccess key ID / Secret Access key / Endpoint / 使えるバゲット名を教えれば概ねOKですが、すべてメモはしておくようにしましょう。

  • Token value: CloudFlare APIを使ってバゲットを操作する場合はこれ。移行やS3互換ソフトでは使わない（どこかでこれ使いたい……）。
  • Access key ID: これを使う。S3のアクセスキーIDとして使用
  • Secret Access Key: これを使う。S3のアクセスキーシークレットとして使用。
  • Endpoint: 基本的にDefaultを使う。

追加

エンジニア向け(簡単に)

エンジニア向けにはAWS CLIでたたき込めばOKです。エンドポイントの指定が必要な点だけ気を付けてもらえれば問題ありません。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-endpoints.html

非エンジニア向け

非エンジニア向けにはCyberduckをお勧めします。
注意点として、特定のバゲットのみ許可している場合（大抵の場合はそう）、
バゲットパスの後にディレクトリとしてバゲット名を入れないと403が返されます。
Cyberduckを説明する場合はそちらの添付をお忘れなく。

  1. 一番上をAmazon S3にする
  2. サーバーはEndpointをホストアドレスだけ抜き出したもの(**.r2.cloudflarestorage.com)
    • Endpointをそのまま入れるのはNG！ 勝手にWebDAVになり。AmazonS3にするとまた消えてしまう。
  3. アクセスキーID・シークレットアクセスキー: 発行したものをそのまま入れる
  4. 詳細設定をクリック
  5. パスに接続したいバゲットの名前を入れる(cdn-test-bucket)
    • これをしないと403帰ってきます！

ここまで出来たらあとはExplorerみたくD&Dすれば入ります。簡単。

カスタムドメインについて

カスタムドメインはCloudFlareに紐ついているドメインであれば可能です。サブドメインも可。
サブサブドメインにしたい場合は[Advanced Certificate Manager]を払いましょう。月10ドルです。

CORSについて

JavaScript等々から読み込ませる場合に欲しくなる設定です。当社だとVketCloud経由、Website経由で読み込むときに使います。ドメイン単位でどのメソッドを使用許可するかを決めます。
https://developers.cloudflare.com/r2/buckets/cors/#example
※ここで指定するのはホストではなくオリジンです。ややこしいかもしれませんが、プロトコル方式+ホストアドレス(+ポート。規定ポート以外の場合)です。
例: exaple.com を許可したい -> example.com はNG。 https://example.com と記載
example.com、ポート3000番で許可したい: https://example.com:3000 と記載

オブジェクトのライフサイクル

一時データを吐き出すバゲットの場合、3-7日程度で消えることを想定しているデータもあります。そういった場合はオブジェクトのライフサイクルを指定することで勝手に消えてくれます。
7日経過していれば削除など、サクッと設定が入れられるので便利です。

AWSからの移行

AWSからデータを移行する方法も用意されています。
https://developers.cloudflare.com/r2/data-migration/
基本的には「Super Slurper」を使用すればOKだと思います。
アプリケーションを動かしながら継続的に移行させたいといったニーズのために「Sippy」も用意されています。

移行させるときはどちらも以下の情報を用意すればOKです。

  • AWSのバゲット名
  • AWSのバゲットにアクセスできるキーID
  • キーIDに対するシークレット
  • 移行させたいバゲットにアクセスできるR2のキーID
  • R2のキーIDに対するシークレット


Overrite files?についてはHIKKYではこうしています。

  • 移行させるデータがある程度膨大な場合の初回: Yes,override
  • 二回目以降: 必ず No,skip

というのも、移行後は基本的に前のバゲットにはデータを入れないようにする前提のためです。
もしR2のバゲットで更新したデータがあった場合にS3から再同期をかけると丸っと昔のデータに巻き戻ってしまうため、それを避ける目的で No,skip にしています。

AWSのキーについて

List / Getに関して全権限を渡せばOKです。Deleteはいらないです。
このキーはそこそこに権限が強いので、使うときだけ発行し終わったら削除するようにしましょう。
https://developers.cloudflare.com/r2/data-migration/super-slurper/#create-amazon-s3-credentials

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

注意点

  • 1バゲット当たりの容量は5TiB / 1ファイル当たりの容量は5GiBまでです。
  • 1アカウント当たり1000バゲットまで作れます。
  • AWS + CloudFrontと違いそれぞれのAPIコールについて細かくとることはできない(後述)。
  • ETagについてはSuper Slurperを使用した場合は一致が保障されていないので、もしETagを用いて差分検出している場合は全件差分に一回なるかもしれないので注意(今回この記事を書いてて初めて知りました)。

最後に

アドカレはちゃんと用意しておきましょうね。
とはいえ、特に単純なCDNとして使用する場合、CloudFlare R2を選択肢に入れていい環境であれば使わない意味はない、といっても過言ではないレベルで便利です。
是非試験的にでも導入してみてくださいませ。

なお、今回は説明しませんでしたらCloudFlare Workersとの連携も可能です。
こちらもまた機会があれば記事にいたします。

Discussion