Desenvolvimento com o Azure Managed Redis (versão prévia)
Resiliência de conexão e carga do servidor
Ao desenvolver aplicativos cliente, confirme se considera as práticas recomendadas relevantes para resiliência de conexão e gerenciamento de carga do servidor.
Considere mais chaves e valores menores
O Azure Managed Redis (versão prévia) funciona melhor com valores menores. Para espalhar os dados em várias chaves, considere dividir partes maiores de dados em partes menores. Para obter mais informações sobre o tamanho de valor ideal, confira este artigo.
Tamanho grande de solicitação ou resposta
Uma solicitação/resposta grande pode causar tempos limite. Por exemplo, suponha que o valor do tempo limite configurado no cliente seja de um segundo. Seu aplicativo solicita duas chaves (por exemplo, "A" e "B") ao mesmo tempo (usando a mesma conexão de rede física). A maioria dos clientes dá suporte à solicitação pipelining, em que as solicitações “A” e “B” são enviadas uma após a outra sem aguardar suas respostas. O servidor devolve as respostas na mesma ordem. Se a resposta “A” for grande, ela poderá consumir a maior parte do tempo limite das solicitações posteriores.
No exemplo a seguir, a solicitação “A” e a “B” são enviadas rapidamente para o servidor. O servidor começa a enviar respostas “A” e “B” rapidamente. Devido aos tempos de transferência de dados, a resposta “B” deve aguardar que a resposta “A” atinja o tempo limite, mesmo que o servidor tenha respondido rapidamente.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
Essa é uma solicitação/resposta difícil de se medir. Você pode instrumentar o código do cliente para monitorar grandes solicitações e respostas.
As resoluções para tamanhos de resposta grandes são variadas, mas incluem:
- Otimizar o aplicativo para um grande número de valores pequenos, em vez de alguns valores grandes.
- A solução preferida é dividir seus dados em valores menores relacionados.
- Veja o post Qual é o intervalo de tamanho de valor ideal para Redis? 100 KB é muito grande? para obter mais detalhes sobre por que valores menores são recomendados.
- Aumentar o tamanho da VM (máquina virtual) para obter recursos de largura de banda mais altos
- Mais largura de banda em sua VM de cliente ou servidor pode reduzir os tempos de transferência de dados para respostas maiores.
- Compare o uso de rede atual em ambos os computadores com os limites do tamanho atual da VM. Mais largura de banda somente no servidor ou somente no cliente pode não ser suficiente.
- Aumentar o número de objetos de conexão que o aplicativo usa.
- Use uma abordagem Round Robin para fazer solicitações em diferentes objetos de conexão.
Uso do pipelining
Tente escolher um cliente Redis que dê suporte ao pipelining Redis. O pipelining ajuda a fazer uso eficiente da rede e obter a melhor taxa de transferência possível.
Evitar operações caras
Algumas operações do Redis, como o comando KEYS têm consumo alto e devem ser evitadas. Para ver algumas considerações sobre comandos de execução prolongada, confira comandos de execução prolongada.
Escolha uma camada adequada
O Azure Managed Redis oferece as camadas: Otimizada para Memória, Balanceada, Computação Otimizada e Otimizada para Flash. Confira aqui mais informações sobre como escolher uma camada de serviço. Recomendamos o teste de desempenho para escolher a camada certa e validar as configurações de conexão. Para obter mais informações, confira Teste de desempenho.
Escolha uma modo de disponibilidade adequado
O Azure Managed Redis permite habilitar ou desabilitar a configuração de alta disponibilidade. Quando o modo de alta disponibilidade estiver desabilitado, os dados da instância do ARM não serão replicados e, portanto, sua instância do Redis ficará indisponível durante a manutenção. Todos os dados na instância do ARM também serão perdidos no caso de manutenção planejada ou não planejada. Recomendamos desabilitar a alta disponibilidade apenas para suas cargas de trabalho de desenvolvimento ou teste. O desempenho das instâncias do Redis com alta disponibilidade também pode ser menor devido à falta de replicação de dados, que é crucial para distribuir a carga entre os fragmentos de dados primários e de réplica.
Cliente na mesma região que a instância do Redis
Localize sua instância do Redis e seu aplicativo na mesma região. Conectar-se a um Redis em uma região diferente pode aumentar significativamente a latência e reduzir a confiabilidade.
Embora você possa se conectar de fora do Azure, não é recomendável, principalmente se estiver usando o Redis para acelerar o desempenho de seu aplicativo ou banco de dados. Se você estiver usando o servidor Redis como apenas um repositório de chave/valor, a latência pode não ser a principal preocupação.
Confiar no endereço IP público do nome do host
O endereço IP público atribuído à sua instância do ARM pode ser alterado como resultado de uma operação de escala ou melhoria de back-end. É recomendável depender do nome do host, em vez de um endereço IP público explícito.
Uso de criptografia do TLS
Por padrão, o Azure Managed Redis exige comunicações criptografadas por TLS. No momento, há suporte para o TLS nas versões 1.2 e 1.3. Se sua ferramenta ou biblioteca de clientes não oferecer suporte ao TLS, é possível habilitar as conexões não criptografadas.
Monitore o uso de memória, métricas de uso de CPU, conexões de clientes e largura de banda de rede
Ao usar a instância do Azure Managed Redis em produção, recomendamos definir alertas para as métricas "CPU", "Porcentagem de Memória Utilizada" e "Clientes Conectados". Se essas métricas estiverem continuamente acima de 75%, considere escalar sua instância para uma camada de serviço de memória maior ou com uma melhor taxa de transferência. Veja quando escalar para mais detalhes.
Considere habilitar a Persistência de Dados ou o Backup de Dados
O Redis foi projetado para dados efêmeros por padrão, o que significa que, em raras ocasiões, seus dados podem ser perdidos devido a várias circunstâncias, como manutenção ou interrupções. Se seu aplicativo for sensível à perda de dados, recomendamos habilitar a persistência de dados ou backups periódicos usando a operação de exportação de dados.
O recurso persistência de dados foi projetado para fornecer automaticamente um ponto de recuperação rápida para dados quando um cache fica inativo. A recuperação rápida é possível armazenando o arquivo RDB ou AOF em um disco gerenciado montado na instância de cache. Os arquivos de persistência no disco não são acessíveis aos usuários ou não podem ser usados por nenhuma outra instância do AMR.
Muitos clientes desejam usar a persistência para fazer backups periódicos dos dados em seu cache. Não recomendamos que você use a persistência de dados dessa maneira. Em vez disso, use o recurso importação/exportação. Você pode exportar cópias de dados no formato RDB diretamente para a conta de armazenamento escolhida e acionar a exportação de dados com a frequência necessária. Esses dados exportados podem então ser importados para qualquer instância do Redis. A exportação pode ser disparada no portal ou usando as ferramentas CLI, PowerShell ou SDK.
Diretrizes específicas para a biblioteca de clientes
Para mais informações, confira o artigo Bibliotecas de clientes do Azure Managed Redis