Esta é uma postagem co-escrita com Rivlin Pereira e Vaibhav Pandey da Tanzu CloudHealth (VMware by Broadcom).

VMware Tanzu CloudHealth é a plataforma de gerenciamento de custos em nuvem preferida por mais de 20,000 organizações em todo o mundo, que confiam nela para otimizar e administrar seus maiores e mais complexos ambientes multinuvem. Nesta postagem, discutimos como a equipe VMware Tanzu CloudHealth DevOps migrou suas cargas de trabalho autogerenciadas do Apache Kafka (executando a versão 2.0) para Amazon Managed Streaming para Apache Kafka (Amazon MSK) executando a versão 2.6.2. Discutimos as arquiteturas do sistema, pipelines de implantação, criação de tópicos, observabilidade, controle de acesso, migração de tópicos e todos os problemas que enfrentamos com a infraestrutura existente, juntamente com como e por que migramos para a nova configuração do Kafka e algumas lições aprendidas.

Visão geral do cluster Kafka

No cenário de rápida evolução dos sistemas distribuídos, a plataforma de microsserviços de próxima geração do VMware Tanzu CloudHealth conta com Kafka como backbone de mensagens. Para nós, o sistema de log distribuído de alto desempenho do Kafka é excelente no tratamento de fluxos de dados massivos, tornando-o indispensável para uma comunicação contínua. Servindo como um sistema de log distribuído, o Kafka captura e armazena com eficiência diversos logs, desde logs de acesso ao servidor HTTP até logs de auditoria de eventos de segurança.

A versatilidade do Kafka brilha no suporte aos principais padrões de mensagens, tratando as mensagens como registros básicos ou armazenamentos estruturados de valores-chave. O particionamento dinâmico e a ordenação consistente garantem uma organização eficiente das mensagens. A confiabilidade inabalável do Kafka está alinhada ao nosso compromisso com a integridade dos dados.

A integração dos serviços Ruby com o Kafka é simplificada através da biblioteca Karafka, atuando como um wrapper de nível superior. Nossos outros serviços de pilha de idiomas usam wrappers semelhantes. Os robustos recursos de depuração e comandos administrativos do Kafka desempenham um papel fundamental para garantir operações tranquilas e integridade da infraestrutura.

Kafka como pilar arquitetônico

Na plataforma de microsserviços de próxima geração do VMware Tanzu CloudHealth, o Kafka surge como um pilar arquitetônico crítico. Sua capacidade de lidar com altas taxas de dados, suportar diversos padrões de mensagens e garantir a entrega de mensagens se alinha perfeitamente com nossas necessidades operacionais. À medida que continuamos a inovar e a escalar, o Kafka continua a ser um companheiro constante, permitindo-nos construir uma infraestrutura resiliente e eficiente.

Por que migramos para o Amazon MSK

Para nós, a migração para o Amazon MSK se resumiu a três pontos de decisão principais:

• Operações técnicas simplificadas – Executar o Kafka em uma infraestrutura autogerenciada foi uma sobrecarga operacional para nós. Fazia algum tempo que não atualizamos o Kafka versão 2.0.0, e os corretores do Kafka estavam com produção interrompida, causando problemas com tópicos que ficavam off-line. Também tivemos que executar scripts manualmente para aumentar os fatores de replicação e reequilibrar os líderes, o que representou um esforço manual adicional.
• Pipelines legados obsoletos e permissões simplificadas – Estávamos procurando nos afastar de nossos pipelines existentes escritos em Ansible para criar tópicos Kafka no cluster. Também tínhamos um processo complicado de dar aos membros da equipe acesso às máquinas Kafka na preparação e produção, e queríamos simplificar isso.
• Custo, aplicação de patches e suporte - Porque Zelador do Zoológico Apache é totalmente gerenciado e corrigido pela AWS, migrar para o Amazon MSK nos pouparia tempo e dinheiro. Além disso, descobrimos que executar o Amazon MSK com o mesmo tipo de corretores em Amazon Elastic Compute Nuvem (Amazon EC2) era mais barato para executar no Amazon MSK. Combinado com o fato de termos patches de segurança aplicados em corretores pela AWS, migrar para o Amazon MSK foi uma decisão fácil. Isso também significou que a equipe ficou livre para trabalhar em outras coisas importantes. Por fim, obter suporte empresarial da AWS também foi fundamental em nossa decisão final de migrar para uma solução gerenciada.

Como migramos para o Amazon MSK

Com os principais motivadores identificados, avançamos com um projeto proposto para migrar o Kafka autogerenciado existente para o Amazon MSK. Conduzimos as seguintes etapas de pré-migração antes da implementação real:

• avaliação:
  • Conduziu uma avaliação meticulosa do cluster EC2 Kafka existente, entendendo suas configurações e dependências
  • Compatibilidade verificada da versão Kafka com Amazon MSK
• Configuração do Amazon MSK com Terraform
• Configuração de rede:
  • Conectividade de rede perfeita garantida entre os clusters EC2 Kafka e MSK, ajustando grupos de segurança e configurações de firewall

Após as etapas de pré-migração, implementamos o seguinte para o novo design:

• Pipelines automatizados de implantação, atualização e criação de tópicos para clusters MSK:
  • Na nova configuração, queríamos implantações e atualizações automatizadas dos clusters MSK de maneira repetível usando uma ferramenta IaC. Portanto, criamos módulos Terraform personalizados para implantações de cluster MSK, bem como atualizações. Esses módulos foram chamados de um Jenkins pipeline para implantações e atualizações automatizadas dos clusters MSK. Para a criação de tópicos Kafka, estávamos usando um pipeline caseiro baseado em Ansible, que não era estável e gerou muitas reclamações das equipes de desenvolvimento. Como resultado, avaliamos opções de implantações para Kubernetes clusters e usou o Operador de tópico Strimzi para criar tópicos em clusters MSK. A criação de tópicos foi automatizada usando pipelines Jenkins, que as equipes de desenvolvimento podiam fazer por conta própria.
• Melhor observabilidade para clusters:
  • Os antigos aglomerados Kafka não tinham boa observabilidade. Recebemos apenas alertas sobre o tamanho do disco do corretor Kafka. Com o Amazon MSK, aproveitamos monitoramento aberto utilização Prometeu. Criamos um servidor Prometheus independente que extraiu métricas de clusters MSK e as enviou para nossa ferramenta interna de observabilidade. Como resultado da melhoria da observabilidade, conseguimos configurar alertas robustos para o Amazon MSK, o que não era possível com nossa configuração antiga.
• CPV aprimorado e melhor infraestrutura de computação:
  • Para nossa antiga infraestrutura Kafka, tivemos que pagar pelo gerenciamento de instâncias Kafka e Zookeeper, além de quaisquer custos adicionais de armazenamento do corretor e custos de transferência de dados. Com a mudança para o Amazon MSK, como o Zookeeper é totalmente gerenciado pela AWS, só temos que pagar pelos nós Kafka, armazenamento do corretor e custos de transferência de dados. Como resultado, na configuração final do Amazon MSK para produção, economizamos não apenas em custos de infraestrutura, mas também em custos operacionais.
• Operações simplificadas e segurança aprimorada:
  • Com a mudança para o Amazon MSK, não tivemos que gerenciar nenhuma instância do Zookeeper. Os patches de segurança do corretor também foram feitos pela AWS para nós.
  • As atualizações de cluster ficaram mais simples com a mudança para o Amazon MSK; é um processo simples de iniciar no console do Amazon MSK.
  • Com o Amazon MSK, temos corretor escala automática sai da caixa. Como resultado, não tivemos que nos preocupar com a falta de espaço em disco dos corretores, levando assim a uma estabilidade adicional do cluster MSK.
  • Também obtivemos segurança adicional para o cluster porque o Amazon MSK oferece suporte à criptografia em repouso por padrão, e várias opções de criptografia em trânsito também estão disponíveis. Para obter mais informações, consulte Proteção de dados no Amazon Managed Streaming para Apache Kafka.

Durante nossas etapas de pré-migração, validamos a configuração no ambiente de teste antes de prosseguir com a produção.

Estratégia de migração de tópicos Kafka

Com a configuração do cluster MSK concluída, realizamos uma migração de dados de tópicos Kafka do cluster antigo em execução no Amazon EC2 para o novo cluster MSK. Para conseguir isso, realizamos as seguintes etapas:

• Configure o MirrorMaker com Terraform – Usamos o Terraform para orquestrar a implantação de um Criador de espelhos cluster composto por 15 nós. Isso demonstrou a escalabilidade e a flexibilidade ao ajustar o número de nós com base nas necessidades de replicação simultânea da migração.
• Implementar uma estratégia de replicação simultânea – Implementamos uma estratégia de replicação simultânea com 15 nós MirrorMaker para agilizar o processo de migração. Nossa abordagem orientada ao Terraform contribuiu para a otimização de custos ao gerenciar recursos de forma eficiente durante a migração e garantiu a confiabilidade e consistência dos clusters MSK e MirrorMaker. Também mostrou como a configuração escolhida acelera a transferência de dados, otimizando tempo e recursos.
• Migrar dados – Migramos com sucesso 2 TB de dados em um período de tempo extremamente curto, minimizando o tempo de inatividade e demonstrando a eficiência da estratégia de replicação simultânea.
• Configurar o monitoramento pós-migração – Implementamos monitoramento e alertas robustos durante a migração, contribuindo para um processo tranquilo ao identificar e resolver problemas prontamente.

O diagrama a seguir ilustra a arquitetura após a conclusão da migração do tópico.

Desafios e lições aprendidas

Embarcar numa jornada de migração, especialmente com grandes conjuntos de dados, é muitas vezes acompanhado de desafios imprevistos. Nesta seção, analisamos os desafios encontrados durante a migração de tópicos do EC2 Kafka para o Amazon MSK usando MirrorMaker e compartilhamos insights e soluções valiosas que moldaram o sucesso de nossa migração.

Desafio 1: Discrepâncias de compensação

