従来のリモートプロシージャコール（RPC）アーキテクチャには、中核的な課題が存在します。プロデューサーとコンシューマーは、規模と時間の両方で整合していなければなりません。プロデューサーがコンシューマーが処理できる以上のデータを送信したり、コンシューマーまたはダウンストリームサービスが利用できなくなったりすると、イベントはドロップされます。この問題は、データを独立して処理する必要がある複数のコンシューマーがいる場合にさらに複雑になります。例えば、eコマースのバックエンドは、トランザクションが完了したときにイベントを発行し、それを分析システムと不正検出サービスが読み取る必要があります。この問題は、プロデューサーとコンシューマーを分離することで解決できます。つまり、書き込みを吸収し、独立したリーダーが自分のペースで消費できるようにするサービスを中間に挿入します。
本日、この問題を解決するために、Cloudflare K2 をパブリックベータ版として発表します。K2 は、Developer Platform 上の耐久性のあるイベントストリーミングプリミティブです。イベントを K2 ストリームに送信すると、ストリームはそれらを順序付けられたログとして保存します。コンシューマーは、例えば、複数のコンシューマーに読み取りを分割したり、すべてのメッセージをすべてのコンシューマーに配信したりするなど、さまざまな方法でそれらを読み取ることができます。完全にサーバーレスで、膨大な量のデータにスケーリングでき、長期保存をサポートしているため、コンシューマーが長時間ダウンしてもデータは失われません。
内部では、K2 は R2 オブジェクトストレージ上にパーティション化された耐久性のあるログを実装しており、これによりストレージの巨大なボリュームにスケーリングできます。開始する準備ができたら、こちらのガイドに従って数秒で最初のストリームを作成できます。K2 を最初に構築したのは、エッジに耐久性のあるバッファが必要だったからであり、当初は Basin Pipelines の取り込みレイヤーとして機能するためでした。当社の独自のアーキテクチャにより、Apache Kafka のような従来の分散システムソフトウェアを実行できないことが多く、これらのシステムの構築と運用の方法を再考する必要があります。
K2 となった耐久性のあるバッファリングシステムを設計するにあたり、当社はすでに持っている強力な状態プリミティブである R2 に依存することを決定しました。R2 のようなオブジェクトストレージシステムは、非常に耐久性の高いストレージ（11 ナイン！）と強力な一貫性のある API を組み合わせています。二次的な利点は、コンピュートとストレージを分離することであり、それぞれを独立してスケーリングできることを意味します。これにより、低コストで膨大な量の履歴データを保存できます。
出典: Hacker News · 要約：HeadlinesBriefing