Ata 04 · Arquitetura de Integrações: Confluent Kafka, OpenShift, Dados e DevOps (09 de julho de 2026)¶

Relatório detalhado da reunião, estruturado a partir da transcrição integral do encontro.


Data	09 de julho de 2026
Horário	10h37 às 12h05 (America/Sao_Paulo)
Duração aproximada	1h28min
Gravação	Vladimir Morozowski de Sousa
Objetivo	Levantamento do ambiente atual, dores, riscos e insumos para revisão arquitetural
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Fontes	Transcrição integral da reunião e compilação produzida na análise do encontro

Índice do relatório¶

Resumo executivo
Contexto, objetivo e escopo do assessment
Participantes e áreas citadas
Visão geral da arquitetura atual
Fluxos de dados e uso do CDC
Segregação entre cargas operacionais e BI e plataforma de dados
Legado, múltiplas empresas e divergência de esquemas
Schema Registry e débitos técnicos
Homologação, testes e representatividade de produção
KSQLDB, consolidação multiempresa e escalabilidade
Particionamento, consumer lag e escalabilidade das aplicações
Storage e dependências do OpenShift
Autenticação LDAP
Licenciamento e capacidade
Disaster Recovery e continuidade
Observabilidade e operação
Riscos consolidados
Recomendações priorizadas
Próximos passos acordados na reunião
Artefatos solicitados para o assessment
Questões em aberto
Conclusão

Anexo A: glossário técnico

1.5.1. Resumo executivo¶

A reunião teve como finalidade apresentar ao time responsável pelo assessment a arquitetura atual de integrações baseada em Confluent Kafka sobre OpenShift, esclarecer a divisão de responsabilidades entre Infraestrutura, DevOps e Desenvolvimento, e registrar as principais dores operacionais e arquiteturais que deverão orientar a revisão do ambiente.

O ambiente atende integrações operacionais, regulatórias, de BI e da plataforma de dados. A principal preocupação é que cargas com perfis muito diferentes compartilham atualmente recursos de conexão, processamento e storage, o que provoca interferência entre workloads, principalmente quando tabelas de grande volumetria e alta taxa de atualização entram no fluxo de CDC.

Também foram identificados riscos relevantes associados ao legado: nove bancos correspondentes às empresas do grupo, divergências de esquemas entre tabelas homônimas, ausência de um ambiente de homologação representativo da produção, testes predominantemente funcionais, escalabilidade reativa, uso intensivo de KSQLDB para consolidação multiempresa, dependência de storage compartilhado, débitos técnicos de Schema Registry e um processo de disaster recovery ainda incompleto.

Conclusão central

A arquitetura funciona e suporta cargas produtivas, porém seu crescimento está elevando a complexidade operacional. O próximo estágio exige segregação de workloads, governança de esquemas, testes não funcionais, revisão da estratégia de consolidação de dados, fortalecimento do DR e maior integração entre Infraestrutura, OpenShift, DevOps, Desenvolvimento, Administração de Dados e Plataforma de Dados.

1.5.2. Contexto, objetivo e escopo do assessment¶

A iniciativa decorre de uma solicitação anterior para avaliar e revisar a arquitetura de integração como um todo. O trabalho não se limita a um componente ou conflito específico: a intenção é entender a estrutura completa, revisar as decisões arquiteturais adotadas e propor mudanças quando necessárias.

Equipe de assessment mencionada: João, Vladimir e Castellani, com apoio dos responsáveis internos pelo ambiente.
Escopo técnico: Confluent Kafka, OpenShift, conectores, CDC, KSQLDB, Schema Registry, observabilidade, DevOps, storage, licenciamento, escalabilidade, DR e dependências com aplicações.
Interlocuções adicionais consideradas necessárias: equipes de Desenvolvimento, OpenShift, F5, API Gateway e Sensedia, Administração de Dados e Plataforma de Dados.
Existe uma frente paralela de trabalho com IBM e Confluent, com reuniões recorrentes, cujas propostas deverão ser correlacionadas ao assessment.

1.5.3. Participantes e áreas citadas¶

