Evoluer vers une plateforme HAProxy de Load-Balancer-as-a-Service avec Booking.com

La situation

Comme tous les piliers de l’ère numérique, l’organisation du réseau de Booking.com a longtemps souffert d’une configuration désuète héritée de ses débuts en ligne. Lorsque Marcin Deranek, ingénieur en fiabilité du site, a pris la relève en 2008, l'infrastructure d'équilibrage de charge était constituée d'une paire de serveurs Linux exécutant un serveur virtuel IP fonctionnant dans une configuration active/veille pour le basculement. Ils rencontraient cependant des problèmes de mise en cache ARP, qui empêchaient la configuration du basculement, ainsi que d'autres problèmes de personnalisation généralement associés à l'équilibrage de charge à ce niveau.

Dès le début, cela a encouragé Marcin à essayer une solution d’équilibrage de charge de couche 7 basée sur F5. Leur système initial consistait en deux gestionnaires de trafic local F5 BIG-IP, qui ouvraient des options en termes de modification des charges utiles ou d'injection ou de suppression d'en-têtes qu'ils n'avaient pas pu adapter auparavant. Cependant, les équilibreurs de charge F5, qui étaient des serveurs physiques non malléables à l'automatisation de la configuration, nécessitaient des étapes manuelles pour mettre à niveau et personnaliser les paramètres, ce qui commençait à avoir des conséquences néfastes même après avoir développé une série de scripts pour le travail et implémenté Puppet pour faciliter le travail. la charge. Ce système n’était également évolutif que verticalement, et à mesure que la clientèle de Booking.com grandissait, ils se retrouvaient avec une arborescence désordonnée de différentes générations de matériel F5. C’est ainsi qu’a commencé le voyage vers une approche logicielle de l’équilibrage de charge.

Les objectifs

Les objectifs initiaux de l'équipe Booking.com étaient d'éliminer cette redondance associée au matériel de cyclisme, ainsi que de dépasser les limites du nombre de séances associées à leur configuration F5. Cela les a amenés à mettre en œuvre un remplacement des serveurs F5 BIG-IP par un système interne d'équilibrage de charge en tant que service utilisant des équilibreurs de charge logiciels HAProxy Enterprise et un routage multi-chemin à coût égal. Cette stratégie a permis le routage des paquets réseau sur plusieurs chemins de coût égal, grâce à un niveau initial de commutateurs de couche de structure et de commutateurs haut de rack sur la couche 3 qui transmettaient les paquets à un niveau d'équilibreurs de charge HAProxy Enterprise qui distribuaient finalement le trafic vers serveurs d'applications : une stratégie qui impliquait à son tour un équilibrage de charge par flux, garantissant qu'un seul flux de paquets restait sur le même chemin tout au long de sa durée de vie en raison des algorithmes de hachage arrondis au premier niveau, qui les envoyaient ensuite à l'équilibreur de charge HAProxy. paires en dessous.

L'équipe souhaitait également s'assurer qu'elle acheminait le trafic réseau vers les bonnes destinations en fonction des mesures de localisation et de latence. Cela signifie que le nouveau système logiciel d'équilibrage de charge HAProxy Enterprise a été mis en œuvre en combinaison avec Anycast, un processus dans lequel le trafic de l'expéditeur est acheminé en fonction d'une topologie de réseau idéale. La théorie Anycast signifiait attribuer des chemins en fonction du coût, de la distance, des sauts ou de la latence mesurée les plus bas, avec une préférence pour la localité.

Afin de gérer ce nouveau système de manière à pouvoir gérer les milliards de demandes que Booking.com commençait à recevoir chaque jour, Marcin a également dirigé la création de sa propre API, qu'ils ont à juste titre intitulée « Balancer ».

La solution

Ce logiciel personnalisé serait utilisé pour gérer l’ensemble de leur plateforme d’équilibrage de charge. Basée sur différents clusters pour différents environnements, l'API Balancer se situe au centre du réseau de distribution et stocke sa configuration sous forme d'objets avec des attributs, ainsi que les relations entre eux. Cela signifiait qu'une logique métier contextuelle pouvait utiliser l'API pour attribuer automatiquement des serveurs aux pools back-end et utiliser un routage intelligent du trafic pour relayer les paquets en fonction d'exigences définies de répartition uniforme du trafic et de rigidité des zones de session.

De plus, l'API a automatisé le provisionnement des serveurs par attributs créés pour chaque pool existant. Et chaque instance de HAProxy Enterprise pourrait également être configurée plus précisément avec un agent d'équilibrage, permettant un dialogue entre l'API, le commutateur haut de rack et les démons de routage BIRD configurés par un vérificateur de santé Anycast.

Les administrateurs système ont également profité de l'observabilité inégalée de HAProxy en attachant des démons à l'équilibreur qui, à son tour, traitait les données capturées. Le démon transmet périodiquement ces statistiques à Graphite via le socket stats, les journaux d'accès et d'erreurs étant capturés par Rsyslog et transmis à un cluster Elasticsearch, ce qui signifie une richesse finale d'informations à la disposition de leur interface utilisateur personnalisée.

Les résultats

Les avantages de cette approche logicielle de l'équilibrage de charge se sont traduits par une visibilité sans précédent pour l'équipe via l'interface utilisateur de leur API Balancer. Ils ont créé une série d'affichages graphiques qui analysent les données fournies par HAProxy Enterprise afin que les travailleurs peut-être moins familiers avec l'équilibrage de charge puissent utiliser le service, visualisant les métriques ainsi que la manière dont chaque objet du système est connecté.

La flexibilité d'utilisation de HAProxy Enterprise dans le cadre d'un réseau Load-Balancer-as-a-Service signifiait que l'équipe pouvait évoluer, visualiser et acheminer comme jamais auparavant. Le routage intelligent offre également une protection contre plusieurs scénarios de panne, qui peuvent tous être résolus au débit de ligne au lieu de retirer les câbles et les vis de leurs anciens systèmes IPVS F5 ou Linux.

Booking.com a également capitalisé sur le dialogue entre HAProxy Technologies et sa communauté à mesure que chaque itération de HAProxy Enterprise devient disponible, communiquant son désir de TCP Fast Open en face arrière et son évolution vers HTTP/3.

Ce que HAProxy entreprise vous apporte

Bien que Booking.com ait mis en œuvre une solution personnalisée basée sur HAProxy Enterprise, vous pouvez bénéficier des mêmes avantages avec le plan de contrôle HAProxy Fusion. Le Fusion Control Plane est livré avec une API complète, la prise en charge du routage intelligent basé sur l'état du serveur, une interface utilisateur riche, et bien plus encore. Contactez-nous pour en savoir plus.

Interested to learn more about HAProxy use cases? Explore our Success Stories page.
Pour en savoir plus sur les cas d'utilisation de HAProxy, consultez la page Exemples de réussite.