Service Mesh sans configuration chez Netflix
Netflix a récemment collaboré avec la communauté Envoy et Kinvolk pour mettre en place une nouvelle fonctionnalité pour Envoy, le proxy open-source développé par Lyft. Cette nouvelle fonctionnalité, appelée On-Demand Cluster Discovery, a permis à Netflix de mettre en place un service mesh sans configuration.
L’IPC avec Eureka
L’Inter-Process Communications (IPC) est crucial pour Netflix depuis que l’entreprise a déplacé toute son infrastructure vers le cloud (AWS) en 2010. Netflix a développé Eureka pour la découverte des services et Ribbon pour les communications IPC afin de gérer facilement l’IPC. Le principal objectif d’Eureka est de masquer le nom des services de destination avec des adresses IP virtuelles (VIP) et, si la communication doit être sécurisée, avec des adresses IP virtuelles sécurisées (SVIP). Les clients IPC sont instanciés avec la VIP ou la SVIP cible, et le client Eureka se charge de la traduction de la VIP ou de la SVIP et du port en un ensemble d’adresses IP, en récupérant les informations depuis le serveur Eureka. Cependant, cela crée un point de défaillance unique.
Migrer vers un service mesh
Cette architecture a bien fonctionné pendant des décennies, mais Netflix avait besoin de migrer vers un service mesh pour trois raisons principales :
- Différentes technologies IPC : REST, graphQL et gRPC.
- Passer d’une architecture basée sur Java à une architecture polyglotte.
- Ajouter des fonctionnalités aux clients IPC.
La décision a été prise d’utiliser Envoy pour centraliser les fonctionnalités IPC dans une seule implémentation et rendre les clients par langage aussi simples que possible. De plus, Envoy prend en charge l’abstraction de découverte, ce qui permet aux clients IPC de continuer à l’utiliser. Cependant, spécifier les clusters dans la configuration du proxy Envoy est devenu problématique pour l’architecture de Netflix, car un service peut potentiellement communiquer avec une douzaine de clusters qui changent régulièrement.
La solution ODCDS
Netflix a évalué différentes approches pour résoudre ce problème, mais aucune n’était idéale. La solution trouvée a été d’obtenir les informations des clusters à la demande au moment de l’exécution. Cette solution nécessitait une nouvelle fonctionnalité pour Envoy. La collaboration entre la communauté Envoy, Netflix et Kinvolk a abouti à la création de la fonctionnalité On-Demand Cluster Discovery (ODCDS). Les proxies peuvent maintenant rechercher les informations des clusters lors de la première connexion. Le nouveau flux est le suivant :
- La demande du client arrive dans Envoy.
- Le cluster cible est extrait en fonction de l’hôte. Si le cluster est déjà connu, passer à l’étape 7.
- Si le cluster n’existe pas, la demande est mise en pause.
- Faire une demande au service de découverte de cluster (CDS) du plan de contrôle. Le plan de contrôle génère une réponse CDS personnalisée en fonction de la configuration du service et des informations d’enregistrement Eureka.
- Envoy récupère le cluster (CDS), ce qui déclenche une récupération des points de terminaison via le service de découverte des points de terminaison (EDS). Les points de terminaison pour le cluster sont renvoyés en fonction des informations d’état Eureka pour cette VIP ou SVIP.
- La demande du client est débloquée.
- Envoy traite la demande comme d’habitude : il choisit un point de terminaison à l’aide d’un algorithme de répartition de charge et envoie la demande.
Ce flux est effectué en millisecondes, mais il existe des cas d’utilisation où les services nécessitent une latence réduite. Les solutions actuelles consistent à préconfigurer les clusters avec lesquels les services communiquent ou à effectuer des connexions préalables avant la première demande. Netflix et la communauté Envoy continuent de travailler ensemble pour améliorer Envoy.
Source : www.infoq.com
