필사 모드: 分散メッセージング 2026 — Kafka 3.9 / NATS / Redpanda / Pulsar / RabbitMQ 4 / WarpStream 徹底比較
日本語プロローグ — 「メッセージキュー使いますか?」が変な質問になった時代
2026 年のあるチームの設計会議。
ジュニア:「イベントは Kafka で送ればいいですよね?」
シニア:「トラフィックどのくらい?」
ジュニア:「秒間 100 件です。」
シニア:「...なぜ Kafka?」
この短い会話に 2026 年の全部が入っている。一方には **「メッセージング = Kafka」** というほぼ宗教的な確信があり、もう一方には **「Kafka が要らない仕事に Kafka を使うな」** というベテランのため息がある。その間を NATS、Redpanda、Pulsar、RabbitMQ 4、RocketMQ、WarpStream、Buf Stream が埋めている。
2026 年現在、分散メッセージングは **三つのパラダイム** に分かれる。古典的なメッセージキュー(RabbitMQ)、ログ基盤のストリーミング(Kafka 系)、クラウドネイティブの pub/sub(NATS、Pulsar)。さらにその上に **運用モデル** の二軸が重なる — ディスク基盤 vs オブジェクトストレージ基盤(WarpStream、Kafka tiered storage)、セルフ運用 vs マネージド。
本記事はその全体地図を一度に整理する。Kafka 3.9 の KRaft 化、WarpStream の S3 上 Kafka、NATS の単一インフラ志向、Pulsar Functions、RabbitMQ 4 の Khepri 化、そして日韓ビッグテックが何をどう使っているかまで。
1 章 · 2026 年の分散メッセージング地図 — Pub/Sub / Queue / Stream の 3 パラダイム
まず用語から。メッセージシステムは通常三つに括られる。
| パラダイム | 意味 | 代表 | 保持 |
| --- | --- | --- | --- |
| Queue(作業キュー) | 1:1 分配、コンシューマが ack 後に削除 | RabbitMQ、SQS、Celery broker | 消費時に削除 |
| Pub/Sub(放送) | 1:N、トピック毎に複数購読者 | NATS Core、Redis Pub/Sub、MQTT | 無し(または短時間) |
| Stream(ログ) | 順序付きログ、複数コンシューマグループ | Kafka、Pulsar、Kinesis、JetStream | 時間/サイズ基準 |
2026 年には境界が曖昧になった。Kafka は queue 風(static membership、share groups)を持ち、RabbitMQ は stream(Streams プラグイン)を加え、NATS は JetStream で persistent stream を獲得し、Pulsar は最初から両方だった。
それでも **選択はパラダイムから** 始める。次の意思決定木を勧める。
1. **「一つの作業を一人のコンシューマが処理して終わり」** か? → Queue(RabbitMQ、SQS)。
2. **「同じイベントを複数システムが見る」** か? → Stream(Kafka、Pulsar)か Pub/Sub(NATS)。
3. **「数日〜数年保管して再処理」** が要るか? → Stream + 長期保持(Kafka + tiered storage、Pulsar tiered)。
4. **「秒間数十〜数百件、単純」** → RabbitMQ か NATS Core。
5. **「マルチテナント、マルチリージョン、短い P99」** → NATS か Pulsar。
6. **「AWS のみ、S3 コストで完結したい」** → WarpStream。
Kafka が金槌なら全ての問題が釘に見える。2026 年のベテランは「秒 100 件なら RabbitMQ で十分、運用が 10 倍楽だ」と言う。
2 章 · Kafka 3.9(KRaft default、ZooKeeper 除去)→ 4.0 展望
2024 年の Kafka 3.7 で KRaft が production-ready 宣言、2024 年末の Kafka 3.9 で **KRaft が既定** となり ZooKeeper モードは deprecated。そして 2025 年の Kafka 4.0 で **ZooKeeper コードそのものが削除** された。
運用への影響は具体的だ。
| 項目 | ZK 時代 | KRaft 時代 |
| --- | --- | --- |
| クラスタコーディネート | 外部 ZooKeeper アンサンブル | Kafka 内部 Raft(KRaft) |
| 起動 | broker + 3〜5 ZK | broker(controller 兼用/分離) |
| メタデータ保存 | ZK znode | Kafka 内部トピック(__cluster_metadata) |
| メタデータ限界 | 約 20 万パーティション | 数百万パーティション |
| 起動時間 | 数十秒〜数分 | 数秒 |
| 運用複雑度 | 二つのシステム | 一つのシステム |
最小の KRaft 起動。
Kafka 3.9, single-node KRaft (開発用)
export KAFKA_HOME=/opt/kafka_2.13-3.9.0
$KAFKA_HOME/bin/kafka-storage.sh random-uuid
出力: yzs8XK6oR1qV3R-... (CLUSTER_ID)
$KAFKA_HOME/bin/kafka-storage.sh format \
-t $CLUSTER_ID \
-c $KAFKA_HOME/config/kraft/server.properties
$KAFKA_HOME/bin/kafka-server-start.sh \
$KAFKA_HOME/config/kraft/server.properties
production では controller と broker を **分離** する(`process.roles=controller` vs `process.roles=broker`)。3 controller + N broker が標準構成。
2026 年現在の中核 KIP。
- **KIP-405 — Tiered Storage**: 古いセグメントを S3/GCS/HDFS に自動オフロード。hot はローカル SSD、cold はオブジェクトストレージ。保存コスト 1/5〜1/10。
- **KIP-848 — Next Gen Consumer Rebalance**: コンシューマグループのリバランスをサーバ側に。stop-the-world 時間短縮。
- **KIP-932 — Queues for Kafka(Share Groups)**: 4.0 の目玉。Kafka 上に **queue セマンティクス** (同一トピックを複数コンシューマが競合消費、ack/timeout/redelivery)を正式サポート。RabbitMQ 領域へ侵入。
- **KIP-1102 — Transactions v2**: トランザクションコーディネータの安定性向上。
KRaft + tiered storage + share groups の組み合わせで、Kafka 4.0 は「stream も queue も長期保管も一つのシステム」を狙う。
3 章 · Confluent Cloud vs Aiven vs Redpanda — マネージド Kafka
Kafka を自前運用するチームは年々減っている。マネージドが成熟したからだ。
| 提供者 | 互換性 | 価格モデル | 特徴 |
| --- | --- | --- | --- |
| Confluent Cloud | 100%(自社 OSS) | スループット + ストレージ(Basic/Standard/Dedicated) | Schema Registry、Connect、ksqlDB、Stream Designer 統合 |
| Aiven for Kafka | 100%(Apache Kafka) | インスタンス時間 + ストレージ | マルチクラウド、Karapace(OSS schema registry) |
| AWS MSK | 100%(Apache Kafka) | インスタンス時間 + ストレージ | KRaft 対応、MSK Serverless は別 |
| Azure Event Hubs | Kafka API 互換(部分) | Throughput Unit + Capture | Azure 統合 |
| Redpanda Cloud | Kafka wire 互換 | クラスタ時間 + ストレージ | 独自エンジン(C++)、tiered storage |
| WarpStream | Kafka wire 互換 | スループットのみ(ストレージは顧客 S3) | S3 上 Kafka、BYOC 標準 |
2026 年の実務ガイド。
- **フルスタック統合 + エンタープライズサポート**: Confluent Cloud。
- **純粋 OSS Kafka、マルチクラウド**: Aiven。
- **AWS ロックインで OK、MSK Serverless で単純化**: MSK。
- **運用簡素 + 半数ノード**: Redpanda Cloud。
- **ストレージコストとクラウド egress を最小化**: WarpStream。
価格で最大変数は **クラウドの inter-AZ 転送費** だ。Kafka が 3 AZ レプリケーション既定だと、レプリカトラフィックが AZ をまたいで GB あたり 0.01〜0.02 ドル発生する。スループットの大きいワークロードではこの費用がクラスタ費用を超える。WarpStream と KIP-392(fetch from follower)はこの費用を削るための核心。
4 章 · Redpanda — C++ ベースの Kafka 互換
Redpanda は 2019 年に Vectorized(現 Redpanda Data)が始めた。一行で言えば **JVM 無しで C++ で書き直した Kafka**。ScyllaDB の Seastar の thread-per-core モデルを持ってきた。
主要な違い。
- **No JVM、No GC pause**: P99 レイテンシが安定。
- **No ZooKeeper from day 1**: Kafka より早く独自 Raft。
- **単一バイナリ**: broker = controller、1〜3 ノードから運用可能。
- **Kafka wire 互換**: client・connector・UI そのまま。
- **Tiered storage 内蔵**: S3/GCS への cold データ。
- **WASM transforms**: Redpanda Data Transforms(broker 内で WASM 実行)。
性能主張は「同一ハードで Kafka 比 2〜5 倍スループット、1/3 ノード」。ベンチマークは常にワークロード次第だが、**ノード数が減って運用負担が軽くなる** 点は実体験と合う。
Docker で single-node 起動。
docker run -d --name redpanda \
-p 9092:9092 -p 9644:9644 \
redpandadata/redpanda:v24.3.1 \
redpanda start --smp 1 --memory 1G --reserve-memory 0M \
--overprovisioned --node-id 0 --check=false
Kafka クライアントでそのまま接続。
docker exec -it redpanda rpk topic create test
docker exec -it redpanda rpk topic produce test
> hello
> ^D
docker exec -it redpanda rpk topic consume test --num 1
2026 年の Redpanda の位置は「**JVM/ZK 運用が嫌で、Kafka 互換が要るチーム**」。ゲーム・金融・IoT のようにレイテンシ一貫性が重要な領域での採用が増えた。
5 章 · WarpStream(Confluent 買収 2024)— S3 上の Kafka
WarpStream は 2023 年に登場、2024 年 9 月に Confluent に買収された。一行で言えば **Kafka wire 互換 + ストレージは S3** が本質。
伝統的 Kafka のコスト構造。
1. broker インスタンス費(EC2/EBS)。
2. AZ 間レプリカ転送費($0.01/GB)。
3. EBS ストレージ費。
4. コンシューマが他 AZ にあると fetch 費。
WarpStream のアーキテクチャ。
1. **ステートレス Agent** が Kafka wire プロトコルを受けて S3 に直接書く。
2. メタデータは WarpStream コントロールプレーン(または BYOC モードの自前コントローラ)。
3. ディスクが無い → AZ 間レプリカ転送が無い。
4. 全データが S3 → 11 ナインの durability はクラウドの責任。
5. コンピュート(Agent)とストレージ(S3)が完全分離 → それぞれ独立スケール。
代償は **レイテンシ**。古典 Kafka は P99 produce が 5〜50ms に対し WarpStream は 200〜500ms(S3 PUT レイテンシのため)。だから「低レイテンシのリアルタイム」には合わず、「高スループット + コスト最小 + 1 秒程度の遅延 OK」のワークロードに合う。データレイク投入、ログ/メトリクスパイプライン、CDC sink が代表例。
買収後の方向性は「Confluent Cloud の一 deployment 形態」への統合。Confluent Cloud Freight Cluster が実質 WarpStream エンジン。
6 章 · NATS + JetStream + KV + ObjectStore
NATS は 2011 年登場の軽量 pub/sub。2018 年に Synadia が会社として分離、同年 CNCF へ寄贈。哲学は「単純さと速さ」。
NATS の進化。
| 時期 | 機能 |
| --- | --- |
| 2011 | Core NATS — fire-and-forget pub/sub |
| 2018 | NATS Streaming(後に deprecated) |
| 2020 | JetStream — persistent stream、KV、ObjectStore |
| 2024 | NATS 2.10 — domains、leaf node セキュリティ |
| 2025 | NATS 2.11 — pull consumer 改善、ADR 統合 |
2026 年に NATS 単一ノード(クラスタリングは設計上単純)。
JetStream 有効化
nats-server -js -sd /data/nats
ストリーム作成。
nats stream add ORDERS \
--subjects "orders.>" \
--storage file --retention limits \
--max-msgs=1000000 --max-age=24h
KV 利用。
nats kv add config
nats kv put config feature.new-checkout '{"enabled":true}'
nats kv get config feature.new-checkout
ObjectStore(S3 風)。
nats object add my-bucket
nats object put my-bucket large.zip ./large.zip
nats object get my-bucket large.zip > out.zip
NATS の強みは **単一インフラ**。queue + pub/sub + stream + KV + オブジェクト + 分散ロック + leader election を一バイナリで賄う。マイクロサービスが多くマルチリージョン/エッジがある現場では、NATS は「Kafka 一つ + Redis 一つ + Consul 一つ + MinIO 一つ」より単純。
弱点はエコシステム。Kafka の巨大な connector エコシステム、Schema Registry、ストリーム処理(ksqlDB、Flink)のような部分は NATS では弱い。
7 章 · Apache Pulsar 4.0 + Pulsar Functions
Apache Pulsar は Yahoo が 2016 年に OSS 化、2018 年に Apache 卒業。差別化は **コンピュートとストレージの分離**(broker = stateless、BookKeeper = storage)。
Pulsar 4.0(2025 年初)の核心。
- **Lakehouse Tiered Storage**: 古いデータを Parquet 形式で S3/GCS へ保存、Trino/Spark が直接クエリ。
- **Pulsar Functions 安定化**: ストリーム上で Lambda 風関数実行、function mesh でワークフロー。
- **Topic Compaction 改善**。
- **WebSocket・HTTP・MQTT プロトコルゲートウェイ統合**。
Pulsar の構造的優位。
| 項目 | Kafka | Pulsar |
| --- | --- | --- |
| broker 状態 | stateful(ディスク) | stateless |
| 保存 | broker ディスク | BookKeeper bookie |
| ノード追加時のリバランス | データ移動が要る | ほぼ即座 |
| マルチテナンシー | クラスタ単位 | 1 クラスタに tenant/namespace/topic |
| 地域レプリ | MirrorMaker 2 | Geo-replication 内蔵 |
弱点は **運用複雑度**。broker + bookie + ZooKeeper(2026 年でも Pulsar は ZK を使う)の三コンポーネントが別運用。さらに日韓では知名度が低く運用人材が見つかりにくい。
2026 年の Pulsar は「**大規模マルチテナント SaaS**」領域で強い。Splunk、Yahoo、Tencent、StreamNative などが数十万トピックを単一クラスタで運用している。
8 章 · RabbitMQ 4.0 — Khepri(Raft)+ Streams プラグイン
RabbitMQ は 2007 年からの AMQP 0.9.1 実装で、「メッセージキューの標準」のような立ち位置。2024 年の RabbitMQ 4.0 が大きな転換だった。
主要変更。
- **Mnesia → Khepri**: クラスタメタデータの保存先を Erlang Mnesia(古典的分散 DB)から Khepri(Raft ベースの自社 DB)へ。split-brain 回復が綺麗になった。
- **Streams プラグイン GA**: Kafka 風の append-only ログを RabbitMQ 内部に統合(Stream Queue Type)。スループット 100 万 msg/s まで。
- **Quorum Queue を既定化**: 古典キューよりも Raft ベースの Quorum Queue を推奨。
- **MQTT 5 / AMQP 1.0 強化**。
RabbitMQ が今でもよく合う場所。
- **ジョブキュー**: Celery、Sidekiq、Resque などのワーカ系。
- **RPC パターン**: request-reply with reply-to queue。
- **fanout / topic routing**: ルーティングキー基準の複雑な分岐。
- **バックオフィス処理**: メール送信、PDF 生成、決済処理。
Quorum Queue 例。
CLI で宣言
rabbitmqadmin declare queue name=tasks queue_type=quorum
Java クライアントから publish。
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("rabbitmq");
try (Connection conn = factory.newConnection();
Channel ch = conn.createChannel()) {
ch.queueDeclare("tasks", true, false, false,
Map.of("x-queue-type", "quorum"));
ch.basicPublish("", "tasks",
MessageProperties.PERSISTENT_TEXT_PLAIN,
"hello".getBytes());
}
RabbitMQ を Kafka に置き換える試みは大抵後悔で終わる。**秒間数千〜数万件のジョブ、複雑なルーティング、短い保持** ならば RabbitMQ の方が単純で安い。
9 章 · Apache RocketMQ(Alibaba)— 中国スケール
RocketMQ は Alibaba が 2012 年に作り 2017 年に Apache 卒業。Double 11(11/11)の中核インフラとして、**秒間数百億メッセージ規模** で実証済みのシステム。
特徴。
- **順序保証モード**: パーティションでなくメッセージグループ単位の順序(FIFO Topic)。
- **トランザクションメッセージ**: half-commit / commit / rollback の 3 段階 — DB トランザクションとメッセージ発行の原子性。
- **スケジュールメッセージ・遅延メッセージ** が内蔵。
- **ダッシュボード・トレース** の完成度が高い。
- **RocketMQ 5.0+**(2023〜): コンピュート/ストレージ分離、クラウドネイティブ。
韓国・日本・欧米ではほぼ使われないが、中国・東南アジアでは Kafka の代替として極めて一般的。Alibaba Cloud のメッセージサービスは実質 RocketMQ。
トランザクションメッセージの例(Java)。
TransactionMQProducer producer = new TransactionMQProducer("group");
producer.setTransactionListener(new TransactionListener() {
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
// 1) DB トランザクション実行
// 2) 成功 -> COMMIT、失敗 -> ROLLBACK、不明 -> UNKNOWN
return LocalTransactionState.COMMIT_MESSAGE;
}
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
// ブローカが未解決メッセージを再確認
return LocalTransactionState.COMMIT_MESSAGE;
}
});
新規プロジェクトに RocketMQ を選ぶ日韓チームはほぼ無いが、Alibaba Cloud / Tencent Cloud にデプロイするならマネージド RocketMQ が自然な選択。
10 章 · NSQ / Memphis(Superstream)
NSQ
NSQ は bitly が 2013 年に OSS 化した分散メッセージシステム。Go 製。哲学は「**中央ブローカ無し、トポロジが単純なシステム**」。
- **単一バイナリ(nsqd)** が各ホストにデプロイされ、メッセージはホストローカルから発行。
- nsqlookupd が発見を担う。
- クラスタリング無し(各ノード独立)。
- メモリ優先、overflow 時にディスク。
NSQ の武器は単純さ。大企業が使わないという印象はあるが、IRC bot・ドメインインデクシング・単純なジョブキューでは今も良い選択。ただし 2026 年の新規プロジェクトなら NATS がほぼ全機能で勝る。
Memphis → Superstream
Memphis は 2022 年登場の Kafka 代替試行。「開発者フレンドリな Kafka」を掲げ、GUI・schema management・DLQ を既定提供した。2024 年に会社が **Superstream** へリブランド、方向を「**Kafka の上のコスト最適化レイヤ**」へ転換した。
2026 年の Superstream のポジショニングは興味深い。
- Kafka を **置き換えない**、AI で config を調整し、自動圧縮や partition balancing を行う。
- Confluent Cloud / MSK / Aiven の上に被せて 30〜50% のコスト削減を約束。
- 人気パターン: 誤って設定された batch.size・linger.ms・compression.type を実ワークロードに基づき再推奨。
「Kafka はそのまま、請求書を削る」コンセプトで、マネージド Kafka の請求が痛いチームが導入している。
11 章 · Buf Stream — gRPC streams の新たな挑戦
Buf は Protocol Buffers ツールで有名な会社。2024 年に **Buf Stream** を発表しメッセージング領域へ参入。
中心アイデア。
- **Schema-first メッセージング**: 全トピックが Protobuf スキーマ持ち。不正なメッセージは発行段階で拒否。
- **Kafka API 互換**: 既存 Kafka client をそのまま使える。
- **Buf Schema Registry** と統合 — スキーマ進化ルールを強制。
- **ステートレスアーキテクチャ**: WarpStream に似て S3/オブジェクトストレージが一次保存。
Buf Stream の価値提案。
- 「不正なデータがトピックに入る事故を、コンパイル/デプロイ段階で止める。」
- 「Buf CLI でスキーマ変更を lint、互換性チェック、breaking change を遮断。」
- 「Kafka client はそのまま — インフラ置き換えだけ。」
2026 年現在の Buf Stream は production 採用が少数だが、**schema governance が中核価値となる組織**(金融・ヘルスケア・B2B SaaS)で注目を集めている。Confluent Schema Registry + Kafka の「二システム」を一システムに束ねる試み。
12 章 · イベントソーシング / CQRS / Outbox / Saga パターン
メッセージシステムは道具にすぎず、**どう使うか** が本体。2026 年でも変わらない核心パターン 4 つ。
1) イベントソーシング(Event Sourcing)
状態を直接保存せず、**状態を作ったイベントの列** を保存する。現在の状態はイベントを fold して得る。
// 注文状態 = イベントの fold
function orderState(events) {
return events.reduce((state, e) => {
switch (e.type) {
case 'OrderCreated': return { id: e.id, status: 'PENDING', items: e.items };
case 'OrderPaid': return { ...state, status: 'PAID', paidAt: e.at };
case 'OrderShipped': return { ...state, status: 'SHIPPED', tracking: e.tracking };
default: return state;
}
}, null);
}
- 長所: 監査ログ、時間旅行、新ビュー再構築。
- 短所: クエリが難しい → CQRS と組合せ。
2) CQRS(Command Query Responsibility Segregation)
書き込みモデルと読み出しモデルを分離。読み出しモデルはイベントストリームから非同期でビルド。
3) トランザクション Outbox
最も多い間違い:「DB トランザクション → イベント発行」を別々にやって、その間で障害が起きると不整合。Outbox は同じ DB トランザクションに `outbox` テーブル INSERT を束ね、**別プロセスが outbox を読んで Kafka に発行**。Debezium CDC か自前 poller。
BEGIN;
INSERT INTO orders (id, user_id, total) VALUES (...);
INSERT INTO outbox (aggregate_id, event_type, payload)
VALUES ('order-123', 'OrderCreated', '{"...":"..."}');
COMMIT;
-- 別プロセスが outbox をポーリング/CDC で Kafka へ
4) Saga
複数サービスをまたぐトランザクションの分散版。各段に補償トランザクションを定義。
- 決済 → 在庫減算 → 配送予約。どこかで失敗したら前の段を補償(返金、在庫戻し)。
- 実装は二つ: オーケストレーション(中央コーディネータ、Temporal、AWS Step Functions)vs コリオグラフィ(各サービスがイベントを見て反応)。
この 4 パターン無しで分散メッセージングを production 運用するのは、データ不整合の時限爆弾。
13 章 · 日韓導入 — カカオ、トス、LINE、Mercari、ZOZO、CyberAgent
カカオ
カカオは **Kafka を社内マネージドサービス化** して運用する。カカオトークのメッセージフロー、検索インデックス、ログパイプラインが Kafka に乗る。KRaft 移行は 2025 年から段階的に進行中。一部チームは RabbitMQ をバックオフィスワーカに利用。
トス(Toss)
トスのデータエンジニアリングは Kafka 中心で知られる。決済イベント・CDC・リアルタイム ML 特徴量ストアが Kafka 上。近頃は一部ワークロードに **WarpStream / Tiered Storage** を検討。社内カンファレンス SLASH で Kafka 運用ノウハウの共有多数。
LINE
LINE はメッセージングインフラ自体が **自社開発キュー(LMQ)** と Kafka のハイブリッド。トラフィックがグローバルでメッセージ順序が重要なため自社ソリューションを維持。広告・ログ・メトリクスは Kafka。Java 陣営が強いだけに ZooKeeper 時代からの運用経験が資産。
Mercari
Mercari は GCP 中心で **Pub/Sub + Dataflow** がメインだが、決済・在庫などで Kafka も使う。Mercari エンジニアリングブログに Pub/Sub vs Kafka の比較記事が多数。
ZOZO
ZOZO は検索・推薦パイプラインに Kafka を採用。ファッションカタログ変更 → 検索インデックス更新のほぼ全フローが Kafka。社内で Schema Registry 運用事例を共有。
CyberAgent / AbemaTV
AbemaTV のライブ配信メタデータ、広告入札パイプラインに Kafka。CyberAgent グループ各社が NATS・Pulsar も部分的に導入 — 日本のカンファレンス発表が増えた。
共通点: **2026 年には「Kafka 一本」より「ワークロード別の適材適所」の流れ**。決済・CDC は Kafka、マイクロサービス通信は NATS、ジョブキューは RabbitMQ、データレイク投入は WarpStream / MSK Tiered。一社の中に 3〜4 種のメッセージングが共存するのが標準になった。
14 章 · 意思決定チェックリスト — 我々は何を使うか
最後にワンページ決定表。
| 状況 | 第一選択 | 代替 |
| --- | --- | --- |
| 秒間 100 件以下、ジョブキュー | RabbitMQ | NATS JetStream、SQS |
| 秒間 1 万〜数十万、複数コンシューマ、イベントログ | Kafka(KRaft) | Redpanda、Pulsar |
| マルチリージョン、P99 1ms 目標 | NATS | Pulsar |
| AWS only、ストレージコストが鍵 | WarpStream | MSK + Tiered Storage |
| マルチテナント SaaS、数十万トピック | Pulsar | Kafka with KRaft + careful partition mgmt |
| 運用人材 0〜1 名 | マネージド(MSK Serverless、Confluent Cloud、NATS Synadia Cloud) | - |
| 中国市場 | RocketMQ / Aliyun MQ | Kafka |
| schema-first、強いガバナンス | Buf Stream | Kafka + Confluent Schema Registry |
| 単純 pub/sub、超小型 | NATS Core | Redis Pub/Sub |
| 既に Kafka、コスト削減希望 | Superstream + WarpStream | 手動チューニング + Tiered Storage |
運用観点で忘れない事。
- **モニタリング**: Prometheus + Kafka Exporter / Burrow(コンシューマ lag)、JMX、Datadog / Grafana。
- **schema 管理**: Confluent Schema Registry / Buf / Karapace。スキーマ無しで production トピックを作ると半年後に後悔。
- **バックアップ/DR**: MirrorMaker 2(Kafka)、Geo-replication(Pulsar)、JetStream mirrors(NATS)。
- **認証/権限**: SASL/OAuth、ACL — production で匿名発行が通ってはいけない。
- **コンシューマ lag 警報**: lag が 30 分以上ならページ。最も多い incident 原因。
エピローグ — メッセージはインフラではなく契約だ
2026 年の分散メッセージングの本当の教訓は道具でなく **契約**。システム間の契約 — どんなイベントが、どんなスキーマで、どんな保証(at-least-once、exactly-once、順序、レイテンシ)の下で流れるか。
道具は変わる。5 年前に ZooKeeper を運用していた人が今日 KRaft を運用し、来年は S3 上の Kafka を運用するかもしれない。しかし **契約をよく設計したチームは道具を変えても生き残る**。設計を誤ったチームは道具を変えても同じ問題に出会う。
次回候補: **Outbox パターン深堀り — Debezium CDC + Kafka で作る最も安全なイベント発行**、**コンシューマ lag を 0 にする方法 — KIP-848 / partition assignment / バックプレッシャ**、**NATS マルチリージョン — leaf node で本当の世界規模分散を作る**。
> 「メッセージキューを選ぶことは、二つのシステムの間の契約を設計することだ。道具はその後に来る。」
— 分散メッセージング 2026、終わり。
参考 / References
- [Apache Kafka 3.9 release notes](https://kafka.apache.org/39/documentation.html)
- [KIP-833 — Mark KRaft as Production Ready](https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready)
- [KIP-405 — Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)
- [KIP-848 — Next Generation Consumer Rebalance Protocol](https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol)
- [KIP-932 — Queues for Kafka (Share Groups)](https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka)
- [Confluent Cloud](https://www.confluent.io/confluent-cloud/)
- [Aiven for Apache Kafka](https://aiven.io/kafka)
- [AWS MSK](https://aws.amazon.com/msk/)
- [Redpanda Documentation](https://docs.redpanda.com/)
- [Redpanda GitHub — redpanda-data/redpanda](https://github.com/redpanda-data/redpanda)
- [WarpStream Documentation](https://docs.warpstream.com/)
- [Confluent acquires WarpStream (2024)](https://www.confluent.io/blog/confluent-acquires-warpstream/)
- [NATS Documentation](https://docs.nats.io/)
- [NATS JetStream](https://docs.nats.io/nats-concepts/jetstream)
- [NATS GitHub — nats-io/nats-server](https://github.com/nats-io/nats-server)
- [Apache Pulsar Documentation](https://pulsar.apache.org/docs/)
- [Pulsar Functions](https://pulsar.apache.org/docs/functions-overview/)
- [RabbitMQ 4.0 release notes](https://www.rabbitmq.com/release-information)
- [RabbitMQ Khepri](https://www.rabbitmq.com/docs/metadata-store)
- [RabbitMQ Streams](https://www.rabbitmq.com/docs/streams)
- [Apache RocketMQ](https://rocketmq.apache.org/)
- [NSQ Documentation](https://nsq.io/)
- [Superstream — formerly Memphis](https://superstream.ai/)
- [Buf Stream](https://buf.build/product/bufstream)
- [Debezium — CDC platform](https://debezium.io/)
- [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html)
- [LINE Engineering Blog](https://engineering.linecorp.com/en/blog)
- [Mercari Engineering](https://engineering.mercari.com/en/blog/)
- [ZOZO TECH BLOG](https://techblog.zozo.com/)
- [CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/)
- [Toss SLASH conference](https://toss.tech/slash)
현재 단락 (1/298)
2026 年のあるチームの設計会議。