Qualquer migração da camada de dados exige planejamento e execução cuidadosos, independentemente do tamanho da migração. Dito isso, concluímos recentemente o que pode muito bem ser a maior migração de Apache Cassandra e Apache Kafka já realizada (o Guinness World Records não controla exatamente isso… ainda).
É, na minha opinião, um caso de uso particularmente interessante para alcançar um feito técnico bastante complexo sem tempo de inatividade (e usando apenas as versões totalmente de código aberto de Cassandra e Kafka – sem núcleo aberto aqui). Abaixo, compartilharei a estratégia e o processo que foram usados, juntamente com algumas práticas recomendadas que ajudarão a tornar qualquer migração de Cassandra e Kafka em grande escala e de missão crítica mais tranquila.
Vamos definir o quão grande foi essa migração. A implantação do Cassandra de código aberto desta empresa consistia em 58 clusters e 1.079 nós, incluindo 17 tamanhos de nós diferentes, espalhados pela AWS e Google Cloud Platform (GCP) em seis regiões separadas de provedores de nuvem. Na frente de Kafka, a empresa usou 154 clusters e 1.050 nós de 21 tamanhos de nós, novamente nos dois provedores de nuvem e em seis regiões. Como você pode imaginar, fazer a mudança requer muito tempo e foco. O cronograma exigia nove meses de preparação, seguidos de oito meses de cuidadosas migrações de produção.
Tal como acontece com qualquer migração, uma forte gestão e governação de projetos foram fundamentais. Se esta etapa falhar, você terá problemas mais tarde. Atribuímos responsabilidades específicas a algumas funções-chave alinhadas com nossa metodologia de gerenciamento de projetos, incluindo um gerente de programa geral, um gerente de projeto de migração para Cassandra e outro para Kafka, líderes técnicos para cada um e um gerente de produto principal. Esta equipe desenvolveu rapidamente uma colaboração estreita e uma comunicação clara com a empresa, outro método comprovado para resultados positivos do projeto.
Esse contacto próximo provou o seu valor ao longo da fase inicial do projecto, pois trabalhámos em sincronia com as equipas de arquitectura, segurança e conformidade da empresa para cumprir os seus rigorosos requisitos nestas áreas. Isso significava garantir que os ambientes de destino para a migração tivessem detecção de invasões, registro de acesso, registros de auditoria, sistemas operacionais reforçados e aceitação em nível de conta para configurar automaticamente novos clusters com envio de registros e outros controles. Também habilitamos o processo de carregamento de conectores Kafka Connect personalizados para usar funções de instância em vez de chaves de acesso para acesso ao Amazon S3 e fizemos melhorias na API SCIM (System for Cross-Domain Identity Management) para provisionar acesso de logon único (SSO). .
Durante esta fase de preparação, também reconhecemos e agimos em oportunidades para otimizar o ajuste arquitetônico para clusters migrados. Como a arquitetura da empresa oferecia alta disponibilidade acima do nível de cluster Kafka, usamos RF2 (fator de replicação 2) para oferecer suporte a clusters Kafka executados em duas zonas de disponibilidade. Também nos preparamos para otimizar custos aproveitando os mais recentes tipos de nós AWS e GCP.
A abordagem “Drain Out” é o primeiro pensamento para migrações Kafka: basta apontar os consumidores Kafka para os clusters de origem e destino, alternar os produtores para enviar mensagens apenas para o cluster de destino, esperar até que todas as mensagens sejam lidas da origem e pronto. A limitação é que um Drain Out não preserva a ordem das mensagens, algo essencial para muitos casos de uso do Kafka, incluindo este.
MirrorMaker2 oferece outra opção forte para migrações Kafka, no entanto, sua alta dependência de aplicativos consumidor/produtor significava que não era adequado aqui.
A abordagem de “Cluster Compartilhado” – operando clusters de origem e destino como um único cluster – emergiu como a melhor opção restante. Prosseguimos com a criação de um plano de mudança detalhado para cada cluster, tendo sempre em mente a ativação da reversão. As etapas de alto nível começaram com o provisionamento do cluster de destino, atualizando as configurações para corresponder à origem e unindo ambientes de rede ao cluster de origem com peering de nuvem privada virtual. Em seguida, iniciamos o Apache ZooKeeper no destino no modo observador, junto com os corretores Kafka de destino.
Em seguida, movemos os dados usando a reatribuição de partição Kafka. Isso incluiu aumentar o fator de replicação e as replicações entre os corretores de destino e de origem, trocando os líderes preferenciais pelos corretores de destino e, em seguida, diminuindo o fator de replicação para remover as réplicas do corretor de origem. Finalizamos reconfigurando os clientes para fazer dos corretores de destino seus pontos de contato iniciais e depois removendo os corretores antigos.
O ambiente de origem veio com alguns problemas extras que resolvemos durante a migração. Por exemplo, ele compartilhou uma instância do ZooKeeper em vários clusters, o que nos levou a reconfigurar e limpar cuidadosamente cada ZooKeeper de destino de dados em outros clusters. Também estendemos a configuração de destino para suportar os mapeamentos de ouvintes de portas específicos da empresa, evitando grandes trabalhos de reconfiguração.
A abordagem mais comum para uma migração do Cassandra sem tempo de inatividade é adicionar um data center a um cluster existente. Também usamos e recomendamos nossa ferramenta de reconstrução consistente com Instaclustr Minotaur (disponível no GitHub). Esta solução de código aberto resolve o problema em que réplicas de dados ausentes em um cluster de origem podem fazer com que o processo de reconstrução copie várias réplicas do mesmo nó, levando a menos réplicas no destino. O Minotaur garante que o cluster de destino tenha pelo menos tantas réplicas quanto o de origem e que quaisquer reparos necessários possam ser adiados até depois da migração.
Usar esta abordagem para esta migração foi especialmente valioso quando encontramos clusters com alta inconsistência. Num caso, um cluster exigiu dois meses e meio de reparação após a migração. Outro conjunto de clusters descartava tabelas regularmente a cada duas ou três horas, devido ao Cassandra descartar dados temporários quando o esquema era alterado durante o streaming. Primeiro tentamos resolver isso pausando manualmente as quedas da tabela durante as reconstruções dos nós, mas achamos esse método insustentável. No final, usamos nossa API de provisionamento para detectar o status do nó e automatizar a pausa de quedas de tabela quando necessário.
No final, a (talvez) maior migração de Cassandra e Kafka já foi concluída dentro do prazo e com o mínimo de contratempos. Credito este resultado positivo à cooperação estreita, ao planeamento cuidadoso e às melhores práticas estratégicas utilizadas por todos os envolvidos, e aconselho qualquer pessoa envolvida em migrações igualmente grandes e complexas a aplicar estas mesmas técnicas.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
