A v2.0 é o último pacote do currículo. Ela acrescenta quatro módulos - schema-registry, authorization, share-groups e capstones - além de três cenários de tópicos diskless no módulo storage, um exercício de DR active-active no módulo dr e o particionamento com reconhecimento de rack no módulo producer, 24 novos cenários no total. Ela desbloqueia as camadas governance e diskless no free play e completa o currículo do Kafka Simulator em 136 de 136.

Esta também é a versão em que o playground em volta desses cenários foi reconstruído. Desde a v1.9, quase todas as partes dele mudaram: o canvas tem três visões, a linha do tempo virou algo que dá para ler, os inspetores respondem a perguntas em vez de listar campos, e o terminal não cobre mais o canvas.

O que há na v2.0

Schema Registry (schema-registry, 3 cenários). Subjects e versões, o que as compatibilidades backward, forward e full verificam e uma mudança incompatível rejeitada antes de ser registrada.

Autorização (authorization, 2 cenários). Controle de acesso no caminho dos dados - como uma ACL, ou um role binding do RBAC, permite ou nega um produce quando o autorizador nega por padrão.

Os dois chegam ao free play com a nova camada de governança: Schema Registry, controles de ACL e RBAC e kafka-acls no terminal, para que você possa reconstruir e quebrar à mão tudo o que os cenários mostram.

Share groups (share-groups, 9 cenários). A semântica de fila do Kafka, introduzida na KIP-932:

Os share groups mudam a forma como o Kafka é consumido, e vê-los ao lado dos grupos de consumidores clássicos mostra o que é diferente.

Capstones (capstones, 5 cenários). Cenários de ponta a ponta que combinam durabilidade, transações, armazenamento, multi-DC e governança, com mais de uma coisa acontecendo ao mesmo tempo: um pipeline de pagamentos exactly-once que sobrevive à perda de uma região, um failover regional sem perda de dados, uma migração sem downtime com Cluster Linking, um backbone ativo/ativo multi-DC e um pipeline ajustado para throughput e latência ao mesmo tempo.

Recuperação de desastres (dr, mais 1 cenário). Um exercício de DR active-active: a região west cai, seu producer e seu consumer group passam para east e continuam escrevendo, depois west reinicia e eles voltam. Nada é promovido, e os registros que west nunca espelhou são o preço.

Producer (producer, mais 1 cenário). Particionamento com reconhecimento de rack, novidade do Kafka 4.4: um producer mantém os registros sem chave na sua própria zona de disponibilidade, até essa zona perder os seus líderes. Mais detalhes abaixo, em Apache Kafka 4.4.

Tópicos diskless (direção da KIP-1150, rascunho das KIP-1163/1164)

Um tópico diskless guarda os dados das suas partições no armazenamento de objetos, e não nos discos dos brokers. Um broker acumula em buffer registros de muitas partições e os envia como um único objeto WAL; um coordenador diskless atribui os offsets quando faz o commit desse objeto, e o produce recebe o ack nesse commit. As réplicas montam o seu log lendo o objeto de volta do armazenamento, em vez de buscá-lo no líder, e produtores e consumidores usam uma réplica na sua própria zona de disponibilidade.

A situação atual: a KIP-1150 foi aceita como direção, enquanto a KIP-1163 e a KIP-1164, que definem como isso funciona, ainda estão em Under Discussion (a KAFKA-19161 acompanha a implementação). Modelamos o rascunho atual e o marcamos como “KIP draft” em todo o simulador. Nomes e comportamento podem mudar antes que qualquer parte disso chegue ao Kafka.

Três cenários (storage, 05.4.1-05.4.3):

  • Diskless: o caminho de escrita - dois produtores e duas partições compartilham um único objeto WAL, nenhum offset existe até o coordenador fazer o commit dele, e as réplicas leem os dados de volta do armazenamento de objetos.
  • Sem replicação entre AZs - os mesmos 3 registros vão para um tópico clássico e para um diskless, distribuídos em três AZs; o card Cross-AZ traffic termina com 7 saltos no clássico e 0 no diskless.
  • O preço é a latência - o mesmo produce com acks=all recebe o ack em 300 ms em um tópico clássico e em 1300 ms em um diskless, enquanto uma rajada que enche o buffer recebe o ack em 800 ms. Os tempos estão ampliados para que cada passo fique visível.

