Redis como um Banco de Dados Primário para Aplicações Complexas

Primeiro, vamos ver o que é o Redis e seu uso, bem como por que é adequado para aplicações modernas de microserviços complexos. Vamos falar sobre como o Redis suporta o armazenamento de múltiplos formatos de dados para diferentes fins por meio de seus módulos. Em seguida, veremos como o Redis, como um banco de dados em memória, pode persistir dados e se recuperar de perda de dados. Também falaremos sobre como o Redis otimiza os custos de armazenamento de memória usando o Redis em Flash.

Em seguida, veremos casos de uso muito interessantes de dimensionamento do Redis e replicação em várias regiões geográficas. Por fim, uma vez que uma das plataformas mais populares para execução de microservices é o Kubernetes, e como executar aplicativos com estado no Kubernetes é um pouco desafiador, veremos como você pode facilmente executar o Redis no Kubernetes.

Por Que o Redis Simplifica Essa Complexidade

Em comparação com um banco de dados multimodal como o Redis, você resolve a maioria desses desafios:

1. Serviço de dados único. Você executa e mantém apenas um serviço de dados. Portanto, sua aplicação também precisa se comunicar com um único armazenamento de dados, o que significa apenas uma interface programática para esse serviço de dados.
2. Latência reduzida. A latência será reduzida ao acessar um único ponto de dados e eliminar várias etapas de rede interna.
3. Múltiplos tipos de dados em um único. Ter um banco de dados como o Redis que permite armazenar diferentes tipos de dados (ou seja, vários tipos de bancos de dados em um) bem como atuar como um cache resolve esses desafios.

Como o Redis Suporta Múltiplos Formatos de Dados

Então, vamos ver como o Redis realmente funciona. Primeiramente, como o Redis suporta múltiplos formatos de dados em um único banco de dados?

Núcleo do Redis e Módulos

A maneira como funciona é que você tem o Redis core, que é um armazenamento de chave-valor que já suporta o armazenamento de vários tipos de dados. Em seguida, você pode estender esse core com o que é chamado de módulos para diferentes tipos de dados, que sua aplicação precisa para diferentes fins. Por exemplo:

• RedisSearch para funcionalidade de busca (como Elasticsearch)
• RedisGraph para armazenamento de dados de grafo

Uma ótima coisa sobre isso é que é modular. Esses diferentes tipos de funcionalidades de banco de dados não estão intimamente integrados em um banco de dados como em muitos outros bancos de dados multimodais, mas sim, você pode escolher exatamente qual funcionalidade de serviço de dados você precisa para sua aplicação e basicamente adicionar esse módulo.

Cache integrado

E, é claro, ao usar o Redis como banco de dados principal, você não precisa de um cache adicional porque você tem isso automaticamente pronto para uso com o Redis. Isso significa, novamente, menos complexidade em sua aplicação porque você não precisa implementar a lógica para gerenciar, popular e invalidar o cache.

Alto desempenho e Testes mais rápidos.

Finalmente, como um banco de dados em memória, o Redis é super rápido e performático, o que, é claro, torna a aplicação em si mais rápida. Além disso, também torna a execução dos testes da aplicação muito mais rápida, pois o Redis não precisa de um esquema como outros bancos de dados. Portanto, não precisa de tempo para inicializar o banco de dados, construir o esquema, e assim por diante antes de executar os testes. Você pode começar com um banco de dados Redis vazio toda vez e gerar dados para testes conforme necessário. Testes rápidos podem realmente aumentar sua produtividade de desenvolvimento.

Persistência de Dados no Redis

Entendemos como o Redis funciona e todos os seus benefícios. Mas, neste ponto, você pode estar se perguntando: Como um banco de dados em memória pode persistir dados? Porque se o processo do Redis ou o servidor em que o Redis está sendo executado falhar, todos os dados em memória serão perdidos, certo? E se eu perder os dados, como posso recuperá-los? Basicamente, como posso ter confiança de que meus dados estão seguros?

A maneira mais simples de ter backups de dados é replicando o Redis. Portanto, se a instância mestre do Redis falhar, as réplicas ainda estarão em execução e terão todos os dados. Se você tiver um Redis replicado, as réplicas terão os dados. Mas é claro, se todas as instâncias do Redis falharem, você perderá os dados porque não haverá réplica restante.

Precisamos de real persistência.

Snapshots (RDB)

O Redis possui vários mecanismos para persistir os dados e mantê-los seguros. O primeiro é snapshots, que você pode configurar com base no tempo, número de solicitações, etc. Os snapshots dos seus dados serão armazenados em um disco, que você pode usar para recuperar seus dados se todo o banco de dados do Redis for perdido. Mas observe que você perderá os últimos minutos de dados, pois geralmente são feitos snapshots a cada cinco minutos ou uma hora, dependendo de suas necessidades.

