Cloudflare R2とは
CloudflareによるS3互換オブジェクトストレージです。
私が思うメリットとデメリットは以下です。
メリット
・エグレス料金がかからない
デメリット
・特定のリージョンを選択することができない
エグレス料金がかからないことは大きなアセットを配信したい際にかなり利点となります。
例えばSteamなどのゲームの配信は1回のダウンロードで100GB程度の転送量が発生するため、R2を利用すれば大きなコスト削減になるように思えます。
参考: steamのダウンロード統計 (https://store.steampowered.com/stats/content/)
しかし実際には採用されていませんし、インターネット全体を見ても私の体感的にも採用例はあまり多くありません。
どのような場合にCloudflare R2は活用でき、なぜ採用が進んでないのでしょうか。
今回はその理由を考察していきます。
Cloudflareの躍進が止まらない
コストを削減したいコンテンツ供給者にとってCloudflareのCDNは選択肢に上がります。
例えばX(Twitter)はTopPageやAPIに自社ASを利用してきました。
画像などのメディアの配信にはFastlyを利用しています。
しかし、最近はCloudflareのアドレスに解決されることが増えています。

video.twimg.comはまだfastlyに解決されることが多いです。video-cf.twimg.comでアクセスすると強制的にCloudflareを使わせることができ、性能の差を体感できます。
fastlyを強制したい場合はvideo-ft.twimg.comです。
Epic Gamesもゲームの配布にCloudflareを利用しています。
これらはR2ではなく、通常のCDNの方になります。
大きなアセットの配信をするにあたり、いくつか問題点があります。
Cloudflare CDNの問題点
大きめのmp4ファイルなど(600MBほど)を206 Partial Requestした場合に、CacheにHitしているにもかかわらずレスポンスが返るまで1分程度かかるという事象が観測されています。
これは課金を行い、大きなファイルをCacheさせるように設定したときにも同様に観測されています。
Cloudflare CDNはそもそも、過去に2.8条という、HTMLの配信を主体とし、HTML以外のコンテンツを配信するために利用した場合はCloudflareによってアカウントが停止できることが明記されていました。
そもそもCloudflareはmp4などのメディアファイルを配信する用途として提供されていません。
HTMLコンテンツの配信を目的として設計されました

現在、2.8条は改定されましたが、以下のような記載に書き換わっています。
Cloudflareのコンテンツ配信ネットワーク(以下「CDN」)サービスは、WebページやWebサイトのキャッシュと配信に使用できます。エンタープライズプランのお客様でない限り、CloudflareはCDN経由で動画やその他の大容量ファイルを提供する際に使用する特定の有料サービス(開発者プラットフォーム、画像、ストリームなど)を提供しています。お客様が有料サービスを使用せずにCDNを使用して動画や過度の割合の画像、音声ファイル、その他の大容量ファイルを配信している場合、または使用している疑いがある場合、Cloudflareはお客様によるCDNへのアクセスや使用を無効化または制限する権利、あるいはお客様のエンドユーザーによるCDN経由の特定リソースへのアクセスを制限する権利を留保します。当社は、かかる措置についてお客様に通知できるよう合理的な努力を払います。

つまり、専用のソリューションを利用しないとき、画像・動画・音声・大容量ファイルを配信しているとCloudflareが判断した場合(または疑われた場合)にサービスが停止される可能性があります。これは無料・プロ・ビジネスプランで同一です。
しかし、多くの違法サイトでメディアをCacheするためにCloudflareが利用されています。
違法サイトと違法サイトでのCloudflareの活用方法については別の記事で紹介する予定です。
Cloudflare R2の問題点
性能の問題
バケットを公開したくない場合、署名付きURLで公開することになると思います。
その場合、Cloudflare CDNのCacheの恩恵を受けることができません。
Cacheがかからない状態での速度は、かなり遅いです。
今回ユーザ側が要因で低下することがほぼ起こらない環境を用意して、性能を計測しました。
Cloudflare CDNにCacheさせたときの速度は1.6Gbpsほどでしたが、CacheさせずにR2より直接取得したときの速度は40Mbps~80Mbpsを行ったり来たりする状態です。
また混雑する時間帯に速度低下が発生しています。
以下の画像は複数並列で丸1日ダウンロードさせたときの転送速度です。

Cloudflare Radarのグラフのトラフィックグラフの推移と概ね一致します。
https://radar.cloudflare.com/ja-jp/jp
また、R2バケットのリージョンがアバウトにしか設定できないことも、採用を足踏みする要因となっているのではないでしょうか。
どのリージョンが指定できるのか、また各リージョンの性能を比較するためのテストファイルを公開しています。
サッと試したいときに、ご利用ください。
Cloudflare R2の活用例
私が見つけた中で最大のCloudflare R2の活用例は、違法なアダルト動画サイトでの活用です。
当該サイトでは動画コンテンツの配信にCloudflare R2の署名付きURLを利用しています。
当該サイトは日本のアダルトサイトで10本の指に入るアクセス数を誇っています。
過去にPornhubが公開していたアクセス数と転送量より、当該サイトの転送量を予測すると、月間1PBにも上ると予測できます。
https://www.pornhub.com/insights/2018-year-in-review
比較的パフォーマンスへの要求が低いそのようなサイトでは、Cloudflare R2を活用することで保管にかかる料金、そして多少のAPI呼び出し料金のみで運用できていると思われます。
Cloudflare R2の不思議な仕様
1. S3 APIのエンドポイント
Cloudflare R2をS3 APIとして利用する場合(署名付きURLでアクセスをさせる場合など)は、R2 Object Storageの設定→一般に記載されているURLを利用します。
そのURLの形式は以下のようになっています。
https://5612084c3756ad89c117f7372ee7f772.r2.cloudflarestorage.com/reze
これはrezeという名前のバケットを作成したときのURLです。
r2.cloudflarestorage.comから左の値はアカウントごと共通のものです。
reze2というバケットを作成した場合、以下のようになります。
https://5612084c3756ad89c117f7372ee7f772.r2.cloudflarestorage.com/reze2
そして、さらにサブドメインを自由に付与できます。
例えば
https://reze.5612084c3756ad89c117f7372ee7f772.r2.cloudflarestorage.com/reze
というURLでも同一です。
さらにサブドメインをつけても解決が行われますが、SSL証明書の対象から外れてしまうため、利用することはできません。
https://reze.reze.5612084c3756ad89c117f7372ee7f772.r2.cloudflarestorage.com/reze
つまり
https://{お好きな文字列}.5612084c3756ad89c117f7372ee7f772.r2.cloudflarestorage.com/{バケット名}
といった形で利用可能です。
アカウントごと固有の値によって、同一のアカウントだということが露呈しますので、お気をつけください。
また、その値はアカウントのIDと同一です。
つまりご自身のアカウントであれば、以下のようにWeb ConsoleにアクセスするときのURLの値と同一です。
https://dash.cloudflare.com/5612084c3756ad89c117f7372ee7f772/home/
公開しても問題ないのでしょうが、あまりむやみに公開したくないなという印象です。
2. カスタムドメインのTLSについて
カスタムドメインを接続するとCloudflare CDNのCacheの恩恵を受けることができますが、バケットの中身が公開されます。
そのため、上で書いた通り、パブリックアクセスなバケット以外はCloudflare CDNの恩恵を受けることができません。
そして、Cloudflare CDNを利用しない場合は、性能の問題が発生します。
カスタムドメインを接続し、バケットを公開するときにTLS関連で奇妙な動作をします。
まずはカスタムドメインを接続します。





その後、ドメインのDNSレコード画面から確認すると、以下のように表示されます。

このホスト名は証明書の対象外です。完全にカバーするには、Advanced Certificate Manager を購入して Total TLS を使用し、プロキシされたホスト名の証明書を完全にカバーします。
このようなサブサブドメイン?は、共有 Cloudflare Universal SSL 証明書のカバーする範囲ではありません。
例えばreze.partyでは、*.reze.party, reze.partyをカバーする証明書がデフォルトで発行されます。
参考 証明書のカバーする範囲: https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/error-messages/
参考 Universal SSL: https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/
参考 Total TLS: https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/
そのため、Advanced Certificate Manager(ACM)を購入する必要があるように思えます。
しかし、実際に設定したドメインにアクセスしてみると、SNIによって証明書が発行されており、正常にアクセスが可能です。
https://reze.r2.reze.party/
これは、何階層にもわたるサブドメインを発行した際でも同じ動作をします。
https://reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.reze.r2.reze.party/
Certificate Transparency(CT)(証明書の透明性の監視)を有効にしていた場合、メールが届くため、新たに証明書が発行されていることが分かります。

最後に
この記事に書いてある内容について何らかのご意見やご要望がある方は以下のメールアドレスまでご連絡ください
[email protected]