Cache do Azure para Redis e excelência operacional
O Cache do Azure para Redis fornece um armazenamento de dados na memória com base no software Redis (Remote Dictionary Server). É um cache de dados seguro e agente de mensagens que fornece alta taxa de transferência e acesso de baixa latência a dados para aplicativos.
As práticas recomendadas que oferecem suporte à excelência operacional incluem:
As seções a seguir incluem considerações de design, uma lista de verificação de configuração e opções de configuração recomendadas específicas para o Cache do Azure para Redis.
Considerações sobre o design
O SLA (Contrato de Nível de Serviço) do Cache do Azure para Redis abrange apenas caches de camadas Standard e Premium. A camada Básica não é coberta.
O Redis é um cache na memória para pares chave-valor e possui HA (Alta Disponibilidade) por padrão, exceto na camada Básica. Há três camadas do Cache do Azure para Redis:
Básica: não é recomendada para cargas de trabalho de produção. A camada Básica é ideal para:
- Nó único
- Vários tamanhos
- Desenvolvimento
- Teste
- Cargas de trabalho não críticas
Standard: um cache replicado em uma configuração primária e secundária de dois nós gerenciada pela Microsoft, com um SLA de alta disponibilidade.
Premium: inclui todos os recursos da camada Standard e os adicionais abaixo:
- Hardware e desempenho mais rápidos em comparação com as camadas Básica e Standard.
- Cache maior, até
120GB
. - Persistência de dados, que inclui o RDB (Arquivo de Banco de Dados do Redis) e o AOF (Arquivo Somente de Acréscimo).
- Suporte à VNET.
- Clustering
- Replicação geográfica: um cache secundário está em outra região e replica dados do primário para recuperação de desastres. Para fazer failover para o secundário, os caches precisam ser desvinculados manualmente e, em seguida, o secundário está disponível para gravações. O aplicativo que grava no Redis precisará ser atualizado com a cadeia de conexão de cache secundária.
- Zonas de Disponibilidade: implantar o cache e as réplicas em zonas de disponibilidade.
Observação
Por padrão, cada implantação terá uma réplica por fragmento. No momento, a persistência, o clustering e a replicação geográfica estão desabilitados com implantações que possuem mais de uma réplica. Seus nós serão distribuídos uniformemente em todas as zonas. Você deve ter uma contagem de réplicas
>=
número de zonas. - Importar e exportar.
A Microsoft garante que, em pelo menos 99.9%
do tempo, os clientes terão conectividade entre os Pontos de Extremidade de Cache e o gateway de Internet da Microsoft.
Lista de verificação
Você configurou o Cache do Azure para Redis com a excelência operacional em mente?
- Agendar atualizações.
- Monitorar o cache e definir alertas.
- Implantar o cache em uma VNET.
- Usar o tipo de cache correto (local, na função, gerenciado, Redis) em sua solução.
- Configure a Persistência de Dados para salvar uma cópia do cache no Armazenamento do Microsoft Azure ou use a Replicação Geográfica, dependendo do requisito de negócios.
- Use uma implementação estática ou singleton do multiplexador de conexão com o Redis e siga o guia de práticas recomendadas.
- Ler atentamente Como administrar o Cache do Azure para Redis.
Recomendações de configuração
Confira a seguinte tabela de recomendações para otimizar sua configuração do Cache do Azure para Redis para excelência operacional:
Recomendação | Descrição |
---|---|
Agendar atualizações. | Agende os dias e horários em que as atualizações do Servidor Redis serão aplicadas ao cache, o que não inclui atualizações do Azure ou atualizações do sistema operacional da VM. |
Monitorar o cache e definir alertas. | Defina alertas para exceções, alta utilização de CPU, alto uso de memória, carga do servidor e chaves removidas para obter insights sobre quando escalar o cache. Se o cache precisar ser escalado, é importante entender quando fazê-lo, pois a CPU será aumentada durante o evento de dimensionamento para migrar dados. |
Implantar o cache em uma VNET. | Dá ao cliente mais controle sobre o tráfego que pode ser conectado ao cache. Verifique se a sub-rede possui espaço de endereço suficiente disponível para implantar os nós de cache e fragmentos (cluster). |
Usar o tipo de cache correto (local, na função, gerenciado, Redis) em sua solução. | Aplicativos distribuídos normalmente implementam uma ou ambas as estratégias a seguir ao colocar dados em cache: - Usando um cache privado, onde os dados são mantidos localmente no computador que executa uma instância de um aplicativo ou de um serviço. - Usando um cache compartilhado, servindo como uma fonte comum que pode ser acessada por vários processos e computadores. Em ambos os casos, o cache pode ser executado no lado do cliente e do servidor. O caching do lado do cliente é feito pelo processo que fornece a interface de usuário para um sistema, como um navegador da Web ou um aplicativo de área de trabalho. O caching do lado do servidor é feito pelo processo que fornece os serviços de negócios que estão sendo executados remotamente. |
Configure a Persistência de Dados para salvar uma cópia do cache no Armazenamento do Microsoft Azure ou use a Replicação Geográfica, dependendo do requisito de negócios. | Persistência de dados: se o mestre e a réplica forem reinicializados, os dados serão carregados automaticamente da conta de armazenamento. Replicação geográfica: o cache secundário precisa ser desvinculado do primário. O secundário agora se tornará o primário e poderá receber gravações. |
Revise Como administrar o Cache Redis do Azure. | Entenda como a perda de dados pode ocorrer com as reinicializações de cache e como testar a resiliência do aplicativo. |
Artefatos de origem
Para identificar as instâncias do Redis que não estão na camada Premium, use a consulta abaixo:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'