エッジのサーバーレスデータベースとしてのUpstash――Cloudflare Workers時代の選択肢

Upstashは、AWS Lambda関数にとって最良のデータベースとなることをミッションに、その歩みを始めました。その過程で、私たちはサーバーレス関数を構築するためのもう一つの優れた選択肢――Cloudflare Workersを発見しました。Cloudflare Workersは、世界中どこでも低レイテンシを実現しながら、低コストでコールドスタートもないという魅力的な製品です。しかし、AWS Lambdaと比較すると多くの制約があり、それによって利用できるデータベースの選択肢はさらに狭まります。私たちはこれを好機と捉え、「CF Workersはステートレスだが、データはどこに置くべきか?」という問いへの最適解としてUpstashを位置づけました。

Cloudflare Workers環境における課題

アクセシビリティ

Cloudflare Workersは、AWSよりも閉じた実行環境です。同じリージョン内に独自のデータベースを構築し、VPC経由でアクセスするといったことができません。そのため、Workers関数から直接データベースへアクセスする必要があります。さらに、Cloudflare WorkersはV8 Isolatesをランタイムとして採用しており、TCP接続が許可されていません。したがって、データベースはHTTP経由でアクセスできることが必須条件となります。

グローバルレプリケーション

Workersの最大の強みは、世界中どこにでもデプロイできる点にあります。関数そのものは世界中から低レイテンシでアクセスできるのに、データベースへのアクセスに数百ミリ秒もかかっていては本末転倒です。データベースは、関数が実行される場所の近くに存在すべきです。これを実現するのが、複数のリージョン・大陸へのデータレプリケーションです。

低レイテンシ

開発者がエッジコンピューティングを選ぶ理由は、どこでも低レイテンシを得られるからです。データベースがボトルネックになっては元も子もありません。Redisのようなインメモリデータベースであれば、サブミリ秒の応答速度を提供できます。

Upstashの歩み

REST APIの誕生

UpstashはネイティブなRedis APIサポートとともにサービスを開始しました。すべてのRedisクライアントに対応しており、既存のRedisアプリケーションには最適な選択肢でした。しかし間もなく、サーバーレス関数上で接続の問題を抱えるユーザーが現れ始めます。さらに、Cloudflare Workersからはアクセスできないという課題もありました。

そこで私たちはまずGraphQL APIを実装しました。しかし、プロキシ層によるパフォーマンスオーバーヘッドがネックとなり、満足のいくものではありませんでした。加えて、GraphQLはRedisコマンドを実行する手段としても直感的ではありません。そこで、オーバーヘッドを最小限に抑えるべく、データベースエンジン内部にRESTサーバーを直接組み込むことにしました。RESTの方がRedisとの相性が良いと判断したのです。実際、REST APIを公開すると、Cloudflare WorkersやWebAssemblyからRedisへアクセスしたい開発者の間で大きな支持を集めました。

エッジキャッシング

REST APIのおかげでWorkersからUpstashへアクセスできるようになりましたが、レイテンシはまだ理想には程遠い状態でした。一部の開発者は、Cloudflare自身のキャッシュ機能を使ってRedisレスポンスをキャッシュしようとしましたが、これはかなり複雑なソリューションでした。そもそもRedis自体が非常に高速なため、別の場所で「Redisをキャッシュする」という発想には違和感があります。

そこで私たちは、すべてのエッジロケーションでRedis RESTレスポンスをキャッシュする「エッジキャッシング」機能を構築しました。CDNプロバイダーを活用してRedisレスポンスをキャッシュすることで、エッジレイテンシが大幅に改善され、最大80%のパフォーマンス向上を達成しています。

グローバルデータベース

エッジキャッシングはグローバルなレイテンシ問題に対する優れたソリューションですが、ユースケースによってはいくつかの弱点があります。

第一に、キャッシュ無効化(パージ)に対応していない点です。キャッシュの有効期限が30秒に設定されている場合、クライアントが最大30秒間、古いデータを読み取る可能性があります。多くのWebユースケースでは許容範囲ですが、そうではないケースも存在します。第二に、エッジキャッシングはREST API限定の機能であり、Redisクライアントはその恩恵を受けられません。

そこで私たちは、データを複数リージョンにレプリケートする新しいデータベースタイプの設計に着手しました。高可用性を保ちながら十分な一貫性を実現する設計は容易ではありませんでしたが、現在Upstashは、データを5つの異なるAWSリージョン(北米東部・西部、ヨーロッパ、アジア、南米)にレプリケートするグローバルデータベースを提供しています。

グローバルデータベースはキャッシュではないため、キャッシュ無効化の問題を抱えません。書き込みはすべてのレプリカへ即座に反映されます。パフォーマンスと可用性を優先し、結果整合性(eventual consistency)モデルを採用しています。

エッジキャッシング vs グローバルデータベース(あるいは両方)

エッジソリューション用のキャッシュが欲しいだけであれば、エッジキャッシングが有力な選択肢です。一方、書き込み時にキャッシュを即座に無効化したいのであれば、グローバルデータベースを選ぶべきです。キャッシング用途にとどまらず、グローバルデータベースは高可用性のグローバルデータストアとしても活用できます。なお、エッジキャッシングはREST呼び出し限定の機能である点にも注意してください。Redisクライアントを使用している場合、エッジで低レイテンシを実現できる唯一の選択肢はグローバルデータベースです。

エッジキャッシングとグローバルデータベースは、どちらも読み取りレイテンシの最小化を目的に設計されています。もしワークロードの90%が書き込みであるなら、シングルリージョン構成の方が合理的です。書き込みレイテンシはマルチリージョンでもシングルリージョンでも変わりませんが、グローバル構成ではコストが5倍になります。

エッジキャッシングが有効な場合、Upstashは最初のリクエストをオリジンから取得し、それをエッジにキャッシュします。オリジンが遠ければ初回のレイテンシは高くなります。あらゆる状況で最高のレイテンシを求めるなら、グローバルデータベース上でエッジキャッシングを有効化し、両者を組み合わせるのがおすすめです。

エッジキャッシングとグローバルデータベースのレイテンシを比較できるベンチマークアプリケーションも公開されているので、ぜひ参考にしてください。

今後の展望

エッジにおけるUpstashをさらに進化させるため、以下のテーマに取り組んでいます。

• 書き込みの低レイテンシ:現在のグローバルデータベースは、シングルリーダーアーキテクチャによって読み取りレイテンシを最適化する設計です。これで大多数のユースケースはカバーできると考えていますが、フィードバックや新たなユースケースの要望に応じて、書き込みも低レイテンシ化するアーキテクチャの検討も可能です。
• Kafkaサポート:近いうちに、Redisに加えてKafkaの提供を開始する予定です。Kafkaが使えるようになれば、クリックストリーム分析や、サーバーレス/エッジ関数からKafkaへのログ送信など、エッジでの新たなユースケースが広がります。

私たちは皆様のフィードバックを頼りに、Upstashの改善と開発を続けていきます。TwitterやDiscordで、ぜひご意見をお聞かせください。