Desenvolvimento

Resiliência da conexão e carga do servidor

Ao desenvolver aplicativos cliente, certifique-se de considerar as práticas recomendadas relevantes para resiliência de conexão e gerenciamento de carga do servidor.

Considere mais chaves e valores menores

O Cache Redis do Azure funciona melhor com valores menores. Para distribuir os dados por várias chaves, considere dividir blocos maiores de dados em blocos menores. Para obter mais informações sobre o tamanho do valor ideal, consulte este artigo.

Grande tamanho de solicitação ou resposta

Um pedido/resposta grande pode provocar tempos limite. Como exemplo, suponha que o valor de tempo limite configurado no cliente seja de 1 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 suporta pipelining de pedidos, onde ambos os pedidos 'A' e 'B' são enviados um após o outro sem esperar por suas respostas. O servidor envia as respostas de volta na mesma ordem. Se a resposta 'A' for grande, ela pode consumir a maior parte do tempo limite para solicitações posteriores.

No exemplo a seguir, as solicitações 'A' e '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 o tempo limite da resposta 'A', 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**)

Este pedido/resposta é difícil de medir. Você pode instrumentar o código do seu cliente para rastrear grandes solicitações e respostas.

As resoluções para grandes tamanhos de resposta são variadas, mas incluem:

• Otimize seu 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 é a faixa de tamanho de valor ideal para redis? 100 KB é muito grande? para obter detalhes sobre por que valores menores são recomendados.
• Aumente o tamanho da sua máquina virtual (VM) para obter maiores recursos de largura de banda
  • Mais largura de banda em sua VM cliente ou servidor pode reduzir os tempos de transferência de dados para respostas maiores.
  • Compare o uso atual da rede em ambas as máquinas com os limites do tamanho atual da VM. Mais largura de banda apenas no servidor ou apenas no cliente pode não ser suficiente.
• Aumente o número de objetos de conexão que seu aplicativo usa.
  • Use uma abordagem round-robin para fazer solicitações em diferentes objetos de conexão.

Distribuição de chaves

Se você estiver planejando usar o cluster Redis, primeiro leia Práticas recomendadas de clustering do Redis com chaves.

Use tubulação

Tente escolher um cliente Redis que suporte pipelining Redis. O pipelining ajuda a fazer uso eficiente da rede e obter o melhor rendimento possível.

Evite operações dispendiosas

Algumas operações Redis, como o comando KEYS, são caras e devem ser evitadas. Para obter algumas considerações sobre comandos de longa execução, consulte Comandos de longa execução.

Escolha um nível apropriado

Use as camadas Standard, Premium, Enterprise ou Enterprise Flash para sistemas de produção. Não use a camada Básica na produção. A camada Basic é um sistema de nó único sem replicação de dados e sem SLA. Além disso, utilize pelo menos uma cache C1. Os caches C0 destinam-se apenas a cenários simples de desenvolvimento/teste porque:

• eles compartilham um núcleo de CPU
• usar pouca memória
• são propensos a problemas de vizinhos barulhentos

Recomendamos testes de desempenho para escolher a camada certa e validar as configurações de conexão. Para obter mais informações, consulte Testes de desempenho.

Cliente na mesma região da cache

Localize sua instância de cache e seu aplicativo na mesma região. Ligar a uma cache numa região diferente pode aumentar significativamente a latência e reduzir a fiabilidade.

Embora você possa se conectar de fora do Azure, isso não é recomendado, especialmente ao usar o Redis como um cache. Se você estiver usando o servidor Redis apenas como um armazenamento de chave/valor, a latência pode não ser a principal preocupação.

Confie no nome do host, não no endereço IP público

O endereço IP público atribuído ao cache pode ser alterado como resultado de uma operação de escala ou melhoria de back-end. Recomendamos confiar no nome do host em vez de um endereço IP público explícito. Aqui estão os formulários recomendados para os vários níveis:

Escolha uma versão apropriada do Redis

