Cloudflare K2 がパブリックベータ — Kafka を運用せずにイベントログを持つ

要約

Cloudflare は 2026-10-01、Cloudflare K2 をパブリックベータで公開しました。イベントを永続かつ順序付きのログとして保持し、プロデューサーとコンシューマーを分離するサーバーレスの基盤です。R2 オブジェクトストレージ上に構築されています。

位置づけを先に整理します。 公式は「Apache Kafka のようなブローカー運用なしで、大規模なデータ移動と長期保持を行える」としています。つまり対象は、Kafka を使いたいが運用したくないという状況です。

この状況は非常によくあります。 イベント駆動のアーキテクチャにしたい、処理を非同期に分離したい、ログを長期保持して後から再処理したい。設計としては Kafka が答えですが、Kafka の運用は専任の担当者が必要になる水準です。結果として、多くのチームはキューやデータベースのテーブルで代用します。

公式が挙げる特徴を見ます。

produce レイテンシは p99 で約1秒。 コンシューマーはバッチ単位で読みます。subscription により複数コンシューマーへ処理を分割でき、fan-out（全員に配る）・負荷分散（分けて処理する）・その併用に対応します。データはバイト列として扱うため形式を問いません。

ここで最も重要な数字は、produce の p99 約1秒です。 これは同期的な処理の途中に挟める水準ではありません。 ユーザーのリクエストを受けてイベントを書き、その完了を待ってレスポンスを返す、という作りにすると1秒待たされる可能性があります。 非同期の「投げて終わり」なら問題ありませんが、設計の前提として押さえる必要があります。

Apache Kafka クライアントのドロップイン対応はロードマップ段階で、現時点のベータでは未提供です。既存の Kafka 利用をそのまま移すことはできません。

提供条件。パブリックベータで、Workers Paid サブスクリプションのアカウントが対象。ベータ期間中は無料です。上限はアカウントあたり 10GB のストレージ、ストリームあたり 30 MB/s の produce スループットで、Discord または上限引き上げフォームから緩和を依頼できます。

ベータ後の想定価格として、produce $0.04/GB、consume $0.04/GB、保持 $0.02/GB・月が示されています。

何が変わったか

• Cloudflare K2 がパブリックベータ。イベントを永続・順序付きのログとして保持
• R2 オブジェクトストレージ上に構築。ブローカー運用が不要
• produce レイテンシは p99 で約1秒
• コンシューマーはバッチ単位で読む
• subscription で複数コンシューマーへ処理を分割（fan-out / 負荷分散 / 併用）
• データはバイト列として扱うため形式を問わない
• Apache Kafka クライアントのドロップイン対応は未提供（ロードマップ段階）
• 対象は Workers Paid。ベータ期間中は無料
• ベータの上限: アカウント 10GB のストレージ、ストリームあたり 30 MB/s の produce。緩和は Discord または申請フォーム
• ベータ後の想定価格: produce $0.04/GB、consume $0.04/GB、保持 $0.02/GB・月

業務インパクト（一般企業向け）

検討の対象になるのは、「イベント駆動にしたいが Kafka の運用ができない」組織です。

自社が該当するかの見分け方を書きます。 次のような状態があるなら該当します。処理を非同期に分けたいが、キューを自作している。 ログを長期保持していないため、障害時に再現できない。 同じデータを複数の処理が必要としているが、それぞれが元データを直接読んでいる。

とくに3番目が、イベントログで解ける典型です。 元データを複数の処理が直接読む構成は、データ側の変更が全処理に波及します。 イベントログを挟めば、データを出す側と使う側を切り離せます。

導入を検討する際の判断軸を3つに分けます。

1つ目は、produce の p99 約1秒を許容できるかです。これが最初のふるいです。

ユーザーの操作に対して同期的にイベントを書き、完了を待つ設計は成立しません。 1秒の遅延はユーザーに見えます。非同期で投げる（レスポンスを返した後にイベントを書く）なら問題ありません。

ここで設計上の注意があります。 非同期で投げると、「イベントが書けなかったときどうするか」という問題が出ます。 レスポンスは既に返しているので、ユーザーに伝えられません。リトライするか、ローカルに退避するか、失敗を受け入れるかを決める必要があります。これは K2 に限らずイベント駆動の一般的な論点ですが、p99 1秒という数字は失敗の確率が無視できないことを示唆します。

2つ目は、Kafka 互換が無いことの影響です。

