Deno KVとUpstash Redisを徹底比較!パフォーマンスとコストの実測ベンチマーク

約2週間前、私たちはCloudflare KVとUpstash Redisのパフォーマンスおよびコストを比較しました。今回は、Denoのグローバルエッジネットワーク上で動作するDenoネイティブのキーバリューストア「Deno KV」を取り上げます。

Deno KVはアーキテクチャの面でUpstash Redisとよく似ています。どちらのストアも、すべての書き込みが送信されるプライマリリージョンを持ち、そこから他のすべてのリージョンへレプリケーションされます。読み取りはクライアントに最も近いリージョンから提供されます。RedisにはKVにはない多くの機能があるため、利用可能な機能には多くの違いがありますが、今回はシンプルな読み書きに焦点を絞って検証します。

ベンチマークは2種類用意し、いずれもDeno Deploy上でコードを実行します。どちらの場合も、KVストアとRedisは利用可能なすべての読み取りリージョンを有効にした状態でテストします。

1. planetfall.ioを使用して、世界中の20のリージョンから関数を呼び出す
2. 単一リージョンから、より高い負荷で関数を呼び出す

その後、結果を比較し、トレードオフと価格について考察します。

ベンチマークのセットアップ

セットアップの内容は以下の通りです。基本的にはCloudflareでの検証と同じ構成を、Deno KV向けに更新したものです。

• キー数:1,000個
• データサイズ:4KB〜64KB(ランダム)
• 全キーのTTL:60秒
• 関数を呼び出すリージョン数:20
• リクエストレート:約10リクエスト/秒

RPSを極端に上げなくてもキャッシュヒットが発生するよう、あえて小さめのキースペースを選択しました。

コード

関数自体は非常にシンプルです。Redisから読み取り、KVから読み取り、その後の評価のためにそれぞれのレイテンシを返すだけです。

app.get("/test", async (c) => {
 const key = Math.floor(Math.random() * 1_000).toString()
 const minValueSize = 4 * 1024
 const maxValueSize = 64 * 1024
 
 const data = randomBytes(minValueSize, maxValueSize)
 
 const ttlSeconds = 60
 
 const beforeRedis = performance.now()
 const redisResponse = await fetch(Deno.env.get("UPSTASH_REDIS_REST_URL")!, {
 method: "POST",
 headers: {
 "Content-Type": "application/json",
 "Authorization": `Bearer ${Deno.env.get("UPSTASH_REDIS_REST_TOKEN")}`,
 },
 body: JSON.stringify(["GET", key])
 })
 const redisLatency = performance.now() - beforeRedis
 
 if (!redisResponse) {
 await fetch(Deno.env.get("UPSTASH_REDIS_REST_URL")!, {
 method: "POST",
 headers: {
 "Content-Type": "application/json",
 "Authorization": `Bearer ${Deno.env.get("UPSTASH_REDIS_REST_TOKEN")}`,
 },
 body: JSON.stringify(["SET", key, data, "EX", ttlSeconds])
 })
 }
 
 const kv = await Deno.openKv();

const beforeKV = performance.now()
 const kvResponse = await kv.get([key])
 const kvLatency = performance.now() - beforeKV
 if (!kvResponse.value) {
 const setRes = await kv.set([key], data, { expireIn: ttlSeconds })
 console.log({ setRes })
 }
 
 return c.json({
 redisLatency,
 kvLatency,
 });
});

結果①:グローバルレイテンシ

30分間の測定後の結果がこちらです。ここで計測されたレイテンシは、Deno Deploy上の関数からストアまでの時間のみで、関数を呼び出すためのネットワークラウンドトリップは含まれていません。

Deno KVからのデータ読み取りは、かなり遅いという結果になりました。最初に思ったのは、「世界中に十分な読み取りリージョンが分散配置されていないのではないか」という点です。このベンチマークの時点で、Deno KVが稼働していたのはgpc-us-east4、gpc-asia-southeast1、gcp-europe-west3、gcp-southamerica-east1、gcp-us-west2の5リージョンでした。

おそらく相当数のリクエストが、データを取得するために複数のリージョンをまたいで移動する必要があるのでしょう。これが高レイテンシの原因であり、コンピュートとストレージを同じクラウド、さらには同じデータセンター内で制御できるというDenoの優位性を事実上打ち消してしまっています。一方、UpstashはAWS上で動作しており、DenoからRedisへのすべてのリクエストはクラウドプロバイダーの境界を越えています。

結果②:単一リージョン

この仮説を検証するため、2つ目のベンチマークを実施しました。今度は単一の場所(自宅)からのみ関数を呼び出し、すべてのリクエストをフランクフルト経由で処理します。Deno KVとUpstash Redisはどちらもそこに読み取りレプリカを持っており、それぞれGCPのgcp-europe-west3、AWSのeu-central-1に該当します。

このシナリオでは両サービスとも大幅に高速化しましたが、それでもDeno KVはUpstash Redisより遅い結果となりました。以下は単一リージョンでのレイテンシです。括弧内はグローバルレイテンシとの差分です。

154msは494msに比べて確かに大幅な改善ですが、これはすべてのトラフィックが単一リージョンから来るという前提のものであり、グローバルエッジネットワークの本来の理念に反しています。グローバルなAPIを運用している場合、世界中からトラフィックが集まり、KVのデータへのアクセスが必要なすべてのリクエストがこの影響で遅延することになります。

料金体系

DenoとUpstashはどちらも主に使用量に応じた課金方式を採用しています。両社とも充実した無料枠があるため、費用をかけずに試してみることができます。

最大の違いは、Denoの料金体系が期待ほど透明性が高くない点です。コストを計算するには、リクエストのサイズがどれくらいになるかを事前に把握しておく必要があります。Upstashではすべてのリクエストが同一料金で課金されるため、この問題はありません。Upstashではデフォルトで1リクエストあたり最大1MBの読み書きが可能で、追加料金を払えばさらに拡張することもできます。

結論として、1リクエストあたり8KBを超えるデータを読み取るケースでは、Upstashの方がほぼ確実に安上がりになります。

まとめ

Deno KVは同じプラットフォーム上にあるため、使い勝手はかなり良好です。別途アカウントを管理する必要がなく、追加のセットアップも不要です。しかし、パフォーマンスとコストの面ではUpstashに遠く及びません。

また、Deno KVでできることにも限りがあります。値の設定と取得は最も一般的な操作ではありますが、それがRedisでできることのすべてではありません。Redisの活用アイデアやユースケースについては、ぜひ弊社のサンプル集をご覧ください。

本記事の内容について質問がある場合は、DiscordまたはXでお気軽にお問い合わせください。