このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
本日、R2のローカルアップロードのオープンベータ版を開始します。ローカルアップロードを有効にすると、オブジェクトデータはまずクライアントに近いストレージ場所に自動的に書き込まれ、その後、バケットがある場所に非同期でコピーされます。データにはすぐにアクセスでき、強力な一貫性が維持されます。アップロードが高速化し、データはグローバルに感じられます。
多くのアプリケーションでは、パフォーマンスはグローバルである必要があります。たとえば、さまざまな地域からメディアコンテンツをアップロードするユーザーや、世界中からログやテレメトリを送信するデバイスです。しかし、データはどこかに存在しなければなりません。つまり、遠方からのアップロードはバケットに到達するために全距離を移動しなければなりません。
R2は、Cloudflareのグローバルネットワーク上に構築されたオブジェクトストレージです。すぐに使える状態で、オブジェクトデータをグローバルに自動的にキャッシュし、どこからでも高速読み取りが可能です。同時に、強整合性を維持し、エグレス料金はゼロです。これは、S3 API、Workersバインディング、通常のHTTPのいずれを使用していても、舞台裏で発生します。そして、ローカルアップロードによって、世界中どこからでも高速の読み込みと書き込みができるようになりました。
このデモでは、ローカルアップロードの利点を詳しくご紹介しています。
試されますか？バケット設定の下にあるCloudflareダッシュボードで、または既存のバケットで単一のWranglerコマンドを使用して、ローカルアップロードを有効化します。
npx wrangler r2 bucket local-uploads enable [BUCKET]
グローバルアップロードの総リクエスト時間を75%短縮
ローカルアップロードは、アップロード要求（つまりputObject、アップロード部など）をより高速化できるようになりました。お客様とのプライベートベータテストと総合ベンチマークの両方で、バケットとは異なる地域でアップロードリクエストが行われた場合、TTLB（Time To Last Byte）が最大75%短縮されることが確認されました。これらの結果では、TTLBは、R2がアップロード要求を受信した時点から、R2が200レスポンスを返すまでの時間を測定しています。
総合テストでは、合成ワークロードを使用してリージョンをまたがるアップロードワークフローをシミュレートすることで、ローカルアップロードの影響を測定しました。西北米にテストクライアントをデプロイし、アジア太平洋地域のロケーションヒントでR2バケットを設定しました。クライアントは30分以上、1秒あたり約20回のPutObjectリクエストを行い、5MBのオブジェクトをアップロードしました。
次のグラフでは、これらのリクエストのp50（または中央値）のTTLBメトリクスを比較し、アップロードリクエスト時間の違いを示しています。最初にローカルアップロードを使用しない場合（TTLBは約2秒）、次にローカルアップロードを有効にした場合（TTLBは約500ミリ秒）です。
Local Uploadsがアップロードリクエストをどのように改善できるかを理解するために、まずR2の仕組みを見てみましょう。R2のアーキテクチャは、以下のような複数のコンポーネントで構成されています。
R2 Gateway Worker: R2 Gateway Worker：認証とルーティングロジックを処理するすべてのAPIリクエストのエントリポイント。Cloudflare Workersを介して、Cloudflareのグローバルネットワーク全体にデプロイされます。
Durable Object Metadata Service: Durable Objects上に構築された分散型レイヤーで、オブジェクトのメタデータ（例：オブジェクトキー、チェックサムなど）を悪用した攻撃に対処します。
分散型ストレージインフラストラクチャ：暗号化されたオブジェクトデータを永続的に保存する基盤となるインフラストラクチャ。
ローカルアップロードを使用しない場合、オブジェクトをバケットにアップロードすると次のようになります。リクエストは、最初にユーザーに近いR2 Gatewayによって受信され、そこで認証されます。そして、クライアントがオブジェクトデータのバイトをストリーミングすると、データは暗号化され、バケットが配置されているリージョンのストレージインフラストラクチャに書き込まれます。これが完了すると、Gatewayはメタデータサービスに連絡して、オブジェクトのメタデータを公開し、コミットされた後に成功レスポンスをクライアントに返します。
クライアントとバケットが別々の地域にある場合、リクエストが移動する距離が長くなると、オブジェクトデータのバイトをアップロードするプロセスに、より多くの変動が生じる可能性があります。これにより、アップロードに時間がかかったり、信頼性が低下したりする可能性があります。
アップロードを有効にせず、東北米からローカル東欧のバケットにアップロードするクライアント。
現在、ローカルアップロードを有効にしてバケットへのアップロードリクエストを行うと、次の2つのケースが処理されます。
クライアントとバケットのリージョンは同じリージョンにあります
クライアントリージョンとバケットリージョンが異なるリージョン
1つ目のケースでは、R2は通常のフローに従い、オブジェクトデータがバケットのストレージインフラストラクチャに書き込まれます。2番目のケースでは、R2はクライアントリージョンにあるストレージインフラストラクチャに書き込みを行いますが、同時にオブジェクトのメタデータをバケットのリージョンに公開します。
重要なのは、最初の書き込みが完了した後、オブジェクトにすぐにアクセスできることです。これは、レプリケーションプロセス全体を通じてアクセス可能な状態です。オブジェクトが読み取られる前に、バックグラウンドのレプリケーションが終了するのを待つ必要はありません。
ローカルアップロードを有効にして、東ヨーロッパから東ヨーロッパのバケットにアップロードするクライアント。
これは、非管轄地域の制限付きバケット用であり、ローカルアップロードは、管轄地域の制限があるバケット（例：EU、FedRAMPなど）有効化。
ローカルアップロードは、バケットがある場所とは異なる地域から発信される大量のアップロードリクエストを受信するワークロード向けに構築されています。この機能は、次のような場合に最適です：
読み取りや書き込みリクエストが開始された場所の地理的分布を把握するには、Cloudflareダッシュボードにアクセスし、R2バケットのメトリクスページに移動して、リクエスト分布（リージョン別）グラフを確認してください。
ローカルアップロードでは、オブジェクトデータはクライアントの近くに書き込まれ、バックグラウンドでバケットのリージョンにコピーされます。このコピージョブをレプリケーションタスクと呼びます。
このようなレプリケーションタスクを考えると、非同期処理コンポーネントが必要でしたが、これはCloudflare Queuesにとって最適なユースケースとなる傾向があります。キューを使用すると、レプリケーションタスクの処理速度を制御でき、リトライやデッドレターキューなどの組み込みの障害処理機能が提供されます。この場合、R2はストレージリージョンごとに複数のキューにレプリケーションタスクをシャーディングします。
ローカルアップロードを有効にし、オブジェクトのメタデータを公開する際、以下の3つの操作をアトミックに実行します。
オブジェクトのメタデータを保存する
まだ実行する必要があるレプリケーションを追跡する、保留中のレプリカキーを作成します
タイムスタンプでキー設定したレプリケーションタスクマーカーを作成します。これは、タスクがキューに送信されるタイミングを制御します
保留中レプリケーションキーには、レプリケーションタスクの数、読み取り元のソースの場所、書き込み先の場所、レプリケーションのモードと優先度、レプリケーションが成功した後にソースを削除するべきかどうかなど、レプリケーションプランの全情報が含まれています。
これにより、オブジェクトのデータの移動方法に柔軟性が得られます。例えば、地理的に長い距離を移動してデータを移動すると、コストがかかります。すべてのレプリカを並行して処理することで、すべてのレプリカをできるだけ高速に移動させることもできますが、これを実行すると、より多くのコストが発生し、ネットワークインフラストラクチャに負荷が集中します。代わりに、まずターゲットバケットリージョンにレプリカを1つ作成し、このローカルコピーを使用してバケットリージョン内に追加のレプリカを作成することで、リージョンを越えたデータ移動の数を最小限に抑えます。
バックグラウンドプロセスは、レプリケーションタスクマークを定期的にスキャンし、宛先ストレージリージョンに関連付けられているキューの1つに送信します。インジケーターは、キューへの少なくとも1回の配信を保証します。エンキューに失敗した場合やプロセスがクラッシュした場合、インジケーターは存続し、タスクは次のスキャンで再試行されます。これにより、異なる時間にレプリケーションを処理し、有効なタスクのみをキューに入れることができます。レプリケーションタスクがキューに届くと、処理する準備ができます。
キューコンシューマーに対しては、中央で集約されたポーリングサービスがリージョンキューからタスクを消費し、実行のためにGateway Workerにディスパッチするプルモデルを選びました。
仕組みは次のとおりです。
ポーリングサービスはリージョンキューからプル： コンシューマーサービスは、レプリケーションタスクのためにリージョンキューをポーリングします。次に、移動させるデータの量に基づいて、統一されたバッチサイズを作成するために、タスクをバッチ処理します。
Gateway Workerへのポーリングサービスディスパッチ：コンシューマーサービスは、Gateway Workerにレプリケーションジョブを送信します。
Gateway Workerがレプリケーションを実行：Workerはソースロケーションからオブジェクトデータを読み取り、宛先に書き込み、Durable Object内のメタデータを更新し、必要に応じてソースロケーションをガベージコレクションを指定します。
Gateway Workerは結果を報告：完了すると、workerは結果をポーラーに返し、タスクがキューに完了または失敗したことを認識します。
このプルモデル的アプローチを使用することで、レプリケーションプロセスが安定し、効率的になるようにします。このサービスは、リアルタイムのシステムの健全性に基づいてペースを動的に調整することができ、データがどの地域でも安全に複製されることを保証します。
ローカルアップロードは、オープンベータ版で利用可能になりました。ローカルアップロードを有効にするための追加費用はかかりません。この機能を有効にして作成されたアップロードリクエストには、ローカルアップロードなしで行われたアップロードリクエストと同じく、標準的なクラスA操作コストがかかります。
開始するには、バケット設定の下にあるCloudflareダッシュボードにアクセスして、ローカルアップロードカードを探して有効にするか、Wranglerを使って次のコマンドを実行するだけでバケットのローカルアップロードを有効にします。
npx wrangler r2 bucket local-uploads enable [BUCKET]
バケットでローカルアップロードを有効にするのはシームレスです。既存のアップロードは期待通りに完了し、トラフィックを中断することはありません。
詳細については、ローカルアップロードのドキュメントを参照してください。ご質問がある場合やフィードバックを共有したい場合は、開発者Discordのディスカッションにご参加ください。