Cloudflare Workers KVをAPIの無料DBとして使うときのポイント
公開日: 2021.4.16
Cloudflare Workers KVをAPIの無料DBとして使うときのポイントをまとめました。上限に引っかかることなく、複数サイトの複数DBを無料で運用するための工夫方法も。
まずはCloudflare Workers KVの無料制限を確認しよう
Cloudflare Workers KVをAPIの無料DBとして使う場合は、まずは制限事項をしっかりと抑えておく必要があります。
Cloudflare Workers KVのコール系の制限事項は下記の通りです。ここはCloudflare Workersの制限回数とは別枠です。
イベント | 単位 | 制限 |
---|---|---|
Reads | 一日 | 100,000回 |
Writes | 一日 | 1,000回 |
Lists | 一日 | 1,000回 |
Deletes | 一日 | 1,000回 |
Storage | 常時 | 1 GB |
Readは1日10万回と多めですが、Write/List/Deleteは毎日1,000回までと、意外と回数が少ないことがわかります。
続いて、KVで保持できるデータの無料作制限について見てみます。
項目 | 制限 |
---|---|
Namespaces | 100 |
Keys/namespace | unlimited |
Key size | 512 bytes |
Key metadata | 1024 bytes |
Value size | 25 MB |
NamespaceはRDS SQLでいうところのデータベースに相当します。ここは100個までなので、データをあまり小さい単位で分割すると、複数サイトを運営している場合などすぐに上限に達してしまいます。
Keys/namespaceは「NamespaceあたりのKey」の数でここが無制限です。無料で運用する際はここがポイントになります。
Key sizeとKey metadataは特別気にする必要はありませんが、Keyが持てるValueの上限は25MBです。ここもポイントです。
制限にかからずCloudflare Workers KVを使うポイント
コール回数を最低限に抑えよう
RDS SQLを使ったAPIの場合は、クエリが大きい・多いほどロードが遅くなるので、小さい単位でデータを出してフロント側で結合するという方法も取られますが、Cloudflare Workers KVでそのやり方をするとReadはともかくWriteはすぐに上限に達してしまいます。
ですので、なるべくコールの回数を減らすようにデータを構築する必要があります。1ページで得るデータはCloudflare Workers KVでは1回のKVコールで終わりにするの理想です。
Key無制限・Value最大25MBを活用しよう
Cloudflare Workers KVでお得なポイントは、
- NamespaceあたりKeyの数が無制限
- KeyのValueの数が25MBと巨大
という点です。
ここを活用して、
- 独自Keyをどんどん発行して関連データを格納する
- RDS SQLの感覚でKey/Valueを「行」として見るのではなく、小さなDBとして使う
というのが無料で回す際のポイントになるでしょう。
例えば、ユーザーの設定データをバックアップするとしたら、RDSだったら、
- ユーザーテーブル
- 設定テーブル
- その他関連するマスターテーブル
をそれぞれ設定するのが通常でしょう。しかし、この方法でCloudflare Workers KVでデータを組むと、1 APIコールあたりで複数回のKVをコールしてしまいます。
また、RDSでは対象のデータを探す際にテーブルスキャンをするのが通常ですが、Cloudflare Workers KVは一覧のロードも1日1,000回までなので、この方法だと1日1,000回という少ない上限のListがすぐにパンパンになってしまいます。KVを呼び出す際はKey検索ではなく、Keyを直接指定するのがベストです。
そのため、Cloudflare Workers KVでは、
- Keyをユーザー「user-UUID」などにユニークにする
- Valueに設定データを全て取り込む
という形を取ると良いでしょう。FirebaseなどのNoSQLデータベースと同じ考え方です。
ユニークなKeyというのは、RDSでいうユニークインデックスの感覚です。RDS SQLのように付随するDBと連動してデータを持っていると、コール回数が増えてしまう(1回のAPIコールでn回のKVコール)ので、基本的にはKeyに収容するValueはそれで完結するのがベストでしょう。
Workersの上限も気をつけよう
Cloudflare Workers KVは、Cloudflare Workersと一緒に使う前提なので、Cloudflare Workers自体が1日の上限に達してしまうと、KVも使えなくなってしまいます。
表示するだけのAPIに使うのなら良いですが、ユーザーデータの格納などに使う際は、上限でAPIがストップすると大問題になるので、細心の注意を払う必要があります。
理想は1ページ/1 APIコール/1 KVコール
KVをAPIのDBとして使う際は、ページが必要とするデータを取得するのがメインになりますが、ここは基本的には「1ページ/1 APIコール/1 KVコール」が利用です。
ただ、あまりにここにこだわると、データの整合性を取るためにサブテーブルが必要になったり、場合によってはサブテーブルのWriteで1,000回の上限に達してしまうケースもあるので、バランスをみながら構築していくのが大事です。
Cloudflare Workers KVをAPIの無料DBとして使うときのポイントをみてきました。
RDSに慣れているとデータ構築の考え方が違って一瞬混乱しますが、NoSQL的な考えに慣れてしまえば高速で無料で使えるかなり便利なDBとなってくれます。
ぜひ試してみてください。
価格は記載がある場合を除き、すべて税込みです。
関連キーワード
サーバレスの新着記事
- サーバレスCloudflare R2の料金体系・無料枠まとめ 2024.8.21
- サーバレスCloudflare R2をCyberduckで使う方法 2024.7.31
- サーバレスAIの学習ボット・クローラーからサイトを守るメリットとブロックする方法 2024.7.19
- サーバレスCloudFlare Pagesのビルド環境の違い 2024.5.9
- サーバレスCloudflare D1の料金体系・無料枠まとめ 2024.3.25
- サーバレスCloudflare PagesでNuxt3のビルド時に「ENOENT: no such file or directory」エラーの対象方法 2024.3.21
- サーバレスGitlab CLIでpush時に「glab auth not found」となった際の対処方法 2024.3.19
- サーバレスCloudFlare Workers AIの料金体系・無料枠まとめ 2024.2.2