Allez au-delà du POLB (Plain Old Load Balancing)
L’évolutivité est une capacité essentielle tant pour les entreprises que pour les applications. Du côté commercial, la mise à l’échelle des opérations est essentielle pour permettre la nouvelle économie des applications et son état quasi constant de déploiement frénétique. Du côté des applications, l'évolutivité nous permet de soutenir la croissance des populations de consommateurs et d'entreprises, en garantissant des performances et une disponibilité de premier ordre pour les deux parties.
Au cœur de l’évolutivité se trouve l’équilibrage de charge. Depuis le milieu des années 1990, l’équilibrage de charge est le moyen par lequel nous faisons évoluer les applications en répartissant les charges de travail sur des fermes de serveurs, de réseaux, d’applications et de services de plus en plus grandes.
Autrefois, l’équilibrage de la charge était une question de réseau. S'appuyant sur des techniques et des protocoles existants permettant d'étendre les réseaux, l'équilibrage de charge s'est concentré sur les aspects de la communication client-serveur qui pourraient être utilisés pour répartir les charges de travail. Le Plain Old Load Balancing (POLB) est né.
Cela a fonctionné, et bien fonctionné. Sans POLB, il est presque impossible de savoir si le Web tel que nous le connaissons aurait vu le jour. C’était – et c’est toujours – essentiel pour soutenir la population des entreprises et des consommateurs d’aujourd’hui, ainsi que pour pouvoir soutenir celle de demain.
Au début des années 2000, l'emplacement stratégique de l'équilibreur de charge en a fait la plate-forme idéale pour s'étendre à d'autres fonctionnalités améliorant l'expérience applicative. L’accélération, l’optimisation, la mise en cache et la compression des applications ont finalement été ajoutées. La sécurité, elle aussi, trouverait sa place sur cette même plateforme, sa position dans le réseau étant trop parfaite pour être ignorée. En tant que gardien des applications, sa capacité à inspecter, extraire, modifier et transformer le trafic des applications lui donne des informations uniques qui s'appliquent aussi bien à la sécurité qu'aux performances.
Au début des années 2000, nous sommes allés au-delà de POLB vers autre chose. Les équilibreurs de charge sont devenus des plates-formes de distribution d'applications, aussi compétentes pour fournir des applications sécurisées, rapides et disponibles qu'elles l'étaient simplement pour les mettre à l'échelle avec POLB.
L' ADC (contrôleur de distribution d'applications), comme on appelle ces plates-formes modernes , est capable non seulement d'offrir des fonctionnalités POLB, mais également une véritable corne d'abondance de fonctionnalités qui le rendent inestimable pour les personnes qui sont aujourd'hui chargées non seulement de déployer des applications, mais également de les livrer.
De plus en plus, ce ne sont pas les équipes réseau qui sont en charge, mais les architectes et les opérations.
Ce changement a été motivé par un certain nombre de technologies apparues au cours de la dernière décennie. De l’agilité au cloud en passant par DevOps et le mobile, les meilleures pratiques actuelles poussent certains services applicatifs hors du réseau et dans le domaine des applications.
Et tout au long du transfert de responsabilité en matière d’évolutivité du réseau vers les architectes et les opérations, l’ADC est déployé comme s’il était bloqué dans les années 1990. Considéré comme un POLB, l’essentiel de la valeur qu’il offre aux architectes et aux opérateurs en matière d’amélioration des performances et de la sécurité est laissé sur la table (ou plus précisément, sur le rack).
C’est généralement parce que les architectes et les équipes d’exploitation désormais responsables de la mise à l’échelle des applications ne connaissent pas exactement ce qu’un ADC peut faire pour eux et, plus important encore, pour leurs applications et leurs architectures. Il est temps de changer cela et d’aller au-delà de POLB.
Au-delà de POLB : Proxy L7 LB
L’objectif de POLB était simple : la disponibilité. Que ce soit par la mise en œuvre d'une architecture HA (haute disponibilité) basée sur la redondance ou par l'utilisation d'une architecture évolutive N+1, l'objectif était le même : maintenir le site Web (ou l'application) opérationnel et disponible, quoi qu'il arrive.
Aujourd’hui, l’objectif reste la disponibilité, mais couplée à l’efficacité et à l’agilité. Ces trois caractéristiques sont essentielles pour les entreprises modernes et les architectures qui prennent en charge leurs applications critiques. Pour y parvenir, nous devons toutefois aller au-delà de POLB, vers un monde de routage d’applications et de distribution de charge qui apporte ces efficacités critiques aux architectures et infrastructures d’applications. Ces capacités sont basées sur la couche 7 de la pile réseau – la couche application – et dans les architectures modernes, cela signifie HTTP.
Les proxys L7 LB sont capables non seulement de distribuer la charge en fonction des variables d'application telles que la charge de connexion, les temps de réponse et l'état de l'application, mais également de répartir (routage) en fonction des URL, des en-têtes HTTP et même des données dans les messages HTTP.
Capables d'analyser, d'extraire et d'agir sur ces différents types de données de couche applicative, les équilibreurs de charge L7 peuvent aujourd'hui participer et augmenter les applications et les architectures de microservices de diverses manières, notamment :
- Architectures de partitionnement des données (Sharding)
- Envoi d'URL complexe
- 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 des API et contrôle d'accès
Au-delà de POLB : Sécurité
Parce qu'un LB L7 est logiquement positionné en amont des applications qu'il dessert, il a une visibilité sur chaque demande – et chaque réponse. Cela signifie qu'il est capable d'effectuer une variété de contrôles et d'équilibres sur les demandes avant qu'elles ne soient autorisées à passer à l'application souhaitée. Ces contrôles et équilibres sont essentiels pour garantir que le trafic malveillant est détecté et rejeté, empêchant ainsi leurs effets néfastes d’affecter la stabilité, la disponibilité et l’intégrité des applications back-end.
Mais il ne s’agit pas seulement d’empêcher le trafic malveillant d’atteindre les serveurs, il s’agit également d’arrêter les mauvais acteurs. Cela signifie pouvoir les identifier – et pas seulement ceux qui ne disposent pas d’informations d’identification valides, mais aussi ceux qui utilisent des informations d’identification qui ne leur appartiennent pas. Le rôle du contrôle d’accès s’est accru à mesure que le nombre de violations résultant du vol d’identifiants est en hausse. Le cloud a également réintroduit l’urgence de gérer les informations d’identification à l’échelle mondiale dans toutes les applications, afin de réduire le risque potentiel lié aux comptes orphelins et de test qui donnent accès aux données d’entreprise stockées dans les applications SaaS. La fédération d’identité est devenue plus qu’une simple stratégie d’amélioration de la productivité, elle est devenue une tactique clé de la stratégie globale de sécurité de l’entreprise.
Les fonctionnalités qui peuvent être ajoutées à un LB L7 incluent à la fois celles qui analysent le comportement et l'identité des clients ainsi que le contenu réel des messages échangés entre les clients et les services back-end. Cela permet au L7 LB d'exécuter des fonctions telles que :
- Protection DDoS de couche 7 (application)
- Pare-feu d'application 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 élément essentiel du succès des applications, et donc des entreprises. Auparavant, les organisations déployaient plusieurs solutions d’accélération d’applications devant les applications pour accélérer le processus de livraison. Les ADC ont incorporé ces mêmes solutions en tant que composants optionnels (complémentaires), mais ont finalement intégré ces capacités directement dans le cadre des capacités d'équilibrage de charge de base ; un reflet de l'importance des performances par rapport à son objectif principal : la fourniture d'applications et de services.
Le L7 LB dispose donc d’une variété de fonctionnalités et de fonctions axées sur l’amélioration des performances. Certaines de ces fonctions – en particulier celles qui agissent sur les réponses des applications renvoyées au client – sont axées sur le contenu. Bon nombre d’entre elles sont des techniques de développement de base utilisées pour réduire la taille du contenu, tandis que d’autres visent à réduire le nombre d’allers-retours requis entre le client et le serveur.
Il est également important de noter que les proxys L7 ne se concentrent pas uniquement sur l'optimisation du contenu, mais sont également des éléments clés d'architectures axées sur les performances qui incluent des techniques d'équilibrage de charge de base de données ainsi que l'intégration de caches en mémoire (comme memcached) pour améliorer les performances globales des applications. Les proxys L7 bien adaptés à l'activation de ces architectures sont généralement dotés d'un langage de script de chemin de données qui offre la possibilité de personnaliser la distribution et le routage.
D’autres fonctionnalités visent à réduire la charge sur les serveurs principaux afin d’améliorer les performances, ainsi qu’à pouvoir répartir la charge en fonction des seuils de performances.
Les fonctionnalités et capacités d'optimisation d'un L7 LB incluent :
Côté client (Optimisation de la réponse) |
Côté serveur backend |
• Minification • Compression HTTP • Mise en mémoire tampon • Agrégation de scripts • Déchargement SSL |
• Multiplexage TCP • Mise en cache • Répartition de charge basée sur les performances • Auto-évolutivité |
Au-delà de POLB : Gérer
Si une infrastructure doit être davantage intégrée à l’architecture de l’application, elle doit absolument pouvoir être intégrée au pipeline CI/CD. Cela signifie soutenir les méthodologies modernes liées à DevOps et Agile ainsi que les ensembles d’outils qui permettent l’exécution de stratégies de publication et de livraison automatisées.
À cette fin, L7 LB doit fournir non seulement des API par lesquelles il peut être géré, mais également les moyens par lesquels il peut être surveillé et déployé pour garantir qu'un retour d'information et une livraison continus sont possibles pour respecter les calendriers et les budgets exigeants d'aujourd'hui.
F5 prend en charge une variété d'options de programmation pour le provisionnement, le déploiement, la gestion et la surveillance de l'infrastructure L7 LB, notamment :
Au-delà de POLB : Il est temps
Il existe de nombreuses raisons pour lesquelles la responsabilité des infrastructures d’application telles que POLB et L7 LB est transférée des équipes réseau aux équipes d’application et d’exploitation. Qu’il s’agisse de l’adoption d’Agile ou de DevOps en réponse à la demande des entreprises pour davantage d’applications avec des délais de livraison plus courts ou au besoin d’évoluer plus rapidement que jamais, aller au-delà de POLB offrira un plus grand éventail d’options de sécurité, de performances et de disponibilité nécessaires pour prendre en charge les architectures d’applications et de livraison modernes sur une plate-forme unique, gérable et programmable qui s’intègre dans le pipeline CI/CD moderne.
Il est temps d’envisager d’aller au-delà de POLB et de commencer à tirer parti de l’infrastructure qui relève de plus en plus de votre domaine.
