QCon London 2026：Tansu.ioの紹介 - リーン運用のためのKafka再考
Peter MorganがQCon Londonで発表したTansu.ioは、Kafka互換でステートレス・リーダーレス、ゼロスケール可能なオープンソースブローカーであり、Rust製で20MBのRAM使用、10ミリ秒起動を実現している。
キーポイント
コアアーキテクチャ
Kafka互換のステートレス・リーダーレスブローカーで、ゼロスケールが可能。プラグ可能なストレージ（S3、SQLite、Postgres）をサポート。
技術仕様と性能
Rust言語で実装され、20MBのRAM使用量と10ミリ秒の起動時間を実現。ブローカー側でのスキーマ検証機能を備える。
データ連携機能
IcebergとDelta Lakeへの直接書き込みをサポートし、現代的なデータレイクとの統合を容易にする。
運用効率化
リーンオペレーションを実現する設計で、従来のKafka運用の複雑さを大幅に軽減する。
影響分析・編集コメントを表示
影響分析
この技術は、ストリーミングデータ処理の運用コストと複雑さを大幅に削減する可能性があり、特にリソース制約のある環境やクラウドネイティブなマイクロサービスアーキテクチャにおいてゲームチェンジャーとなり得る。既存のKafkaエコシステムとの互換性を保ちながら、より軽量で効率的な代替ソリューションを提供することで、業界の標準的なアプローチに挑戦する。
編集コメント
Kafkaの運用上の課題（リソース消費、運用複雑さ）に真正面から取り組む画期的なアプローチ。特に「ゼロスケール」と「10ミリ秒起動」は、サーバーレス環境やエッジコンピューティングでの応用可能性を大きく広げる。
QCon London 2026において、ピーター・モーガンは、過去2年間一人で開発してきたオープンソースのApache Kafka互換メッセージングブローカー「Tansu」を紹介しました。その提案はシンプルかつ意図的に挑発的なものでした。Kafkaのプロトコルを維持しつつ、レプリケーションやリーダー選出、永続的なブローカーの状態といった他のすべての要素を捨てて、耐久性を外部ストレージに完全に委譲するステートレスなブローカーで置き換えるとしたらどうなるでしょうか。
DisneyのMagicBand用プラットフォームや大規模なベッティングシステムなど、Kafkaの上にイベント駆動型システムを10年以上構築してきた経験を持つモーガンは、TansuとKafkaを分ける中核的な前提から話を始めました。Kafkaはブローカー間でのデータレプリケーションによって耐障害性を確保しますが、Tansuはストレージがすでに耐久性と耐障害性を持っていると仮定し、その前提からすべてを構築します。
このアプローチには実用的な大きな影響があります。モーガンはKafkaのブローカーを「ペット」と呼んでいます。それらは固有のIDを持ち、広範な設定が必要で、4ギガバイトのヒープメモリを24時間365日稼働させます。スケールダウンは極めて稀であり、彼は聴衆に実際にそれをやっている人がいるかと尋ねました。すると一人が手を挙げました。一方、Tansuのブローカーは「家畜」です。状態を持たず、リーダーも存在せず、約20メガバイトのレジデントメモリで動作し、ゼロからスケールアップするまでおよそ10ミリ秒しかかかりません。モーガンは冗談めかして、「Kafkaの第一法則は、稼働していることを口に出さないことだ」と述べました。なぜなら、部署内の誰もがすぐに自分のクラスターにトピックを要求してくるからです。
ライブデモでは、モーガンが Tansu を Fly.io にデプロイしました。これはゼロから構築したコンテナイメージ内の 40 メガバイトの静的リンクされたバイナリであり、オペレーティングシステムは含まれておらず、バイナリと一部の SSL 証明書のみです。Fly のプロキシを使用してスケール・トゥ・ゼロ（スケール・トゥ・ゼロ）を設定し、標準的な Kafka CLI ツールでトピックを作成し、メッセージを生成しました。その後、ブローカーを停止しましたが、コンシューマーが接続するとブローカーは自動的に起動します。このデプロイ全体は 256 メガバイトのマシン上で実行されました。
ストレージアーキテクチャこそが Tansu の面白さです。単一の組み込みストレージエンジンではなく、URL パラメータで選択可能なプラグイン形式のバックエンドを提供しています。ディスクレス動作には S3（または Tigris や R2 などの互換ストア）を、テスト実行間で状態をリセットするために単一ファイルをコピーしたい開発環境には SQLite を、ストリーミングデータを直接データベースに格納したいチームには Postgres を使用します。モーガンは自分の好みを率直に明かしました。Postgres です。プロジェクトの元々の動機について彼は説明しました。データが Kafka トピックを流れて最終的にはデータベースに到達する様子を見ており、なぜ中間ステップが必要なのか疑問に思ったことがきっかけでした。
Postgres の統合は、単なる保存先としての利用を超えています。Morgan は、Tansu が当初レコードの書き込みに逐次的な INSERT 文を使用していたが、各実行ごとに往復応答が必要となるためボトルネックになっていたことを示しました。これを Postgres の COPY FROM プロトコルに置き換え、個別の承認を待たずにストリーミングでデータベースへ行を書き込むようにしました。これは、単一の COPY FROM セットアップ、COPY DATA メッセージのストリーム、そして最後に COPY DONE を行うという構成です。その結果、バッチ取り込みにおけるスループットが大幅に向上します。また、Tansu における produce は単なる INSERT（または COPY）であり、fetch は単なる SELECT に過ぎないため、トランザショナルアウトボックスパターンは不要になります。つまり、Tansu が提供するストアドプロシージャを用いて、ビジネスデータの更新とメッセージのキューイングを同じデータベーストランザクション内で原子的に実行できるようになるのです。
スキーマ検証もまた、Tansu が Kafka と異なる点の一つです。標準的な Kafka では、スキーマの強制は別個のレジストリに依存しており、クライアント側ではオプションとなっています。一方、Tansu では、トピックに Avro、JSON、または Protobuf のスキーマが定義されている場合、ブローカーが書き込み前にすべてのレコードを検証します。無効なデータはクライアントではなくブローカーで拒否されます。Morgan はこれを意図的なトレードオフとして説明しました。ブローカーが各レコードをデコンプレッションして検証する必要があるため、Kafka のパススルー方式よりも低速になりますが、どのクライアントから生産されたデータであっても、データの整合性が保証されるのです。
このブローカー側のスキーマ認識機能により、Tansu は Kafka では不可能なことを実現しています。それは検証済みのデータを直接オープンテーブルフォーマットに書き込むことです。トピックに Protobuf スキーマがある場合、Tansu は自動的にレコードを Apache Iceberg、Delta Lake、または Parquet に書き込み、テーブルを作成し、変更に応じてスキーマを更新し、メタデータを処理します。さらにモーガン氏は次のようにコメントしています。
実際には AVRO、JSON、Protobuf のすべてに対応しています。Protobuf が「最良」なのは、後方互換性のあるスキーマ変更のための組み込み機構を持っているためです（デモで使用したもの）。しかし、これらすべてを Parquet/Iceberg/Delta として書き込むことができます。
"sink topic"設定では通常のストレージを完全にスキップし、オープンテーブルフォーマットへの書き込みのみを行い、Tansu を Kafka 互換プロデューサーから分析準備完了データへの直接パイプラインに変えます。
プロキシとして、Tansu は既存の Kafka クラスターの前に配置され、控えめなハードウェア（Mac Mini の 13 メガバイトの RAM）で秒間 60,000 レコードをプロキシし、P99 レイテンシはサブミリ秒を実現します。
モーガン氏は欠点についても率直に述べています。SSL サポートは存在しますが再設計中です。スロットリングやアクセス制御リストはまだありません。S3 上でのコンパクションやメッセージ削除も実装されていません。共有グループの計画もありません。このプロジェクトは非同期 Rust で書かれており、Apache ライセンスの下で公開され、積極的にコントリビューターを募集しています。Fly.io デプロイメントデモを含むすべての例は GitHub で利用可能です。
著者について
Steef-Jan Wiggers
Steef-Jan Wiggins は、InfoQ のシニアクラウド編集者の一人であり、オランダの VGZ でドメインアーキテクトとして勤務しています。彼の現在の技術的専門分野は、統合プラットフォームの実装、Azure DevOps、AI、および Azure プラットフォームソリューションアーキテクチャに焦点を当てています。Steef-Jan は会議やユーザーグループで定期的に登壇し、InfoQ 向けに記事も執筆しています。さらに、マイクロソフトからは過去 16 年間にわたり Microsoft Azure MVP に認定されています。
Show moreShow less
原文を表示
At QCon London 2026, Peter Morgan introduced Tansu, an open-source, Apache Kafka-compatible messaging broker he has been building solo for the past two years. The pitch was simple and deliberately provocative: what if you kept Kafka's protocol, however, threw out everything else, the replication, the leader elections, the permanent broker state, and replaced it with stateless brokers that delegate durability entirely to external storage?
Morgan, who has spent over a decade building event-driven systems on top of Kafka, including platforms for Disney's MagicBand and large-scale betting systems, opened with the core assumption that separates Tansu from Kafka. Kafka achieves resilience by replicating data between brokers. Tansu assumes that storage is already durable and resilient, and builds everything from that premise.
The practical consequences are significant. Kafka brokers are what Morgan called "pets." They have identities, need extensive configuration, run 24/7 with four-gigabyte heaps, and scaling them down is so rare that he asked the audience whether anyone actually does it. One hand went up. Tansu brokers are "cattle." They carry no state, have no leaders, run in about twenty megabytes of resident memory, and can scale to zero and back up in roughly ten milliseconds. Morgan joked that the first rule of Kafka is not to mention you're running it, because everyone in your department will immediately want topics on your cluster.
In a live demo, Morgan deployed Tansu to Fly.io as a forty-megabyte statically linked binary in a from-scratch container image, no operating system, just the binary and some SSL certificates. He configured it to scale to zero using Fly's proxy, created a topic with standard Kafka CLI tools, produced a message, killed the broker, and then consumed the message. The broker woke up automatically when the consumer connected. The entire deployment ran on a 256MB machine.
The storage architecture is where Tansu gets interesting. Rather than a single built-in storage engine, it offers pluggable backends selected via a URL parameter: S3 (or compatible stores like Tigris and R2) for diskless operation, SQLite for development environments where you want to copy a single file to reset state between test runs, and Postgres for teams that want their streaming data to land directly in a database. Morgan was candid about his favourite: Postgres. The original motivation for the project, he explained, was watching data flow through Kafka topics only to end up in a database anyway, and wondering why the intermediate step was necessary.
The Postgres integration goes beyond using it as a store. Morgan showed how Tansu originally used sequential INSERT statements to write records, which became a bottleneck because each execution requires a round-trip response. He replaced this with Postgres's COPY FROM protocol, which streams rows into the database without waiting for individual acknowledgements. A single COPY FROM setup, a stream of COPY DATA messages, and one COPY DONE at the end. The result is substantially higher throughput for batch ingestion. And because a produce in Tansu is just an INSERT (or COPY) and a fetch is just a SELECT, the transactional outbox pattern simply disappears: you can atomically update business data and queue a message in the same database transaction using a stored procedure that Tansu provides.
Schema validation is another area where Tansu diverges from Kafka. In standard Kafka, schema enforcement relies on a separate registry and is optional at the client. In Tansu, if a topic has a schema Avro, JSON, or Protobuf, the broker validates every record before writing it. Invalid data gets rejected at the broker, not the client. Morgan described this as a deliberate trade-off: it's slower than Kafka's pass-through approach because the broker must decompress and validate each record, but it guarantees data consistency regardless of which client produces.
That broker-side schema awareness also enables something Tansu does that Kafka cannot: writing validated data directly into open table formats. If a topic has a Protobuf schema, Tansu can automatically write records to Apache Iceberg, Delta Lake, or Parquet, creating tables, updating schemas on change, and handling metadata. In addition, Morgan comments:
It actually works for AVRO, JSON, and Protobuf. Protobuf is the "best" because it has a built-in mechanism for backwards-compatible schema changes (and the one I used in the demo), but they can all be written as Parquet/Iceberg/Delta.
A "sink topic" configuration skips the normal storage entirely and writes exclusively to the open table format, turning Tansu into a direct pipeline from Kafka-compatible producers to analytics-ready data.
As a proxy, Tansu can also sit in front of an existing Kafka cluster, proxying requests at 60,000 records per second with sub-millisecond P99 latency on modest hardware, 13 megabytes of RAM on a Mac Mini.
Morgan was upfront about the gaps. SSL support is present but being reworked. There's no throttling or access control lists yet. Compaction and message deletion aren't implemented on S3. Share groups are not planned. The project is written in asynchronous Rust, Apache-licensed, and actively looking for contributors. All examples, including the Fly.io deployment demo, are available on GitHub.
About the Author
Steef-Jan Wiggers
Steef-Jan Wiggers is one of InfoQ's senior cloud editors and works as a Domain Architect at VGZ in the Netherlands. His current technical expertise focuses on implementing integration platforms, Azure DevOps, AI, and Azure Platform Solution Architectures. Steef-Jan is a regular speaker at conferences and user groups and writes for InfoQ. Furthermore, Microsoft has recognized him as a Microsoft Azure MVP for the past sixteen years.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み