VT2017 Netflix Zuul

From air
Jump to: navigation, search

Présentation

Zuul.png

  • Technologie : Netflix Zuul
  • Auteur : Hugo Amodru-Favin
  • Enseignants : Didier Donsez, Georges-Pierre Bonneau
  • Présentation : Transparents
  • Date : 15/09/17

Résumé Français

Zuul est un Gateway accessible en open source développé par Netflix. Un Gateway sert à faire le lien entre Internet et les services dans le cloud. Il est nécessaire au fonctionnement de toute application fonctionnant sur un modèle similaire. Faisant face à une clientèle toujours plus nombreuse et à statut mondial, Netflix ne pouvait plus se satisfaire de Gateway déjà existants comme AWS ou Mashery. En 2012, Zuul était mis en place par Netflix. Ce gateway avait été développé pour permettre à Netflix d'avoir notamment une vue interne de leur système, facilitant la gestion de pannes. Zuul est essentiellement un système de filtres, chacun composé d'un type, d'un ordre hiérarchique, d'un critère d'éxecution et d'une action correspondante. Rapide et facile à écrire, un filtre peut être implémenté moins d'une minute après détection de panne grâce à une compilation dynamique.

Mots clés : Micro Service, Gateway, Filtre, Gestion des Pannes, Réactivité, Adaptabilité, Routage

Résumé Anglais

Zuul is an open source Gateway developed by Netflix. A Gzteway is needed to link Internet to services in the cloud. Without it, applications similar to Netflix couldn't work. Facing a huge and growing market and a world status, Netflix couldn't be satisfied with already existing Gateway such as AWS or Mashery. In 2012, Zuul was released by Netflix. This Gateway has been developed to have an insight view of the system, making the management of network failures easier. Zuul is mainly a series of filters composed of a type, an order of priority, a criteria, and an action. Fast and easy to write, a filter can be implemented in less than one minute thanks to a dynamic compilation.

Keywords : Micro Service, Gateway, Filter, Troubleshooting, Adaptability, Reactivity, Routing

Synthèse

Contexte

Netflix comptabilise plus de 100 millions d'utilisateurs dans le monde. Un nombre encore plus grand d'appareils est comptabilisé puisqu'il est possible d'utiliser Netflix sur différentes machines avec un seul compte utilisateur. Netflix ne cesse de croîre et est actuellement implanté dans 190 pays à travers le monde. En 2015, les utilisateurs de Netflix ont regardé 42,000 Millions d'heures de contenu en streaming. La croissance et l’expansion continue de Netflix impose de garantir un haut niveau de satisfaction client. Aux heures de pointes et à fonctionnement normal, Netflix traite 50,000 requêtes par secondes, d'où la nécessité de d'améliorer au mieux le traitement de pannes réseaux. Avec cet objectif, Netflix a développé en 2012 un Gateway nommé Zuul pour répondre à leurs besoins de gestion d’erreurs et pannes réseaux tout en étant au plus proche de leur API. Ils ajoutèrent Zuul à leur liste de software disponibles en open source.

Gateway

L’équipe techinque du service décida de mettre en place leur propre Gateway, Zuul. Un Gateway fait la liaison entre Internet et les services dans le cloud. Il est nécessaire au fonctionnement de l’application Netflix car l'architecture Netflix est basée sur un système de micro services, Netflix en comptabilise un millier. Le Gateway est principalement utilisé pour la gestion du trafic. Il permet également de réaliser d'autres actions comme des checks ou des authentifications. Il peut aussi être utilisé pour faire un suivi d’éléments du trafic avec des outils de visionnement internes, le tout en garantissant une certaine flexibilité. Ce Gateway peut aussi être utilisé pour réaliser des expérimentations. Plusieurs Gateway existent et auraient pu être utilisés par Netflix comme Mashery, AWS, etc..

Ils développèrent le leur, plutôt que d’utiliser un existant, afin de satisfaire pleinement leurs besoins et d’avoir un système correspondant parfaitement à leur structure et objectifs. Implémenter un Gateway propre à Netflix a pour objectif principal de convenir à leur architecture et leur API. Plusieurs avantages sont à mettre en évidence comme la capacité d'avoir une vue interne du système et donc comprendre plus facilement et rapidement une panne et sa cause afin de la traiter plus efficacement. Une logique de routing dynamique pourra ensuite être mise en place tout comme un load balancing performant. En plus d'outils d'assurance qualité et une meilleure protection du service, Netflix aura un Gateway qui sera plus ancré dans leur écosystème de micro services.

Gateway.png

Zuul

Zuul est un micro service créé en 2012 par Netflix. Utilisant le langage Groovy, synthaxiquement proche de Python et Ruby, il est rapide à mettre en place, tout en étant destiné à la plateforme Java. Zuul peut être simplifié comme étant un système de filtres. Ces filtres ont la capacité d'être utilisés partout et pour tout, ils peuvent être destinés à traiter des situations basiques du système ou à être implémenté pour une durée réduite mais répondant à une panne soudaine du réseau pouvant affecter une zone géographique ou un type d'appareil en particulier. Les filtres sont caractérisés par quatre éléments. Tout d'abord, le type du filtre, il peut s'agir d'un filtre de routage, de pré-routage, de post-routage, ou filtre décrivant le fonctionnement du load balancing, etc. Un filtre est caractérisé par un ordre de priorité et un critère d'activation du filtre. Enfin, une fonction éxecutable, à effectuer lorsque le critère est vérifié, décrit les différentes actions du filtre. Bien que les filtres ne communiquent pas entre eux, ils partagent leur état. La compilation dynamique permet une implémentation immédiate d'un filtre dans le système.

Ainsi, Netflix a la capacité d'identifier et de comprendre une panne en moins de 30 secondes et de mettre en place une solution (développement et compilation), souvent temporaire, dans le même temps. Netflix est donc passé d'une situation ou la compréhension d'une panne pouvait prendre un temps important avant d'être identifiée et un système inflexible n'aidant pas à la correction à une situation ou le traitement complet d'une panne peut être fait en une minute. Ces corrections n'ont pas pour but d'être définitives mais servent à contrer une panne réseau non provoquée par Netflix afin de garantir un fonctionnement optimal de l'application sur l'ensemble des appareils dans le monde.

Filter.png

Succès

Zuul est un succès pour Netflix. Il répondait aux attentes en permettant l’implémentation d’une correction d’erreur en moins d’une minute avec résultats immédiats. Il a donc été adopté à grande echelle. De leur point de vue, la satisfaction client était une preuve de réussite supplémentaire.

Ils ont pu apprendre de leurs erreurs après avoir tenté de suivre un business logic qui s'avéra une mauvaise idée. Le point négatif majeur est la perte d’élasticité du système. ­À cela peut s'ajouter la perte de clarté concernant la vue d'ensemble du système comme certains filtres ne sont activés que pour certaines régions ou pour certains appareils ou sont tout simplement temporaires.

Ces deux défauts n’impactent pas le succès qui est d’autant plus grand car Netflix s’est fixé des objectifs clairs de stratégie sur l’utilisation de Zuul afin de l’utiliser au mieux de la façon la plus pertinente possible sans en abuser. La vitesse de réaction et la vue interne du système reste la base de leur micro service, mais ils décidèrent de se focaliser sur un routing créatif et dynamique ainsi que de perfectionner la mise en forme de leur trafic réseau.

Zuul 2.0

En 2016, Netflix implémenta Zuul 2.0 dans le but d’améliorer les performances et de mieux structurer leur système. Ils décidèrent de passer d’un système bloquant utilisant des threads, et donc gourmand en connexion (une thread par requête), à un système non bloquant asynchrone. D’un point de vue utilisation, les performances ne sont pas inférieures mais n’ont pas été améliorées. Netflix considère tout de même cela comme un succès car la restructuration du système garanti des connexions persistantes et donc une charge réseau nettement inférieure. En revanche, l’absence de threads complique les phases de debugs.

Références