Desenvolvimento

  • Artigo

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 Cache do Azure para Redis funciona melhor com valores menores. Considere dividir partes maiores de dados em partes menores para difundir os dados em várias chaves. 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.
  • Aumentar o tamanho da VM para capacidade de largura de banda mais alta
    • Mais largura de banda na VM do cliente ou do 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.

Distribuição de chaves

Se você estiver planejando usar o clustering do Redis, primeiro leia Melhores práticas de clustering do Redis com chaves.

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

Use as camadas Standard, Premium, Enterprise ou Enterprise Flash para sistemas de produção. Não use a camada do tipo Básico em produção. A camada do tipo Básico é um sistema de nó único sem replicação de dados ou SLA. Além disso, use pelo menos um cache C1. Caches C0 são destinados apenas a cenários de desenvolvimento/teste simples, pois:

  • compartilham um núcleo de CPU
  • usam pouca memória
  • são propensos a problemas de ruídos

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.

Cliente na mesma região que o cache

Localize sua instância de cache e seu aplicativo na mesma região. Conectar-se a um cache em uma região diferente pode aumentar significativamente a latência e reduzir a confiabilidade.

Embora você possa se conectar de fora do Azure, isso não é recomendado, especialmente ao usar o Redis como cache. Se você estiver usando o servidor Redis apenas como repositório de chaves/valor, talvez a latência não seja a principal preocupação.

Confiar no endereço IP público do nome do host

O endereço IP público atribuído ao seu cache pode ser alterado como resultado de uma operação de dimensionamento ou melhoria de back-end. É recomendável depender do nome do host, em vez de um endereço IP público explícito. Aqui estão os formulários recomendados para as várias camadas:

Camada Formulário
Básico, Standard e Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Escolher uma versão apropriada do Redis

A versão padrão do Redis usada ao criar um cache pode ser alterada ao longo do tempo. O Cache do Azure para Redis 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 Redis explicitamente ao criar o cache.

Diretrizes específicas para as camadas Enterprise

Como as camadas Enterprise e Enterprise Flash são criadas no Redis Enterprise em vez do Redis de código aberto, existem algumas diferenças nas melhores práticas de desenvolvimento. Confira Melhores práticas para camadas Enterprise e Enterprise Flash para obter mais informações.

Uso de criptografia do TLS

Por padrão, o Cache do Azure para Redis exige comunicações criptografadas por TLS. No momento, há suporte para o TLS nas versões 1.0, 1.1 e 1.2. No entanto, as versões 1.0 e 1.1 do TLS estão em vias de substituição em todo o setor. Por isso, se possível, use o TLS 1.2.

Se sua ferramenta ou biblioteca de clientes não oferecer suporte ao TLS, a habilitação de conexões não criptografadas é possível por meio do portal do Azure ou de APIs de gerenciamento. Se as conexões criptografadas não forem possíveis, é recomendável colocar seu cache e o aplicativo cliente em uma rede virtual. Para mais informações sobre quais portas são usadas no cenário de cache de rede virtual, consulte esta tabela.

Alterações no certificado TLS do Azure

A Microsoft está atualizando os serviços do Azure para que eles usem certificados TLS de outro conjunto de Autoridades de Certificação (ACs). Essa alteração está distribuída 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 AC atuais não estão em conformidade com um dos requisitos de Linha de Base do Fórum do Navegador/da AC. O problema foi relatado em 1º de julho de 2020 e se aplica a vários provedores de PKI (Infraestrutura de Chave Pública) populares em todo o mundo. A maioria dos certificados TLS usados pelos serviços do Azure hoje vem da PKI Baltimore Cybertrust Root. O serviço Cache do Azure para Redis continuará vinculado à Baltimore CyberTrust Root. Seus certificados de servidor TLS, no entanto, serão emitidos por novas ICAs (Autoridades de Certificação Intermediárias) a partir de 12 de outubro de 2020.

Observação

Essa alteração é limitada aos serviços em regiões públicas do Azure. Ele exclui regiões soberanas (por exemplo, a China) ou nuvens governamentais.

Esta alteração me afeta?

Esperamos que a maioria dos clientes do Cache do Azure para Redis não seja 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 certificado”. Se ele estiver fixado em um certificado de entidade final ou intermediário em vez da Baltimore CyberTrust Root, você deverá executar ações imediatas para alterar a configuração do certificado.

O Cache do Azure para Redis não dá suporte à associação OCSP.

A tabela a seguir fornece informações sobre os certificados que estão sendo revistos. Dependendo do certificado usado pelo seu aplicativo, você pode precisar atualizá-lo para evitar a perda de conectividade com a instância do Cache do Azure para Redis.

Tipo de AC Current Após a Revisão (12 de outubro de 2020) Ação
Root Impressão digital: d4de20d05e66fc53fe1a50882c78db2852cae474

Expiração: segunda-feira, 12 de maio de 2025, 16:59:00

Nome da entidade:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Não alterando Nenhum
Intermediários Impressão digital:
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

Expiração: sexta-feira, 20 de maio de 2024 5:52:38

Nome da entidade:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 Impressão digital:
CN = Microsoft RSA TLS CA 01
Impressão digital: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

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

Expiração: terça-feira, 8 de outubro de 2024 12:00:00;

Nome da entidade:
O = Microsoft Corporation
C = US
 Obrigatório

Quais ações devo realizar?

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

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

Certificado Impressão digital
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
DigiCert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Dica

Espera-se que os certificados intermediários e finais sejam alterados com frequência. É recomendável não depender deles. Em vez disso, fixe seu aplicativo a um certificado raiz, uma vez que ele é revisto com menos frequência.

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

Nome comum da AC Impressão digital
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Emissora de AC Microsoft Azure TLS 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Emissora de AC Microsoft Azure TLS 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Emissora de AC Microsoft Azure TLS 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Emissora de AC Microsoft Azure TLS 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Se seu aplicativo validar o certificado em código, você precisará modificá-lo para reconhecer as propriedades — por exemplo, Emissores, Impressão digital — dos certificados recentemente afixados. Essa verificação extra deve abranger todos os certificados fixados para terem maior durabilidade no futuro.

Diretrizes específicas para a biblioteca de clientes

Para saber mais, confira Bibliotecas do cliente.

Próximas etapas