Développement

  • Article

Résilience de la connexion et charge du serveur

Lorsque vous développez des applications clientes, veillez à prendre en compte les meilleures pratiques pertinentes pour la résilience des connexions et la gestion de la charge du serveur.

Prendre en compte d’autres clés et des valeurs plus petites

Azure Cache pour Redis fonctionne mieux avec les valeurs plus petites. Envisagez de diviser les plus grandes portions de données en plus petits segments pour répartir les données sur plusieurs clés. Pour plus d’informations sur la taille idéale des valeurs, consultez cet article.

Taille importante de la demande ou de la réponse

Une demande/réponse volumineuse peut entraîner des délais d’expiration. Par exemple, supposons que la durée du délai d’expiration que vous avez configurée sur votre client soit de 1 seconde. Votre application demande deux clés (par exemple, « A » et « B ») en même temps (à l’aide de la même connexion réseau physique). La plupart des clients prennent en charge le traitement en pipeline des requêtes, de sorte que les deux requêtes A et B sont envoyées l’une après l’autre sans attendre les réponses. Le serveur renvoie les réponses dans le même ordre. Si la réponse A est volumineuse, elle peut consommer la majeure partie du délai d’expiration des requêtes suivantes.

Dans l’exemple suivant, les requêtes A et B sont envoyées rapidement au serveur. Le serveur commence rapidement à envoyer les réponses A et B. En raison des temps de transfert de données, la réponse B doit attendre l’expiration de la réponse A, même si le serveur a répondu rapidement.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Cette demande/réponse est difficile à mesurer. Vous pouvez instrumenter votre code client pour suivre les requêtes et les réponses volumineuses.

Les solutions possibles pour la gestion des réponses volumineuses sont variées, et incluent notamment :

  • Optimiser votre application pour prendre en charge un grand nombre de petites valeurs plutôt qu’un petit nombre de grandes valeurs
  • Augmenter la taille de votre machine virtuelle pour obtenir des capacités de bande passante plus élevées
    • Une plus grande quantité de bande passante sur votre machine virtuelle cliente ou serveur peut réduire le temps de transfert des données pour les réponses volumineuses.
    • Comparez l’utilisation actuelle du réseau par les deux ordinateurs aux limites associées à la taille de votre machine virtuelle. L’augmentation de la bande passante sur le serveur ou le client uniquement peut ne pas suffire.
  • Augmenter le nombre d’objets de connexion qu’utilise votre application
    • Utilisez un tourniquet (round-robin) pour envoyer des requêtes vers différents objets de connexion.

Distribution de clés

Si vous envisagez d’utiliser le clustering Redis, lisez Bonnes pratiques concernant le clustering Redis avec des clés.

Utilisez le traitement en pipeline

Essayez de choisir un client Redis qui prend en charge le traitement en pipeline Redis. Le traitement en pipeline permet d’utiliser efficacement le réseau et d’obtenir le meilleur débit possible.

Éviter les opérations coûteuses

Certaines opérations Redis, comme la commande KEYS, sont très coûteuses à exécuter et sont donc à proscrire. Pour connaître quelques éléments à prendre en compte concernant les commandes de longue durée, consultez Commandes de longue durée.

Choisir un niveau approprié

Utilisez les niveaux Flash Standard, Premium, Enterprise ou Enterprise pour les systèmes de production. N’utilisez pas le niveau de base en production. Le niveau De base est un système à nœud unique, sans réplication des données ni contrat SLA. En outre, utilisez au moins un cache C1. Les caches C0 s’appliquent uniquement aux scénarios de développement/test simples, car :

  • ils partagent un cœur de processeur
  • ils utilisent peu de mémoire
  • sont sujets à des problèmes de voisinage bruyant

Nous vous recommandons de tester les performances pour choisir le niveau approprié et valider les paramètres de connexion. Pour plus d’informations, consultez Test de performances.

Client dans la même région que le cache

Placez votre instance de cache et votre application dans la même région. La connexion à un cache dans une autre région peut considérablement augmenter la latence et réduire la fiabilité.

Vous pouvez vous connecter depuis en dehors d’Azure, mais ce n’est pas recommandé, en particulier si vous utilisez Redis comme cache. Si vous utilisez le serveur Redis simplement comme magasin de clés/valeurs, la latence n’est sans doute pas votre première préoccupation.

S’appuyer sur l’adresse IP non publique du nom d’hôte

L’adresse IP publique affectée à votre cache peut changer à la suite d’une opération de mise à l’échelle ou d’une amélioration du back-end. Nous vous recommandons de vous appuyer sur le nom d’hôte au lieu d’une adresse IP publique explicite. Voici les formulaires recommandés pour les différents niveaux :

Niveau Formulaire
De base, Standard, Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Choisir une version Redis appropriée

La version par défaut de Redis utilisée lors de la création d’un cache peut changer au fil du temps. Azure Cache pour Redis peut adopter une nouvelle version lorsqu’une nouvelle version de Redis open source est publiée. Si votre application nécessite une version spécifique de Redis, nous vous recommandons de choisir explicitement cette version de Redis lorsque vous créez le cache.

Conseils spécifiques pour les niveaux Enterprise

