3 choses que les équipes opérationnelles doivent savoir sur la répartition de charge

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

L’équilibrage de charge. Il est communément admis que nous en avons besoin, que nous comptons sur lui et que nous l’utilisons chaque jour pour faire évoluer les applications à la hausse (et, espérons-le, à la baisse). Il est devenu une infrastructure critique, chargée non seulement d’adapter les capacités à la demande, mais aussi d’assurer la disponibilité continue des applications et des services dont les entreprises dépendent pour leur productivité comme pour leur rentabilité.

C’est pourquoi nous devons nous pencher à nouveau sur la question. Car l’équilibrage de charge ne devrait pas être traité de manière aussi tactique qu’il l’est de plus en plus par les équipes d’exploitation, qui doivent désormais, le plus souvent, provisionner, configurer et déployer ces services aux pouvoirs presque magiques. Envisagé sous un angle stratégique, l’équilibrage de charge permet d’améliorer les performances, de réduire les risques et d’utiliser plus efficacement les ressources nécessaires à la mise à disposition des applications. Ces services sont plus intelligents que ne le laisse entendre l’étiquette de « plomberie » qu’on leur impose souvent, et la compréhension de quelques points clés aidera les équipes d’exploitation à mieux réfléchir à la manière dont elles utilisent l’équilibrage de charge pour prendre en charge les applications.

Sans plus attendre, voici trois choses que les équipes d’exploitation doivent absolument savoir sur l’équilibrage de charge.

1. Les algorithmes sont relatifs

Je commencerais par préciser que l’algorithme round robin est le dernier que vous devriez envisager, mais vous le saviez déjà, n’est-ce pas ? Passons donc directement à des algorithmes plus intelligents, comme celui du plus petit nombre de connexions et celui du temps de réponse le plus rapide. Ce sont bien sûr de bien meilleurs choix lorsqu’il s’agit de trouver le juste équilibre entre performances et utilisation efficace des ressources. Chacun tient compte des caractéristiques de l’application (ou, du moins, de celles des plateformes qui la fournissent), lesquelles sont essentielles pour déterminer quelle instance de l’application (ou quel conteneur, si vous préférez) doit recevoir la requête suivante. L’algorithme du plus petit nombre de connexions part du principe que si une instance compte moins de connexions, elle dispose d’une plus grande capacité et est donc mieux à même de traiter immédiatement la requête en cours. Il privilégie l’efficacité de la capacité aux performances.

Le temps de réponse le plus rapide se situe à l’autre extrémité du spectre et consiste à acheminer les requêtes en fonction des performances. Plus une instance est rapide, plus elle sera souvent sélectionnée. Compte tenu des principes opérationnels (plus la charge augmente, plus les performances diminuent), un serveur moins sollicité finira par répondre plus rapidement et sera donc choisi. Bien que cela tienne quelque peu compte de l’efficacité de la capacité, cet algorithme privilégie systématiquement les performances au détriment de la capacité.

Mais remarquez maintenant les noms des algorithmes : le moins de connexions et le temps de réponse le plus rapide. Imaginez maintenant que deux tortues fassent la course sur le trottoir : l’une d’elles est plus rapide, même si elles avancent toutes les deux à une vitesse que nous qualifierions de « lente ». Il en va de même pour le plus petit nombre de connexions. Lorsqu’il faut choisir entre 99 et 100, 99 est incontestablement le plus petit des deux.

Pourquoi est-ce important ?

La manière dont l’équilibrage de charge gère les requêtes a un impact direct et immédiat sur les performances et la disponibilité. Ces deux caractéristiques sont essentielles, car elles influent en définitive sur l’engagement des clients et la productivité des employés. L’optimisation des architectures intégrant l’équilibrage de charge contribuera à la réussite de l’entreprise en lui permettant d’atteindre ses objectifs d’amélioration de la productivité et de la rentabilité.

Pour aller plus loin :

• Retour aux fondamentaux : la théorie de la relativité (des performances)
• Retour aux fondamentaux : le moins de connexions ne signifie pas la charge la plus faible

2. L’échec instantané est (souvent) un mythe

Depuis l’essor du cloud et des centres de données définis par logiciel, l’élasticité s’est imposée comme le moyen de faire évoluer les applications. Elle permet d’augmenter — ou de réduire — les capacités à la demande afin d’optimiser l’utilisation des ressources (et des budgets). Pourquoi surdimensionner l’infrastructure lorsqu’il suffit d’accroître les capacités à la demande ? De même, les architectures à haute disponibilité (HA), fondées sur les principes de redondance, sont presque devenues désuètes. Pourquoi maintenir des ressources inutilisées en veille dans l’éventualité (peu probable) où l’instance principale de l’application tomberait en panne ? Quel gaspillage de budgets d’investissement et d’exploitation ! Hors d’ici, maudites ressources de secours !

