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 pourquoi c’est quelque chose que nous devons revoir. Parce que l’équilibrage de charge ne doit pas être aussi tactique que le pensent de plus en plus les équipes opérationnelles qui, le plus souvent, doivent désormais provisionner, configurer et déployer ces services magiques. L'équilibrage de charge, lorsqu'il est envisagé de manière stratégique, peut améliorer les performances, réduire les risques et contribuer à une utilisation plus efficace des ressources nécessaires à la fourniture des applications. Ils sont plus intelligents que le surnom de « plomberie » qu’ils sont souvent obligés de porter et la compréhension de quelques points clés aidera les opérations à réfléchir davantage à la manière dont ils utilisent l’équilibrage de charge pour prendre en charge les 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 mentionner que le round robin est le dernier algorithme que vous devriez mentionner, mais vous le saviez déjà, n'est-ce pas ? Nous allons donc ignorer cela et aborder les algorithmes plus intelligents comme le moins de connexions et le temps de réponse le plus rapide . Il s’agit bien entendu de choix bien meilleurs lorsque vous élaborez une stratégie visant à équilibrer les performances avec une utilisation efficace des ressources. Chacun prend en compte les caractéristiques de l'application (ou au moins les caractéristiques des plates-formes fournissant les applications) qui sont essentielles pour prendre des décisions sur l'instance d'application (ou le conteneur, si vous préférez) qui doit recevoir la prochaine demande. Le moins de connexions implique que si une instance a moins de connexions, elle a plus de capacité et est donc mieux à même de répondre à cette demande ici maintenant. Il s’agit de privilégier l’efficacité des capacités 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
Depuis l’essor du cloud et des centres de données définis par logiciel, l’élasticité est devenue le moyen de faire évoluer les applications. L’élasticité nécessite une mise à l’échelle à la demande – et une réduction – comme moyen d’optimiser l’utilisation des ressources (et des budgets). Pourquoi surprovisionner quand on peut simplement augmenter la capacité à la demande ? De même, les architectures à haute disponibilité (HA) dépendant des principes de redondance sont devenues presque dépassées. Pourquoi exiger des ressources inactives en veille dans le cas (peu probable) où l'instance d'application principale échoue ? C’est un gaspillage de budgets d’investissement et de fonctionnement ! Dehors, dehors, maudit, en attente !
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.
De tous les problèmes qui surviennent lorsqu’une application passe du développement à la production, celui-ci est probablement le plus courant et le plus facilement évitable. Vous voyez, la plupart des services d’équilibrage de charge (tous les bons, en tout cas) sont des proxys . Cela signifie que le client se connecte au proxy et que le proxy se connecte à votre application. Tous deux utilisent TCP pour transporter ce HTTP, ce qui signifie qu'ils doivent obéir aux lois du réseau. L'IP source (ce que vous pensez être l'IP du client) est en fait l'adresse IP du proxy. Si vous effectuez des opérations de sécurité, d'authentification ou de mesure basées sur l'adresse IP, cela pose un problème sérieux. La valeur que vous extrayez de l'en-tête HTTP n'est pas celle que vous souhaitez.
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 :