Allez au-delà du POLB (équilibrage de charge classique)

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

L’évolutivité est une capacité essentielle tant pour les entreprises que pour les applications. Côté entreprise, la mise à l’échelle des opérations est indispensable pour accompagner la nouvelle économie des applications et son rythme de déploiement effréné et quasi permanent. Côté applications, l’évolutivité permet de répondre à la croissance du nombre d’utilisateurs, qu’il s’agisse de particuliers ou d’entreprises, tout en leur garantissant des performances et une disponibilité optimales.

L’équilibrage de charge est au cœur de la capacité de mise à l’échelle. Depuis le milieu des années 1990, il permet de faire évoluer les applications en répartissant les charges de travail sur des parcs toujours plus vastes de serveurs, de réseaux, d’applications et de services.

À l’époque, l’équilibrage de charge concernait avant tout le réseau. S’appuyant sur les techniques et protocoles existants permettant de faire évoluer les réseaux horizontalement, il se concentrait sur les aspects de la communication client-serveur susceptibles d’être utilisés pour répartir les charges de travail. C’est ainsi qu’est né le « Plain Old Load Balancing » (POLB), ou équilibrage de charge traditionnel.

Cela a fonctionné, et même très bien. Sans le POLB, il est presque impossible de savoir si le Web tel que nous le connaissons aurait pu voir le jour. Il a joué — et joue encore — un rôle essentiel pour répondre aux besoins actuels des entreprises et des consommateurs, tout en permettant de répondre à ceux de demain.

Au début des années 2000, l’emplacement stratégique de l’équilibreur de charge en a fait la plateforme idéale pour intégrer d’autres fonctionnalités destinées à améliorer l’expérience applicative. Des fonctions d’accélération, d’optimisation, de mise en cache et de compression des applications ont ainsi fini par être ajoutées. La sécurité a elle aussi trouvé sa place sur cette même plateforme, dont la position au sein du réseau était trop idéale pour être ignorée. Véritable gardien des applications, l’équilibreur de charge peut inspecter, extraire, modifier et transformer le trafic applicatif, ce qui lui confère une visibilité unique, aussi précieuse pour la sécurité que pour les performances.

Au début des années 2000, nous avons dépassé le cadre du POLB pour évoluer vers autre chose. Les répartiteurs de charge sont devenus des plateformes de mise à disposition d’applications, aussi efficaces pour fournir des applications sécurisées, rapides et disponibles qu’ils l’étaient auparavant pour assurer leur mise à l’échelle avec le POLB.

Les ADC (contrôleurs de mise à disposition d’applications), comme on appelle ces plateformes modernes, offrent non seulement des fonctionnalités POLB, mais aussi une véritable profusion de fonctions qui les rendent indispensables aux personnes chargées aujourd’hui non seulement de déployer les applications, mais aussi de les mettre à disposition.

De plus en plus, cette responsabilité n’incombe plus aux équipes réseau, mais aux architectes et aux équipes d’exploitation.

Cette évolution a été favorisée par plusieurs technologies apparues au cours de la dernière décennie. Des méthodes agiles au cloud, en passant par le DevOps et le mobile, les bonnes pratiques actuelles conduisent à transférer certains services applicatifs du réseau vers le domaine des applications.

Et tandis que la responsabilité de l’évolutivité passe du réseau aux architectes et aux équipes d’exploitation, l’ADC continue d’être déployé comme s’il était resté bloqué dans les années 1990. Considéré comme un simple POLB, il voit l’essentiel de la valeur qu’il peut apporter aux architectes et aux équipes d’exploitation en matière d’amélioration des performances et de la sécurité rester inexploité (ou, plus exactement, dormir dans la baie).

Cela s’explique généralement par le fait que les architectes et les équipes d’exploitation désormais chargés de la mise à l’échelle des applications ne savent pas précisément ce qu’un ADC peut leur apporter et, surtout, ce qu’il peut apporter à leurs applications et à leurs architectures. Il est temps d’y remédier et d’aller au-delà du POLB.

