This use case is about real time database replication, extracting the CDCs from a legacy database in AS400 using a third party tool, processing using Apache Kafka®, Kafka Streams and Kubernetes and populating Cloud databases using custom Kafka Connect. All Kafka components are running on AWS, which is composed of MSK, EC2 Clusters for Kafka Connect, and Kubernetes Cluster for Kafka Streams.
Boas práticas de programação com Object Calisthenics
Real time replication using Kafka Connect
1. Replicação de Dados
em Tempo Real
Um projeto de replicação de banco de dados DB2/AS400
para a nuvem u@lizando a plataforma
Apache KaEa, KaEa Streams e KaEa Connect
16/11/2022
Gil César Faria
2. • Gil César Faria, atua em TI desde 1991, formou-se em Ciência da Computação
pela Unicamp e com MBA RH pela FIA
• Co-founder da Inmetrics, atuou no Brasil e no Chile em Consultoria de TI e Gestão
• Atualmente é sócio da TruStep, onde é responsável técnico pelos projetos da
empresa, com atuação no Brasil e no Chile, com foco em AWS e Apache KaEa
• Meu papel no projeto foi de arquiteto e líder técnico da solução, coordenando
uma equipe de quatro pessoas, interagindo com outras equipes do cliente e de
terceiros envolvidas diretamente na execução, e implementando diretamente
alguns dos componentes crí@cos da plataforma.
Apresentação Pessoal
3. Contexto Inicial
• Empresa chilena do ramo financeiro com mais de 2 milhões de clientes a@vos
• Core bancário world class (an@go) implementado sobre DB2/AS400
• Digitalização inicial trouxe colapso seguido da plataforma de integração fuse
8. • Tabelas u@lizadas com se fossem “arquivos” estruturados hierarquicamente
• Sem chaves primarias definidas, sem chaves estrangeiras definidas, embora
algumas chaves lógicas implícitas assumidas pelos aplica@vos exis@ssem.
• Sem garan@a de integridade referencial e sem normalização
• Manutenção anual com reorganização completa das tabelas para gerenciar
espaço e arquivamento de informações (truncates, reorganize, copias de tabelas)
• Regras de negócio implementadas em programas RPG
Caracterís@cas do Core Bancário
9. • Change Data Capture (CDC): representa uma transação de banco de dados, um
insert, um update ou um delete em par@cular
• Traz a informação sobre os valores de cada coluna, além de metadados, como o
nome da tabela, @po de operação, @mestamp da transação, dentre outros
O que são CDCs
19. • Serviço gerenciado AWS MSK - KaEa 2.7.0 - provisionado
• 3 nós kaEa.m5.large (2vCPU, 8Gb RAM, 10Gbps banda rede), 350GB disco cada
• Entrada: replica@on.factor=3, par@@ons=1, min.insync.replicas=2, reten@on=2d
• Saída: replica@on.factor=3, par@@ons=3, min.insync.replicas=2, cleanup.policy=compact
• Ocupação média de disco varia entre 20% a 40%
• Durante a noite, Picos de CPU de 15%, RX/TX packets de 1200 avg
• Durante o dia média de CPU fica em 5%, RX/TX packets de 600 ou menos avg
Cluster KaEa Brokers (MSK)
20. • Launch Templates instalação automa@zada do cluster (confluent 6.0.0)
• Autoscaling groups com 3 instancias
• Applica@on Load Balance para API REST de administração
• Target Groups para verificar saúde de cada nó através da API REST
• t2.medium (2 vCpus, 4Gb RAM), 8Gb Disco
• Pico de CPU abaixo de 10%
• 41 conectores, somente 1 com 3 tasks, todos os demais com apenas 1 task
Cluster KaEa Connect (EC2)
21. • Launch Templates instalação automa@zada do cluster (confluent 6.0.0)
• Autoscaling groups com 2 instancias
• Applica@on Load Balance para API REST de administração
• Target Groups para verificar saúde de cada nó através da API REST
• t2.small (1 vCpus, 2Gb RAM), 8Gb Disco
• Pico de CPU abaixo de 5%
• 481 schemas, entre chaves e valores, para tópicos de entrada, intermediários e de saída
Cluster KaEa Schema Registry (EC2)
22. • Launch Configura@on com instalação e cofiguração automa@zada por terraform
• Autoscaling groups com 3 instancias
• m5.xlarge (4 vCpus, 16Gb RAM), 100Gb Disco
• Pico de CPU abaixo de 25%, na média abaixo de 10%
• 54 pods, reinicio automá@co, cada um executando uma aplicação kaEa streams
Cluster Kubernetes (EKS)
27. • Transformações de Entrada processam um tópico de entrada (stream) gerando um ou
mais tópicos em formato de tabela (changelogs)
• São capazes de processar todos os @pos de transações (sv_manip_type).
• Inserts/Updates/Deletes possuem tratamento trivial
• Truncates e cargas iniciais possuem tratamento similar: ambos eliminam todas as
chaves existentes nos des@nos antes de processar a informação. Ela ocorre sem que
se interrompa o processamento de novas transações.
• Um buffer temporário (tópico kaEa) armazena as transações novas enquanto a
limpeza é efetuada nos tópicos de des@no.
Transformações de Entrada
31. • Processam um ou mais tópico de entrada em formato de tabela (changelogs)
• Aplicam regras de negócio e mapeamentos
• Geram um tópico de saída (changelog) que representa a tabela de des@no
• Inserts, Updates e Cargas Iniciais são tratados como “upserts”
• Deletes em geral são tratados como “delete lógico”, com algumas exceções
• Truncates são ignorados, com algumas exceções
Transformações de Saída
42. • São responsáveis por executar comandos SQL no banco de dados
• Limpam os caches Redis em algumas transações específicas
• Garantem seman@ca de processamento 1 e somente 1
• Controlam offsets dos consumer groups em tabelas do banco de dados, por
tópico e par@ção, mas também atualizam o mecanismo default como backup,
sem garanza de transação.
• Podem invocar Stored Procedures ou executar as primi@vas SQL diretamente
Conectores
44. • Falhas são tratadas de duas formas dis@ntas:
• Erros de infra-estrutura, conec@vidade ou de programação bloqueiam o fluxo
• Erros de lógica relacional (chaves estrangeiras inexistentes principalmente)
bloqueiam o fluxo até um limite, liberando-o após um número de tenta@vas
pré-determinado.
• São enviados para DLQs (uma para cada tópico de saída)
• Um conector especial copia as DLQs de cada saída para um conjunto de tabelas,
permi@ndo acesso fácil aos usuários para revisão manual
Tratamento de Exceções
45. • Todos os tópicos de saída possuem múl@plas par@ções.
• Quando um truncate chega, não basta apenas executá-lo na BBDD
• É necessário reposicionar os offsets do consumer group para refle@r o tempo
correto da execução do truncate
Tratamento de Truncates e Par@ções
46. Tratamento de Truncates e Par@ções
Registros atrasados não precisam
mais ser processados, já “caducaram”
Registros adiantados devem ser
reprocessados para não se perderem
após o truncate ser executado
48. • Paradigma Relacional versus orientação a eventos
• Compa@bilização e consistência dos modelos de dados
• Conhecimento do sistema legado incompleto ou disperso
• Tratamento de exceções e casos não previstos: QA vs Pro
• Monitoramento e resposta a falhas no pipeline
• Testes unitários e integrados: TopologyTestDriver, TestContainers e Flyway são seus amigos
• Avro: desajo adicional pois a documentação não é muito extensa no uso de APIs de kaEa,
principalmente componentes kaEa streams, em combinação com schemas Avro
Durante o projeto e pós passo a produção
49. • Estabelecimento de um plano de recuperação de desastres (AWS Region offline)
• Diminuir o tempo de resposta a incidentes nos fluxos de dados
• Monitoramento detalhado dos fluxos: lags, atraso no processamento de
mensagens
• Reestruturação do repositório GIT e projetos Maven
• Melhoria do processo de CI/CD no projeto
Próximos Passos