Arquitetura Redis Gerenciada do Azure (visualização)
O Azure Managed Redis (visualização) é executado na pilha Redis Enterprise, que oferece vantagens significativas em relação à edição comunitária do Redis. As informações a seguir fornecem mais detalhes sobre como o Azure Managed Redis é arquitetado, incluindo informações que podem ser úteis para usuários avançados.
Importante
O Azure Managed Redis está atualmente em pré-visualização. Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
Comparação com o Cache Redis do Azure
As camadas Básica, Standard e Premium do Cache do Azure para Redis foram criadas na edição comunitária do Redis. Esta versão do Redis tem várias limitações significativas, incluindo ser single-threaded por design. Isso reduz significativamente o desempenho e torna o dimensionamento menos eficiente, pois mais vCPUs não são totalmente utilizadas pelo serviço. Uma instância típica do Cache do Azure para Redis usa uma arquitetura como esta:
Observe que duas VMs são usadas: uma primária e uma réplica. Essas VMs também são chamadas de "nós". O nó primário contém o processo Redis principal e aceita todas as gravações. A replicação é conduzida de forma assíncrona no nó da réplica para fornecer uma cópia de backup durante manutenção, dimensionamento ou falha inesperada. Cada nó só é capaz de executar um único processo de servidor Redis devido ao design single-threaded da comunidade Redis.
Melhorias arquitetônicas do Azure Managed Redis
O Azure Managed Redis usa uma arquitetura mais avançada semelhante a esta:
Existem várias diferenças:
- Cada máquina virtual (ou "nó") executa vários processos de servidor Redis (chamados "fragmentos") em paralelo. Vários fragmentos permitem uma utilização mais eficiente de vCPUs em cada máquina virtual e maior desempenho.
- Nem todos os fragmentos Redis primários estão na mesma VM/nó. Em vez disso, os fragmentos primários e de réplica são distribuídos em ambos os nós. Como os fragmentos primários usam mais recursos de CPU do que os fragmentos de réplica, essa abordagem permite que mais fragmentos primários sejam executados em paralelo.
- Cada nó tem um processo de proxy de alto desempenho para gerenciar os fragmentos, lidar com o gerenciamento de conexões e acionar a autorrecuperação.
Essa arquitetura permite maior desempenho e também recursos avançados, como replicação geográfica ativa
Clustering
Como o Redis Enterprise pode usar vários fragmentos por nó, cada instância do Azure Managed Redis é configurada internamente para usar clustering, em todas as camadas e SKUs. Isso inclui instâncias menores que são configuradas apenas para usar um único fragmento. O clustering é uma maneira de dividir os dados na instância do Redis entre os vários processos do Redis, também chamados de "fragmentação". O Azure Managed Redis oferece duas políticas de cluster que determinam qual protocolo está disponível para clientes Redis para conexão com a instância de cache.
Políticas de cluster
O Azure Managed Redis oferece duas opções para a política de clustering: OSS e Enterprise. A política de cluster OSS é recomendada para a maioria dos aplicativos porque oferece suporte a uma taxa de transferência máxima mais alta, mas há vantagens e desvantagens em cada versão.
A política de clustering OSS implementa a mesma API de Cluster Redis que o Redis community edition. A API de Cluster Redis permite que o cliente Redis se conecte diretamente a fragmentos em cada nó Redis, minimizando a latência e otimizando a taxa de transferência da rede, permitindo que a taxa de transferência seja dimensionada quase linearmente à medida que o número de fragmentos e vCPUs aumenta. A política de cluster OSS geralmente fornece o melhor desempenho de latência e taxa de transferência. A política de cluster OSS, no entanto, requer que sua biblioteca de cliente ofereça suporte à API de Cluster Redis. Atualmente, quase todos os clientes Redis suportam a API do Cluster Redis, mas a compatibilidade pode ser um problema para versões de cliente mais antigas ou bibliotecas especializadas. A política de cluster OSS também não pode ser usada com o módulo RediSearch.
A política de cluster Enterprise é uma configuração mais simples que utiliza um único ponto de extremidade para todas as conexões de cliente. O uso da política de cluster Enterprise roteia todas as solicitações para um único nó Redis que é usado como proxy, roteando internamente as solicitações para o nó correto no cluster. A vantagem dessa abordagem é que ela faz com que o Azure Managed Redis pareça não clusterizado para os usuários. Isso significa que as bibliotecas de cliente Redis não precisam suportar o Clustering Redis para obter algumas das vantagens de desempenho do Redis Enterprise, aumentando a compatibilidade com versões anteriores e tornando a conexão mais simples. A desvantagem é que o proxy de nó único pode ser um gargalo, tanto na utilização da computação quanto na taxa de transferência da rede. A política de cluster Enterprise é a única que pode ser usada com o módulo RediSearch. Embora a política de cluster Enterprise faça com que uma instância do Azure Managed Redis pareça não estar clusterizada para os usuários, ela ainda tem algumas limitações com comandos Multi-key.
Dimensionamento ou adição de nós
O software Redis Enterprise principal é capaz de escalar (usando VMs maiores) ou expandir (adicionando mais nós/VMs). Em última análise, qualquer ação de dimensionamento realiza a mesma coisa: adicionar mais memória, mais vCPUs e mais fragmentos. Devido a essa redundância, o Azure Managed Redis não oferece a capacidade de controlar o número específico de nós usados em cada configuração. Esse detalhe de implementação é abstraído para o usuário evitar confusão, complexidade e configurações subótimas. Em vez disso, cada SKU é projetado com uma configuração de nó para maximizar vCPUs e memória. Algumas SKUs do Azure Managed Redis usam apenas dois nós, enquanto outras usam mais.
Comandos multi-teclas
Como as instâncias do Azure Managed Redis são projetadas com uma configuração clusterizada, você pode ver CROSSSLOT exceções em comandos que operam em várias chaves. O comportamento varia dependendo da política de agrupamento utilizada. Se utilizar a política de agrupamento OSS, os comandos multi-teclas exigem que todas as teclas sejam mapeadas para o mesmo bloco hash.
Também pode ver CROSSSLOT erros com a política de agrupamento Empresarial. Apenas os seguintes comandos multi-teclas são permitidos nos blocos com o agrupamento Empresarial: DEL, MSET, MGET, EXISTS, UNLINK e TOUCH.
Nas bases de dados Ativo-Ativo, os comandos de escrita multi-teclas (DEL, MSET, UNLINK) apenas podem ser executados em teclas que estejam no mesmo bloco. No entanto, os comandos multi-teclas seguintes são permitidos entre blocos em base de dados Ativo-Ativo: MGET, EXISTS e TOUCH. Para mais informações, consulte Agrupamento de bases de dados.
Configuração de compartilhamento
Cada SKU do Azure Managed Redis é configurado para executar um número específico de processos de servidor Redis, fragmentos em paralelo. A relação entre o desempenho da taxa de transferência, o número de fragmentos e o número de vCPUs disponíveis em cada instância é complicada. A adição de fragmentos geralmente aumenta o desempenho, pois as operações Redis podem ser executadas em paralelo. No entanto, se os fragmentos não puderem executar comandos porque não há vCPUs disponíveis para executar comandos, o desempenho pode realmente cair. A tabela a seguir mostra a configuração de fragmentação para cada SKU Redis Gerenciado do Azure. Esses fragmentos são mapeados para otimizar o uso de cada vCPU enquanto reservam ciclos de vCPU para proxy Redis Enterprise, agente de gerenciamento e tarefas do sistema operacional que também afetam o desempenho.
Nota
O número de fragmentos e vCPUs usados em cada SKU pode mudar ao longo do tempo à medida que o desempenho é otimizado pela equipe do Azure Managed Redis.
| Escalões | Otimizada para Flash | Otimizada para Memória | Equilibrado | Computação Otimizada |
|---|---|---|---|---|
| Tamanho (GB) | vCPUs/fragmentos primários | vCPUs/fragmentos primários | vCPUs/fragmentos primários | vCPUs/fragmentos primários |
| 0.5 | - | - | 2/1 | - |
| 1 | - | - | 2/1 | - |
| 3 | - | - | 2/1 | 4/2 |
| 6 | - | - | 2/1 | 4/2 |
| 12 | - | 2/1 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 | 32/24 | 128/192 | 256/192 | - |
| 1440 | 48/48 | 192/192 | - | - |
| 1920 | 64/48 | 256/192 | - | - |
| 4500 | 144/96 | - | - | - |
Em execução sem o modo de alta disponibilidade ativado
É possível executar sem o modo de alta disponibilidade (HA) ativado. Isso significa que sua instância Redis não tem replicação habilitada e não tem acesso ao SLA de disponibilidade. Não recomendamos a execução no modo não-HA fora dos cenários de desenvolvimento/teste. Não é possível desativar a alta disponibilidade em uma instância que já foi criada. No entanto, você pode habilitar a alta disponibilidade em uma instância que não a tenha. Como uma instância executada sem alta disponibilidade usa menos VMs/nós, as vCPUs não podem ser utilizadas com a mesma eficiência, portanto, o desempenho pode ser menor.
Memória reservada
Em cada Instância Redis Gerenciada do Azure, aproximadamente 20% da memória disponível é reservada como um buffer para operações sem cache, como replicação durante failover e buffer de replicação geográfica ativo. Esse buffer ajuda a melhorar o desempenho do cache e evita a falta de memória.
Redução da escala
Atualmente, não há suporte para redução na redis gerenciada do Azure. Para obter mais informações, consulte Pré-requisitos/limitações do dimensionamento do Azure Managed Redis.
Camada otimizada para Flash
A camada otimizada para Flash utiliza armazenamento flash NVMe e RAM. Como o armazenamento Flash é de menor custo, o uso da camada Flash Optimized permite que você troque algum desempenho por eficiência de preço.
Em instâncias otimizadas para Flash, 20% do espaço em cache está na RAM, enquanto os outros 80% usam armazenamento Flash. Todas as chaves são armazenadas na RAM, enquanto os valores podem ser armazenados em armazenamento Flash ou RAM. O software Redis determina de forma inteligente a localização dos valores. Os valores quentes que são acessados com frequência são armazenados na RAM, enquanto os valores de frio que são menos usados são mantidos no Flash. Antes que os dados sejam lidos ou gravados, eles devem ser movidos para a RAM, tornando-se dados quentes .
Como o Redis otimiza para obter o melhor desempenho, a instância primeiro preenche a RAM disponível antes de adicionar itens ao armazenamento Flash. Preencher a RAM primeiro tem algumas implicações para o desempenho:
- Melhor desempenho e menor latência podem ocorrer ao testar com baixo uso de memória. O teste com uma instância de cache completa pode gerar um desempenho menor porque apenas a RAM está sendo usada na fase de teste de baixo uso de memória.
- À medida que você grava mais dados no cache, a proporção de dados na RAM em comparação com o armazenamento Flash diminui, normalmente fazendo com que a latência e o desempenho da taxa de transferência também diminuam.
Cargas de trabalho adequadas para a camada otimizada para Flash
As cargas de trabalho que provavelmente funcionarão bem na camada Otimizada para Flash geralmente têm as seguintes características:
- Leitura pesada, com uma alta proporção de comandos de leitura para escrever comandos.
- O Access é focado em um subconjunto de chaves que são usadas com muito mais frequência do que o resto do conjunto de dados.
- Valores relativamente grandes em comparação com nomes de chaves. (Como os nomes das chaves são sempre armazenados na RAM, valores grandes podem se tornar um gargalo para o crescimento da memória.)
Cargas de trabalho que não são adequadas para a camada otimizada para o Flash
Algumas cargas de trabalho têm características de acesso menos otimizadas para o design da camada otimizada para o Flash:
- Escreva cargas de trabalho pesadas.
- Padrões de acesso a dados aleatórios ou uniformes na maior parte do conjunto de dados.
- Nomes de chaves longos com tamanhos de valor relativamente pequenos.