No free play: um preset Diskless 3 AZ, uma opção diskless por tópico e controles deslizantes para os tempos do diskless. O canvas ganha uma faixa de armazenamento de objetos com o seu próprio eixo de tempo, bandejas de WAL sob cada broker e um selo do coordenador, e o painel de métricas ganha um card Cross-AZ traffic. No terminal, kafka-topics --create --config diskless.enable=true cria um tópico diskless, e kafka-diskless-metadata (ela mesma uma ferramenta em rascunho, que ainda não está no Apache Kafka) mostra os offsets por partição e lista os objetos WAL no armazenamento.

O trade-off em resumo: menos tráfego de replicação entre AZs, produces mais lentos - o rascunho mira uma latência de produce em torno de 500 ms no P50 e de 1-2 s no P99. O Kafka clássico já consegue ler de um follower na mesma AZ (KIP-392), então o que o diskless acrescenta é a ausência de replicação de broker para broker e um produce que não precisa chegar ao líder.

Apache Kafka 4.4

O modelo agora segue o Apache Kafka 4.4, lançado nesta semana. Comparamos a 4.3.0 com a 4.4.0 e não encontramos nenhum valor padrão, saída da CLI ou mensagem de erro em que o simulador se apoie que tenha mudado, então tudo nos cenários se comporta como antes.

A v2.0 modela uma novidade da 4.4: o particionamento com reconhecimento de rack no producer (KIP-1123). Com partitioner.rack.aware=true e um client.rack, o particionador padrão envia os registros sem chave para partições cujo líder está na zona de disponibilidade do producer, e para qualquer partição quando essa zona não tem líder, o que mantém o tráfego de produção dentro da zona. O novo cenário Particionamento com reconhecimento de rack mostra os dois casos. No free play, o inspetor do producer tem o interruptor, e os producers com que um sandbox começa podem escolher o seu client.rack. Sem client.rack, o producer recusa a configuração, como o Kafka faz.

As dead-letter queues dos share groups (KIP-1191), outra novidade da 4.4, ainda não são modeladas.

Um playground reconstruído

Três maneiras de ver um cluster

O canvas agora tem três visões, alternadas pela sua barra de ferramentas:

  • Brokers é a imagem conhecida: produtores à esquerda, o cluster no meio, grupos de consumidores e share groups à direita.
  • Lanes desenha uma linha por partição sobre um eixo de offsets compartilhado: as réplicas uma embaixo da outra, o líder primeiro, o high watermark como uma única linha atravessando todas. Um follower atrasado tem um log visivelmente mais curto, o log de um broker parado fica imóvel, e cada consumidor aparece na sua posição de leitura com o seu offset confirmado e o seu lag. Você vê num relance onde cada um está no log.
  • Matrix é para clusters grandes demais para desenhar: uma tabela com tópicos nas linhas e brokers nas colunas, e quatro lentes - Failures, Balance, Lag e Traffic - que a colorem e ordenam do pior para o melhor. Passar o mouse sobre um broker mostra o que o cluster perderia, tópico a tópico, antes que você o pare. Um cluster grande de free play já abre em Matrix.

O canvas mostra o que mudou

As mudanças de estado agora são animadas no elemento que mudou, em vez de um pulso genérico: os marcadores de high watermark deslizam até o novo offset, a coroa do líder passa do líder antigo para o novo, e a etiqueta de ISR de um follower assume a cor da mudança. Um registro produzido cai na sua própria célula do log, um canvas movimentado desenha os registros como rastros curtos, e um broker parado continua no canvas, esmaecido, para que você veja o que estava ali. Nos canvas multirregião, o link de mirror mostra o seu RPO, cada faixa de DC diz quanto custaria perdê-lo, uma partição de rede mostra qual lado continua atendendo, a faixa do KRaft conta a sua maioria, e a faixa de um share group mostra o timer de lock e a contagem de entregas de cada registro.

Uma linha do tempo que dá para ler

No desktop, a dock inferior agora é um trilho de uma linha: os quadros ficam no seu tempo real de simulação, de modo que uma rajada aparece como um aglomerado e um trecho tranquilo como um vão, e você navega arrastando ao longo dele. Abra as suas faixas de eventos e todos os eventos da execução aparecem distribuídos nas faixas de produce, replicação, brokers e consumo, com as falhas em vermelho e o evento principal de cada quadro destacado.

Inspetores que respondem a perguntas

O painel direito agora parte das perguntas que você faz. Uma partição aparece como uma régua dos seus offsets, um broker como aquilo que você perde quando ele para, um tópico como uma faixa por partição, um produtor como o seu caminho de envio, e um grupo de consumidores como faixas ou como uma grade de partições. Why lista o que quebrou e por quê, as Metrics são agrupadas por papel, e alguns inspetores mostram o que vai acontecer em seguida, não só o estado atual. As visões multirregião ganham um card de DR que mostra o log de cada região e a cauda não espelhada como RPO.

O canvas abre espaço para o terminal

O terminal da CLI do Kafka continua acoplado embaixo do canvas, mas agora o canvas abre espaço para ele em vez de ficar escondido atrás dele - então kafka-server-stop e o broker-1 caindo aparecem juntos na tela, e o terminal tem toda a largura do canvas para o que você digita e para o que as ferramentas imprimem. Em uma tela larga, dock side na barra de título dele o leva para uma coluna ao lado do canvas. A saída mantém as suas colunas, e o menu de hosts é uma tabela ssh com todos os brokers e controladores. Os arquivos de configuração dos brokers correspondem ao Kafka 4.4, e kafka-reassign-partitions --generate, assim como drenar um broker antes de removê-lo, funcionam como em um cluster real.

Primeiros passos, sem tour

O tour modal de 13 passos acabou. No lugar dele há um card Getting started no canto do canvas: os mesmos tópicos em forma de checklist, que você percorre em qualquer ordem, cada um com um “Show me”. A ajuda agora é uma referência para consultar, um cenário roteirizado pode virar um sandbox com Undo, os cenários sugerem os seus próprios movimentos de “Try it yourself” e o que fazer em seguida, e um link compartilhado agora reproduz como chegou ao estado que mostra.

Um visual novo e uma revisão de acessibilidade

O site inteiro, playground incluído, ganhou um visual novo inspirado na gralha do nosso nome: tinta escura, um brilho azulado e cinza, com todos os pares de cores de texto no nível WCAG AA. Junto com ele vieram skip links e regiões nomeadas, um trilho de cenários com uma única parada de tab, contraste AA para regiões inativas, feedback ao toque e alvos de toque maiores, e movimento que respeita prefers-reduced-motion, mantendo os fades e eliminando o deslocamento. O layout para celular teve a sua própria revisão, até um teste que garante que todo rótulo ainda cabe.

Fora do playground

O playground em si não é indexável, então os mecanismos de busca nunca viram o texto dos seus cenários. Agora cada cenário tem a sua própria página em /kafka-simulator/scenarios/: a sua introdução e conclusão, cada passo com um link “Open at this step”, um quadro real do canvas que você pode percorrer passo a passo, e as configurações do Kafka que ele envolve. Com a v2.0, são 136 páginas.

Ao lado delas estão as páginas de troubleshooting para erros e sintomas do Kafka - o que o problema significa, as causas prováveis, as correções e o que não fazer, se o cliente tenta de novo ou não - cada uma ligada aos cenários em que o problema acontece, abertos no momento exato em que ele aparece. A página de autorização se junta a elas nesta versão. O changelog agora se lê como notas de versão em uma linha do tempo.

Mais uma coisa

Escondemos algo nesta versão. Encontrar fica por sua conta.

O fim do roadmap

A v2.0 conclui o que começou na v1.0: onze pacotes quinzenais, 136 cenários, da anatomia de um único broker até filas e capstones de plataforma completa. Tudo roda no navegador, de forma determinística, com a semântica do Apache Kafka 4.4, sem backend e sem telemetria sobre os seus cenários.

O currículo está completo, mas o simulador é um sandbox, não um curso que se termina. Abra o simulador, construa algo e quebre.