既存で Kafka を使っているなら、K2 への移行はコードの書き換えを伴います。 「Kafka の運用から逃れたい」という動機で検討する場合、運用コストの削減と書き換えコストを比較することになります。ロードマップにドロップイン対応があるので、待つという選択肢も合理的です。

新規に作るなら、この論点はありません。 ただし将来 Kafka へ移る可能性を考えると、K2 への依存を抽象化しておく（自前のインターフェースを挟む）価値はあります。ベータの製品に直接依存するコードを広く書くのは避けるべきです。

3つ目は、ベータであることとコストです。

ベータ期間中は無料で、上限は 10GB / 30 MB/s です。 検証には十分ですが、本番で使うには上限緩和の申請が必要になる可能性があります。申請が通るかは事前に分かりません。

ベータ後の想定価格は読みやすいです。 produce と consume がそれぞれ $0.04/GB、保持が $0.02/GB・月。注意すべきは consume 側にも課金される点です。 fan-out（同じイベントを複数のコンシューマーが読む）を多用すると、consume の課金が読んだ回数ぶん発生します。 設計時に「何個のコンシューマーが読むか」を数えておくべきです。

実務的な導入順序を提案します。 まず既存のログ・イベントのうち1種類だけを K2 に流し、ベータ期間中に運用の感触を掴む。 保持期間を長くして、「過去のイベントを再処理する」という使い方を試す。 これができるかどうかが、イベントログの価値の中心です。最初から全イベントを移すのは、ベータ段階では過剰です。

副業・個人活用視点

個人開発では、K2 の価値は「ベータ期間中が無料」という点に集約されます。

個人でイベント駆動のアーキテクチャを試すのは、これまで難しかったです。 Kafka を自前で立てるのは重く、マネージドの Kafka は個人には高い。結果として、キューの代わりにデータベースのテーブルを使う、という実装になります。

ベータ期間が無料で、Workers Paid（月5ドル程度）の範囲で使えるなら、試す価値があります。 10GB・30 MB/s は個人のプロジェクトには十分な規模です。

具体的な使いどころを2つ挙げます。

1つ目は、処理の分離です。 たとえば Webhook を受けて重い処理をするサービスでは、受信と処理を分けないと Webhook のタイムアウトに引っかかります。 イベントログに入れて、別の Worker が処理する構成にすれば解けます。

2つ目は、ログの長期保持と再処理です。 個人のサービスで何かがおかしくなったとき、「何が起きたか分からない」のが最もつらい状況です。 イベントを永続化しておけば、後から読み直して再現できます。 保持コストが $0.02/GB・月（想定）なら、個人の規模では無視できる額です。

ただし注意点を2つ。

1つ目。produce の p99 約1秒は、個人のサービスでも体感に出ます。 レスポンスを返す前にイベントを書く設計にすると、遅いサービスになります。 非同期で投げる作りにしてください。

2つ目。ベータ後の価格が確定していません。 「想定価格」として示されているだけです。無料のうちに作り込んで、課金開始後に想定外の額になるのは、個人開発でよくある失敗です。使用量を測る仕組みを最初から入れておくべきです。

受託の文脈では、現時点では提案を控えるのが妥当です。

理由は、ベータであることと Kafka 互換が無いことの2点です。 顧客に「イベント基盤を作ります」と提案して、ベータの製品に依存した構成を作るのは、保守の引き受けが曖昧になります。 GA を待つべきです。

ただし、顧客との会話の材料としては使えます。 「イベント駆動にしたいが Kafka の運用が無理」という相談に対して、「そういう選択肢が出てきています」と伝えられるだけでも価値があります。今すぐ作らないとしても、設計の方向性を変える判断材料になります。

学習の観点では、「ログとして保持する」という発想そのものを押さえる価値があります。

キューとイベントログは似ていますが、本質が違います。 **キューは「処理したら消える」**ものです。**イベントログは「処理しても残る」**ものです。この違いが何を可能にするかというと、後から別の処理を追加して過去のデータから流し直せることです。

この性質は、実務で非常に強力です。 「この集計も取っておけばよかった」と後から気づいたとき、キューなら手遅れですが、ログなら過去に遡れます。 逆に、ログを残していなければ、気づいた時点から先しか集計できません。

設計判断としては、「消す設計」と「残す設計」のどちらを選ぶかという話になります。 残す設計はストレージコストがかかりますが、将来の選択肢を保ちます。 消す設計は安いですが、過去を取り戻せません。 どちらが正しいかは場合によりますが、この違いを意識して選んでいるかどうかは設計力の差になります。