Étant donné que les niveaux Enterprise et Enterprise Flash sont basés sur Redis Enterprise plutôt que sur Redis open source, les bonnes pratiques en matière de développement présentent des différences. Pour plus d’informations, consultez les bonnes pratiques pour les niveaux Enterprise et Enterprise Flash.

Utiliser le chiffrement TLS

Azure Cache pour Redis nécessite des communications chiffrées avec le protocole TLS par défaut. Les versions 1.0, 1.1 et 1.2 de TLS sont actuellement prises en charge. Toutefois, TLS 1.0 et 1.1 étant en passe de dépréciation dans l’ensemble du secteur, utilisez TLS 1.2 dans la mesure du possible.

Si votre outil ou bibliothèque de client ne prend pas en charge TLS, vous pouvez activer des connexions non chiffrées par le biais du portail Azure ou des API de gestion. Dans les cas où il est impossible d’établir des connexions chiffrées, nous vous recommandons de placer votre cache et votre application cliente dans un réseau virtuel. Pour plus d’informations sur les ports utilisés dans le scénario de mise en cache du réseau virtuel, consultez ce tableau.

Changement de certificat Azure TLS

Microsoft met à jour les services Azure pour qu’ils utilisent des certificats de serveur TLS issus d’un autre ensemble d’autorités de certification (CA). Cette modification est déployée dans les phases du 13 août 2020 au 26 octobre 2020 (estimation). Azure apporte ce changement parce que les certificats d’autorité de certification actuels ne sont pas conformes à l’une des exigences de ligne de base du forum sur l’autorité de certification/le navigateur. Le problème a été signalé le 1er juillet 2020 et s’applique à plusieurs fournisseurs d’infrastructure à clé publique (PKI) populaires dans le monde entier. La plupart des certificats TLS qu’utilisent les services Azure proviennent aujourd’hui de l’infrastructure à clé publique Baltimore CyberTrust Root. Le service Azure Cache pour Redis continue d’être chaîné à Baltimore CyberTrust Root. Toutefois, ses certificats de serveur TLS seront émis par de nouvelles autorités de certification intermédiaires (ICA) à partir du 12 octobre 2020.

Notes

Cette modification est limitée aux services dans les régions Azure publiques. Elle exclut les clouds souverains (par ex., de Chine) ou gouvernementaux.

Ce changement m’affecte-t-il ?

Nous pensons que la plupart des clients d’Azure Cache pour Redis ne sont pas affectés par la modification. Votre application pourrait être affectée si elle spécifie explicitement une liste de certificats acceptables, pratique appelée « épinglage de certificat ». En cas d’épinglage à un certificat intermédiaire ou feuille au lieu de Baltimore CyberTrust Root, vous devez prendre des mesures immédiates pour modifier la configuration du certificat.

Azure Cache pour Redis ne prend pas en charge l’agrafage OCSP.

Le tableau suivant fournit des informations sur les certificats en cours de déploiement. En fonction du certificat que votre application utilise, il se peut que vous deviez le mettre à jour pour éviter tout perte de connectivité à votre instance Azure Cache pour Redis.

Type d'autorité de certification Actuel Post déploiement (12 octobre 2020) Action
Root Thumbprint : d4de20d05e66fc53fe1a50882c78db2852cae474

Expiration : Lundi 12 mai 2025, 16:59:00

Nom de l’objet :
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Pas de modification Aucun
Intermédiaires Thumbprints :
CN = Microsoft IT TLS CA 1
Empreinte : 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Empreinte : 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Empreinte : 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Empreinte : Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Expiration : Vendredi 20 mai 2024 5:52:38

Nom de l’objet :
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 Thumbprints :
CN = Microsoft RSA TLS CA 01
Empreinte : 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Thumbprint : b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Expiration : Mardi 8 octobre 2024 12:00:00 ;

Nom de l’objet :
O = Microsoft Corporation
C = US
 Obligatoire

Que dois-je faire ?

Si votre application utilise le magasin de certificats du système d’exploitation ou épingle la racine Baltimore parmi d’autres, aucune action n’est nécessaire.

Si votre application épingle un certificat TLS intermédiaire ou feuille, nous vous recommandons d’épingler les racines suivantes :

Certificat Empreinte numérique
Autorité de certification racine Baltimore d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Conseil

Les certificats intermédiaires et feuilles sont censés changer fréquemment. Nous vous recommandons de ne pas pendre de dépendance sur ceux-ci. Au lieu de cela, épinglez votre application à un certificat racine, car il est déployé moins fréquemment.

Pour continuer à épingler des certificats intermédiaires, ajoutez ce qui suit à la liste des certificats intermédiaires épinglés, qui en comprend quelques autres pour minimiser les modifications futures :

Nom commun de l’autorité de certification Empreinte numérique
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Issuing CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Si votre application valide le certificat dans le code, vous devez le modifier pour reconnaître les propriétés (par exemple, émetteurs, thumbprint) des certificats nouvellement épinglés. Cette vérification supplémentaire doit couvrir tous les certificats épinglés pour être plus sécurisés.

Conseils pour la bibliothèque cliente

Pour plus d’informations, consultez Bibliothèques clientes.

Étapes suivantes