AOF (Append Only File)

Como alternativa, o Redis utiliza algo chamado AOF, que significa Append Only File. Neste caso, cada alteração é salva continuamente no disco para persistência. Ao reiniciar o Redis ou após uma interrupção, o Redis irá reproduzir os logs do arquivo Append Only File para reconstruir o estado. Portanto, o AOF é mais durável, mas pode ser mais lento do que os snapshots.

Combinação de Snapshots e AOF

E, é claro, você também pode usar uma combinação de AOF e snapshots, onde o arquivo somente de anexos está persistindo dados da memória para o disco continuamente, além de ter snapshots regulares entre eles para salvar o estado dos dados, caso seja necessário recuperá-los. Isso significa que mesmo que o próprio banco de dados do Redis ou os servidores, a infraestrutura subjacente onde o Redis está sendo executado, falhem, você ainda terá todos os seus dados seguros e poderá facilmente recriar e reiniciar um novo banco de dados do Redis com todos os dados.

Onde Está Esse Armazenamento Persistente?

Uma pergunta muito interessante é, onde está esse armazenamento persistente? Então, onde está esse disco que contém seus snapshots e os logs do arquivo somente para anexos localizados? Eles estão nos mesmos servidores onde o Redis está sendo executado?

Esta pergunta na verdade nos leva à tendência ou melhor prática de persistência de dados em ambientes de nuvem, que é sempre melhor separar os servidores que executam sua aplicação e serviços de dados do armazenamento persistente que guarda seus dados.

Com um exemplo específico: Se suas aplicações e serviços são executados na nuvem em, digamos, uma instância AWS EC2, você deve usar o EBS ou Armazenamento de Blocos Elásticos para persistir seus dados em vez de armazená-los no disco rígido da instância EC2. Porque se aquela instância EC2 falhar, você não terá acesso a nenhum de seus armazenamentos, seja RAM ou armazenamento em disco ou qualquer coisa. Portanto, se você deseja persistência e durabilidade para seus dados, é necessário colocar seus dados fora das instâncias em um armazenamento de rede externo.

Como resultado, ao separar esses dois, se a instância do servidor falhar ou se todas as instâncias falharem, você ainda terá o disco e todos os dados nele sem serem afetados. Basta iniciar outras instâncias e pegar os dados do EBS, e é isso. Isso torna sua infraestrutura muito mais fácil de gerenciar porque cada servidor é igual; você não tem nenhum servidor especial com dados ou arquivos especiais nele. Então não importa se você perder toda a sua infraestrutura porque você pode simplesmente recriar uma nova e extrair os dados de um armazenamento separado, e está pronto para seguir em frente.

Voltando ao exemplo do Redis, o serviço do Redis estará em execução nos servidores e utilizando a RAM do servidor para armazenar os dados, enquanto os logs de arquivo somente para adição e instantâneos serão persistidos em um disco fora desses servidores, tornando seus dados mais duráveis.

Otimização de custos com Redis em Flash

Agora sabemos que é possível persistir dados com o Redis para durabilidade e recuperação enquanto se utiliza RAM ou armazenamento em memória para ótimo desempenho e velocidade. Portanto, a pergunta que você pode ter é: Armazenar dados em memória não é caro? Porque você precisaria de mais servidores em comparação com um banco de dados que armazena dados em disco, simplesmente porque a memória é limitada em tamanho. Há um equilíbrio entre o custo e o desempenho.

Bem, o Redis na verdade tem uma maneira de otimizar isso usando um serviço chamado Redis em Flash, que faz parte do Redis Enterprise.

Como o Redis em Flash funciona

É um conceito bastante simples, na verdade: o Redis em Flash estende a RAM para o disco flash ou SSD, onde os valores usados com frequência são armazenados na RAM e os menos usados são armazenados no SSD. Portanto, para o Redis, é apenas mais RAM no servidor. Isso significa que o Redis pode usar mais da infraestrutura subjacente ou dos recursos do servidor subjacente usando tanto a RAM quanto a unidade SSD para armazenar os dados, aumentando a capacidade de armazenamento em cada servidor e, dessa forma, economizando custos de infraestrutura.

Dimensionando o Redis: Replicação e Sharding

Nós falamos sobre o armazenamento de dados para o banco de dados Redis e como tudo funciona, incluindo as melhores práticas. Agora, outro tópico muito interessante é como escalamos um banco de dados Redis?

Replicação e Alta Disponibilidade

Vamos supor que minha instância do Redis fique sem memória, então os dados se tornam muito grandes para serem mantidos na memória, ou o Redis se torna um gargalo e não consegue lidar com mais solicitações. Nesse caso, como aumentar a capacidade e o tamanho da memória do meu banco de dados Redis?