Si la reprise après défaillance et la mise à l’échelle à la demande sont séduisantes en théorie, dans la pratique, les choses ne sont pas aussi simples. En réalité, même les serveurs virtuels (ou serveurs cloud, ou quel que soit le terme que vous préférez employer) mettent un certain temps à démarrer. Si vous (ou votre système automatisé) attendez que le serveur principal tombe en panne ou atteigne sa capacité maximale avant d’en lancer un autre, il est déjà trop tard. Dans les environnements cloud, la planification des capacités ne peut pas reposer sur les mêmes calculs que ceux utilisés dans un environnement traditionnel. Pour adapter les ressources de manière fluide à la demande, les seuils de capacité doivent désormais tenir compte à la fois du rythme de consommation et du temps nécessaire au démarrage d’un nouveau serveur.

Il en va de même pour le basculement. En cas de défaillance du serveur principal, le lancement d’un serveur de remplacement prendra du temps. Pendant ce temps, les utilisateurs verront leur connexion interrompue, subiront des délais d’attente et finiront probablement par se tourner vers un concurrent ou la dernière vidéo de chat à la mode. Même si un serveur de secours inutilisé peut sembler superflu (comme une assurance), vous serez heureux de l’avoir lorsqu’il vous sera nécessaire. En particulier, si cette application joue un rôle dans l’engagement client ou la génération de revenus, le risque de subir ne serait-ce que quelques minutes d’indisponibilité (et les coûts qui en découlent) peut largement justifier le coût du maintien d’un serveur de secours prêt à prendre le relais.

Fait intéressant, les conteneurs semblent pouvoir résoudre ces problèmes grâce à des temps de démarrage fulgurants. Si la disponibilité, les performances et les coûts revêtent tous la même importance, il est peut-être temps de commencer à étudier la valeur que les conteneurs peuvent apporter pour concilier ces trois aspects.

Pourquoi est-ce important ?

Les interruptions de service sont coûteuses. Leur cause importe bien moins que le fait de les éviter en premier lieu. En cas de défaillance, il est impératif de disposer d’une architecture adaptée et de plans de basculement afin de garantir la disponibilité continue indispensable à la réussite de l’entreprise.

Pour aller plus loin :

• Introduction à l’équilibrage de charge : mise à l’échelle ou panne

3. L’adresse IP du client n’est pas la véritable adresse IP du client.

Parmi tous les problèmes qui surviennent lorsqu’une application passe de l’environnement de développement à la production, celui-ci est probablement le plus courant et le plus facile à éviter. En effet, la plupart des services d’équilibrage de charge (du moins, tous ceux qui sont de qualité) sont des proxys. Cela signifie que le client se connecte au proxy, qui se connecte à son tour à votre application. Tous deux utilisent TCP pour transporter le trafic HTTP, qui doit donc respecter les règles du réseau. L’adresse IP source (celle que vous pensez être l’adresse IP du client) est en réalité celle du proxy. Si vous vous appuyez sur l’adresse IP à des fins de sécurité, d’authentification ou de mesure de l’utilisation, cela pose un sérieux problème. La valeur extraite de l’en-tête HTTP n’est pas celle que vous recherchez.

Le secteur a pratiquement standardisé la gestion de ce problème en s’appuyant sur des en-têtes HTTP personnalisés. L’en-tête X-Forwarded-For est probablement celui que vous recherchez réellement : c’est là qu’un proxy indique la véritable adresse IP du client lorsqu’il transmet les requêtes. Malheureusement, il ne s’agit pas d’une norme officielle, mais plutôt d’une norme de fait sur laquelle « tout le monde s’est plus ou moins mis d’accord » ; vous devrez donc le vérifier.

Le fait est que l’adresse IP du client que vous recherchez n’est pas celle que vous pensez. Les développeurs doivent donc en tenir compte avant que les applications qui ont besoin de cette information ne soient déployées dans un environnement de production et cessent soudainement de fonctionner.

Pourquoi est-ce important pour l’entreprise ?

La résolution des problèmes en production est bien plus coûteuse que dans les environnements de développement ou de test. Le temps nécessaire pour identifier et corriger le problème a une incidence négative sur les délais du projet et retarde la mise sur le marché, pourtant essentielle à l’avantage concurrentiel et à la réussite de l’entreprise dans un monde axé sur les applications. Identifier ce problème courant et le traiter dès la phase de développement ou de test permet d’assurer un déploiement en production et une mise sur le marché plus rapides et fluides.

Pour aller plus loin :

• Dans la dèche (de l’équilibrage de charge) : je veux l’adresse IP de mon client

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie