Comment la SNCF a bâti son propre CDN avec HAProxy

La situation

Il y a plus de dix ans, lorsqu'il fonctionnait initialement sous son ancien nom de Oui.sncf, le site utilisait un système à trois niveaux avec un serveur Web Apache, un serveur d'applications Weblogic et des bases de données Oracle. Face au manque d'observabilité sur cette infrastructure, l'équipe a utilisé la version communautaire de HAProxy pour les aider à surveiller les statistiques d'erreurs, avant de passer au logiciel HAProxy Enterprise pris en charge devant leurs applications Web plusieurs années plus tard.

Puis, en 2014, face à la hausse des coûts de leur fournisseur de réseau de diffusion de contenu standard Akamai, les ingénieurs Antonin Mellier et Nicolas Besin ont commencé à reconsidérer leurs options. Leurs besoins croissants en bande passante rendaient les prix prohibitifs, et ils ont réalisé que bon nombre des fonctionnalités optionnelles pour lesquelles ils payaient, comme l'analyse des journaux en temps réel et les certificats SSL, pouvaient être implémentées gratuitement dans une solution CDN personnalisée.

L'équipe a donc décidé de construire son propre réseau de diffusion de contenu, avec HAProxy Enterprise en son cœur.

Les objectifs

L’objectif principal du passage de Nicolas et Antonin à un CDN personnalisé était de conserver les avantages en matière de latence d’un système de serveurs de cache dans leur réseau, tout en éliminant les tiers de sa structure. En répondant aux demandes des utilisateurs finaux sur le lieu d'origine, les réseaux de diffusion de contenu minimisent les délais de chargement du contenu des pages Web, tout en offrant également une protection contre les pics de trafic élevés et les attaques DDoS. ompte tenu des coûts réduits de bande passante, il est également nettement moins cher que l’hébergement traditionnel.

L'équipe avait également besoin d'un produit DNS non traditionnel pour son CDN. Ainsi, après avoir finalisé le choix de leurs hôtes CDN bare metal, Nicolas et Antonin ont opté pour GeoDNS, leur offrant la possibilité d'attribuer des IP en fonction de la localisation des clients en plus d'une lecture aléatoire pondérée pour différentes charges sur chacun des serveurs Edge. Ils ont également ajouté un fournisseur DNS distinct et géré dans Dyn afin d'accroître leur présence mondiale. Cette solution multi-DNS leur a fourni un basculement en cas d'urgence et la possibilité de répartir le trafic entre les deux solutions.

La solution

L'infrastructure étant désormais en place, SNCF Connect a implémenté ses équilibreurs de charge HAProxy Enterprise à la périphérie de son CDN, avec Varnish comme solution de mise en cache. Le fait de disposer de l'instance HAProxy Enterprise à la périphérie du CDN a donné à Nicolas et Antonin une vue standardisée de leurs entrées et sorties au fur et à mesure du routage des données, ce qui a facilité la détermination des taux d'erreur et de cache, ainsi que la localisation de la source des problèmes potentiels depuis soit à l'intérieur ou à l'extérieur de leur réseau CDN.

Afin de gérer leurs fichiers de configuration, l'équipe a développé sa propre application pour faire office de base de données de gestion de configuration. Pour chaque site ou application utilisant le réseau, la CMDB a stocké des paramètres pour des fonctionnalités telles que les règles de mise en cache, les adresses IP et les ports à utiliser, ainsi que l'activation HTTP/2 ou IPv6. Ces fichiers devaient être générés en Ruby puis déployés par Ansible.

Le backend du CDN de SNCF Connect a ensuite été acheminé via leurs instances HAProxy Enterprise vers l'un de leurs deux centres de données, chacun traité par les équilibreurs de charge comme un serveur de destination. Pour chaque application, un pourcentage prédéterminé de trafic est acheminé vers l'une des deux destinations, les cookies étant utilisés pour la persistance de la session lorsque l'application n'est pas apatride. Les listes de contrôle d'accès sont également utilisées dans certains cas, notamment lors de la récupération de médias à partir d'un serveur dédié ou de parties du site Web hébergées dans le cloud public sur AWS.

Les résultats

L'équipe de SNCF Connect profite également de l'observabilité inégalée de ses équilibreurs de charge HAProxy Enterprise. En utilisant Prometheus pour collecter des métriques sur leurs différents composants, ils sont à leur tour en mesure d'afficher et d'analyser les données dans leurs visualiseurs Promviz et Grafana. Une autre innovation HAProxy qu'ils utilisent sont les tables bâton, qui leur permettent de déterminer la présence d'un comportement IP anormal sur leur réseau.

Le résultat final du passage de Nicolas et Antonin à un CDN auto-exploité s’est traduit par une baisse des deux tiers de leurs coûts d’exploitation par rapport à leur précédent modèle payant. Et ce, même après une augmentation de 80 % de la bande passante au cours des années qui ont suivi sa mise en œuvre. Le cache de contenu signifie également que seulement 10 % des requêtes doivent atteindre leurs serveurs d'origine, ce qui signifie une meilleure expérience de site Web pour leurs clients et moins de pression sur le réseau interne.

Ce que HAProxy Enterprise vous apporte

Que vous ayez besoin d'une observabilité supérieure, d'une protection contre les menaces basées sur le Web ou simplement d'un équilibreur de charge pouvant s'intégrer à une plate-forme personnalisée, HAProxy Enterprise a beaucoup à offrir. Pendant que l'équipe de SNCF Connect construisait son propre CDN, vous pouvez proposer vos propres applications à grande échelle avec HAProxy Edge, le CDN basé sur la technologie HAProxy.

Pour en savoir plus sur les cas d'utilisation de HAProxy, consultez la page Exemples de réussite.