A versão padrão do Redis usada ao criar um cache pode mudar ao longo do tempo. O Cache Redis do Azure pode adotar uma nova versão quando uma nova versão do Redis de código aberto for lançada. Se você precisar de uma versão específica do Redis para seu aplicativo, recomendamos escolher a versão do Redis explicitamente ao criar o cache.

Orientações específicas para os níveis Enterprise

Como as camadas Enterprise e Enterprise Flash são construídas no Redis Enterprise em vez de Redis de código aberto, há algumas diferenças nas práticas recomendadas de desenvolvimento. Para obter mais informações, consulte Práticas recomendadas para as camadas Enterprise e Enterprise Flash.

Usar criptografia TLS

O Cache Redis do Azure requer comunicações criptografadas TLS por padrão. As versões 1.0, 1.1 e 1.2 do TLS são suportadas atualmente. No entanto, o TLS 1.0 e o 1.1 estão em um caminho para a descontinuação em todo o setor, portanto, use o TLS 1.2 se possível.

Se a sua biblioteca ou ferramenta de cliente não suportar TLS, é possível ativar ligações não encriptadas através do portal do Azure ou das APIs de gestão. Nos casos em que as conexões criptografadas não são possíveis, recomendamos colocar o cache e o aplicativo cliente em uma rede virtual. Para obter mais informações sobre quais portas são usadas no cenário de cache de rede virtual, consulte esta tabela.

Alteração de certificado TLS do Azure

A Microsoft está atualizando os serviços do Azure para usar certificados de servidor TLS de um conjunto diferente de Autoridades de Certificação (CAs). Esta mudança é implementada em fases de 13 de agosto de 2020 a 26 de outubro de 2020 (estimado). O Azure está fazendo essa alteração porque os certificados de CA atuais não fazem parte dos requisitos de linha de base do Fórum da CA/Navegador. O problema foi relatado em 1º de julho de 2020 e se aplica a vários provedores populares de infraestrutura de chave pública (PKI) em todo o mundo. A maioria dos certificados TLS usados pelos serviços do Azure atualmente vêm da PKI raiz do Baltimore CyberTrust . O serviço Cache do Azure para Redis continua a ser encadeado à raiz do Baltimore CyberTrust. Seus certificados de servidor TLS, no entanto, serão emitidos por novas Autoridades de Certificação Intermediárias (ICAs) a partir de 12 de outubro de 2020.

Esta alteração afeta-me?

A maioria dos clientes do Cache Redis do Azure não é afetada pela alteração. Seu aplicativo pode ser afetado se especificar explicitamente uma lista de certificados aceitáveis, uma prática conhecida como fixação de certificados. Se ele estiver fixado a um certificado intermediário ou folha em vez do Baltimore CyberTrust Root, você deve tomar medidas imediatas para alterar a configuração do certificado.

O Cache Redis do Azure não oferece suporte ao grampeamento OCSP.

A tabela a seguir fornece informações sobre os certificados que estão sendo rolados. Dependendo de qual certificado seu aplicativo usa, talvez seja necessário atualizá-lo para evitar a perda de conectividade com sua instância do Cache do Azure para Redis.

Que ações devo seguir?

Se seu aplicativo usa o armazenamento de certificados do sistema operacional ou fixa a raiz de Baltimore, entre outros, nenhuma ação é necessária.

Se seu aplicativo fixar qualquer certificado TLS intermediário ou folha, recomendamos que você fixe as seguintes raízes:

Para continuar a fixar certificados intermediários, adicione o seguinte à lista de certificados intermediários fixos, que inclui mais alguns para minimizar alterações futuras:

Se seu aplicativo valida o certificado no código, você precisa modificá-lo para reconhecer as propriedades --- por exemplo, Emissores, Impressão digital --- dos certificados recém-fixados. Esta verificação adicional deve abranger todos os certificados fixados para estarem mais preparados para o futuro.

Orientação específica da biblioteca do cliente

Para obter mais informações, consulte Bibliotecas de cliente.

Próximos passos

• Teste de desempenho
• Ativação pós-falha e aplicação de patches – Cache de Redis do Azure