Existem alguns problemas na postagem cruzada devido ao dialeto de remarcação na postagem original. Especialmente os diagramas não são mostrados que existem no post original. Portanto, verifique o original também se estiver interessado. Acho que o original é mais compreensível

Atualização do HBase sobre o Event Sourcing e a arquitetura CQRS em 3 semanas

TL;DR

Usamos uma estratégia de implantação azul-verde para a atualização da versão do HBase sobre o Event Sourcing e o sistema de arquitetura CQRS.
A abordagem de implantação funcionou muito bem e levou apenas 3 semanas no total para atingir a meta do projeto. Essa experiência foi nova e emocionante para nós. Então eu quero compartilhar :)

Sobre a atualização do banco de dados

Uma atualização de banco de dados é sempre problemática e sempre que você está lidando com tais circunstâncias em cenários de produção você ficaria super nervoso (eu diria 100 vezes em comparação com outras operações de produção com as quais você está lidando) .

Esse sentimento é difícil de compartilhar com pessoas que não têm experiência ou exposição na operação de ambientes de banco de dados. E acho que 99,9% das pessoas concordam se você tem experiência e passou por momentos difíceis ao lidar com as operações relacionadas ao banco de dados. É arriscado e custa muito, mas a atualização em si não significa que forneça um novo valor ao produto e embora não seja priorizado em muitos casos, a menos que haja algum motivo urgente.

Ao mesmo tempo, é um enorme risco oculto se o banco de dados se tornar "intocável" e como lidar com esse problema tem sido um tópico, muitos desenvolvedores e operadores têm lutado com essas situações

Abordagem de atualização

Em geral, você teria duas opções.

atualização contínua

Uma delas é uma atualização contínua. Atualizando a versão do banco de dados uma a uma de maneira sequencial.
Encontrei uma boa explicação aqui. Por favor, leia isto se você não estiver familiarizado com a palavra.

O que significa uma atualização contínua no desenvolvimento de software?

Prós
- Os dados estão em um só lugar. Portanto, você não precisa pensar em como sincronizar os dados entre diferentes clusters e como garantir que a sincronização funcione perfeitamente.
Contras
- Depois que a atualização estiver concluída, não há uma maneira fácil de reverter. Portanto, se a atualização acionar um problema de desempenho de alguma forma, você terá um grande problema.
- O banco de dados de longa execução tem algum estado inesperado que você não pode reproduzir no ambiente de teste. Às vezes você precisa lidar com o problema quando se trata de produção. E essa possibilidade deixa você muito nervoso.

implantação azul-verde

A outra é uma implantação azul-verde. Nesse caso, você precisa provisionar o cluster de banco de dados atualizado separadamente e alternar o aplicativo para usar o novo em algum momento.
Verifique esta postagem do blog se você não estiver familiarizado com a palavra "implantação azul-verde".

Implantação BlueGreen

Acho que essa abordagem é generalizada na implantação de aplicativos da Web, mas se você substituir a palavra "roteador" por "aplicativo" e "servidor da Web" por "banco de dados", a mesma abordagem poderá ser aplicada à atualização do banco de dados.

Prós
- Você não toca no banco de dados de produção em execução durante a atualização. Isso torna sua vida muito mais fácil em comparação com a abordagem de atualização contínua.
- Você pode reverter facilmente para o cluster antigo quando ocorrer algum problema inesperado. E você também pode distribuir as solicitações gradualmente para minimizar o escopo caso tenha algum problema (para fazer isso, como em "Cons", você precisa sincronizar os dados do novo cluster para o cluster antigo)
- Devido ao fator acima, você pode encurtar um pouco o teste de carga no ambiente de teste e prosseguir com o projeto rapidamente.
Contras
- Você precisa garantir que os dados sejam sincronizados entre os dois clusters de banco de dados. Não apenas do cluster antigo para o novo cluster, mas também do cluster novo para o cluster antigo, se você quiser ter uma maneira fácil de reverter após a atualização. Mas a replicação mútua de dados é bastante difícil em muitos casos. Pode ser possível gravar em dois clusters em cada operação, mas você precisa se preparar quando apenas um cluster estiver inativo e a operação somente para esse cluster falhar. Esse manuseio seria muito complicado.
- Você precisa ter servidores de tamanho duplo ao executar os dois clusters. Isso vai custar algum dinheiro e pode ser difícil se o seu sistema não estiver na infraestrutura de nuvem.

Nossa abordagem

Basicamente, nossa abordagem é a implantação azul-verde. E como temos Kafka na frente como barramento de fornecimento de eventos, ficou muito mais fácil lidar com o problema de sincronização de dados em "Cons" listados acima.

Arquitetura atual

Primeiro, deixe-me apresentar a arquitetura básica. Aliás, chamamos todo o subsistema de mensagens de bate-papo "Falcon". É por isso que o ícone do falcão está no diagrama.

quando um usuário final publica uma mensagem de bate-papo, o write-api coloca os dados da mensagem no Kafka
read-model-updater ("rmu" em resumo) busca dados do Kafka, converte-os em read-model e os coloca no HBase
quando um usuário final lê mensagens de bate-papo, os dados da mensagem de pull-api são lidos do HBase

Não explico porque escolhemos o CQRS neste post. Portanto, confira os slides abaixo se quiser conhecer em detalhes ou se não estiver familiarizado com o conceito de CQRS.
Kafka Summit SF 2017 - Serviços de mensagens escaláveis e resilientes em todo o mundo com Kafka e Kafka Streams
Serviços de mensagens escaláveis e resilientes em todo o mundo por CQRS e Event Sourcing usando Akka, Kafka Streams e HBase

Fluxo de atualização do banco de dados

Agora, vou explicar como fizemos a atualização do banco de dados em cima dessa arquitetura

Etapa 1: Prepare novos clusters e faça a restauração inicial do backup.

Etapa 2: Prepare outro consumidor (rmu2 neste diagrama) para sincronizar dados do Kafka com o novo cluster de banco de dados. Você reproduzirá eventos antigos do Kafka começando antes da restauração inicial. Certifique-se de implementar a idempotência em seu consumidor. Quer dizer, o sistema precisa funcionar corretamente mesmo que o mesmo evento seja consumido mais de uma vez.

Etapa 3: Quando o novo consumidor (rmu2) alcançar as mensagens mais recentes do Kafka, prepare outra API de leitura extraindo dados do novo cluster de banco de dados. E envie solicitações para nova read-api gradualmente.

Haveria alguma diferença de estado entre o cluster antigo e o novo cluster, mesmo que a sincronização de dados fosse concluída em alguns milissegundos. Tivemos um pequeno problema devido a essa diferença, então você precisa confirmar e executar uma verificação de avaliação para ver que tipo de problema pode ser acionado pela diferença entre os clusters e a lógica do aplicativo com antecedência. Ou se você tiver algumas boas camadas na frente do read-api para distribuir a solicitação de acordo com o atributo do usuário ou algo assim (por exemplo, roteamento via Nginx ou Envoy como proxy), basta definir a regra adequada e a diferença pode ser tratada com eficiência e não será um problema.

E na retrospectiva deste projeto, notamos que se você puder espelhar as solicitações da api existente para a nova api, poderá fazer o teste de carga usando o tráfego de produção sem afetar os usuários finais.

Etapa 4: Mude para a nova API de leitura 100% e desligue clusters e aplicativos antigos quando tiver certeza de que tudo está funcionando perfeitamente.

Por que acho que essa abordagem é melhor

Deixe-me explicar a diferença com a abordagem azul-verde normal. Um problema no azul-verde normal é que você precisa garantir que os dados sejam sincronizados em ambos os clusters, de preferência não apenas antes da atualização, mas também após a atualização. Nessa abordagem, em vez de usar a funcionalidade de replicação fornecida pelo banco de dados, as atualizações do banco de dados são aplicadas separadamente por meio do aplicativo que escrevemos e preparamos. Essa abordagem nos traz muitos méritos.

Primeiro, como eles estão trabalhando separadamente, você não precisa se preocupar com a sincronização dos dados em cada fase. Especialmente, você precisará de algum esforço extra (e bastante difícil na maioria dos casos) na sincronização de dados do novo cluster para o cluster antigo se quiser ter uma maneira fácil de reverter após a atualização. Mas nesta abordagem, eles estão apenas trabalhando de forma independente. Assim, você pode simplesmente voltar a usar os antigos caso algum problema inesperado comece a acontecer após a atualização.

Em segundo lugar, você não precisa se preocupar com a compatibilidade de versão entre clusters antigos e novos. Se você usar a funcionalidade de sincronização de dados de cluster fornecida pelo banco de dados, haverá alguma restrição de versão e problemas de compatibilidade que podem ocorrer em alguns casos extremos. Mas nesta abordagem, tudo que você precisa fazer é preparar um aplicativo independente que coloque dados em cada banco de dados. Eu acho que é o problema que você pode resolver muito mais facilmente na maioria dos casos. E, em teoria, não apenas atualizando a versão do banco de dados, mas também você pode alternar o novo cluster para um completamente diferente (por exemplo, DynamoDB) usando a mesma abordagem. Nesse caso, você não pode usar os dados de backup para a configuração inicial e precisa preparar o programa de migração de dados inicial. Isso vai levar algum tempo, mas acho que esse é o item razoável para lidar.

Conclusão

Os assuntos de CQRS e fonte de eventos são frequentemente discutidos na arquitetura de software. Do ponto de vista operacional, ter mais uma camada como barramento de eventos aumenta a complexidade da infraestrutura e o custo de operação. Honestamente falando, eu não gostava muito dessa abordagem dessa visão antes. Mas percebemos que isso também muda a forma como operamos a infraestrutura e nos traz a tranquilidade na operação do banco de dados. E sim, eu sou uma grande diversão do CQRS e do fornecimento de eventos agora :)

Próximo desafio

Você pode se perguntar o que atualizaríamos o Kafka (ônibus de fornecimento de eventos)? Sim, esse será o nosso próximo desafio. Espero que exista uma abordagem melhor do que a atualização contínua normal e a implantação azul-verde. A vida de engenheiro continua!