Sozu
Clever Cloud déploie, héberge et maintient en condition opérationnelle les applications et données de ses clients. Le cycle de vie de leurs applications est beaucoup plus facile à gérer, sans contrepartie sur la résilience et la sécurité. Cela leur permet de se focaliser sur leur code métier en ne se souciant plus de la gestion de la maintenance de leur infrastructure, et donc d'être plus rapides et agiles dans leur marché.
Présentation
Sōzu est un reverse proxy léger, rapide, sécurisé et toujours opérationnel.
A quoi sert-elle et que peut-on faire avec ?
Sōzu est né d’un besoin chez Clever Cloud de gérer des changements de configuration fréquents dans un reverse proxy. Étant donné que la plateforme suit les principes de l’infrastructure immuable, les applications se déplacent fréquemment d’une machine virtuelle à une autre, et la configuration de routage du reverse proxy doit être mise à jour fréquemment.
Les solutions classiques telles que HAProxy ont été conçues pour redémarrer leur processus à chaque changement de configuration. Cela pose quelques problèmes : le redémarrage du processus d’un proxy entraîne une augmentation temporaire de l’utilisation du processeur et de la RAM (l’utilisation des ressources est dupliquée) gestion des connexions persistantes :
- soit l’ancien processus est arrêté et les connexions qu’il traitait encore sont perdues
- soit l’ancien processus est conservé jusqu’à ce que les connexions soient terminées, mais il y a un risque d’avoir beaucoup d’anciens processus lorsque les machines virtuelles sont souvent redémarrées
- Modifications de la configuration en temps d’exécution
- Modifications fines et précises
- Utilisation bornée des ressources
Changer la configuration du proxy devrait être une tâche courante effectuée en temps d’exécution. Nous ne devrions pas avoir besoin de redémarrer un processus complet pour gérer cela.
Cela signifie que la gestion de la configuration doit prendre en charge les modifications dynamiques, elle doit donc être reflétée dans les outils que nous utilisons pour piloter sōzu, et nous devons fournir de bonnes bibliothèques pour gérer ce cas d’utilisation.
- Au lieu de recharger l’intégralité de l’état (comme le rechargement à chaud d’un fichier de configuration), nous pouvons effectuer de petites modifications, telles que supprimer ce serveur backend ou ajouter ce certificat. Cela nous donne plus d’informations sur le système en cours d’exécution, comme savoir quand nous pouvons réellement supprimer un serveur backend (une fois qu’aucune autre connexion ne l’utilise).
Nous devrions pouvoir fixer les limites d’utilisation des ressources (CPU, RAM, connexions, etc.) directement dans la configuration de sōzu. Au lieu d’augmenter indéfiniment l’utilisation des ressources sous charge, nous refuserons immédiatement le nouveau trafic. Cela permet d’exercer une contre pression et permet aux clients de gérer intelligemment leurs nouvelles tentatives de connexion, tout en maintenant une latence et un comportement prévisibles pour les connexions existantes.
Une fois que vous avez démarré sōzu, il est capable de traiter le trafic indéfiniment. En cas de problèmes entraînant une défaillance, cela ne devrait pas faire tomber l’ensemble du proxy, et il devrait être capable de reprendre automatiquement la gestion du trafic.
Effet secondaire de cette approche : une mise à niveau binaire ne devrait pas entraîner de perte de trafic. C’est le principal moteur de l’architecture multiprocesseur actuelle.
Les besoins des utilisateurs évoluent, et au gré des capacités grandissantes, le protocole HTTP (Hypertext Transfer Protocol) a lui aussi subit quelques modifications. D’une simple version dite “plain text”, il a muté progressivement vers un protocole binaire, pouvant gérer le multiplexage des connexions réseau. La raison à cela est bien évidemment l’optimisation de l’usage du réseau et la rationalisation des ressources, tant côté client avec une expérience utilisateur améliorée, tant côté serveur avec un nombre de connexion à supporter drastiquement réduit à l’échelle. Sozu doit également supporter ces différentes versions de protocole, avec la particularité d’être en mesure de passer d’une version HTTP1 à une version supérieure, et inversement.
Étant donné que Sōzu est susceptible de voir le trafic de nombreuses connexions clientes, ainsi que les clés privées de leurs certificats TLS, il doit être suffisamment sécurisé pour protéger sa mémoire.
Dans cette optique, nous avons choisi Rust pour ses fonctionnalités de sécurité de la mémoire.
Sōzu devrait avoir un comportement très prévisible en termes d’utilisation de la mémoire et de latence. Toute irrégularité doit être observée et corrigée.
Cette approche a guidé diverses décisions :
- Choix du langage Rust pour éviter les pauses de collecte des déchets
- Pré allocations et pooling pour éviter certaines allocations dans le chemin critique
- Une architecture mono thread et partagée entre les processus pour éviter la synchronisation entre les cœurs
Bénéfices
- Configurable à chaud : Sozu peut recevoir des changements de configuration au moment de l’exécution par le biais de sockets unix sécurisés sans avoir à être rechargé
- Mises à jour sans redémarrage : Sozu est toujours en marche, ce qui signifie qu’il se met à jour tout en continuant à traiter les requêtes.
- Gestion du SSL : Sozu gère le SSL grâce à Rustls, de sorte que vos serveurs backend peuvent se concentrer sur ce qu’ils font le mieux.
- Protection du réseau : Sozu protège les backends en les plaçant derrière le reverse proxy, limitant ainsi l’accès direct au réseau. Sozu utilise Rust, un langage conçu pour la sécurité de la mémoire. Et même si un worker subit un exploit, les autres workers de Sozu sont isolés.
- Optimisation des performances : Sozu peut exposer votre service web sur Internet avec le protocole HTTP/2 même si votre backend ne supporte que HTTP/1.*. Vos applications Web bénéficient du multiplexage de connexion en utilisant des flux HTTP/2 transparents.
Cas d’usage et valeur ajoutée
Bien que Sōzu soit capable de gérer des modifications de configuration précises, il n’a pas vocation à se connecter à tous les outils de gestion de configuration existants (etcd, Kubernetes, etc.). Au lieu de cela, il est pertinent de fournir des moyens d’écrire des outils connectant Sōzu et le reste du système. L’objectif est donc de garder Sōzu le plus simple possible dans la philosophie Unix et de KISS (Keep It Simple Stupid), afin d’avoir des performances optimales, tout en incitant à créer de l’outillage, afin de faire s’interfacer Sōzu avec des systèmes plus complexes.
De plus, le code qui gère les modifications de configuration devrait être réutilisable en dehors de Sōzu. Il est actuellement assez facile d’écrire un outil qui charge un état de configuration à partir d’un fichier, obtient l’état actuel de sōzu, génère une différence, puis envoie des messages de configuration pour la différence à Sōzu. Écrire des outils de configuration est suffisamment simple afin que le protocole de configuration puisse être accessible depuis n’importe quel langage.
Informations complémentaires
Spécificités organisationnelles
- Ressources mobilisables par le consortium ?
Un ingénieur Clever Cloud dédié pour assurer le support, ressources de test en cloud public Clever Cloud
- Temps hommes ?
2 mois homme d’assistance par Clever Cloud sur 12 mois
Spécificités techniques
- Normes techniques : langage Rust
- Documentation : https://github.com/sozu-proxy/sozu/blob/main/doc/README.md
- Le code source est disponible sur Github: https://github.com/sozu-proxy/sozu Les conditions de contribution y sont spécifiées
- License AGPL3 : en cas de projet commercial basé sur Sozu, il est demandé de fournir les contributions au projet initial ou d’établir un accord spécifique avec Clever Cloud .