Temos várias opções para isso. Em primeiro lugar, o Redis suporta clustering, o que significa que você pode ter uma instância principal ou mestre do Redis que pode ser usada para ler e escrever dados, e você pode ter várias réplicas dessa instância principal para ler os dados. Dessa forma, você pode escalar o Redis para lidar com mais solicitações e, além disso, aumentar a alta disponibilidade do seu banco de dados. Se o mestre falhar, uma das réplicas pode assumir e seu banco de dados do Redis pode basicamente continuar funcionando sem problemas.

Essas réplicas terão todas cópias dos dados da instância principal. Portanto, quanto mais réplicas você tiver, mais espaço de memória você precisará. E um servidor pode não ter memória suficiente para todas as suas réplicas. Além disso, se você tiver todas as réplicas em um único servidor e esse servidor falhar, todo o seu banco de dados do Redis desaparecerá e você terá tempo de inatividade. Em vez disso, você deseja distribuir essas réplicas entre vários nós ou servidores. Por exemplo, sua instância principal estará em um nó e duas réplicas nos outros dois nós.

Sharding para Conjuntos de Dados Maiores

Bem, isso parece bom o suficiente, mas e se seu conjunto de dados crescer demais para caber na memória de um único servidor? Além disso, escalamos as leituras no banco de dados, então todas as solicitações basicamente apenas consultam os dados, mas nossa instância principal ainda está sozinha e ainda precisa lidar com todas as gravações. Então, qual é a solução aqui?

Para isso, usamos o conceito de sharding, que é um conceito geral em bancos de dados e que o Redis também suporta. Sharding basicamente significa que você pega seu conjunto de dados completo e divide em pedaços menores ou subconjuntos de dados, onde cada shard é responsável por seu próprio subconjunto de dados. 

Isso significa que, em vez de ter uma instância mestre que lida com todas as gravações no conjunto de dados completo, você pode dividi-lo em, digamos, quatro shards, cada um responsável por leituras e gravações em um subconjunto dos dados. Cada shard também precisa de menos capacidade de memória porque possui apenas um quarto dos dados. Isso significa que você pode distribuir e executar shards em nós menores e basicamente escalar seu cluster horizontalmente. E, é claro, à medida que seu conjunto de dados cresce e você precisa de ainda mais recursos, você pode re-shardar seu banco de dados Redis, o que basicamente significa que você apenas divide seus dados em pedaços ainda menores e cria mais shards.

Portanto, ter vários nós que executam várias réplicas do Redis, todos sharded, oferece um banco de dados Redis muito eficiente e altamente disponível que pode lidar com muito mais solicitações sem criar gargalos. 

Agora, devo observar aqui que essa configuração é ótima, mas você precisaria gerenciá-la sozinho, fazer o escalonamento, adicionar nós, fazer o sharding e, em seguida, o resharding, etc. Para algumas equipes que estão mais focadas no desenvolvimento de aplicativos e mais na lógica de negócios do que na execução e manutenção de serviços de dados, isso poderia ser um esforço indesejado. Portanto, como uma alternativa mais fácil, no Redis Enterprise, você obtém esse tipo de configuração automaticamente porque o dimensionamento, sharding e assim por diante são todos gerenciados para você.

Replicação Global com Redis: Implantação Ativa-Ativa

Vamos considerar outro cenário interessante para aplicações que precisam de ainda mais disponibilidade e desempenho em várias localidades geográficas. Então, digamos que tenhamos um cluster de banco de dados Redis replicado e particionado em uma região, no data center de Londres, Europa. Mas temos os dois seguintes casos de uso:

1. Nossos usuários estão distribuídos geograficamente, então estão acessando a aplicação de diferentes partes do mundo. Queremos distribuir nossos serviços de aplicação e dados globalmente, próximos aos usuários, para oferecer melhor desempenho aos usuários.
2. Se o data center completo em Londres, Europa, por exemplo, falhar, queremos uma mudança imediata para outro data center para que o serviço Redis permaneça disponível. Em outras palavras, queremos réplicas de todo o cluster Redis em data centers em várias localidades ou regiões geográficas.

Múltiplos Clusters Redis em Diferentes Regiões

Isto significa que um único dado deve ser replicado para muitos clusters distribuídos em várias regiões, sendo que cada cluster seja totalmente capaz de aceitar leituras e escritas. Neste caso, você teria múltiplos clusters Redis que atuariam como instâncias locais do Redis em cada região, e os dados seriam sincronizados entre esses clusters distribuídos geograficamente. Esta é uma funcionalidade disponível no Redis Enterprise e é chamada de implantação ativa-ativa porque você tem múltiplos bancos de dados ativos em diferentes localidades.

