Kafkaをゼロから作り直せるとしたら？

• KIP-1150（ディスクレス Kafka）と AutoMQ の Kafka フォークプロジェクトを通じて、クラウド最適化 Kafka をめぐる議論が活発化
• Kafka を作り直すなら、既存の パーティション構造を取り除き、キー中心のアプローチを提案
• 並行性制御 と ブローカーサイドのスキーマサポート 機能が必要な状況
• スケーラビリティ、スナップショット、マルチテナンシー といった最新システムの特性を統合する必要性も強調
• Kafka を基盤に、既存 Kafka の限界を超える 真のクラウドネイティブなイベントログシステム を構想

---

Kafkaを作り直すなら？

• 最近、KIP-1150（ディスクレス Kafka）と AutoMQ の Kafka フォークが発表され、これは S3 のようなオブジェクトストレージと Kafka を統合して、クラウド環境での弾力性向上とコスト削減を目指すもの
• 既存 Kafka の限界を超える クラウドネイティブなイベントログシステム を構想し、さまざまな改善案を提示

パーティションのない構造の提案

• クラウドのオブジェクトストレージが無限のストレージのように振る舞うため、トピックパーティション の必要性は低下する
• グローバルなメッセージ順序、または同じキーを持つメッセージの順序だけが重要な場合が多い
• ユーザーにパーティションの概念を隠し、より単純な使い勝手を提供できる

キー中心のアプローチ

• パーティションスキャンではなく、特定キーのすべてのメッセージ に高速にアクセスして再生できるようにする設計を提案
• 数百万件のエンティティレベルのストリームをサポートし、需要に応じてコンシューマ数を柔軟に調整できる
• 障害がキー単位で分離されるため、システム全体の処理効率が向上する
• イベントソーシング や アクターモデルシステム に理想的な構造

トピック階層のサポート

• Solace のようなシステムのように、メッセージペイロードの一部を構造化されたパス形式のトピック識別子へ昇格させ、パターンベースのサブスクリプションを可能にする必要がある
• ブローカーがメッセージ全体を解析しなくても、効率的な購読フィルタリングをサポートできる

並行性制御機能

• 現在の Kafka には、書き込み時の競合を防ぐ方法がない
• キーごとの楽観ロック（optimistic locking）をサポートすれば、メッセージが最新状態を見た後で書き込まれたかを検証できる
• 更新の取りこぼし問題 を防止できる

ブローカーサイドのスキーマサポート

• Kafka は現在、メッセージを単なるバイト配列として扱うため、外部のスキーマレジストリに依存している
• スキーマ整合性 を確保するため、ブローカーレベルで AsyncAPI メタデータのようなスキーマ情報を標準サポートすべきだと提案
• これにより、Apache Iceberg のようなオープンテーブルフォーマットにも容易に連携できる

スケーラビリティとプラグイン構造

• Postgres や Kubernetes のように、拡張性 と プラグイン可能性 を備えた構造を提案
• プロトコル認識プロキシ（Kroxylicious など）なしに、ブローカー側フィルターや変換を容易に実装できるべき
• レート制限、トピック暗号化、Iceberg テーブルベースのバックエンドサポートなどをプラグインとして実装できるべき

同期コミットコールバック

• 現在の Kafka は 結果整合性 しか保証しない
• プロデューサーがメッセージを送信した後、その派生データが更新されたかを即座に確認できる構造が必要だと提案
• read-your-own-writes 保証 をサポートし、Kafka を真のデータベースログとして使えるようにする

スナップショット機能

• Kafka の現在の compaction は最後のメッセージだけを残すが、これは全体状態を含む場合にのみ有効
• 変更点だけを記録する場合、キーごとにすべてのイベントを再生しなければならず、時間がかかる
• キー単位でイベントをスナップショットに要約する 論理 compaction 機能が必要

マルチテナンシーの標準サポート

