Desenvolvimento

  • Artigo

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.
  • 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:

Escalão de serviço Formulário
Básico, Standard e Premium <cachename>.redis.cache.windows.net
Empresa, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

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.

Nota

Esta alteração está limitada a serviços em regiões públicas do Azure. Exclui nuvens soberanas (por exemplo, China) ou governamentais.

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.

Tipo de AC Atual Post Rolling (12 de outubro de 2020) Ação
Raiz Impressão digital: d4de20d05e66fc53fe1a50882c78db2852cae474

Caducação: Segunda-feira, 12 de maio de 2025, 16:59:00

Nome do assunto:
CN = Raiz Baltimore CyberTrust
UO = CyberTrust
O = Baltimore
C = IE		 Não mudar Nenhuma
Substâncias intermédias Impressões digitais:
CN = Microsoft IT TLS CA 1
Impressão digital: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Impressão digital: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Impressão digital: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Impressão digital: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Caducação: Sexta-feira, 20 de maio de 2024 05:52:38

Nome do assunto:
UO = TI da Microsoft
O = Microsoft Corporation
L = Redmond
S = Washington
C = EUA
 Impressões digitais:
CN = Microsoft RSA TLS CA 01
Impressão digital: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Impressão digital: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Caducidade: Terça-feira, 8 de outubro de 2024 12:00:00;

Nome do assunto:
O = Microsoft Corporation
C = EUA
 Necessário

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:

Certificado Thumbprint
AC raiz de Baltimore d4de20d05e66fc53fe1a50882c78db2852cae474
Autoridade de certificação raiz Microsoft RSA 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Raiz Global G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Gorjeta

Espera-se que tanto o certificado intermédio como o certificado folha mudem frequentemente. Recomendamos não depender deles. Em vez disso, fixe seu aplicativo em um certificado raiz, pois ele rola com menos frequência.

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:

Nome comum da AC Thumbprint
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Emissão de TLS do Microsoft Azure CA 01 2F2877C5D778C31E0F29C7E371DF5471BD673173
Emissão de TLS do Microsoft Azure CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Emissão de TLS do Microsoft Azure CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Emissão de TLS do Microsoft Azure CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

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