Cloudflare D1 がヤバい
まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。
Announcing D1: our first SQL database
Cloudflare D1 = Edge SQLite
Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。
このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。
Durable Objects は CDN 上の Actor モデルを構築できます。この Actor は強整合で、アクセスが多い地域に実体が移動するストレージと説明されています。
Cloudflare Workers の Durable Objects について
↑の記事で Durable Objects について翻訳したとき、この節が気になってました。
私たちは、 Durable Objects を分散システムを構築するための低レベルのプリミティブと考えています。上記のようなアプリケーションの中には、オブジェクトを直接使用して調整層を実装したり、唯一のストレージ層として使用することができるものもあります。
しかし、現在の Durable Objects は完全なデータベースソリューションではありません。各オブジェクトは独自のデータしか見ることができません。複数のオブジェクトにまたがってクエリやトランザクションを実行するためには、アプリケーションはいくつかの余分な作業を行う必要があります。
つまり、すべての大規模な分散型データベース（リレーショナル、ドキュメント、グラフなど）は、低レベルで構成されています。大規模な分散データベースでは、低レベルでは、全体のデータの一部を格納する「チャンク」や「シャード」で構成されています。分散データベースの仕事は、チャンク間の調整です。
私たちは、各「チャンク」を耐久性のあるオブジェクトとして保存するエッジデータベースの未来を見ています。そうすることで、リージョンやホームロケーションを持たず、完全に分散したエッジで動作するデータベースを構築することが可能になるでしょう。このようなデータベースは、私たちが構築する必要はありません。誰でもDurable Objectsの上に構築することができます。耐久性のあるオブジェクトは、エッジ ストレージの旅の第一歩に過ぎません。
これがまさに今回の D1 であると思われます。
おそらくですが、 Durable Objects と同じ仕組みの上で、CDN Edge 上でホットスポットを特定し、マスターノードを CDN Edge 上で動的に移動する仕組みを備えていると思われます。
D1 なら個人でも大規模クラウドに安価に勝てる(かもしれない)
D1 の最大の特長は、おそらくコストです。CDN Edge 同士で replicate することで、今まで Spanner や Cockroach DB などで実現していた地理的分散を安価に手に入れることができます。それらが Cloudflare の基盤の上で最適化されています。
ところで、最近こういう記事がバズってました
対象や規模感によりますが、Web 系の業務で使うクラウドは、高価な機能をふんだんに使って大規模にスケールするものが採用されることが多いです。
Spanner や Aurora Serverless, Kubernetes 等はホットスタンバイするためにノードが起きっぱなしで、そのため最低でも 月6000円〜みたいなプライシングが多いです。もちろん、使うとすぐに値段が爆発し、個人で耐えられるものではなくなっていきます。
この状況はあまり健全ではないと思っていて、静的サイトに関しては Netlify や Cloudflare Pages, Netilfy, Firebase Hosting で安くつくものの、DB はどうしてもホビーなものだと価格・スケールに難がある、という状態でした。
そんな中にわかに話題になったのが、sqlite を replicate する litestream で、これで sqlite インスタンスを s3 同士で replicate することで、安く済ませられないか？という試みが自分の周辺で試行されはじめてました。
自分も cloudflare r2 + litestream でこの構成を試せないか考えてたんですが、 cloudflare d1 はそれをさらに最適化したものになります。やる前に出てよかった…
ボトルネックの予想
恐らく、このアーキテクチャは sqlite のデータ量が増えるにつれて、replicate 速度とクエリ実行のための scan がボトルネックになります。
なので、恐らくそこまで多くない動的なデータを、高速に CDN に展開されるのに向いていると思われます。
大規模に使う場合、ホットスポットが予想して、アクセスが少ないものは他のストレージに退避しつつ、部分的に乗せる、みたいな工夫が必要になるかもしれません。
ただこれも D1 で sqlite テーブル単位の分散ができるようになったら解決するかもしれません。
やるぞ
というわけで、ここまで触らず適当にスペックだけ見て書いてきました。自分はこれから触ってきます。
みなさんもベンチとるなどして触ってみましょう！
Discussion