Catégories
Start-up et applications

Comment Gitlab place le gRPC dans le monde réel

Dans les versions précédentes de cette série, nous avons examiné les événements historiques qui ont conduit à la création de gRPC ainsi que les détails de la programmation à l'aide de gRPC. Nous avons discuté des concepts clés de la spécification gRPC. Nous avons jeté un coup d'œil à l'application que nous avons créée spécialement pour cette série qui présente les principaux concepts de gRPC. Nous avons également examiné comment utiliser l'outil de génération automatique, protocole fourni par gRPC pour créer du code standard dans une variété de langages de programmation afin d'accélérer le développement de gRPC. Nous avons également expliqué comment se lier aux fichiers protobuf de manière statique et dynamique lors de la programmation sous gRPC. De plus, nous avons créé un certain nombre de leçons sur l'environnement d'apprentissage interactif de Katacoda qui illustrent les concepts et les pratiques que nous avons abordés dans les articles d'introduction.

Après avoir présenté les bases nécessaires pour comprendre ce qu'est le gRPC et son fonctionnement, nous allons maintenant faire quelques tranches sur la façon dont gRPC est utilisé dans le monde réel. L'une de nos enquêtes dans le monde réel a exploré comment gRPC est utilisé par Kubernetes dans sa technologie Container Runtime Interface (CRI).

Dans cet épisode, nous allons voir comment le service de gestion du contrôle de source GitLab a adopté gRPC lorsqu'il a refactoré son architecture côté serveur dans le projet Gitaly.

Gitaly redéfinit l'écosystème GitLab

GitLab se présente comme une plate-forme complète qui unifie l'ensemble du processus DevOps sous une seule application. Au lieu d'avoir à utiliser des outils et des services distincts pour la gestion du contrôle de la source, le suivi des problèmes, la gestion de projet et l'intégration continue / déploiement continu (CI / CD), l'entreprise combine tout dans un seul portail. Ils appellent cette unification "Concurrent DevOps".

Mais, GitLab avait un problème. Son infrastructure numérique n'a pas pu répondre à la demande à mesure que l'entreprise se développait.

Lorsque GitLab a démarré, il exécutait toute sa plate-forme sur un seul serveur. La façon dont l'entreprise a mis à l'échelle son infrastructure au fur et à mesure de sa croissance consistait à créer des instances identiques du serveur derrière un équilibreur de charge, puis à acheminer le trafic en conséquence. Cette approche est appelée mise à l'échelle horizontale. Bien qu'utile au début, la mise à l'échelle horizontale des serveurs est devenue un goulot d'étranglement.

En plus des problèmes inhérents à la mise à l'échelle horizontale, la plate-forme avait un problème particulier à la façon dont elle gérait l'accès au .git fichiers qui constituent la base des référentiels Git qu'il héberge. Chaque référentiel Git hébergé par GitLab a un sous-jacent .git annuaire. Cette .git répertoire stocke tous les fichiers de code source selon les différentes branches en vigueur dans le référentiel. Également .git Le répertoire stocke également les données d'activité, telles que les informations de validation, les informations de fusion, etc. .git l'annuaire est un atout essentiel à la mission. Il est utilisé par tous les développeurs travaillant avec le référentiel ainsi que par les administrateurs système, le personnel de test et une pléthore de scripts d'automatisation qui font tout, de l'escalade de code à la publication de rapports exécutifs. Comme on peut l'imaginer, un seul .git répertoire connaîtra une énorme quantité de lectures et d'écritures.

Avoir un grand nombre de personnes et de processus partagent l'accès à un .git annuaire a causé des problèmes pour GitLab. Premièrement, si un ordinateur sur lequel un .git le répertoire a été stocké est tombé en panne, la plate-forme entière pourrait tomber en panne. Deuxièmement, à mesure que l'activité de lecture / écriture augmentait, l'utilisation du processeur et les opérations d'entrée / sortie (IOPS) augmentaient également. L'entreprise avait besoin de quelque chose de mieux.

Un groupe d'ingénieurs a eu une idée pour résoudre le problème: au lieu de faire interagir chaque utilisateur et processus avec un .git répertoire, pourquoi ne pas fournir une couche de sécurité .git fichier, puis faites en sorte qu'un processus côté serveur optimisé agisse comme un proxy pour le .git fichier. Tout le travail serait effectué côté serveur et le résultat serait renvoyé sur le réseau. Cette réflexion a donné naissance à Gitaly. Gitaly est désormais l'architecture qui traite toutes les requêtes adressées à GitLab.

Comment GitLab a implémenté gRPC

Gitaly v1.0, qui a fait ses débuts en novembre 2018, a complètement remanié la façon dont GitLab traitait les demandes des utilisateurs. Avant l'arrivée de Gitaly, toutes les demandes provenant de GitLab.com faisaient des appels directs à .git fichiers stockés sur des montages NFS connectés au serveur GitLab. Gitaly a supprimé l'accès direct au .git fichier. Au lieu d'avoir une architecture dans laquelle une requête à GitLab entraîne un appel direct à un montage NFS contenant un .git fichier, Gitaly le fait donc demander à GitLab.com de se résoudre finalement au service Gitaly. Le service Gitaly interagit à son tour avec un .git fichier. La communication entre les composants côté client qui font la demande au service Gitaly côté serveur est facilitée à l'aide de gRPC.

Les clients Gitaly qui appellent les serveurs Gitaly ont été créés à l'aide de l'outil d'auto-génération de protocoles. Ces clients sont privés de l'environnement GitLab et ne sont utilisés que par les internes de Gitaly. Ils ne sont pas disponibles pour un usage public. Il existe un client Ruby et un client Go. Une partie du client Ruby utilise des bibliothèques internes écrites en C. L'implémentation Go utilisait go-grpc.

La figure 1 ci-dessous illustre l'architecture Gitaly et le tableau 1 qui suit décrit chaque composant de l'architecture.

Figure 1: L'architecture du framework Gitaly

Figure 1: L'architecture du framework Gitaly

Composant La description
gitlab-rails Le client ruby ​​pour accéder à GitLan et à son tour, Gitaly
Cheval de labour Gitlab-workhorse est un proxy inverse intelligent pour GitLab. Il gère les requêtes HTTP «volumineuses» exécutées via git clone pour les requêtes lentes qui servent des données Git brutes telles que les téléchargements de fichiers, les téléchargements de fichiers, git push / pull et les téléchargements d'archives Git.
Shell GitLab GitLab Shell gère les sessions git SSH pour GitLab et modifie la liste des clés autorisées. GitLab Shell n'est pas un shell Unix ni un remplacement pour Bash ou Zsh. GitLab Shell est utilisé pour des tâches telles que pour git clone, git push etc… exécutés via SSH.
Client de ligne de commande L'outil de ligne de commande pour interagir avec GitLab
Bouts de client Gitaly gRPC Ruby Un client gRPC spécial pour les programmeurs accédant à GitLab en utilisant du code Ruby
Bouts de client Gitaly gRPC Un client gRPC spécial pour l'instance HTTPS, l'interaction ssh et l'outil de ligne de commande
Interface du serveur Gitaly gRPC Le serveur gRPC avec lequel les clients gRPC interagissent pour accéder au service Gitaly
Service Gitaly Le service principal qui coordonne et exécute l'accès aux référentiels Git sous GitLab
Intégration Gitaly git (git spawn) Implémentation du service Gitaly dans Go
gitaly-ruby-service Utilisé pour prendre en charge les appels gRPC qui interagissent avec plus d'un référentiel, comme la fusion d'une branche
Git spawn et libgit2 / robuste Le mécanisme de prise en charge de l'accès au .git fichier via une interface C interne
Système de fichiers local sur NFS Le système de fichiers sur lequel .git les référentiels sont stockés

Tableau 1: Les composants qui composent le framework Gitaly

Pourquoi les ingénieurs de GitLab ont-ils choisi d'utiliser gRPC comme mécanisme de communication? Comme Zeger-Jan van de Weg, directeur de l'ingénierie backend de GitLab, Gitaly l'a dit ProgrammableWeb:

«L'une de nos valeurs chez GitLab est l'efficacité … bien que tout à fait nouveau au moment où il (gRPC) a été choisi chez GitLab, il a montré des concepts matures et beaucoup d'expérience avec les RPC dans le passé.

L'outillage pour gRPC et Protobuf est également mature et il existe un bon support pour plusieurs langues. Pour GitLab, il était important d'avoir un support de première classe pour Ruby and Go. En tant qu'entreprise, Google investit généralement beaucoup de ressources dans l'outillage, et gRPC ne fait pas exception.

De plus, la communauté est également de taille raisonnable. Ce n'est pas aussi gros que disons Ruby on Rails, mais la plupart des questions quotidiennes qu'un développeur peut se poser, il peut rechercher la réponse sur Google. Et des cas d'utilisation légèrement plus avancés ont également été couverts. Par exemple, il y avait un besoin d'un proxy qui jette un œil dans le premier message d'un flux (Protocol Buffers) pour modifier le routage et réécrire partiellement le message proto. Vous trouverez en quelques minutes des exemples sur la façon de le faire et sur ce qu'il faut rechercher. Pour l'équipe Gitaly, gRPC (plus protobuf) pose très peu de problèmes, et ne pas avoir à nous soucier de la stabilité ou de l'outillage immature nous permet de nous concentrer sur la création de valeur pour les clients. "

