Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

KV の仕組み

最終更新 Markdown で表示Agent セットアップ

KV は、グローバルで低レイテンシのキーバリューデータストアです。少数の中央データセンターにデータを保存し、アクセス後に Cloudflare のデータセンターへキャッシュします。

KV は非常に高い読み取り量を低レイテンシで処理できます。KV の組み込みキャッシュとグローバル分散により、スケールする動的 API を構築できます。 キャッシュになく、中央ストアへアクセスする必要があるリクエストは、レイテンシが高くなることがあります。

KV への書き込みと KV からの読み取り

KV に書き込むと、データは中央データストアに書き込まれます。データがすべてのロケーションのキャッシュへ自動送信されるわけではありません。

KV に書き込むと、データは中央データストアに書き込まれます。

あるロケーションでの初回読み取りには、キャッシュされた値がありません。データは、最も近いリージョナルティア、次にセントラルティアの順で読み取られます。世界的に完全なコールドリードの場合は、最終的に中央ストアまで辿ります。初回アクセスは世界的に遅くなりますが、以降のリクエストは速くなります。特に、リクエストが 1 つのリージョンに集中している場合です。

初回の読み取りはキャッシュをミスし、まず最も近い中央データストアへ向かいます。

同じロケーションからの頻繁な読み取りは、他の場所から読み取らずにキャッシュ値を返すため、応答が最も速くなります。KV は、キャッシュの有効期限が切れる前に、上位ティアのキャッシュと中央データストアからバックグラウンドで更新し、キャッシュ値を維持します。

上位ティアと中央データストアからのバックグラウンド更新は慎重に行われます。アクセス中のアセットは、停滞なくキャッシュから配信し続けます。

前述のとおり、頻繁な読み取りはキャッシュ値を返します。

KV は読み取りが多いアプリケーション向けに最適化されています。データは中央に保存し、プッシュとプルを組み合わせたハイブリッドレプリケーションでキャッシュへ格納します。比較的少ない書き込みで、すばやく頻繁に読み取るユースケースに適しています。あまり読まれない値は他のデータセンターや中央ストアから取得し、よく使われる値はリクエスト元のデータセンターにキャッシュされます。

パフォーマンス

KV のパフォーマンスを上げるには、cacheTtl パラメーター をデフォルトの 60 秒より大きくします。

KV は キャッシュ によって高いパフォーマンスを実現します。そのため、読み取りは書き込みに対して結果整合です。

変更を行った Cloudflare グローバルネットワークのロケーションでは、通常、すぐに反映されます。他のグローバルネットワークロケーションでは、キャッシュされたデータがタイムアウトするまで、反映に最大 60 秒以上かかることがあります。

キーが存在しないことを示すネガティブルックアップもキャッシュされます。そのため、値が作成されたことに気づくまでの遅延は、値が変更された場合と同じです。

一貫性

KV は結果整合であることで、高いパフォーマンスを実現しています。変更を行った Cloudflare グローバルネットワークのロケーションでは、通常すぐに見えます。ただし保証はないため、この動作に依存しないでください。他のグローバルネットワークロケーションでは、キャッシュされたデータがタイムアウトするまで、最大 60 秒以上かかることがあります。

あるキーの以前のバージョンを最近読み取ったロケーションでは、変更が見えるまでにさらに時間がかかります(キーが存在しないと示した読み取りも含みます。それもローカルにキャッシュされます)。

write-after-write(書き込み後の書き込み)の一貫性を得る方法の 1 つは、対象の KV キーへの書き込みを、対応する Durable Object インスタンス経由にまとめ、他の Workers では KV からその値を読み取ることです。書き込みをより細かく制御したいが、上記の KV の読み取り特性で十分な場合に有効です。

指針

Workers KV は、結果整合のエッジキーバリューストアです。次のような 読み取りが多い、キャッシュしやすいワークロードに向いています。

  • 静的アセットの配信
  • アプリケーション設定の保存
  • ユーザー設定の保存
  • 許可リスト / 拒否リストの実装
  • キャッシュ

これらのシナリオでは、ユーザーに最も近いデータセンターで Workers が起動し、以降のリクエストのレイテンシを抑えるため、Workers KV のデータはそのリージョンにキャッシュされます。

同じキーを 1 秒あたり数十回から数百回更新する、書き込みが多い Redis 型のワークロードでは、KV は向きません。 単一のキーバリューペアへの書き込み方法を見直し、複数の個別キーに書き込みを分散できれば、Workers KV は要件に合う場合があります。 または、Durable Objects は、キーあたりの書き込みレート上限が高いキーバリュー API を提供します。

セキュリティ

Workers KV がデータを保護する仕組みは、データセキュリティのドキュメント を参照してください。

役に立ちましたか?