Como migrar do Apache Kafka open source para a Confluent sem parar a operação

Muitas organizações da região chegaram ao Apache Kafka pelo caminho certo: uma equipe com bom critério subiu o cluster para resolver um problema concreto, funcionou, e ele foi virando infraestrutura crítica sem que ninguém tomasse a decisão formal de que seria.

O ponto de ruptura chega quando esse cluster que começou como projeto de uma equipe sustenta processos que não podem cair, e a organização percebe que a operação depende de duas ou três pessoas que sabem como aquilo funciona.

É aí que aparece a conversa sobre migrar para uma plataforma gerenciada. E é aí que a maioria dos planos se quebra, porque são desenhados como um corte.

Por que a janela de manutenção não funciona

O instinto natural é agendar um fim de semana, mover tudo e voltar na segunda-feira. Com um banco de dados às vezes dá. Com uma plataforma de eventos, quase nunca.

A razão é que o Kafka não é um repositório, é um fluxo com estado distribuído em muitos consumidores. Migrar significa mover não só os dados, mas a posição de leitura de cada aplicação consumidora, e fazer isso de forma que nenhuma reprocesse o que já processou nem pule o que faltava.

Com cinco aplicações pode dar certo. Com quarenta, a probabilidade de que todas as quarenta fiquem exatamente onde deveriam estar na mesma janela é baixa. E o modo de falha não é um erro visível: é um consumidor que ficou atrasado e ninguém percebe até aparecer uma diferença em uma conciliação três dias depois.

Convivência em vez de corte

A abordagem que aplicamos é outra: os dois clusters operam em paralelo durante a migração, e os domínios se movem de um para o outro quando cada um está pronto.

A peça que torna isso possível é a replicação entre clusters. Os topics são replicados da origem para o destino de forma contínua, incluindo a posição dos consumidores. Isso transforma um evento único e irreversível em uma série de decisões pequenas e reversíveis.

A ordem que funcionou para nós:

Primeiro se replica, sem mover ninguém. O cluster destino recebe tudo e ninguém consome. Aqui se validam o desempenho, a retenção, os esquemas e o dimensionamento real, com tráfego de produção e sem risco.

Depois se movem os consumidores, não os produtores. Um consumidor que lê do destino em vez da origem é uma mudança de configuração reversível. Se algo der errado, ele volta a apontar para a origem e segue operando. Começa-se pelos consumidores menos críticos.

No final se movem os produtores, domínio por domínio. Este é o passo que torna o corte irreversível para aquele domínio, e por isso é o último. Quando um produtor escreve no destino, seus consumidores já vêm lendo dali há tempo sem incidentes.

A origem se desliga quando ninguém mais a usa, não quando o plano dizia que era a hora.

O que se descobre pelo caminho

Uma migração de streaming quase sempre revela coisas que estavam escondidas. Vale esperá-las em vez de ser surpreendido por elas.

Topics que ninguém consome. É comum descobrir que parte do que está sendo publicado não é lido por ninguém há meses. Migrar é uma boa oportunidade para parar de pagar por movê-los.

Esquemas que na verdade não existem. Muitos clusters open source operam sem Schema Registry, com o contrato vivendo na cabeça da equipe que o escreveu. Ao passar para uma plataforma com Schema Registry aparecem as incompatibilidades que estavam latentes. É melhor que apareçam na migração do que em um incidente.

Configurações de retenção herdadas. Retenções de sete dias colocadas por padrão três anos atrás, sobre topics em que o negócio precisaria de trinta, ou o contrário.

Consumidores que dependem da ordem sem saber. Aplicações que funcionam porque as partições chegaram até elas em certa ordem e ninguém documentou isso.

O que é preciso ter antes de começar

Antes de replicar o primeiro topic, convém ter três coisas resolvidas.

Um inventário real de produtores e consumidores, não o diagrama de arquitetura, mas quem está conectado hoje. Quase sempre divergem.

Um critério de domínio para decidir o que se move junto. Mover por ordem alfabética de topic garante problemas; mover por domínio de negócio, não.

Uma definição explícita do que significa um domínio estar migrado, acordada antes e não negociada durante. Sem isso, cada corte vira uma discussão.

Quanto tempo leva

Depende quase inteiramente do número de aplicações produtoras e de quão acoplado está o consumo, não do volume de dados. Um cluster com muito tráfego e poucas aplicações se migra rápido. Um cluster médio com dezenas de aplicações de equipes diferentes leva bem mais tempo, porque o trabalho real é de coordenação, não técnico.

O que dá para afirmar com segurança é o contrário do instinto inicial: não é preciso parar a operação. Se o plano de migração exige uma janela de indisponibilidade para uma plataforma de eventos, provavelmente o plano está errado.