N'oubliez pas que lorsqu'il s'agit de travailler avec des dizaines de milliers de fichiers de référentiel répartis sur un cluster de machines en constante croissance, GitLab avait besoin d'un protocole de communication rapide, efficace et relativement facile à adopter du point de vue d'un développeur. gRPC a répondu au besoin et plus encore.

Ce qui est intéressant à noter, c'est que GitLab n'avait pas beaucoup d'expertise avec gRPC lorsqu'il a commencé le développement avec Gitaly. Comme l'a dit van de Weg lors de la ProgammableWeb entretien,

«Au moment où gRPC a été choisi, il n'y avait aucune expérience significative avec gRPC, ni Protobuf. Il n'y a pas de formation active, ni demandé. Dans notre équipe, gRPC est l'une des technologies les plus faciles à apprendre, (par opposition à) exécuter Git à grande échelle et comprendre l'architecture GitLab. "

Pourtant, bien qu'il n'ait pas d'expertise immédiatement disponible, GitLab a prévalu. L'entreprise a trouvé que le gRPC était une technologie simple à mettre en œuvre. van de Weg continue,

"Comme toujours, une nouvelle technologie et une nouvelle API prennent du temps à s'habituer, bien que le gRPC le rend facile à intégrer. Personnellement, je n'ai pas trouvé que le gRPC était trop difficile à utiliser. L'API a des abstractions propres, et ne le fait pas. 'pas trop de fuite de l'implémentation. "

Pourtant, pour GitLab, tout n'était pas des pêches et de la crème. La société a connu un succès considérable en utilisant gRPC dans Gitaly, mais le succès est venu avec quelques défis.

GitLab fait face aux défis avec gRPC

Comme mentionné ci-dessus, l'un des avantages du gRPC est la rapidité du transfert de données entre les sources et les cibles. La réduction des données au format binaire augmente la vitesse de transmission. Mais, pour prendre en charge un format binaire, gRPC nécessite un schéma bien défini qui est partagé à la fois par le client et le serveur. Ce schéma est défini dans un fichier protobuf qui décrit les méthodes et le type d'un service gRPC selon la spécification gRPC.

Travailler avec un schéma commun documenté dans un fichier protobuf peut être un peu difficile pour ceux qui sont habitués à travailler avec des formats de données auto-descriptifs tels que JSON ou XML. Commun aux modèles d'architecture d'API faiblement couplés tels que REST, un format auto-descriptif ne nécessite pas que le client sache quoi que ce soit à l'avance sur les données envoyées par un serveur afin de décoder une réponse. D'autre part, gRPC nécessite que la structure d'une interface soit bien connue à la fois du client et du serveur et par conséquent, à mesure que les modèles architecturaux d'API évoluent, elle est plus étroitement couplée. S'habituer à cette formalité nécessite une réinitialisation de l'état d'esprit des développeurs. Créer des interfaces gRPC cohérentes et utiles était un défi pour les développeurs de Gitaly. van de Web a reconnu ce défi en disant: "Les problèmes de familiarisation avec gRPC et Protobuf au début ont créé des incohérences dans notre interface."

En plus d'apprendre à créer des structures de données / interfaces pouvant évoluer avec un impact minimal, GitLab devait résoudre les problèmes qui se posaient autour de la taille réelle d'un message binaire renvoyé à une requête, comme l'explique van der Web,

"Certains choix ont été faits il y a longtemps, pour lesquels je ne sais pas (est) actuellement s'ils sont toujours optimaux. La taille maximale des messages me vient à l'esprit, ou comment segmenter les demandes ou réponses potentielles importantes. Dans le cas où pour exemple, une liste de branches est demandée au serveur, vous pouvez envoyer un message par branche trouvée, ou envoyer plusieurs objets de branche par message. Les deux solutions que nous employons actuellement, mais si les solutions correctes sont choisies à chaque fois (de la part du demandeur)? Je ne parierais pas dessus. "

Gitaly utilise des side-cars comme services auxiliaires pour soutenir les opérations de plus haut niveau. Il s'est avéré que les side-cars ont créé des problèmes difficiles à détecter. Certains des problèmes étaient directement liés à gRPC, mais l'événement réel à l'origine de l'erreur était profondément ancré dans un side-car, rendant la résolution difficile. A van der Web souligne, il a fallu un certain temps pour découvrir les coupables.

"Ensuite, en termes de bogues ou de comportements surprenants, il y a eu des moments où notre service a fait une erreur avec des erreurs d'épuisement des ressources. Il a été assez rapidement identifié comme venant du side-car. Mais à part cela, ils étaient très sporadiques et n'avaient pas source cohérente. Les erreurs que nous n’avons pas générées dans le code de l’application, mais il n’y avait pas encore suffisamment d’informations pour être reproduites de manière cohérente, ce qui a permis de découvrir la cause première. Après un certain temps, nous avons découvert que le serveur ruby ​​gRPC avait une limite de concurrence que notre le side-car frappait. "

L'un des autres problèmes rencontrés par GitLab concernait la compréhension des informations d'erreur provenant des composants internes de Gitaly. S'il est vrai que la plupart des développeurs de GitLab ont interagi avec le service interne de Gitaly en utilisant les clients Gitaly / gRPC, il y avait encore un segment de la communauté des développeurs qui devait travailler avec Gitaly à un niveau inférieur. Lorsque des problèmes se posaient, les développeurs travaillant à un niveau inférieur avaient du mal à comprendre ce qui se passait avec une demande lorsqu'elle se frayait un chemin dans la pile Gitaly car la plupart des codes d'erreur de cause première étaient spécifiques à gRPC. van der Web explique la situation,

"L'interface sur les clients est généralement à un niveau supérieur … Cela signifie que ces développeurs ne savent pas comment leurs demandes parviennent à notre service, tout comme de nombreux développeurs ne savent pas comment les requêtes sont envoyées à d'autres banques de données comme Redis ou Postgres . Cependant, avec gRPC, les erreurs sont beaucoup plus susceptibles de remonter jusqu'à ces développeurs. Comme gRPC utilise HTTP / 2, il aurait peut-être été préférable de s'en tenir aux codes d'état HTTP pour mieux les connaître. "

En d'autres termes, vous pouvez comprendre ce qui se passe si vous ne savez pas sur quoi portent les messages d'erreur. La plupart des développeurs comprennent la signification des codes d'état HTTP tels que 200, 404 ou 500. D'un autre côté, gRPC est toujours une technologie «sous les couvertures» pour beaucoup. En conséquence, le débogage de gRPC était encore une aventure dans l'inconnu pour un large segment de la communauté de développement.

Mettre tous ensemble

GitLab est une entreprise qui a connu une croissance significative. Selon Forbes, la croissance de ses revenus d'une année à l'autre est de 143%. Il a recueilli 268 millions de dollars en financement de série E. Et, sa valorisation en septembre 2018 était de 2,75 milliards de dollars. C'est beaucoup d'argent. Rien de tout cela n'aurait été possible si GitLab ne disposait pas d'une infrastructure technique solide pour soutenir ses activités actuelles ainsi que sa croissance prévue. Plus d'une entreprise a dérapé parce que sa technologie ne pouvait pas répondre aux demandes du marché.

À son honneur, GitLab a eu la clairvoyance de comprendre les risques inhérents à sa croissance anticipée. La société les a abordés de front avec Gitaly et gRPC.

La gestion fiable des référentiels Git est une fonctionnalité clé de l'écosystème GitLab. Sans cela, tous les autres services qui font partie de la plate-forme Concurrent DevOps de GitLab deviennent sans conséquence. Placer le gRPC au centre de son service de gestion de référentiel Gitaly était une décision critique. Alors que beaucoup de travail lié à l'adoption de gRPC était facile à faire pour GitLab, il y avait des défis, principalement autour de la maîtrise de l'utilisation de la spécification Protocol Buffers et de l'optimisation de la transmission des messages.

À ce jour, GitLab réussit. L'entreprise continue de prospérer. le choix d'utiliser gRPC semble être judicieux. La formalité qui accompagne la mise en œuvre de gRPC a apporté plus de discipline aux efforts de développement de GitLab.

Pour les entreprises qui envisagent d'adopter gRPC, la chose à garder à l'esprit en ce qui concerne GitLab est que l'entreprise avait déjà beaucoup d'expérience dans l'écriture de services backend à un niveau très profond. Ses ingénieurs connaissaient bien les détails de la communication réseau via les prises. Ils ont compris les nuances inhérentes au protocole HTTP / 2 et au format binaire Protocol Buffers. En bref, ils étaient des programmes très confortables pour le côté service avant même l'arrivée de Gitaly.

Une entreprise qui s'approche de gRPC pour la première fois fera bien de s'assurer qu'elle possède une expertise en programmation côté serveur. Cela comprend tout, de la maîtrise des subtilités de la mise à l'échelle verticale et horizontale à la compréhension de la complexité de travailler avec un format de données binaire tel que les tampons de protocole.

L'étude du succès et des défis rencontrés par GitLab fournira des leçons concrètes qui profiteront à toute entreprise envisageant l'adoption du gRPC dans l'entreprise. gRPC prend un certain temps pour s'y habituer, mais comme GitLab l'a montré, l'investissement de temps et d'attention a produit des résultats bénéfiques à court et à long terme.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *