Cloudflareが、サーバーレスの event streaming サービス「K2」を public beta として公開した。Kafka のような仕組みを連想すると分かりやすいが、K2 はクラスタ運用を前提にした製品ではなく、Cloudflare の Developer Platform 上で動く“耐久性のあるログ”として設計されている。記事の中心にあるのは、送信側と受信側の速度や稼働状況をそろえなくても、イベントを失わずに受け渡しできるようにする、という発想だ。Cloudflare はこれを自社の Pipelines 向けに必要になった機能として説明していて、単なる新製品紹介というより、同社のストレージや処理基盤の組み合わせ方を示す話でもある。
元記事がまず問題にしているのは、従来の RPC 型の構成では、送信側と受信側が同じ速度で動いていないとイベントを失いやすい、という点だ。たとえば送信元が大量のデータを吐き出したのに、受け手や下流サービスが追いつかなければ、処理しきれない分が落ちる。しかも受信側が複数あると、analytics 系と fraud detection 系のように、それぞれが独立して同じデータを読みたい場面でも扱いが難しくなる。
そこで Cloudflare は、真ん中にイベントを一時的に受け止める層を置き、producer と consumer を切り離すべきだと述べる。K2 はそのための仕組みで、イベントを送ると ordered log として保存され、consumer は自分のペースで読み出せる。読み方も一つではなく、consumer 群に読みを分担させることも、全メッセージを全 consumer に配ることもできる。Cloudflare はこれを “durable event streaming primitive” と呼び、Developer Platform 上で使えるサーバーレスの基盤として public beta で提供する。
重要なのは、K2 が単なるキューではなく、長期保持を前提にしている点だ。consumer 側が長く止まっても、accepted されたイベントは失われない。これは、処理の都合で受け取り側が止まりやすい実運用ではかなり大きい。仕組みの下では、K2 は partitioned, durable log を R2 object storage の上に実装している。Cloudflare は、R2 上に積むことで巨大なストレージ量に耐えられると説明している。記事では、これが自社の Basin Pipelines の ingestion layer として必要だったと明かしており、最初の動機は edge 上で使える durable buffer を持ちたかったからだとしている。
この発表で面白いのは、K2 が「新しい分散システムの理想像」から降ってきた話ではなく、Cloudflare が自分たちのプロダクトを作る中で困った結果として出てきたことだ。Pipelines は pull-based の stream processing engine に支えられていて、読み出し、変換、R2 への書き込みの前に、どこかがイベントを保持していなければならない。しかも Cloudflare は、Pipelines Stream に入ったイベントは絶対に落とさないと約束している。そうなると、中間の保管先も “たぶん大丈夫” では済まない。サーバーが落ちた時、consumer が遅れた時、混雑した時、それでも残っている必要がある。K2 はその要件に合わせた答えだ。
記事の書き方も、単なる機能列挙ではなく「なぜ必要だったか」を先に置いている。これは分かりやすい。イベントストリーミングの話は抽象的に聞こえやすいが、実際には「注文確定」「不正検知」「分析基盤」といった、処理の順番がずれると困る場面が多い。Cloudflare はそこに対して、中心に broker cluster を据える昔ながらの重い構成ではなく、エッジと R2 を使ってより軽く、しかも耐久性を保った方式を提示している。少なくとも狙いは、運用の手間を減らしながらデータ移動の信頼性を上げることにある。
K2 の魅力は分かりやすい。インフラを抱えずに、順序付きのイベントログを持てる。consumer が遅れても破綻しにくい。しかも R2 を土台にしているので、大量の保存に向いている。ここまではかなり筋がいい。ただし、便利さの裏で、設計の責任はアプリケーション側に少し戻ってくるはずだと思う。どの consumer にどう配るのか、どこまでを一つの stream にまとめるのか、長期保持をどう扱うのか。キューやストリームを持つと、今度は「イベントの粒度」と「再処理のしやすさ」をどう設計するかが効いてくる。
Cloudflare は「独立した reader が自分のペースで consume できる」と書いているが、これは裏返すと、遅延や再読み込みの扱いをちゃんと決めないと、かえって整合性の悩みが増えるとも言える。特に analytics と fraud detection のように、同じイベントを見ても要求が違う consumer が並ぶと、順序保証と分配の設計は難しい。K2 はその難しさを消すのではなく、逃がし先を作る製品だと見るほうが自然だろう。
K2 を R2 object storage の上に作ったという点は、Cloudflare らしさが強い。CDN や edge の会社が、ネットワークの近くでイベントを受けて、耐久保管も自前のストレージ層で面倒を見る。アーキテクチャとしてはきれいだし、既存のプロダクト群ともつながりやすい。一方で、これはかなり野心的でもあると思う。イベントストリーミングの世界では、性能だけでなく、再生、順序、分割、保持、障害復旧が全部絡む。そこを object storage ベースでやる以上、Cloudflare は単に「保管できる」だけでなく、「ストリーミングとして自然に使える」体験を作らないといけない。
だからこの発表は、機能追加というより基盤の方向性の表明に近い。Cloudflare は、Workers や R2、Pipelines をそれぞれ別物として売るのではなく、edge で受けて、保持して、処理して、必要なら長く残す、という流れを一つにつなげたいのだと思う。K2 はその中継点になる。うまくいけば、サーバーレスでイベント駆動のシステムを組むハードルはかなり下がるはずだ。
この手のサービスは、派手な新機能というより、事故が起きた時に効いてくる。売上の注文、決済、監査ログ、不正検知、配信イベント。落ちると困るデータほど、こうした中間ストレージが必要になる。Cloudflare が K2 を public beta で出したのは、その需要がある程度見えているからだろう。しかも「producer と consumer を edge で分離する」と言っている点から、単なるバックエンド基盤ではなく、低遅延の入口として使う想定も感じる。
ただ、導入の判断は慎重になるはずだ。長期保持がある分、ログの扱いは一度決めると後で変えにくい。しかも public beta なので、完成品というより試用段階に近い。とはいえ、Cloudflare が自分たちの Pipelines のために必要として作った、という筋はかなり強い。机上の理想ではなく、実際に「落としたくないイベント」をどう捌くかから逆算しているからだ。そこにこの発表の説得力がある。