Au-delà de POLB : proxy d’équilibrage de charge L7

L’objectif de POLB était simple : assurer la disponibilité. Qu’il s’agisse de mettre en œuvre une architecture HA (haute disponibilité) fondée sur la redondance ou d’utiliser une architecture évolutive N+1, l’objectif restait le même : maintenir le site web (ou l’application) opérationnel et disponible en toutes circonstances.

Aujourd’hui, l’objectif reste la disponibilité, mais celle-ci va de pair avec l’efficacité et l’agilité. Ces trois qualités sont des caractéristiques essentielles des entreprises modernes et des architectures qui prennent en charge leurs applications critiques. Pour y parvenir, nous devons toutefois aller au-delà du POLB et entrer dans un univers de routage des applications et de répartition de charge qui apporte ces gains d’efficacité indispensables tant aux architectures applicatives qu’à l’infrastructure. Ces capacités reposent sur la couche 7 de la pile réseau — la couche applicative —, ce qui, dans les architectures modernes, signifie HTTP.

Les proxys d’équilibrage de charge de couche 7 sont capables non seulement de répartir la charge en fonction de variables applicatives telles que le nombre de connexions, les temps de réponse et l’état de l’application, mais aussi d’acheminer le trafic en fonction des URL, des en-têtes HTTP et même des données contenues dans les messages HTTP.

Capables d’analyser, d’extraire et d’exploiter ces différents types de données de la couche applicative, les répartiteurs de charge L7 peuvent aujourd’hui contribuer aux applications et aux architectures de microservices et les enrichir de diverses manières, notamment :

• Architectures de partitionnement des données (sharding)
• Routage complexe des URL
• Manipuler les en-têtes de réponse
• Routage dynamique basé sur les données du backend
• Mise à l’échelle par décomposition fonctionnelle
• Mesure de l’utilisation des API et contrôle d’accès

Au-delà de POLB : sécurité

Étant donné qu’un équilibreur de charge L7 est logiquement positionné en amont des applications qu’il dessert, il bénéficie d’une visibilité sur chaque requête, ainsi que sur chaque réponse. Il peut donc effectuer divers contrôles sur les requêtes avant qu’elles ne soient autorisées à atteindre l’application souhaitée. Ces contrôles sont essentiels pour garantir que le trafic malveillant est détecté et rejeté, empêchant ainsi ses effets néfastes de compromettre la stabilité, la disponibilité et l’intégrité des applications backend.

Mais il ne s’agit pas seulement d’empêcher le trafic malveillant d’atteindre les serveurs, il faut aussi bloquer les acteurs malveillants. Cela implique de pouvoir les identifier — non seulement ceux qui ne disposent pas d’identifiants valides, mais aussi ceux qui utilisent des identifiants qui ne leur appartiennent pas. Le contrôle des accès joue un rôle de plus en plus important à mesure qu’augmente le nombre de violations de données résultant du vol d’identifiants. Le cloud a lui aussi rendu urgente la gestion globale des identifiants dans l’ensemble des applications, afin de réduire les risques potentiels liés aux comptes orphelins et aux comptes de test donnant accès aux données de l’entreprise stockées dans des applications SaaS. La fédération des identités n’est plus seulement une stratégie visant à améliorer la productivité : elle est devenue une tactique essentielle de la stratégie globale de sécurité de l’entreprise.

Les fonctionnalités pouvant être ajoutées à un équilibreur de charge de couche 7 comprennent aussi bien l’analyse du comportement et de l’identité des clients que celle du contenu réel des messages échangés entre les clients et les services backend. L’équilibreur de charge de couche 7 peut ainsi assurer notamment les fonctions suivantes :

• Protection contre les attaques DDoS de couche 7 (applicative)
• Pare-feu pour applications web
• Top 10 de l’OWASP
• Contrôle d’accès aux applications
• Identité fédérée

Au-delà de POLB : optimisation

Les performances sont un facteur essentiel de la réussite des applications et, par conséquent, de celle des entreprises. Autrefois, les organisations déployaient plusieurs solutions d’accélération en amont des applications afin d’en accélérer la diffusion. Les contrôleurs de mise à disposition d’applications (ADC) ont d’abord proposé ces mêmes solutions sous forme de composants facultatifs (modules complémentaires), avant d’intégrer directement ces fonctionnalités aux fonctions principales d’équilibrage de charge, témoignant ainsi de l’importance des performances dans leur mission première : assurer la mise à disposition des applications et des services.

Ainsi, l’équilibreur de charge de couche 7 dispose de diverses fonctionnalités visant à améliorer les performances. Certaines d’entre elles — notamment celles qui agissent sur les réponses de l’application renvoyées au client — portent sur le contenu. Beaucoup reposent sur des techniques de développement fondamentales permettant de réduire la taille du contenu, tandis que d’autres visent à diminuer le nombre d’allers-retours nécessaires entre le client et le serveur.

Il est également important de noter que les proxys L7 ne se limitent pas à l’optimisation du contenu : ils jouent aussi un rôle clé dans la mise en œuvre d’architectures axées sur les performances, qui intègrent des techniques d’équilibrage de charge des bases de données ainsi que des caches en mémoire (comme memcached) afin d’améliorer les performances globales des applications. Les proxys L7 les mieux adaptés à la mise en œuvre de ces architectures disposent généralement d’un langage de script du chemin de données permettant de personnaliser la répartition et le routage.

D’autres fonctionnalités visent à réduire la charge sur les serveurs back-end afin d’améliorer les performances, ainsi qu’à répartir la charge en fonction de seuils de performance.

Les fonctionnalités et capacités d’optimisation d’un répartiteur de charge de couche 7 comprennent :

Au-delà de POLB : gérer

Pour qu’une infrastructure soit davantage intégrée à l’architecture applicative, elle doit impérativement pouvoir être intégrée au pipeline CI/CD. Cela implique de prendre en charge les méthodologies modernes liées au DevOps et à l’Agile, ainsi que les ensembles d’outils permettant de mettre en œuvre des stratégies automatisées de mise en production et de livraison.

À cette fin, l’équilibreur de charge L7 doit fournir non seulement des API permettant de le gérer, mais aussi les moyens de le surveiller et de le déployer afin de garantir la possibilité d’assurer un retour d’information et une livraison continus pour respecter les contraintes actuelles en matière de délais et de budgets.

F5 prend en charge diverses options programmatiques pour le provisionnement, le déploiement, la gestion et la supervision de l’infrastructure d’équilibrage de charge de couche 7, notamment :

• API REST et SOAP
• Plug-ins pour Chef, Puppet, Cisco, VMware, Electric Cloud, New Relic, Nagios, Ansible, Urban {code}, et bien plus encore
• Modèles intelligents

Au-delà de POLB : le moment est venu

Diverses raisons expliquent pourquoi la responsabilité des infrastructures applicatives telles que le POLB et l’équilibrage de charge de couche 7 est transférée des équipes réseau aux équipes chargées des applications et des opérations. Qu’il s’agisse d’adopter les méthodes agiles ou le DevOps pour répondre à la demande des entreprises, qui souhaitent davantage d’applications avec des délais de livraison plus courts, ou de pouvoir évoluer plus rapidement que jamais, aller au-delà du POLB offrira un éventail plus large d’options en matière de sécurité, de performances et de disponibilité, indispensables à la prise en charge des architectures modernes d’applications et de livraison sur une plateforme unique, facile à gérer et programmable, qui s’intègre au pipeline CI/CD moderne.

Il est temps d’envisager d’aller au-delà du POLB et de commencer à tirer parti de l’infrastructure qui relève de plus en plus de votre domaine de responsabilité.

À 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