A transcrição apresenta identificação parcial dos participantes. Foram citados ou reconhecidos nominalmente: Vladimir Morozowski de Sousa, João, Vinícius, Gabriel, Norberto (Roberto), Fabiano, Castellani, Lucas, Guilherme e Fabrício. Também foram mencionadas as áreas de Infraestrutura, DevOps, Desenvolvimento, OpenShift, Administração de Dados, Plataforma de Dados e BI, F5 e API Gateway.

Nota de registro

Como os rótulos de falante da transcrição não permitem confirmar todos os nomes com absoluta segurança, este relatório privilegia responsabilidades e conteúdos, evitando atribuições individuais quando houver ambiguidade.

1.5.4. Visão geral da arquitetura atual¶

1.5.4.1. Plataforma e componentes¶

Confluent Kafka executado dentro do OpenShift.
Deploy dos componentes realizado por meio do Azure DevOps.
Componentes citados: Kafka brokers, Kafka Connect, KSQLDB, Schema Registry, Control Center e controllers em modo KRaft.
Uso de storage classes e volumes para dados e metadados do Kafka.
Observabilidade com Grafana e Prometheus nativos do OpenShift; logs centralizados no ambiente de logging citado como LK ou ELK.
F5 utilizado para load balancing e camada de acesso.
JFrog Artifactory e X-Ray utilizados no ciclo de aplicações e artefatos.
Microserviços atuam como produtores e consumidores, acessando brokers e, em parte dos casos, o Schema Registry.

1.5.4.2. Ambientes¶

Existem três ambientes: desenvolvimento, homologação e produção. Embora formalmente separados, desenvolvimento é pouco usado pelos times, e homologação absorve parte do desenvolvimento e dos testes antes da promoção para produção.

Desenvolvimento: uma réplica dos principais componentes; usado atualmente para testes de versão, compatibilidade, split de Connect e experimentos de DR e cobertura.
Homologação: semelhante ao desenvolvimento, com alguma capacidade adicional em Kafka Connect; não representa de forma adequada a volumetria, atualização e diversidade das bases produtivas.
Produção: três brokers, três KRaft controllers, dois Schema Registry, três KSQLDB, um Control Center e cinco pods de Kafka Connect, conforme apresentado na reunião.

1.5.4.3. Divisão de responsabilidades¶

Infraestrutura: recursos de base, storage, disco, memória, CPU, licenciamento OpenShift e vCPU e camadas abaixo da aplicação.
Equipe Kafka e Confluent: componentes do barramento e sua operação dentro do OpenShift.
DevOps: Azure DevOps, pipelines, Artifactory, X-Ray e mecanismos de deploy.
Desenvolvimento: construção e evolução dos microserviços consumidores e produtores.
Outros times da mesma estrutura: F5 e API Gateway com Sensedia.

1.5.5. Fluxos de dados e uso do CDC¶

As origens operacionais utilizam predominantemente Oracle e, em evolução, SQL Server. A captura de mudanças é feita via CDC. Para Oracle, foi adotado XStream após avaliação de alternativas como GoldenGate e LogMiner.

GoldenGate for Big Data foi considerado, mas o custo on-premises foi apontado como muito elevado para o projeto.
LogMiner apresentou limitações e falta de suporte em versões mais recentes do Oracle.
Foi realizada POC de aproximadamente um mês com XStream, que resultou na adoção da solução.
SQL Server está em processo de início e maturação no fluxo de CDC.
A plataforma de dados no Azure e Databricks recebe dados de diversas fontes, incluindo Kafka.

1.5.6. Segregação entre cargas operacionais e BI e plataforma de dados¶

A dor mais imediata é o compartilhamento do mesmo Kafka Connect por cargas operacionais e cargas voltadas a BI e Data Lake. Embora ambas usem CDC, seus comportamentos são diferentes: as tabelas de BI podem ter volumetrias muito elevadas, padrões de atualização fora da curva e processamento capaz de impactar fluxos operacionais.