Um dos desafios que encontramos foi a incompatibilidade nas compensações de tópicos entre os clusters de origem e de destino, mesmo com a sincronização de compensações habilitada no MirrorMaker. A lição aprendida aqui foi que os valores de deslocamento não precisam necessariamente ser idênticos, desde que a sincronização de deslocamento esteja habilitada, o que garante que os tópicos tenham a posição correta para ler os dados.

Resolvemos esse problema usando uma ferramenta personalizada para executar testes em grupos de consumidores, confirmando que as compensações traduzidas eram menores ou alcançadas, indicando sincronização conforme MirrorMaker.

Desafio 2: Migração lenta de dados

O processo de migração enfrentou um gargalo: a transferência de dados foi mais lenta do que o previsto, especialmente com um conjunto de dados substancial de 2 TB. Apesar de um cluster MirrorMaker de 20 nós, a velocidade era insuficiente.

Para superar isso, a equipe agrupou estrategicamente os nós do MirrorMaker com base em números de porta exclusivos. Clusters de cinco nós MirrorMaker, cada um com uma porta distinta, aumentaram significativamente o rendimento, permitindo-nos migrar dados em horas, em vez de dias.

Desafio 3: Falta de documentação detalhada do processo

Navegar pelo território desconhecido da migração de grandes conjuntos de dados usando o MirrorMaker destacou a ausência de documentação detalhada para tais cenários.

Por tentativa e erro, a equipe criou um módulo IaC usando Terraform. Este módulo simplificou todo o processo de criação de cluster com configurações otimizadas, permitindo um início contínuo da migração em poucos minutos.

Configuração final e próximas etapas

Como resultado da mudança para o Amazon MSK, nossa configuração final após a migração do tópico ficou semelhante ao diagrama a seguir.

Estamos considerando as seguintes melhorias futuras:

Conclusão.

Nesta postagem, discutimos como o VMware Tanzu CloudHealth migrou sua infraestrutura Kafka existente baseada no Amazon EC2 para o Amazon MSK. Orientamos você sobre a nova arquitetura, pipelines de implantação e criação de tópicos, melhorias na observabilidade e controle de acesso, desafios de migração de tópicos e os problemas que enfrentamos com a infraestrutura existente, além de como e por que migramos para a nova configuração do Amazon MSK. Também falamos sobre todas as vantagens que o Amazon MSK nos proporcionou, a arquitetura final que alcançamos com essa migração e as lições aprendidas.

Para nós, a interação entre sincronização de deslocamento, agrupamento de nós estratégicos e IaC se mostrou fundamental para superar obstáculos e garantir uma migração bem-sucedida do Amazon EC2 Kafka para o Amazon MSK. Esta publicação serve como um testemunho do poder da adaptabilidade e da inovação nos desafios da migração, oferecendo insights para outros que estejam navegando por um caminho semelhante.

Se você estiver executando o Kafka autogerenciado na AWS, recomendamos que você experimente a oferta gerenciada do Kafka, Amazon MSK.

Sobre os autores

Rivlin Pereira é engenheiro de DevOps da equipe da divisão VMware Tanzu. Ele é muito apaixonado por Kubernetes e trabalha na plataforma CloudHealth, construindo e operando soluções em nuvem que são escaláveis, confiáveis ​​e econômicas.

Vaibhav Pandey, engenheiro de software da Broadcom, é um contribuidor importante para o desenvolvimento de soluções de computação em nuvem. Especializado em arquitetura e engenharia de camadas de armazenamento de dados, ele é apaixonado por construir e dimensionar aplicativos SaaS para obter desempenho ideal.

Raj Ramasubbu é um arquiteto de soluções especialista em análises sênior com foco em big data e análises e IA/ML com Amazon Web Services. Ele ajuda os clientes a arquitetar e criar soluções baseadas em nuvem altamente escaláveis, de alto desempenho e seguras na AWS. Raj forneceu conhecimento técnico e liderança na criação de soluções de engenharia de dados, análise de big data, inteligência de negócios e ciência de dados por mais de 18 anos antes de ingressar na AWS. Ele ajudou clientes em vários setores verticais, como saúde, dispositivos médicos, ciências da vida, varejo, gestão de ativos, seguro de carro, REIT residencial, agricultura, seguro de título, cadeia de suprimentos, gerenciamento de documentos e imóveis.

Todd McGrath é especialista em streaming de dados na Amazon Web Services, onde aconselha clientes sobre estratégias, integração, arquitetura e soluções de streaming. No lado pessoal, ele gosta de assistir e apoiar seus três filhos adolescentes em suas atividades preferidas, bem como de seguir suas próprias atividades, como pesca, pickleball, hóquei no gelo e happy hour com amigos e familiares em barcos flutuantes. Conecte-se com ele no LinkedIn.

Satya Pattanaik é arquiteto de soluções sênior na AWS. Ele tem ajudado ISVs a criar aplicações escaláveis ​​e resilientes na Nuvem AWS. Antes de ingressar na AWS, ele desempenhou um papel significativo nos segmentos empresariais com seu crescimento e sucesso. Fora do trabalho, ele passa o tempo aprendendo “como preparar um churrasco saboroso” e experimentando novas receitas.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/