3 choses que les opérateurs doivent savoir sur l'équilibrage de charge
Équilibrage de charge. Il est communément admis que nous en avons besoin, que nous y comptons et que nous l’utilisons tous les jours pour faire évoluer (et, espérons-le, réduire) les applications. Il s’agit désormais d’une infrastructure essentielle, chargée non seulement d’évoluer pour répondre à la demande, mais également de garantir la disponibilité continue des applications et des services sur lesquels les entreprises s’appuient pour assurer leur productivité et leurs bénéfices.
C’est pour cela que nous devons y revenir. L’équilibrage de charge ne doit pas rester aussi tactique que le perçoivent souvent les équipes opérationnelles, qui se retrouvent fréquemment à devoir provisionner, configurer et déployer ces services pourtant essentiels. Abordé stratégiquement, l’équilibrage de charge améliore les performances, diminue les risques et optimise l’utilisation des ressources nécessaires à la livraison des applications. Ces systèmes sont bien plus que de simples « tuyauteries ». Comprendre certains points clés aidera vos équipes à mieux exploiter l’équilibrage de charge au service des applications.
Alors sans plus tarder, voici trois choses que les opérateurs doivent vraiment savoir sur l’équilibrage de charge.
1. Les algorithmes sont relatifs
Je commencerais par dire que le round robin est le dernier algorithme dont vous devriez parler, mais vous le saviez déjà, n'est-ce pas ? Passons donc à des algorithmes plus intelligents comme le moins de connexions et le temps de réponse le plus rapide. Ces options sont, bien sûr, beaucoup plus pertinentes quand vous voulez équilibrer performances et utilisation efficace des ressources. Chacun prend en compte les caractéristiques des applications (ou du moins de leurs plateformes) qui sont essentielles pour décider quelle instance de l’application (ou quel conteneur, si vous préférez) doit recevoir la prochaine requête. Le moins de connexions suppose qu’une instance avec moins de connexions dispose de plus de capacité et peut donc mieux traiter cette requête immédiatement. Vous privilégiez ainsi l’efficacité de la capacité plutôt que la performance.
Le temps de réponse le plus rapide , à l’autre extrémité du spectre, consiste à choisir d’orienter les demandes en fonction des performances. Plus l'instance est rapide, plus elle sera sélectionnée souvent. Les axiomes opérationnels étant ce qu'ils sont (à mesure que la charge augmente, les performances diminuent), cela signifie qu'à terme, un serveur moins surchargé répondra plus rapidement et sera donc choisi. Bien que cela implique un clin d’œil à l’efficacité de la capacité, cet algorithme choisit à chaque fois la performance plutôt que la capacité.
Mais notez maintenant les noms des algorithmes : Le moins et le plus rapide . Imaginez maintenant que deux tortues courent sur le trottoir, l’une d’elles est la plus rapide, même si elles se déplacent toutes les deux à ce que nous appelons tous une vitesse « lente ». Il en va de même pour les connexions minimales . Lorsqu'on a le choix entre 99 et 100, 99 est certainement le moins élevé des deux.
Pourquoi c'est important
La manière dont l’équilibrage de charge gère les demandes a un impact direct et immédiat sur les performances et la disponibilité. Ces deux caractéristiques sont essentielles et ont en fin de compte un impact sur l’engagement des clients et la productivité des employés. L'optimisation des architectures incluant l'équilibrage de charge contribuera à garantir le succès de l'entreprise dans la réalisation d'objectifs de productivité et de profit plus élevés.
Plongée plus profonde :
- Retour aux fondamentaux : La théorie de la relativité (de performance)
- Retour aux fondamentaux : Le moins de connexions n'est pas le moins chargé
2. L'échec instantané est (souvent) un mythe
Avec l’essor du cloud et des centres de données définis par logiciel, l’élasticité est devenue la méthode clé pour faire évoluer les applications. Nous utilisons l’élasticité pour augmenter ou réduire la capacité à la demande afin d’optimiser les ressources et maîtriser les budgets. Pourquoi surdimensionner alors que vous pouvez simplement augmenter la capacité à la demande ? De même, les architectures haute disponibilité (HA), basées sur des principes de redondance, appartiennent presque au passé. À quoi bon garder des ressources inactives en réserve au cas où l’instance principale de l’application tomberait en panne ? C’est un gâchis pour vos investissements et vos budgets opérationnels ! Fini, fini, cette veille inutile !
Bien que la défaillance et la mise à l’échelle à la demande soient une belle théorie, dans la pratique, ce n’est pas aussi simple. La réalité est que même les serveurs virtuels (ou serveurs cloud, ou quel que soit le terme que vous souhaitez utiliser) prennent du temps à lancer. Si vous (ou votre système automatisé) attendez que ce serveur principal tombe en panne ou atteigne sa capacité maximale avant d’en lancer un autre, il est déjà trop tard. La planification de la capacité dans les environnements cloud ne peut pas être basée sur les mêmes calculs que ceux qui fonctionnent dans un environnement traditionnel. Les seuils de capacité doivent désormais prendre en compte dans l’équation le taux de consommation ainsi que le temps nécessaire au lancement d’un autre serveur afin de s’adapter de manière transparente à la demande.
Et il en va de même pour le basculement. Si le premier échoue, il faudra du temps pour lancer un remplaçant. Une période pendant laquelle les gens perdent la connexion, perdent le fil et vous abandonnent probablement pour un concurrent ou la dernière vidéo de chat. Même si une roue de secours inutilisée peut sembler être un gaspillage (comme une assurance) lorsque vous en avez besoin, vous serez heureux qu’elle soit là. En particulier, si cette application est responsable de l’engagement client ou des revenus, le risque d’une indisponibilité de quelques minutes (et le coût qui en découle) peut largement compenser le coût de maintien d’une application de rechange à disposition.
Il est intéressant de noter que les conteneurs semblent potentiellement résoudre ces problèmes avec des temps de lancement extrêmement rapides. Si la disponibilité, les performances et le coût sont tous aussi importants, il est peut-être temps de commencer à explorer la valeur que les conteneurs peuvent apporter en termes d’équilibre entre les trois.
Pourquoi c'est important
Les temps d’arrêt sont coûteux. La cause des temps d’arrêt n’est pas aussi importante que le fait de les éviter en premier lieu. Il est impératif de garantir que l’architecture appropriée et les plans de basculement sont en place en cas de panne pour maintenir la disponibilité continue essentielle au succès de l’entreprise.
Plongée plus profonde :
3. L'adresse IP du client n'est pas la véritable adresse IP du client.
Parmi tous les problèmes rencontrés lors du passage d’une application du développement à la production, celui-ci est sans doute le plus fréquent et le plus facile à éviter. Vous voyez, la plupart des services de répartition de charge (tous les bons, en tout cas) fonctionnent comme des proxis. Cela signifie que le client se connecte au proxy, qui à son tour connecte votre application. Tous deux utilisent TCP pour transporter le HTTP, donc ils respectent les règles du réseau. L’adresse IP source (celle que vous croyez être celle du client) correspond en réalité à l’adresse IP du proxy. Si vous appliquez des contrôles de sécurité, d’authentification ou des mesures basées sur l’adresse IP, vous allez rencontrer un problème majeur. La valeur extraite de l’en-tête HTTP n’est pas celle que vous attendez.
L’industrie a pratiquement standardisé la manière de gérer ce problème en tirant parti des en-têtes HTTP personnalisés. L'en-tête X-Forwarded-For est probablement ce que vous recherchez vraiment : c'est là qu'un proxy place l'adresse IP réelle du client lorsqu'il transmet des requêtes. Malheureusement, ce n'est pas une norme, c'est plutôt une norme de facto « nous sommes tous plus ou moins d'accord », vous devrez donc vérifier.
Le problème est que l’adresse IP du client que vous recherchez n’est pas celle que vous pensez, et les développeurs doivent donc en tenir compte avant que les applications qui ont besoin de ces informations ne se déplacent vers un environnement de production et cessent soudainement de fonctionner.
Pourquoi c'est 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 trouver et résoudre le problème a un impact négatif sur les délais du projet et entrave la mise sur le marché, si essentielle à l'avantage concurrentiel et au succès commercial dans un monde d'applications. Reconnaître ce problème courant et le résoudre lors de la phase de développement ou de test peut garantir un déploiement plus rapide et transparent en production et sur le marché.
Plongée plus profonde :