Com essa configuração, teremos menor latência para os usuários. E mesmo que o banco de dados Redis em uma região seja totalmente interrompido, as outras regiões não serão afetadas. Se a conexão ou sincronização entre as regiões for interrompida por um curto período de tempo devido a algum problema de rede, por exemplo, os clusters Redis nessas regiões podem atualizar os dados de forma independente e, uma vez que a conexão seja restabelecida, podem sincronizar essas mudanças novamente.

Resolução de Conflitos com CRDTs

Agora, é claro, quando você ouve isso, a primeira pergunta que pode surgir em sua mente é: Como o Redis resolve as alterações em várias regiões para o mesmo conjunto de dados? Portanto, se os mesmos dados mudarem em várias regiões, como o Redis garante que as alterações de dados de qualquer região não sejam perdidas e os dados sejam sincronizados corretamente, e como garante a consistência dos dados?

Especificamente, o Redis Enterprise usa um conceito chamado CRDTs, que significa tipos de dados replicados sem conflitos, e esse conceito é usado para resolver automaticamente quaisquer conflitos no nível do banco de dados e sem perda de dados. Basicamente, o próprio Redis possui um mecanismo para mesclar as alterações feitas no mesmo conjunto de dados a partir de várias fontes de forma que nenhuma das alterações de dados seja perdida e quaisquer conflitos sejam resolvidos adequadamente. E, como você aprendeu, o Redis suporta vários tipos de dados, cada tipo de dados usa suas próprias regras de resolução de conflitos de dados, que são as mais adequadas para esse tipo de dados específico.

Simplesmente, em vez de apenas substituir as alterações de uma fonte e descartar todas as outras, todas as alterações em paralelo são mantidas e resolvidas de forma inteligente. Novamente, isso é feito automaticamente para você com esse recurso de geo-replicação ativo-ativo, para que você não precise se preocupar com isso.

Executando o Redis no Kubernetes

E o último tópico que eu quero abordar com o Redis é executando o Redis no Kubernetes. Como eu disse, o Redis é uma ótima opção para micro-serviços complexos que precisam suportar vários tipos de dados e que precisam escalar facilmente um banco de dados sem se preocupar com a consistência dos dados. E também sabemos que o novo padrão para executar microserviços é a plataforma Kubernetes. Portanto, executar o Redis no Kubernetes é um caso de uso muito interessante e comum. Então, como isso funciona?

Redis Open Source no Kubernetes

Com o Redis de código aberto, você pode implantar o Redis replicado como um gráfico Helm ou arquivos de manifesto do Kubernetes e, basicamente, usando as regras de replicação e dimensionamento que já discutimos, configurar e executar um banco de dados Redis altamente disponível. A única diferença é que os hosts onde o Redis será executado serão pods do Kubernetes em vez de, por exemplo, instâncias EC2 ou qualquer outro servidor físico ou virtual. Mas os mesmos conceitos de fragmentação, replicação e dimensionamento se aplicam aqui também quando você deseja executar um cluster Redis no Kubernetes, e basicamente você teria que gerenciar essa configuração você mesmo.

Operador Redis Enterprise

No entanto, como mencionei, muitas equipes não querem fazer o esforço de manter esses serviços de terceiros porque preferem investir seu tempo e recursos no desenvolvimento de aplicativos ou em outras tarefas. Portanto, ter uma alternativa mais fácil é importante aqui também. O Redis Enterprise possui um cluster Redis gerenciado, que você pode implantar como um operador Kubernetes.

Se você não conhece operadores, um operador no Kubernetes é basicamente um conceito onde você pode agrupar todos os recursos necessários para operar um determinado aplicativo ou serviço para que você não precise gerenciá-lo ou operá-lo. Em vez de um ser humano operar um banco de dados, basicamente você tem toda essa lógica de forma automatizada para operar um banco de dados para você. Muitos bancos de dados possuem operadores para o Kubernetes, e cada operador desse tipo possui, é claro, sua própria lógica com base em quem os escreveu e como os escreveu.

O operador Redis Enterprise no Kubernetes automatiza especificamente a implantação e configuração de todo o banco de dados Redis em seu cluster Kubernetes. Ele também cuida do dimensionamento, realização de backups e recuperação do cluster Redis, se necessário, etc. Portanto, ele assume a operação completa do cluster Redis dentro do cluster Kubernetes.

Conclusão

Espero que você tenha aprendido muito neste blog e que eu tenha conseguido responder a muitas de suas perguntas. Se você deseja aprender mais sobre tecnologias e conceitos semelhantes, certifique-se de me seguir, pois escrevo regularmente sobre IA, DevOps e tecnologias em nuvem.

Também, comente abaixo se tiver alguma dúvida sobre o Redis ou sugestões de novos tópicos. E com isso, obrigado por ler e até o próximo blog.

Vamos nos conectar no LinkedIn!