Josh Evans parle du monde chaotique et coloré des microservices Netflix, en commençant par les bases : l'anatomie des microservices, les défis associés aux systèmes distribués et leurs avantages. S'appuyant sur ces bases, il explore les pratiques culturelles, architecturales et opérationnelles qui mènent à la maîtrise des microservices.
Contrairement à la dérive opérationnelle, l'introduction de nouveaux langages pour l'internationalisation des services et de nouvelles technologies telles que les conteneurs sont des décisions conscientes visant à ajouter une nouvelle complexité à l'environnement. Mon équipe opérationnelle a standardisé la meilleure feuille de route technologique pour Netflix, qui était intégrée aux meilleures pratiques prédéfinies basées sur Java et EC2, mais à mesure que l'entreprise se développait, les développeurs ont commencé à ajouter de nouveaux composants tels que Python, Ruby, Node-JS et Docker.
Je suis très fier que nous ayons été les premiers à plaider pour que notre produit fonctionne parfaitement sans attendre les plaintes des clients. Tout a commencé assez simplement : nous avions des programmes d'exploitation en Python et quelques applications de back-office en Ruby, mais les choses sont devenues beaucoup plus intéressantes lorsque nos développeurs Web ont annoncé qu'ils allaient abandonner la JVM et qu'ils allaient déplacer le Web. application à la plateforme logicielle Node.js. Après l’introduction de Docker, les choses sont devenues beaucoup plus complexes. Nous avons suivi la logique et les technologies que nous avons imaginées sont devenues réalité lorsque nous les avons mises en œuvre pour les clients, car elles avaient beaucoup de sens. Je vais vous dire pourquoi il en est ainsi.
API Gateway a en fait la capacité d'intégrer d'excellents scripts qui peuvent servir de points de terminaison pour les développeurs d'interface utilisateur. Ils ont converti chacun de ces scripts de telle sorte qu'après avoir apporté des modifications, ils puissent les déployer en production, puis sur les appareils des utilisateurs, et toutes ces modifications ont été synchronisées avec les points de terminaison exécutés dans la passerelle API.
Cependant, cela répétait le problème de la création d'un nouveau monolithe dans lequel le service API était surchargé de code de telle sorte que divers scénarios de défaillance se produisaient. Par exemple, certains points de terminaison ont été supprimés ou des scripts ont généré de manière aléatoire tellement de versions de quelque chose que ces versions occupaient toute la mémoire disponible du service API.
Il était logique de prendre ces points de terminaison et de les retirer du service API. Pour ce faire, nous avons créé des composants Node.js qui s'exécutaient comme de petites applications dans des conteneurs Docker. Cela nous a permis d'isoler les problèmes et plantages causés par ces applications de nœuds.
Le coût de ces changements est assez important et comprend les facteurs suivants :
- Outils de productivité. La gestion des nouvelles technologies nécessitait de nouveaux outils car l'équipe UI, utilisant de très bons scripts pour créer un modèle efficace, n'avait pas à passer beaucoup de temps à gérer l'infrastructure, il lui suffisait d'écrire des scripts et de vérifier leurs fonctionnalités.
Aperçu et tri des opportunités – Un exemple clé est celui des nouveaux outils nécessaires pour découvrir les informations sur les facteurs de performance. Il était nécessaire de savoir à quel point le processeur était occupé, comment la mémoire était utilisée, et la collecte de ces informations nécessitait différents outils. - Fragmentation des images de base - l'AMI de base simple est devenue plus fragmentée et spécialisée.
- Gestion des nœuds. Il n'existe aucune architecture ou technologie disponible dans le commerce qui vous permette de gérer des nœuds dans le cloud. Nous avons donc créé Titus, une plate-forme de gestion de conteneurs qui fournit un déploiement de conteneurs évolutif et fiable et une intégration dans le cloud avec Amazon AWS.
- Duplication d'une bibliothèque ou d'une plateforme. Fournir de nouvelles technologies avec les mêmes fonctionnalités de base que la plate-forme nécessitait de la dupliquer dans des outils de développement Node.js basés sur le cloud.
- Courbe d'apprentissage et expérience industrielle. L’introduction de nouvelles technologies crée inévitablement de nouveaux défis qu’il faut surmonter et dont il faut tirer les leçons.
Ainsi, nous ne pouvions pas nous limiter à une seule « route pavée » et avons dû constamment créer de nouvelles façons de faire progresser nos technologies. Pour réduire les coûts, nous avons limité le support centralisé et nous sommes concentrés sur la JVM, les nouveaux nœuds et Docker. Nous avons donné la priorité à un impact efficace, informé les équipes du coût de leurs décisions et les avons encouragées à rechercher des moyens de réutiliser les solutions à fort impact qu'elles avaient déjà développées. Nous avons utilisé cette approche lors de la traduction du service en langues étrangères afin de livrer le produit à des clients internationaux. Les exemples incluent des bibliothèques client relativement simples qui peuvent être générées automatiquement, de sorte qu'il est assez facile de créer une version Python, une version Ruby, une version Java, etc.
Nous étions constamment à la recherche d'opportunités pour utiliser des technologies éprouvées qui avaient fait leurs preuves dans un endroit et dans d'autres situations similaires.
Parlons du dernier élément : les changements ou variations. Regardez comment la consommation de notre produit varie inégalement selon le jour de la semaine et selon l'heure tout au long de la journée. On pourrait dire que 9 heures du matin est le moment le plus difficile pour Netflix, lorsque la charge du système atteint son maximum.
Comment pouvons-nous atteindre une vitesse élevée de mise en œuvre des innovations logicielles, c'est-à-dire apporter constamment de nouvelles modifications au système, sans provoquer d'interruptions dans la prestation de services et sans créer de désagréments pour nos clients ? Netflix y est parvenu grâce à l'utilisation de Spinnaker, une nouvelle plateforme mondiale de gestion et de livraison continue (CD) basée sur le cloud.
Spinnaker a été conçu pour intégrer nos meilleures pratiques afin que, lorsque nous déployons des composants en production, nous puissions intégrer la sortie directement dans notre technologie de diffusion multimédia.
Nous avons pu intégrer deux technologies que nous apprécions grandement dans notre pipeline de livraison : l'analyse Canary automatisée et le déploiement par étapes. L'analyse Canary signifie que nous dirigeons un filet de trafic vers la nouvelle version du code et faisons passer le reste du trafic de production via l'ancienne version. Ensuite, nous vérifions comment le nouveau code s'acquitte de la tâche - meilleur ou pire que celui existant.
Un déploiement échelonné signifie que si un déploiement dans une région rencontre des problèmes, nous passons à un déploiement dans une autre région. Dans ce cas, la liste de contrôle mentionnée ci-dessus doit être incluse dans le pipeline de production. Je vais vous faire gagner du temps et vous recommander de consulter mon exposé précédent, Ingénierie des opérations mondiales de Netflix dans le cloud, si vous souhaitez approfondir ce sujet. L'enregistrement vidéo du discours peut être visionné en suivant le lien au bas de la diapositive.
A la fin de l'exposé, j'évoquerai brièvement l'organisation et l'architecture de Netflix. Au tout début, nous avions un système appelé Electronic Delivery, qui était la première version du streaming multimédia NRDP 1.x. Le terme « backstream » peut être utilisé ici car, au départ, l'utilisateur ne pouvait télécharger que du contenu pour une lecture ultérieure sur l'appareil. La toute première plateforme de diffusion numérique de Netflix, en 2009, ressemblait à ceci.
La machine utilisateur contenait l'application Netflix, composée d'une interface utilisateur, de modules de sécurité, d'activation et de lecture de services, basés sur la plateforme NRDP - Netflix Ready Device Platform.
A cette époque, l’interface utilisateur était très simple. Il contenait ce qu'on appelait un lecteur Queque, et l'utilisateur se rendait sur le site pour ajouter quelque chose à Queque, puis visualisait le contenu ajouté sur son appareil. Le point positif était que l’équipe front-end et l’équipe back-end appartenaient à la même organisation de livraison électronique et entretenaient une relation de travail étroite. La charge utile a été créée sur la base de XML. Dans le même temps, l'API Netflix pour le secteur DVD a été créée, ce qui a encouragé les applications tierces à diriger le trafic vers notre service.
Cependant, l'API Netflix était bien préparée pour nous aider avec une interface utilisateur innovante, contenant des métadonnées de tout le contenu, des informations sur les films disponibles, ce qui a créé la possibilité de générer des listes de surveillance. Il disposait d'une API REST générique basée sur le schéma JSON, du code de réponse HTTP, le même que celui utilisé dans l'architecture moderne, et d'un modèle de sécurité OAuth, ce qui était requis à l'époque pour une application frontale. Cela a permis de passer d’un modèle public de diffusion de contenu en streaming à un modèle privé.
Le problème de la transition était la fragmentation, car notre système exploitait désormais deux services basés sur des principes de fonctionnement complètement différents - l'un sur Rest, JSON et OAuth, l'autre sur RPC, XML et un mécanisme de sécurité utilisateur basé sur le système de jetons NTBA. Ce fut la première architecture hybride.
Il y avait essentiellement un pare-feu entre nos deux équipes car au départ, l'API ne s'adaptait pas très bien au PNCE, ce qui entraînait des frictions entre les équipes. Les différences concernaient les services, les protocoles, les circuits, les modules de sécurité et les développeurs devaient souvent basculer entre des contextes complètement différents.
À cet égard, j'ai eu une conversation avec l'un des ingénieurs principaux de l'entreprise, à qui j'ai posé la question : « Quelle devrait être la bonne architecture à long terme ? » et il a posé la contre-question : « Vous êtes probablement plus préoccupé par sur les conséquences organisationnelles : que se passe-t-il si nous intégrons ces éléments et qu'ils brisent ce que nous avons appris à bien faire ? Cette approche est très pertinente par rapport à la loi de Conway : « Les organisations qui conçoivent des systèmes sont contraintes par une conception qui reproduit la structure de communication de cette organisation. » Il s’agit d’une définition très abstraite, je préfère donc une définition plus spécifique : « Tout logiciel reflète la structure organisationnelle qui l’a créé. » Voici ma citation préférée d'Eric Raymond : "Si vous avez quatre équipes de développeurs travaillant sur un compilateur, vous vous retrouverez avec un compilateur en quatre passes." Eh bien, Netflix dispose d'un compilateur en quatre passes, et c'est ainsi que nous travaillons.
On peut dire que dans ce cas, c'est la queue qui remue le chien. Notre première priorité n’est pas la solution, mais l’organisation ; c’est l’organisation qui pilote l’architecture que nous avons. Petit à petit, d'un mélange de services, nous sommes passés à une architecture que nous avons appelée Blade Runner, car nous parlons ici de services de pointe et de la capacité du NCCP à être séparé et intégré directement dans le proxy Zuul, la passerelle API et les fonctionnalités correspondantes. Les « pièces » ont été transformées en de nouveaux microservices dotés de fonctionnalités plus avancées de sécurité, de relecture, de tri des données, etc.
Ainsi, on peut dire que les structures départementales et la dynamique de l’entreprise jouent un rôle important dans la conception du système et constituent un facteur qui favorise ou freine le changement. L’architecture des microservices est complexe et organique, et sa santé repose sur la discipline et le chaos introduit.
Un peu de publicité
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com