• すべての現代的なデータシステムは、マルチテナンシー を前提として考えるべき
• 新規テナント環境を低コストかつ即座に作成でき、リソース、セキュリティ、アクセス制御を厳格に分離しなければならない

その他の参考事項

• 一部の機能は、S2（高カーディナリティストリーム）、Waltz（楽観ロック）、Apache Pulsar（マルチテナンシー）といったシステムですでにサポートされている
• ただし、提案されたすべての機能を同時にサポートするオープンソースシステムは存在しない
• この記事は Confluent 所属の著者による個人的見解であり、公式見解ではない
• 理論上は LSM ツリーベース のアーキテクチャが有力な選択肢になると言及している

[kaydash]

私たちはすでにそれをRedisと呼んでいます

[GN⁺]

Hacker Newsの意見

• 同意する。特定のユースケースではヘッド・オブ・ライン問題を解決する価値がある

  • しかし、現在のすべてのストリーミングシステム（または回避策）は、メッセージキーごとの ack に対して O(n^2) のコストを発生させる
  • Pulsar のようなシステムはこの機能のためによく使われる
  • この複雑さは毎日表面化するわけではないが、表面化したときには待たされることになる
  • 同僚たちと長い間この問題を研究した結果、スケーラブルなメッセージキーごとの ack をサポートするには根本的なアーキテクチャ変更が必要だという結論に達した
  • アーキテクチャにはソート済みインデックスが必要で、これは n 個のメッセージを O(n log n) で処理することを意味する
  • このテーマについてブログを書きたかったが、時間がなかった
  • メッセージキーごとの ack に依存しようとするなら、断続的な停止や遅延を予想すべきだ

• NATS.io は Kafka より使いやすく、パーティションの排除、キー基盤のストリーム対応、柔軟なトピック階層といったいくつかの点をすでに解決している

• Kafka との歩みはほとんど同じだった

  • 最初は「おお、スケーラブルな append-only ログ、素晴らしくてシンプルだ」と思った
  • しかし使ってみると、非常に複雑だと気づく

• 特定のユースケースでは、作成リクエストが ack された時点で派生データビューが更新済みであることを保証できるなら有用だろう

  • Kafka を使わず、下流のデータストアに直接書き込むべきだ
  • そうすれば、データがコミットされたことが分かり、クエリ可能なデータベースを持てる

• 6年前にこの質問をした

  • Rust で書いて WASM を活用したらどうだろう
  • 過去6年間、この作業を進めてきた
  • 過去2年間は Rust と WASM を使って Flink を構築してきた

• Kafka のオブジェクトストレージ？ それはレイテンシとコストを 10 倍にするだろう

  • Kafka は成功の犠牲者だ
  • 設計がシンプルでエレガントなので、本来想定されていなかったさまざまな用途に使われている
  • もちろん、そのようなユースケースに完璧ではない

• 「パーティションの排除」と「キー単位のストリーム」について

  • ストレージバックエンドが物理パーティショニングに依存しているなら、それは単にパーティションをキーに、キーをイベントに名前変更しているのと同じだ

• Northguard に注目すべきだ

  • これは LinkedIn による Kafka の再実装の名前で、約1週間前にストリーム処理のミートアップで発表された

• Apache Kafka の問題のうち、Apache Pulsar に切り替えることでどれだけ解決するのか気になる

  • Kafka の学習を飛ばして、いきなり Pulsar を使った
  • 私たちのユースケースによく合っている
  • 不満はない
  • ただ、なぜこれほど使う人が少ないのか不思議だ

• 有用な思考実験だ

  • Kafka を何か新しいもので置き換えるべきだという結論を示唆する回答が少ないのは興味深い
  • Kafka の最大の強みは、その上に構築された広く有用なエコシステムだ
  • それは同時に弱みでもある
  • 今日ゼロから始めるなら採用しなかったであろう設計上の決定を、いくつか維持しなければならない
  • あるいは後方互換性を捨てて、すでに持っているエコシステムを作り直さなければならない