A equipe está testando a separação do cluster de conexões em dois domínios: um operacional e outro dedicado a BI e plataforma de dados. A expectativa é retornar o domínio operacional a três pods e reservar dois pods para o fluxo de Data Lake e BI, dentro dos cinco pods atuais.

Objetivo: isolar impacto, melhorar previsibilidade e reduzir concorrência por recursos.
Risco residual: tabelas consumidas por operação e BI continuarão exigindo tratamento compartilhado ou duplicação controlada.
Próximo passo técnico: validar a separação em desenvolvimento, promover para homologação e, após os testes, implantar em produção.

1.5.7. Legado, múltiplas empresas e divergência de esquemas¶

O grupo possui nove empresas e bancos de dados. Tabelas com o mesmo nome podem apresentar estruturas diferentes, sobretudo nas bases mais antigas. Isso afeta captura, Schema Registry, consultas, consolidação e comportamento das aplicações.

Cada empresa possui uma conexão e um tópico ou origem correspondente.
O desenho vigente consolida as nove fontes para fornecer uma visão unificada às aplicações.
Consultas genéricas com seleção de todos os campos quebraram quando campos e esquemas divergiram.
A resposta tem sido substituir consultas genéricas por seleção explícita de campos e tratamentos individualizados.
Foi citado um caso em que um schema Avro extraído de uma empresa foi assumido como padrão para todas, causando falha em produção.
A Administração de Dados passou a realizar um crivo prévio e emitir alertas para tabelas conhecidas, embora o processo ainda não consiga simular todas as nove bases de forma completa.

Risco arquitetural

Sem um catálogo confiável de esquemas por empresa, uma alteração local pode provocar incompatibilidade em cadeia no CDC, no Schema Registry, no KSQLDB e nos consumidores.

1.5.8. Schema Registry e débitos técnicos¶

Os tópicos originados diretamente dos conectores de banco possuem esquema associado. Entretanto, alguns tópicos internos de aplicações, criados após processamento e aplicação de regras de negócio, foram implementados sem vínculo com o Schema Registry por pressão de prazo e facilidade de entrega.

O problema não está nos tópicos JDBC e CDC de origem, mas em determinados tópicos derivados pelas aplicações.
Esse cenário foi reconhecido como débito técnico e deve entrar em plano de regularização.
A governança precisa definir obrigatoriedade, compatibilidade, versionamento e exceções justificadas.

1.5.9. Homologação, testes e representatividade de produção¶

O ambiente de homologação não reproduz adequadamente a produção. Os bancos de homologação não têm atualização contínua, a volumetria é muito inferior e não há representação consistente das diferenças existentes entre as nove empresas.

Os testes atuais verificam principalmente se a aplicação funciona e se quebra ou não quebra.
Não há ambiente propício para testes de carga, estresse, performance, resiliência e comportamento sob sazonalidade.
Problemas de volumetria, particionamento e consumo são descobertos apenas após entrada em produção.
Quando existem testes não funcionais, são restritos a subconjuntos do cenário.

Implicação

A homologação reduz risco funcional, mas não reduz de forma suficiente o risco operacional. É necessário estabelecer uma capacidade de teste representativa, ainda que baseada em amostragem, replay controlado ou dados sintéticos.

1.5.10. KSQLDB, consolidação multiempresa e escalabilidade¶

A arquitetura atual usa KSQLDB para consolidar dados das nove empresas em tópicos unificados. A unificação facilita o consumo pelas aplicações e permite acrescentar o código da empresa de origem, mas gera crescimento expressivo do número de streams e queries.

Estimativa apresentada: cada tabela distribuída nos nove bancos pode gerar aproximadamente dez estruturas KSQLDB entre streams e consultas.
Para cerca de 100 tabelas, o ambiente pode alcançar aproximadamente mil estruturas KSQLDB.
Foi citado um patamar prático de cerca de 100 a 100 e poucas estruturas por pod, sinalizando gargalo e risco de expansão.
Novos projetos com dezenas de tabelas elevam significativamente a necessidade de capacidade e o custo.

