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 nous devons y revenir. L’équilibrage de charge ne devrait pas se limiter à une tâche tactique, comme le pensent souvent les équipes opérationnelles qui doivent désormais provisionner, configurer et déployer ces services complexes. Abordé stratégiquement, l’équilibrage de charge améliore les performances, réduit les risques et optimise l’utilisation des ressources nécessaires à la livraison des applications. Ces services sont bien plus qu’une simple « plomberie » comme on les appelle parfois, et comprendre quelques principes clés vous aidera à mieux exploiter l’équilibrage de charge pour soutenir vos 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 préciser que le round robin est le dernier algorithme dont vous devriez parler, mais vous le saviez déjà, n’est-ce pas ? Alors, passons à des algorithmes plus intelligents comme le moins de connexions et le temps de réponse le plus rapide. Ce sont évidemment de bien meilleurs choix quand vous cherchez à équilibrer performance et optimisation des ressources. Chacun prend en compte les caractéristiques de l’application (ou du moins celles des plateformes qui la délivrent) essentielles pour décider quelle instance d’application (ou conteneur, si vous préférez) doit recevoir la requête suivante. Le moins de connexions signifie qu’une instance avec moins de connexions dispose de plus de capacité et peut mieux traiter cette requête immédiatement. Vous privilégiez ainsi l’efficacité de la capacité plutôt que la performance brute.
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 le mode de mise à l’échelle des applications. L’élasticité vous permet d’augmenter et de réduire les ressources à la demande pour optimiser leur utilisation (et vos budgets). Pourquoi surprovisionner alors que vous pouvez simplement monter en charge à la demande ? De même, les architectures haute disponibilité (HA) basées sur la redondance sont quasiment dépassées. Pourquoi immobiliser des ressources inutilisées au cas où l’instance principale de l’application tomberait en panne ? C’est un gaspillage inutile de vos capitaux et budgets opérationnels ! Assez de cette veille condamnée !
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 :