---
title: "Kafka Simulator v2.0 - カリキュラムの完成と、作り直したプレイグラウンド"
date: 2026-10-21T00:00:00.000Z
author: "michal"
excerpt: "v2.0 で 136 本すべてのシナリオがそろいます。Schema Registry と認可、そしてフリープレイ向けのガバナンス階層。シェアグループ（KIP-932）、ディスクレストピック（KIP-1163/1164 のドラフト）、キャップストーン。それらを取り巻くプレイグラウンドも作り直しました。クラスタを見る 3 つのビュー、読めるタイムライン、問いに答えるインスペクター、そしてキャンバスを隠さなくなったターミナルです。"
---
v2.0 はカリキュラムの最後のパックです。**schema-registry**、**authorization**、**share-groups**、**capstones** の 4 つのモジュールに加えて、storage モジュールに **ディスクレストピック** のシナリオを 3 本、dr モジュールにアクティブ-アクティブ DR 訓練を 1 本、producer モジュールにラック対応パーティショニングを 1 本追加し、合計で**24 本の新しいシナリオ**となります。フリープレイでは **governance** と **diskless** の階層が解放され、[Kafka Simulator](/kafka-simulator/) のカリキュラムは **136 本中 136 本**で完成します。

このリリースは、それらのシナリオを取り巻くプレイグラウンドを作り直したリリースでもあります。v1.9 以降、ほぼすべての部分が変わりました。キャンバスには 3 つのビューができ、タイムラインは読めるものになり、インスペクターはフィールドを並べる代わりに問いに答えるようになり、ターミナルはキャンバスを隠さなくなりました。

## v2.0 の内容

**Schema Registry（`schema-registry`、3 本）。** [サブジェクトとバージョン](/kafka-simulator/scenarios/subjects-and-versions/)、[backward、forward、full の互換性がそれぞれ何をチェックするのか](/kafka-simulator/scenarios/compatibility-modes/)、そして[登録される前に拒否される破壊的変更](/kafka-simulator/scenarios/breaking-change-rejected/)です。

**認可（`authorization`、2 本）。** データパス上のアクセス制御です。オーソライザーがデフォルトで拒否するとき、[ACL](/kafka-simulator/scenarios/acls-authorizing-a-producer/) や [RBAC のロールバインディング](/kafka-simulator/scenarios/rbac-role-bindings/)が produce をどう許可し、どう拒否するのかを扱います。

どちらも新しい**ガバナンス階層**とともにフリープレイに登場します。Schema Registry、ACL と RBAC の操作、そしてターミナルの `kafka-acls` がそろうので、シナリオで見たものを自分の手で組み立て直し、壊してみることができます。

**シェアグループ（`share-groups`、9 本）。** KIP-932 で導入された [Kafka のキューセマンティクス](/kafka-simulator/scenarios/share-group-queue/)です。

- シェアグループでは、[1 つのパーティションを多数のコンシューマーで処理でき](/kafka-simulator/scenarios/cooperative-beyond-partitions/)、コミット済みオフセットではなくレコード単位で確認応答します。
- [取得（acquire）、確認応答（acknowledge）、解放（release）](/kafka-simulator/scenarios/acknowledge-accept-release-reject/) - キュー型の消費を支える、レコードごとのライフサイクルです。
- 配信回数の上限と[ポイズンピルの経路](/kafka-simulator/scenarios/share-group-poison-pill/) - 失敗し続けるレコードが、永遠に再配信されるのではなくアーカイブされる仕組みです。

シェアグループは Kafka の消費のあり方を変えます。従来のコンシューマーグループと並べて見ると、何が違うのかがよく分かります。

**キャップストーン（`capstones`、5 本）。** 耐久性、トランザクション、ストレージ、マルチ DC、ガバナンスを組み合わせ、複数のことが同時に起きるエンドツーエンドのシナリオです。[リージョンを失っても生き残る exactly-once の決済パイプライン](/kafka-simulator/scenarios/exactly-once-payments-pipeline/)、[データ損失ゼロのリージョンフェイルオーバー](/kafka-simulator/scenarios/survive-regional-outage-zero-loss/)、[Cluster Linking によるダウンタイムゼロの移行](/kafka-simulator/scenarios/migrate-with-cluster-linking/)、[マルチ DC のアクティブ/アクティブなバックボーン](/kafka-simulator/scenarios/active-active-event-backbone/)、そして[スループットとレイテンシを同時にチューニングしたパイプライン](/kafka-simulator/scenarios/tune-high-throughput-low-latency/)です。