Alternativas discutidas: consolidar previamente no banco por procedure; manter a consolidação em KSQLDB; implementar microserviço dedicado de consolidação; ou avaliar Flink por meio de POC. A migração direta de KSQLDB para Flink não é transparente e provavelmente exigirá reescrita.

1.5.11. Particionamento, consumer lag e escalabilidade das aplicações¶

As definições iniciais de particionamento nem sempre se confirmam quando a volumetria real chega à produção. Os times vêm reparticionando tópicos e ajustando aplicações de forma pontual, normalmente após identificação de lag ou degradação.

O processo de capacidade ainda é predominantemente reativo, não proativo.
Eventos de contingência em uma empresa podem aumentar abruptamente o volume em uma partição específica.
O HPA padrão do OpenShift é orientado a CPU e memória e pode não refletir backlog ou lag de consumo.
KEDA ou mecanismo equivalente foi estudado, mas ainda não estava implantado segundo a discussão.
O tempo de consumo também depende da lógica interna: tamanho dos lotes, processamento, escrita em logs e persistência em bancos.
Lags elevados aumentam o risco de perda ou recuperação incompleta em um desastre, especialmente em arquitetura ativo-passivo.

1.5.12. Storage e dependências do OpenShift¶

Foram relatados incidentes associados a manutenção e rebalanceamento de discos e indisponibilidade do OpenShift. Em um episódio histórico, a adição de disco provocou rebalanceamento prolongado; no dia anterior à reunião, ocorreu perda de acesso durante o expediente aparentemente relacionada ao storage.

Há percepção de que o storage é um pool compartilhado por Kafka e outras aplicações.
Uma degradação do storage pode impactar simultaneamente múltiplos ambientes e serviços.
Kafka é altamente dependente de latência e throughput de disco; portanto, o tema foi classificado como preocupante.
Os pods críticos usam regras de afinidade e anti-afinidade, tolerations e distribuição de uma réplica por node, reduzindo falhas correlacionadas no nível lógico.
Permanece a necessidade de confirmar com a equipe OpenShift se os nodes estão em hardware físico efetivamente segregado ou apenas separados logicamente.

1.5.13. Autenticação LDAP¶

O ambiente enfrentou falhas intermitentes de autenticação quando utilizava uma busca genérica no LDAP. A indisponibilidade ou mudança de servidores encontrados pela busca podia impedir autenticação do Kafka.

A mitigação adotada foi declarar primeiro três servidores nomeados e usar a busca genérica apenas como fallback.
A medida reduziu significativamente a frequência do problema nos três ambientes.
Ainda é recomendável formalizar monitoramento, health check, timeout e estratégia de fallback do serviço de identidade.

1.5.14. Licenciamento e capacidade¶

O ambiente produtivo foi apresentado como licenciado, com 18 licenças e uma unidade ainda disponível no momento da reunião. A licença foi descrita como vinculada aos pods e componentes produtivos.

Cada projeto que utiliza Kafka passa por estimativa e precificação de consumo de recursos.
A separação dos clusters de Connect foi considerada viável dentro do licenciamento atual.
A expansão futura de KSQLDB, Flink, DR ou novos agrupamentos poderá demandar nova análise contratual.

1.5.15. Disaster Recovery e continuidade¶

O DR ainda não está operacional de ponta a ponta. Não há backup ativo completo dos tópicos e estruturas; em caso de perda de produção, parte da reconstrução dependeria de rerun das fontes, reaplicação de scripts e recriação manual de componentes KSQLDB.

Existe iniciativa para subir um ambiente vazio no site de DR por pipeline.
A pipeline foi criada, mas ainda apresentava erros e não havia concluído o teste integral.
O desenho original é ativo-passivo, alinhado ao padrão dos sistemas corporativos e à contenção de custos de licenciamento.
Em um desastre, seriam levantadas a infraestrutura OpenShift e a camada Confluent Kafka no site alternativo, reutilizando a mesma chave de licença.
Não há replicação ativo-ativo com mecanismo Confluent entre sites no cenário atual.
A evolução para ativo-ativo foi associada à evolução futura dos próprios sistemas corporativos.

