Kafka Diskless Topics(KIP-1150)とは — クロスAZコストと引き換えるレイテンシ、そしてまだ出荷されていない機能

はじめに — Tiered Storageが解けなかったコスト
承認されたこと、されなかったこと
コスト計算の出発点 — クロスAZトラフィック
アーキテクチャ — WAL SegmentとDiskless Coordinator
レイテンシの請求書 — KIP-1163自身が書き残した予算
ベンダーの数字をどう読むか
静かに壊れるもの
では、あなたは待つべきか
残された道
おわりに
参考資料

はじめに — Tiered Storageが解けなかったコスト

Kafkaをクラウドで運用したことがある人は、請求書のどの行が痛むか知っています。ディスクではありません。ネットワークです。

KIP-405 Tiered Storageはすでに広く使われており、非アクティブなセグメントをオブジェクトストレージへ落とすことで保管コストを大きく下げました。ところがKIP-1150の動機セクションが突くのはまさにここです — Tiered Storageは「アクティブセグメントのレプリケーションと耐久性のある保存に対する必要性を排除せず、それが今日のハイパースケーラーにおいてKafka運用者にとって最大のインフラコストである」というのです。

なぜならKafkaのレプリケーションはブローカー対ブローカーの通信であり、アベイラビリティゾーン(AZ)をまたいで配置されたクラスタでは、そのトラフィックはすべてクロスAZになるからです。データをどれだけ長く保持するかとは無関係に、入ってくるすべてのバイトがレプリケーションのファンアウトの数だけAZ境界を越えます。Tiered Storageは「古いデータ」を安くしましたが、「今入ってくるデータ」を安くすることはできませんでした。

2026年3月2日、Apache Kafkaコミュニティはこの問題を正面から狙った提案を承認しました。KIP-1150: Diskless Topicsです。

承認されたこと、されなかったこと

まず誤解を解いておきます。承認は出荷ではありません。

KIP-1150本文のProposed Changesセクションはこう始まります — "This KIP will not require any changes to the codebase or documentation upon acceptance."(このKIPは承認されてもコードベースやドキュメントへの変更を要求しない)。承認してもコードは一行も変わらないという意味です。続く文はさらに明確です。このKIPを承認することでコミュニティは「この機能の必要性とエンドユーザー要件について合意に達するのであって、具体的な実装の詳細について合意するのではない」としています。

Kafkaコミュニティはこれを「メタKIP」あるいは「動機付けKIP」と呼びます。前例があります。ZooKeeperを取り除きKRaftを導入したKIP-500も同じやり方でした — 大きな方向性を先に合意し、実際の設計は後続のKIPに分割するというものです。

そこで、現状を正確に書き出すとこうなります。

KIP-1150: Diskless Topics       Accepted (2026-03-02)   <- 方向性のみ承認
  ├─ KIP-1163: Diskless Core         Under Discussion    <- 実際の設計
  ├─ KIP-1164: Diskless Coordinator  Under Discussion    <- 実際の設計
  └─ KIP-1165: Object Compaction     Under Discussion (Re-Opened)

Apache Kafka 最新リリース: 4.3.1 (2026-06-25 released) -> Disklessなし

つまり2026年7月現在、Diskless TopicsはどのKafkaリリースにも含まれていません。目標リリースバージョンも公表されていません。方向性に合意しただけです。

時間感覚のための参考として一つ付け加えると — AivenのJosep Pratが承認後の振り返り記事で明かしたところによると、KIP-405 Tiered Storageは最初の草案から承認まで2年3か月かかりました(2018年12月14日 → 2021年2月18日)。そしてそれは「承認まで」の時間でした。KIP-1150自体は2025年4月16日に最初のバージョンが公開されてから約10か月半で承認されましたが、それは分割戦略のおかげで早かったのであって、実装が早まったわけではありません。同じ記事の表現を借りれば、「KIP-1150が承認されたことで、私たちは道筋を描き、ベースキャンプに到達した。これから登攀が始まる」ということです。

コスト計算の出発点 — クロスAZトラフィック

KIP-1150の動機セクションが示す数字はちょうど3行だけです。そのまま引用します。

AWSはGiBあたり$0.02を課金する(AWSリージョン内データ転送料金)
Google CloudはGiBあたり$0.01を課金する(GCPネットワーク料金)
Azureはクロスゾーントラフィックを課金しない

最後の行が重要です。3大クラウドのうち2つしかクロスAZトラフィックに課金していません。Azureで運用しているなら、Disklessの中核をなす経済的合理性は成立しません。 KIPもこの点を認めたうえで、ネットワークコストを除いてもなお残るメリットを別途挙げています — ディスクに保存しブローカー間でリバランスすべきデータが減ることでクラスタの拡張性が良くなり、オブジェクトストレージがローカルディスクより耐久性に優れるというものです。誠実な記述ですが、コスト削減が主な動機だったチームならAzureでは計算をやり直す必要があります。

Disklessがなくすと約束している項目は二つです。

レプリケーションによるゾーン間データ転送コストの排除
プロデューサーからのゾーン間イングレス、コンシューマーへのゾーン間イーグレスコストの排除

二つ目が目を引きます。レプリケーショントラフィックだけでなくクライアントトラフィックまで狙っています。どう実現するのかはアーキテクチャを見る必要があります。

アーキテクチャ — WAL SegmentとDiskless Coordinator

KIP-1163: Diskless Coreが実際の設計を担っています。中心となる転換は一つだけです — データとメタデータを分離する。

クラシックトピックでProduceリクエストを受けたブローカーは6つのことを行います。データ検証、オフセット・タイムスタンプの割り当て、バッチデータへのオフセット注入、耐久性のあるストレージへの書き込み、レプリケーション完了の待機、応答の返却です。Disklessでは、このうちオフセット・タイムスタンプの割り当てが「Diskless Coordinator」に移り、オフセットの注入は各レプリカが担当します。

Produceパスはこう流れます。

1. プロデューサーが任意のブローカーにProduceリクエストを送る(リーダーである必要はない)
2. ブローカーがリクエストをバッファに積む(サイズまたは時間の上限まで)
3. 上限に達すると、ブローカーが一つのWAL Segmentを作る
   -> 複数のトピック/パーティションのバッチが一つのオブジェクトに混ざって入る
4. WAL Segmentをオブジェクトストレージにアップロード(ここで耐久性を確保)
5. ブローカーがDiskless Coordinatorにbatch coordinatesをコミットする
6. Coordinatorがオフセットを割り当て、座標を永続化し、応答する
7. ブローカーが該当オブジェクトに束ねられたすべてのProduceリクエストに応答する

ここで一つの設計判断がコストに直接効いてきます。WAL Segmentはクラシックなセグメントと異なり、複数パーティションのデータを一つのオブジェクトに混ぜて格納します。KIPの表現では「オブジェクトストレージの書き込み操作コストを合理的な水準に保つために必要」だとされています。パーティションごとに別々のオブジェクトを作ると、PUTリクエスト数がパーティション数に比例して爆発するからです。その代わり代償も伴います — 一つのオブジェクトの中に複数トピックのデータが混在するため、物理削除が難しくなります。KIP-1163はこの問題を論理削除で解決し、コンプライアンス目的の物理削除のタイミングを「最長のロールタイムより少し長い」時点だと正直に規定しています。

「"ディスクがない"という言葉の実際の意味」も、KIP-1150自身が整理しています。Disklessはブローカーのディスクをユーザーデータの主たる耐久性ストレージとして使わないという意味であって、ディスクが消えるという意味ではありません。KRaftメタデータ、バッチメタデータ、Tiered Storageへコピー中のデータ、コンシューマーへのサービングのためのキャッシュは依然としてディスクを使います。KIPの一文が気が利いています — 「Disklessが『ディスクなし』に対して持つ関係は、Serverlessが『サーバーなし』に対して持つ関係と同じである」。

メタデータ側であるKIP-1164: Diskless Coordinatorには興味深い実装上の選択があります。Coordinatorの状態を__diskless_metadataという新しい内部トピックに保存し、このトピックを複数パーティションにシャーディングしてコーディネーターを複数作ります。そしてローカル状態のマテリアライズにはSQLiteを使います。理由が明記されています — 他のコーディネーターと異なり、DCの状態サイズは「数百メガバイト、あるいはギガバイトにさえ」達すると見込まれ、すべてをメモリに載せるのは非現実的だからです。Kafkaブローカーの中にSQLiteが入り込むことに違和感を覚えるなら、その感覚こそがこれらのKIPがまだUnder Discussionである理由の一部です。

レイテンシの請求書 — KIP-1163自身が書き残した予算

ここが本稿で最も重要な部分です。Disklessの代償はレイテンシであり、KIP-1163はその予算を隠さずに書き残しています。

Append latency is broadly composed by:
- Buffering: up to 250ms or 4MiB (both configurable)
- Upload to Remote Storage: P99 ~200-400ms, P50 ~100ms
- Batch Coordinates Commit: P99 ~20-50ms, P50 ~10ms (バッチ数による)

We are aiming for a Produce request latency of P50 ~500ms P99 ~1-2 sec

読み方が重要です。これは測定値ではなく目標値です。KIPの原文は"We are aiming for"であり、私はこれを「こう出る」と読み替えることはしません。まだアップストリームの実装がないのですから、測定値があるはずもありません。

それでもこの予算は構造を明らかにしています。目標P50が約500msで、そのうち最大250msがバッファリングです。レイテンシの半分ほどが、ストレージが遅いからではなく「待つと決めたこと」から生まれているという意味です — オブジェクトストレージの書き込み操作コストを吸収するにはバッチをまとめる必要があり、バッチをまとめるには待つ必要があるからです。物理法則ではなく経済法則から生まれたレイテンシです。

残り半分は物理側です。KIP-1163は「リモートストレージはローカルディスクよりレイテンシが高くなり得て、これはKafkaリクエストとエンドツーエンドのデータレイテンシを増加させる」と書き、WarpStreamのドキュメントも「オブジェクトストレージにファイルを作ることはローカルディスクへの書き込みに比べて相対的にレイテンシの高い操作である」と同じことを述べています。

では、この500msを何と比べるべきでしょうか。KIPもベンダーのドキュメントもクラシックKafkaのProduceレイテンシの基準値を示しておらず、ですから私もここで代わりに数字を作り出すことはしません。比較対象はあなたの現行クラスタです — 今あなたのプロデューサーが何ミリ秒で応答を受け取っているかはあなたのダッシュボードにしかなく、その数字と500msを並べることだけが唯一意味のある比較です。

KIP-1163はこのトレードオフを隠すどころか、設計原則そのものにしています。Diskless トピック、クラシックトピック、ティアードトピックが「一つのクラスタに共存」し、アプリケーション開発者が「トピック単位でレイテンシとコストをトレードオフできる」ようにします。KIPのデータフローの説明では、低レイテンシのデータはクラシックトピックが引き続き運び、高レイテンシ許容のデータがDisklessインジェクションエンジンへ向かいます。つまりこれはKafkaを置き換える機能ではなく、Kafkaに「ダイヤルを一つ追加する」機能です。

ベンダーの数字をどう読むか

Disklessと同じ発想をすでにプロダクションで動かしている商用製品があります。WarpStream、Buffstream、Confluent Freight Clusters、Redpanda Cloud Topicsなどです。これらの公開数値は「S3ベースのログエンジンが実際どれほどのレイテンシを出すのか」についての唯一の実測参考点ですが、そのすべてがベンダー自己測定であることを忘れてはいけません。

WarpStreamの公式ドキュメントは比較的率直なほうです。性能チューニングのドキュメントはこう書きます — 「WarpStream Agentにはローカルディスクがなく、オブジェクトストレージへデータを直接書き込みます。オブジェクトストレージにファイルを作ることは、ローカルディスクへの書き込みに比べて相対的にレイテンシの高い操作です。たとえば、私たちの経験ではS3に4MiBのファイルを書き込むP99レイテンシは約400msです。」(Tuning for Performance) 「私たちの経験では(in our experience)」という限定句が原文にそのまま入っています。

このドキュメントが続けて語る話のほうが実務的です。400msのレイテンシの上でスループットを出すには、リトルの法則に従って並行性が必要です。ドキュメントの例をそのまま持ってくると — 1MiBのバッチサイズで1GiB/sの書き込みスループットを達成するには、同時に400件のProduceリクエストが実行中である必要があります。そして「十分な未処理リクエストがないことが、WarpStream使用時に書き込みスループットが低くなる最大の単一の原因である」と言い切っています。S3ベースのエンジンに移ると、クライアントチューニングの性質そのものが変わるということです。

レイテンシをさらに下げる道もありますが、タダではありません。WarpStreamのS3 Expressドキュメントは「バッチタイムアウトの短縮と組み合わせれば、S3 ExpressはProduceリクエストのP99レイテンシを150ms未満に下げられる」としています。しかし同じドキュメントが代償を列挙しています — S3 Express One Zoneはその名の通り単一AZにしか保存しないため、WarpStreamは複数の単一ゾーンバケットのクォーラムにまたがってレプリケーションしなければならず、S3 Expressの保管コストは「レプリケーションを考慮する前に、すでに通常のオブジェクトストレージの約7倍」です。そのため推奨構成はインジェクションだけをS3 Expressにし、コンパクションは通常のバケットに落とすというものです。レイテンシを買うには金を払わなければならないという元の話に戻ります。

一方で、注意して読むべき数字もあります。Aivenの承認後の振り返り記事には、関連資料カードに「TCOを最大80%まで削減」という文言が付いています。これはベンダー自身の主張であり、その記事にはその80%が何を含み何を除いた計算なのか — どのワークロード、どのクラウド、どのレプリケーションファクター、どの保管期間、コンピュートを含めたのか — についての根拠は一切示されていません。宣伝コピーに付いた上限(「最大」)にすぎません。AivenはKIP-1150の主著者であり、マネージドKafkaで収益を上げる会社でもあります(記事自体はこの利害関係を正直に明かしてはいます)。ストリーミングベンダーのTCO計算は特に自己都合的になりがちなので、こうした数字はあなたのワークロードで直接検証するまでは方向指示器程度に扱うのが正しいでしょう。

静かに壊れるもの

KIP-1150は、Disklessトピックがクラシックトピックと「意味論的に置き換え可能」であることを意図していると述べ、順序保証・冪等性・トランザクション・コンシューマーグループ・キュー/シェアグループ・ティアードストレージのすべてをサポートすると列挙しています。大半は事実でしょうが、設計文書を詳しく読むと、いくつか滑らかでない角が見えてきます。

キュー(シェアグループ)はコスト面の恩恵を完全には受けられません。 KIP-1163が直接書いています — ShareFetchリクエストを処理できるのはシェアパーティションのリーダーだけであり、そのリーダーはパーティションリーダーと同じ場所にいます。したがって「キューコンシューマーはShareFetchリクエストをパーティションリーダーに送らなければならず、コンシューマーのゾーン間トラフィック排除の恩恵を常に受けられるわけではない」のです。ゾーン間イーグレスをなくすという約束に一つ例外がある形で、キュー機能に対するラック認識の最適化はこのKIPの範囲外に押し出されています。

ISRの意味が変わります。 Disklessでは「in-sync replica」はリーダーと同期しているという意味ではなく、「Diskless Coordinatorと同期している」という意味です。Coordinatorが真実の源だからです。KIP-1163が突く含意が鋭いところです — リーダーもただの一つのレプリカにすぎないため、リーダー自体がout-of-syncになりえます。そうなるとリーダーはティアードストレージへセグメントをオフロードする自分の任務を効率的に果たせなくなり、他のout-of-syncレプリカと同様、リーダーから読むことは推奨されません。長年Kafkaを運用してきた人の直感がここで一度折れる地点です。参考までに、レプリカはブローカー間レプリケーションをしないにもかかわらず、依然としてリーダーにFetchRequestを送ります — リーダーはレコードのない空の応答を返し、この往復だけがISR追跡の手段として残ります。

古いクライアントは回避策を使う必要があります。 新しいクライアントはMetadataRequest v14でラック情報を送り、どのトピックがDisklessなのか、どのブローカーにproduceするのが良いかを受け取ります。しかし旧バージョンやサードパーティのクライアントのためにKIP-1163が提案しているのは、クライアントIDにラック識別子を付け加える方式です。

client.id = "my-app,diskless_rack_id=use1-az4"

ブローカーはこの文字列を見て、該当ラックのレプリカをまるでリーダーであるかのように応答に埋め込みます。動作はしますが、KIP自身が認めているように、これでは本物のリーダーしか処理できないShareFetchが妨げられます。そのため「プロデューサーと通常のコンシューマーにはdiskless_rack_idを指定し、シェアコンシューマーには指定するな。後者はコード上別インスタンスであるべきだ」という運用指針が付いてきます。エレガントではなく、彼ら自身もそれを分かっています。

では、あなたは待つべきか

判断基準はこう整理できます。

コストに見合う可能性が高い場合

AWSまたはGCPで運用しており、スループットが大きくクロスAZレプリケーショントラフィックが請求書上の実際の項目として見える。
ワークロードがレイテンシに寛容である — ログ収集、メトリクス、分析パイプライン、バッチ的なインジェストのように、数百ミリ秒のProduceレイテンシが何の意味も持たない場所。
スループットが高く、パーティションあたりのデータが厚いためバッチが自然に埋まる。

過剰、あるいは有害な場合

Azureで運用している。クロスAZ課金がないため中核の経済的合理性が消えます。
レイテンシが製品要件である。目標値がP50 500msの経路に注文執行やユーザーリクエストの経路を乗せることはできません。
スループットが低い。トラフィックが少なければクロスAZコストも少なく、バッファリングのレイテンシだけをそのまま被ることになります。
キュー/シェアグループが主な利用パターンである。上で見た例外に正面から引っかかります。
そして今すぐ必要である。 これが最も現実的な除外条件です。

最後の項目をもう一度強調します。2026年7月時点でこの機能は存在しません。方向性だけが承認され、設計KIPが二つまだ議論中で、目標リリースもありません。今クロスAZの請求書が痛むなら、選択肢は商用製品(WarpStreamなど)か、Aivenがオープンソースとして公開した実験フォークInklessか、あるいは既存の手法(単一ラックトピックなど)で耐えることです。KIP-1150は単一ラックトピックのような既存の回避策を「耐久性・可用性・意味論・使いやすさの面でアプリケーションごとの妥協を強いる」として却下対案セクションで明示的に退けていますが、その妥協こそが今あなたが選べるものだというのは皮肉です。

残された道

KIP-1150が興味深いのは、技術よりも政治に近い理由からです。

却下対案セクションの最後の項目は「Do Nothing」ですが、その論拠が異例なほど率直です — 何もしなければこれが「アップストリーム実装で最も大きく欠けた単一の機能」になり、高スケール・クラウドユーザーをKafkaの代替へ押しやり、Kafkaが「Kafkaプロトコルに対する権威を完全に失う」可能性があるというのです。実際、ここ数年に登場したクラウドネイティブなKafka互換製品は、どれもオープンソースではありません。KIP-1150はその流れに対するアップストリームの応答です。

その応答がどれほど本気だったかは、競合提案が同時に三つも上がったという事実に表れています — KIP-1150のほかにKIP-1176(Tiered Storage for the Active Log Segment)とKIP-1183(Unified Shared Storage)が同じ領域に提出され、最終的にKIP-1183の著者たち(Slack)が自分たちの提案を取り下げてKIP-1150を正式に支持することで収まりました。投票は2026年1月9日に再開され3月2日に通過し、Aivenの集計によればバインディング票9とノンバインディング票5を獲得しました。

これから残っているのは、KIP-1163とKIP-1164を実際に通すことです。そしてその先には、KIP-1150が「Further Work」として残した、まだKIPすら存在しない項目があります — クラシックトピックとDisklessトピック間のタイプ変換、ブローカーの役割特化(produce/consume/coordination/compaction専用ブローカー)、高レイテンシ環境でプロデューサーあたりのスループットを上げるための並列Produce処理、Icebergフォーマット、メタデータレプリケーションによるマルチリージョンのアクティブ-アクティブです。最後の二つは実現すればKafkaのアイデンティティそのものに関わる話ですが、今はまだリストの一行にすぎません。

おわりに

まとめるとこうなります。Tiered Storageは古いデータを安くしましたが、アクティブセグメントのレプリケーショントラフィックはそのままにし、それがハイパースケーラーにおけるKafkaの最大のインフラコストです。KIP-1150は、オブジェクトストレージを正本として据えてそのコストをなくそうという方向性にコミュニティが合意したものです — 方向性だけです。

代償は明確で、設計文書はそれを隠していません。目標Produceレイテンシは P50約500ms、P99約1〜2秒。その半分は、オブジェクトストレージのPUTコストを吸収するためにバッチをまとめる時間です。だからDisklessは「より良いKafka」ではなく、「トピック単位で回せるダイヤル」です — 低レイテンシが必要なトピックはクラシックに残り、レイテンシに寛容な大容量トピックだけがDisklessへ送られるというのが、設計者たちが描いた絵です。

そしてそのダイヤルはまだあなたの手の中にありません。Kafka 4.3.1には入っておらず、いつ入るかも公表されていません。ですから今やるべきことは移行計画ではなく計測です — あなたのクロスAZトラフィックが実際に請求書のいくらを占めているのか、あなたのプロデューサーが500msに耐えられるのか。この二つの数字を知らなければ、この機能が到着してもそれを使うべきかどうか判断できません。機能が先ではなく、請求書が先です。