**ディザスタリカバリ（`dr`、1 本追加）。** [アクティブ-アクティブ DR 訓練](/kafka-simulator/scenarios/active-active-dr-drill/)です。west リージョンを失い、その producer と consumer group を east へ移して書き込みを続け、west を再起動したら元に戻します。何も昇格させず、west がミラーしなかったレコードがその代償です。

**プロデューサー（`producer`、1 本追加）。** [ラック対応パーティショニング](/kafka-simulator/scenarios/rack-aware-partitioning/)です。Kafka 4.4 の新機能で、プロデューサーはキーのないレコードを自分のアベイラビリティゾーン内にとどめ、そのゾーンがリーダーを失うまでそれを続けます。詳しくは下の「Apache Kafka 4.4」で説明します。

## ディスクレストピック（KIP-1150 の方針、KIP-1163/1164 のドラフト）

ディスクレストピックは、パーティションのデータをブローカーのディスクではなくオブジェクトストレージに置きます。ブローカーは多数のパーティションのレコードをバッファし、1 つの WAL オブジェクトとしてアップロードします。そのオブジェクトをコミットするときにディスクレスコーディネーターがオフセットを割り当て、produce はコミットの時点で ack されます。レプリカはリーダーからフェッチするのではなく、ストレージからオブジェクトを読み戻してログを組み立て、プロデューサーとコンシューマーは自分と同じアベイラビリティゾーンのレプリカを使います。

現状について。[KIP-1150](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics) は方針として承認されていますが、仕組みを定義する [KIP-1163](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1163%3A+Diskless+Core) と [KIP-1164](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1164%3A+Diskless+Coordinator) はまだ Under Discussion です（実装は [KAFKA-19161](https://issues.apache.org/jira/browse/KAFKA-19161) で追跡されています）。私たちは現在のドラフトをモデル化し、シミュレータ全体で「KIP draft」と表示しています。Kafka に実際に入るまでに、名前や振る舞いが変わる可能性があります。

**3 本のシナリオ（`storage`、05.4.1-05.4.3）:**

- **[ディスクレス: 書き込みパス](/kafka-simulator/scenarios/diskless-write-path/)** - 2 つのプロデューサーと 2 つのパーティションが 1 つの WAL オブジェクトを共有し、コーディネーターがコミットするまでオフセットは存在しません。レプリカはデータをオブジェクトストレージから読み戻します。
- **[AZ をまたぐレプリケーションなし](/kafka-simulator/scenarios/no-cross-az-replication/)** - 同じ 3 件のレコードを、3 つの AZ にまたがる従来型のトピックとディスクレストピックに送ります。Cross-AZ traffic カードの最終値は、従来型が 7 ホップ、ディスクレスが 0 ホップです。
- **[代償はレイテンシ](/kafka-simulator/scenarios/diskless-produce-latency/)** - 同じ `acks=all` の produce が、従来型のトピックでは 300 ms、ディスクレストピックでは 1300 ms で ack されます。一方、バッファを満たすバーストは 800 ms で ack されます。各ステップが見えるよう、タイミングは拡大してあります。

**フリープレイでは:** **Diskless 3 AZ** プリセット、トピックごとのディスクレス切り替え、そしてディスクレスのタイミング用スライダーが加わります。キャンバスには独自の時間軸を持つオブジェクトストレージのレーン、各ブローカーの下の WAL トレイ、コーディネーターのバッジが、メトリクスパネルには **Cross-AZ traffic** カードが加わります。ターミナルでは、`kafka-topics --create --config diskless.enable=true` でディスクレストピックを作成でき、`kafka-diskless-metadata`（これ自体もドラフトのツールで、まだ Apache Kafka には入っていません）がパーティションごとのオフセットを表示し、ストレージ内の WAL オブジェクトを一覧します。

トレードオフを一言で言えば、AZ をまたぐレプリケーションのトラフィックが減る代わりに、produce が遅くなります。ドラフトが目標とする produce レイテンシは、P50 で約 500 ms、P99 で 1-2 秒です。従来の Kafka でもすでに同じ AZ のフォロワーから読めるので（KIP-392）、ディスクレスが加えるのは、ブローカー間のレプリケーションがなくなることと、produce がリーダーに届く必要がなくなることです。

## Apache Kafka 4.4

モデルは今週リリースされた Apache Kafka 4.4 に準拠するようになりました。4.3.0 と 4.4.0 を比較しましたが、シミュレーターが依拠しているデフォルト値、CLI の出力、エラーメッセージで変わったものはありませんでした。シナリオの挙動はこれまでと同じです。

v2.0 は 4.4 の新機能を 1 つモデル化しています。プロデューサーのラック対応パーティショニング（[KIP-1123](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1123%3A+Rack-aware+partitioning+for+Kafka+Producer)）です。`partitioner.rack.aware=true` と `client.rack` を設定すると、デフォルトのパーティショナーはキーのないレコードを、リーダーがプロデューサーと同じアベイラビリティゾーンにあるパーティションへ送ります。そのゾーンにリーダーがなければ、どのパーティションにも送ります。こうしてプロデュースのトラフィックがゾーン内にとどまります。新しいシナリオ [ラック対応パーティショニング](/kafka-simulator/scenarios/rack-aware-partitioning/) で両方のケースを見られます。フリープレイでは、プロデューサーのインスペクターにスイッチがあり、サンドボックス開始時のプロデューサーは `client.rack` を選べます。`client.rack` がなければ、Kafka と同じくプロデューサーはこの設定を受け付けません。

もう 1 つの 4.4 の新機能、シェアグループのデッドレターキュー（KIP-1191）は、まだモデル化していません。

## 作り直したプレイグラウンド

### クラスタを見る 3 つの方法

キャンバスには 3 つのビューがあり、ツールバーで切り替えます。

- **Brokers** はおなじみの絵です。左にプロデューサー、中央にクラスタ、右にコンシューマーグループとシェアグループが並びます。
- **Lanes** は、共通のオフセット軸の上にパーティションごとに 1 行を描きます。レプリカはリーダーを先頭に上下に並び、ハイウォーターマークはそれらすべてを貫く 1 本の線になります。遅れているフォロワーはログが目に見えて短く、停止したブローカーのログは動かず、各コンシューマーはコミット済みオフセットとラグを伴って読み取り位置に置かれます。全員がログのどこにいるのかが一目で分かります。
- **Matrix** は、描ききれないほど大きなクラスタ向けです。縦にトピック、横にブローカーを並べた表で、**Failures**、**Balance**、**Lag**、**Traffic** の 4 つのレンズが、表を色分けし、悪いものから順に並べ替えます。ブローカーにホバーすると、停止する前に、クラスタが何を失うのかがトピックごとに表示されます。大きなフリープレイクラスタは、自動的に Matrix で開きます。

### キャンバスが変化を見せる

状態の変化は、汎用的なパルスではなく、変化した要素そのものの上で再生されるようになりました。ハイウォーターマークのマーカーは新しいオフセットへスライドし、リーダーの王冠は古いリーダーから新しいリーダーへ移り、フォロワーの ISR タグは変化に応じた色になります。produce されたレコードは自分のログセルに着地し、混み合ったキャンバスではレコードが短い軌跡として描かれます。停止したブローカーは薄く表示されたままキャンバスに残るので、そこに何があったのかが分かります。マルチリージョンのキャンバスでは、ミラーリンクが自分の RPO を示し、各 DC の帯はそれを失ったときのコストを示し、ネットワーク分断ではどちら側がサービスを続けるのかが表示され、KRaft のストリップは過半数を数え、シェアグループのレーンは各レコードのロックタイマーと配信回数を示します。

### 読めるタイムライン

デスクトップでは、下部のドックが 1 行の**レール**になりました。フレームは実際のシミュレーション時刻の位置に置かれるので、バーストはひと固まりに、静かな時間は隙間として読み取れます。スクラブはレールに沿ってドラッグするだけです。**イベントレーン**を開くと、実行中のすべてのイベントが produce、replicate、brokers、consume の各レーンに並び、障害は赤で、各フレームの主要なイベントには印が付きます。

### 問いに答えるインスペクター

右パネルは、あなたが投げかける問いから始まるようになりました。パーティションはオフセットの定規として、ブローカーは停止したときに失うものとして、トピックはパーティションごとのレーンとして、プロデューサーは送信経路として、コンシューマーグループはレーンまたはパーティションのグリッドとして表示されます。**Why** は何が壊れたのか、そしてなぜなのかを挙げ、**Metrics** は役割ごとにまとめられています。一部のインスペクターは、現在の状態だけでなく、次に何が起きるのかも示します。マルチリージョンのビューには DR カードが加わり、各リージョンのログと、まだミラーされていない末尾を RPO として表示します。

### キャンバスがターミナルの場所を作る

Kafka CLI ターミナルはこれまでどおりキャンバスの下に収まりますが、キャンバスはその後ろに隠れるのではなく、場所を空けるようになりました。そのため、`kafka-server-stop` と broker-1 が落ちる様子が同時に画面に映り、ターミナルは入力したコマンドとツールの出力にキャンバスの幅をすべて使えます。ワイドな画面では、タイトルバーの **dock side** でキャンバスの横の列に移せます。出力は列の揃いを保ち、ホストメニューはすべてのブローカーとコントローラーを並べた `ssh` の表になりました。ブローカーの設定ファイルは Kafka 4.4 に合わせてあり、`kafka-reassign-partitions --generate` や、ブローカーを削除する前のドレインも、実際のクラスタと同じように動きます。

### ツアーなしで始める

13 ステップのモーダルツアーはなくなりました。代わりに、キャンバスの隅に **Getting started** カードがあります。同じ内容を、好きな順番で進められるチェックリストにしたもので、各項目に「Show me」が付いています。ヘルプは調べものをするためのリファレンスになりました。台本のあるシナリオは Undo 付きのサンドボックスとしてフォークでき、シナリオは自分から「Try it yourself」の操作や次にやることを提案し、共有されたリンクは、表示している状態にどうやってたどり着いたのかを再生するようになりました。

### 新しい見た目と、アクセシビリティの見直し

プレイグラウンドを含むサイト全体が、私たちの名前の由来であるコクマルガラスをもとにした新しい見た目になりました。濃いインク色、青い光沢、そしてグレーで、すべてのテキストの色の組み合わせが WCAG AA を満たしています。あわせて、スキップリンクと名前付きのランドマーク領域、タブストップが 1 つだけのシナリオレール、非アクティブ領域の AA コントラスト、押したときのフィードバックと大きくしたタッチターゲット、そして `prefers-reduced-motion` を尊重し、フェードは残して動きをなくすモーションが加わりました。スマートフォンのレイアウトも個別に見直し、すべてのラベルがまだ収まっているかを確かめるテストまで用意しています。

## プレイグラウンドの外で

プレイグラウンド自体は検索エンジンにインデックスされないので、シナリオのテキストが検索エンジンの目に触れることはありませんでした。いまでは [/kafka-simulator/scenarios/](/kafka-simulator/scenarios/) の下に、**シナリオごとの専用ページ**があります。導入と結論、「Open at this step」リンク付きのすべてのステップ、ステップ実行できる実際のキャンバスのフレーム、そしてそのシナリオが扱う Kafka の設定が載っています。v2.0 で、その数は 136 ページになりました。

その隣には、Kafka のエラーや症状を扱う **[トラブルシューティングページ](/kafka-simulator/troubleshooting/)** があります。問題が何を意味するのか、考えられる原因、修正方法とやってはいけないこと、クライアントがリトライするかどうか。各ページは、その問題が起きるシナリオに、まさにそれが起きる瞬間を開いた状態でリンクしています。このリリースで、認可のページも加わりました。[変更履歴](/kafka-simulator/changelog/)は、タイムライン上のリリースノートとして読めるようになりました。

## もう 1 つだけ

このリリースには、あるものを隠してあります。見つけるのは、あなたにお任せします。

## ロードマップの終わり

v2.0 は、v1.0 で始まったものを完成させます。隔週で 11 のパック、136 本のシナリオ。単一ブローカーの解剖から、キューやプラットフォーム全体にわたるキャップストーンまで。すべてがブラウザ内で、決定的に、Apache Kafka 4.4 のセマンティクスに基づいて動きます。バックエンドはなく、あなたのシナリオに関するテレメトリも一切ありません。

カリキュラムは完成しましたが、シミュレータは修了して終わりのコースではなく、サンドボックスです。[シミュレータ](/kafka-simulator/)を開き、何かを組み立てて、壊してみてください。