Ponto crítico

O DR precisa ser validado por exercício completo com RTO, RPO, sequência de ativação, recriação de tópicos, restauração de configurações, tratamento de offsets, consumidores, KSQLDB, Schema Registry, rotas e validação das aplicações.

1.5.16. Observabilidade e operação¶

A equipe usa Grafana, Prometheus, Control Center e logs centralizados para acompanhar o ambiente. Entretanto, várias decisões de escala e particionamento ainda dependem de eventos ocorridos em produção.

É necessário consolidar métricas de broker, Connect, consumidores, lag, storage, throughput, partições, rebalanceamentos e falhas de schema.
Alertas devem ser ligados a runbooks e responsáveis claros.
A operação deve diferenciar indicadores por domínio: operacional, BI e regulatório, empresa, aplicação e criticidade.

1.5.17. Riscos consolidados¶


Interferência BI e operação	Connect e recursos compartilhados	Atrasos, lag e degradação de serviços críticos	Muito alta
Divergência de esquemas	Nove bases legadas não padronizadas	Quebra de pipelines, schemas e consumidores	Muito alta
Homologação não representativa	Baixa volumetria e dados desatualizados	Falhas descobertas apenas em produção	Muito alta
DR incompleto	Pipeline e restauração não validadas	RTO e RPO incertos e recuperação manual	Muito alta
Storage compartilhado	Pool comum e dependências de OpenShift	Indisponibilidade correlacionada	Alta
Crescimento do KSQLDB	Multiplicação de streams e queries	Gargalo, aumento de custo e baixa escalabilidade	Alta
Escala reativa	HPA por recurso e ausência de gatilho por lag	Backlog e lentidão em contingências	Alta
Tópicos sem schema	Exceções criadas por prazo	Incompatibilidade e baixa governança	Média / alta
Dependência de conhecimento tácito	Documentação lógica incompleta	Diagnóstico lento e risco operacional	Média / alta

1.5.18. Recomendações priorizadas¶

1.5.18.1. Imediatas, de 0 a 30 dias¶

Concluir a POC de separação de Kafka Connect entre operação e BI, com critérios objetivos de throughput, lag, falha e recuperação.
Inventariar tópicos, conectores, schemas, KSQLDB, produtores, consumidores, owners e criticidade.
Mapear as divergências de esquema das tabelas atualmente capturadas nas nove empresas.
Corrigir e testar a pipeline do DR até subir o ambiente vazio de forma repetível.
Realizar workshop com Desenvolvimento para mapear padrões de consumo, tamanho de lote, commits, retries, idempotência e gargalos.
Realizar sessão técnica com OpenShift e storage para validar segregação física, classes de storage, IOPS, latência, rebalanceamentos e limites.

1.5.18.2. Curto prazo, de 30 a 90 dias¶

Definir política de Schema Registry e plano de regularização dos tópicos derivados sem schema.
Criar laboratório de performance com replay anonimizado ou geração sintética representando perfis de produção.
Implantar escalabilidade orientada por lag e eventos com KEDA ou solução equivalente, após POC controlada.
Definir estratégia de consolidação multiempresa, comparando KSQLDB, Flink, microserviço e pré-consolidação no banco.
Estabelecer SLOs e painéis por domínio, empresa, aplicação e fluxo crítico.
Executar primeiro teste formal de DR com medição de RTO e RPO e registro de falhas.

1.5.18.3. Médio prazo, de 90 a 180 dias¶

Evoluir a homologação para testes não funcionais recorrentes e gates de produção.
Automatizar validação de compatibilidade dos nove schemas antes de liberar alterações.
Revisar capacidade, licenciamento e topologia para a entrada dos agrupamentos 1 e 2 e expansão do BI.
Avaliar isolamento de storage e fault domains para componentes críticos do Kafka.
Consolidar documentação arquitetural do estado atual e do estado alvo, incluindo fluxos lógicos por solução e matrizes RACI.

1.5.19. Próximos passos acordados na reunião¶

