Cloud Load Balancing fournit des mécanismes permettant de répartir le trafic utilisateur entre plusieurs instances d'une application. Ces mécanismes répartissent la charge sur plusieurs instances de l'application et permettent aux utilisateurs finaux de bénéficier d'une application offrant des performances optimales. Cette page décrit certaines des bonnes pratiques assurant que l'équilibreur de charge est optimisé pour votre application. Pour garantir des performances optimales, nous vous recommandons d'effectuer une analyse comparative des modèles de trafic de votre application.
Placer les backends à proximité des clients
Plus vos utilisateurs ou applications clientes sont proches de vos charges de travail (backends de l'équilibreur de charge), plus la latence du réseau entre eux est faible. Par conséquent, créez les backends de votre équilibreur de charge dans la région la plus proche de celle où vous prévoyez que le trafic de vos utilisateurs va arriver sur Google Front End. Dans de nombreux cas, l'exécution de vos backends dans plusieurs régions est nécessaire pour réduire la latence induite pour les clients situés dans différentes parties du monde.
Pour plus d'informations, consultez les articles suivants :
- Distribution du trafic pour les équilibreurs de charge d'application externes
- Bonnes pratiques pour la sélection des régions Compute Engine
Activer la mise en cache avec Cloud CDN
Activez Cloud CDN et la mise en cache dans le cadre de votre configuration par défaut de l'équilibreur de charge d'application externe. Pour plus d'informations, consultez la section Cloud CDN.
Lorsque vous activez Cloud CDN, la mise en cache des réponses peut prendre quelques minutes. Cloud CDN ne met en cache que les réponses dont le contenu peut être mis en cache. Si les réponses ne sont pas mises en cache dans le cas d'une URL, vérifiez les en-têtes renvoyés pour cette URL ainsi que la configuration de la mise en cache pour votre backend. Pour en savoir plus, consultez la page Résoudre les problèmes liés à Cloud CDN.
Sélection du protocole de règle de transfert
Pour l'équilibreur de charge d'application externe global et l'équilibreur de charge d'application classique, nous recommandons HTTP/3, un protocole Internet basé sur IETF QUIC. Le protocole HTTP/3 est activé par défaut dans les principaux navigateurs Android Cronet et iOS. Pour utiliser HTTP/3 pour vos applications, assurez-vous que le trafic UDP n'est pas bloqué ni soumis à une limitation de débit sur votre réseau, et que le protocole HTTP/3 n'était pas auparavant désactivé sur vos équilibreurs de charge d'application externes globaux. Les clients qui ne sont pas encore compatibles avec HTTP/3, tels que les navigateurs ou les bibliothèques réseau plus anciens, ne seront pas affectés. Pour plus d'informations, consultez la section HTTP/3 QUIC.
Pour l'équilibreur de charge d'application externe régional, nous acceptons les protocoles HTTP/1.1, HTTPS et HTTP/2. Les protocoles HTTPS et HTTP/2 nécessitent tous deux une phase initiale de configuration de TLS.
Sélection du protocole de service de backend
Le choix du protocole de backend (HTTP, HTTPS ou HTTP/2) affecte la latence de l'application et la bande passante réseau disponible pour l'application. Par exemple, l'utilisation de HTTP/2 entre l'équilibreur de charge et l'instance backend peut nécessiter beaucoup plus de connexions TCP à l'instance que le protocole HTTP(S). Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP(S), n'est pas disponible actuellement avec HTTP/2. Vous risquez par conséquent de constater des latences de backend élevées, car les connexions backend sont établies plus fréquemment.
Le protocole du service de backend a également une incidence sur la façon dont le trafic est chiffré en transit. Avec les équilibreurs de charge HTTP(S) externes, l'intégralité du trafic vers des backends hébergés sur des réseaux VPC Google Cloud est automatiquement chiffrée. Cela s'appelle le chiffrement automatique au niveau du réseau. Toutefois, le chiffrement automatique au niveau du réseau n'est disponible que pour les communications avec des groupes d'instances et des backends NEG zonaux. Pour tous les autres types de backends, Google Cloud vous recommande d'utiliser des protocoles sécurisés tels que HTTPS et HTTP/2, pour chiffrer la communication avec le service de backend. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.
Durée de connexion recommandée
Les conditions du réseau sont changeantes et l'ensemble des backends peut évoluer en fonction de la charge. Pour les applications qui génèrent beaucoup de trafic vers un seul service, une connexion de longue durée n'est pas toujours une configuration optimale. Plutôt que d'utiliser indéfiniment une connexion unique au backend, nous vous recommandons de définir une durée de vie maximale de la connexion (par exemple, entre 10 et 20 minutes) et/ou un nombre maximal de requêtes (par exemple, entre 1 000 et 2 000 requêtes), après quoi une autre connexion sera utilisée pour les nouvelles requêtes. L'ancienne connexion est fermée lorsque toutes les requêtes actives qui l'utilisent sont terminées.
Cela permet à l'application cliente de bénéficier des modifications apportées à l'ensemble des backends, y compris les proxys de l'équilibreur de charge et toute réoptimisation du réseau nécessaire pour servir les clients.
Critères de sélection du mode d'équilibrage
Pour améliorer les performances, envisagez de choisir le groupe de backend pour chaque nouvelle requête en fonction du backend le plus réactif. Cette opération peut être effectuée à l'aide du mode d'équilibrage RATE. Dans ce cas, le groupe de backend choisi est celui qui a la latence moyenne la plus faible sur les requêtes récentes ou, pour HTTP/2 et HTTP/3, celui qui a le moins de requêtes en attente.
Le mode d'équilibrage UTILIZATION ne s'applique qu'aux backends de groupe d'instances ; il répartit le trafic en fonction de l'utilisation des instances de VM dans un groupe d'instances.
Configurer l'affinité de session
Dans certains cas, il peut être intéressant pour un même backend de gérer des requêtes provenant des mêmes utilisateurs finaux, ou associées au même utilisateur final, au moins pendant une courte période. Cette valeur peut être configurée à l'aide de l'affinité de session, un paramètre configuré sur le service de backend. L'affinité de session contrôle la distribution des nouvelles connexions des clients aux backends de l'équilibreur de charge. Vous pouvez utiliser l'affinité de session pour vous assurer qu'un même backend traite les requêtes provenant de la même ressource, associées par exemple au même compte utilisateur ou concernant le même document.
L'affinité de session est spécifiée pour l'ensemble de la ressource du service de backend, et non par backend. Cependant, un mappage d'URL peut pointer vers plusieurs services de backend. Par conséquent, vous n'avez pas besoin d'utiliser un seul type d'affinité de session pour l'équilibreur de charge. Selon votre application, vous pouvez utiliser différents services de backend avec différents paramètres d'affinité de session. Par exemple, si une partie de votre application diffuse du contenu statique à de nombreux utilisateurs, il est peu probable qu'elle bénéficie de l'affinité de session. Vous devriez plutôt utiliser un service de backend avec Cloud CDN activé pour diffuser les réponses mises en cache.
Pour plus d'informations, consultez la section Affinité de session.