Compartilhar a documentação disponível sobre aplicações, tabelas, tópicos, consumidores, produtores e KSQLDB; foi mencionado o envio de arquivo Markdown compactado.
Conversar com as várias mesas de Desenvolvimento, incluindo fluxos como WFM e operação de despacho, CRM, canais digitais, atendimento convencional e SGM.
Agendar, em paralelo, reunião com a equipe OpenShift.
Agendar conversa com o responsável por F5 e API Gateway com Sensedia, citado como Guilherme.
A agenda seguinte foi sugerida para o dia posterior, no mesmo horário, sujeita à disponibilidade.
Retomar a equipe técnica sempre que o assessment avançar ou novas hipóteses e recomendações forem formuladas.

1.5.20. Artefatos solicitados para o assessment¶

Desenho físico atualizado dos ambientes DEV, HML e PRD.
Desenhos lógicos por solução, mostrando produtores, consumidores, tópicos, eventos e dependências.
Inventário de connectors e suas fontes e tabelas.
Inventário de queries, streams e tabelas KSQLDB.
Catálogo de schemas por empresa e histórico de incompatibilidades.
Matriz de aplicação, tópico, tabela, owner e criticidade.
Configurações de particionamento, retenção, replicação, quotas e políticas de erro.
Dashboards e alertas atuais de Prometheus, Grafana e Control Center.
Topologia OpenShift, nodes, afinidade, tolerations e classes de storage.
Pipelines DevOps de implantação e DR.
Contrato e licenciamento Confluent e premissas de capacidade.
Runbooks de incidente, recuperação e failover.

1.5.21. Questões em aberto¶

Qual o volume, taxa de mudança e sazonalidade de cada tabela crítica.
Quais aplicações são responsáveis pelos maiores consumer lags.
Qual o RPO aceitável por fluxo e por sistema consumidor.
O storage dos nodes Kafka possui isolamento físico e garantias de desempenho.
Quais workloads exigem realmente tempo real, near real time ou processamento em lote.
Quais tópicos derivados ainda não usam Schema Registry.
Qual o limite real de KSQLDB observado em testes e produção.
Quais critérios orientarão a escolha entre KSQLDB, Flink, microserviços e consolidação no banco.
Como serão incorporados os agrupamentos 1 e 2 e o crescimento da plataforma de dados.

1.5.22. Conclusão¶

A reunião forneceu uma visão ampla e consistente do ambiente atual e expôs um conjunto de riscos que não decorrem de um único componente, mas da combinação entre crescimento de demanda, legado heterogêneo, baixa representatividade dos testes, concentração de workloads, dependência do OpenShift e do storage e processos ainda reativos.

O assessment deve evitar uma análise isolada do Kafka. A recomendação é tratar a plataforma como um ecossistema sociotécnico, envolvendo arquitetura de dados, aplicações, infraestrutura, identidade, observabilidade, DevOps, licenciamento e continuidade. A separação de Connect e o amadurecimento do DR são prioridades imediatas, mas a sustentabilidade dependerá principalmente da governança de schemas, testes não funcionais, capacidade orientada por métricas e simplificação da consolidação multiempresa.

Anexo A · Glossário técnico¶


CDC	Change Data Capture; captura contínua das mudanças realizadas nas bases de dados.
Kafka Connect	Framework para mover dados entre Kafka e sistemas externos por meio de conectores.
KSQLDB	Camada de processamento de streams baseada em SQL para Apache Kafka.
Schema Registry	Repositório e mecanismo de governança e versionamento de schemas de mensagens.
KRaft	Modo de consenso e gerenciamento de metadados do Kafka sem ZooKeeper.
Consumer lag	Diferença entre a posição mais recente do tópico e a posição já processada pelo consumidor.
HPA	Horizontal Pod Autoscaler; escala pods com base em métricas de recursos.
KEDA	Kubernetes Event-Driven Autoscaling; escala workloads com base em eventos e métricas externas.
RTO	Tempo máximo aceitável para restabelecimento de um serviço.
RPO	Quantidade máxima aceitável de dados perdidos, normalmente medida em tempo.