Catégories
Start-up et applications

Comment Ably.io utilise les API gRPC pour rationaliser son service de messagerie

Dans les tranches précédentes de cette série, nous avons examiné les événements historiques qui ont conduit à la création de gRPC. Nous avons également examiné 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. Et, nous avons 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 à un fichier 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 gRPC et comment il fonctionne, nous allons maintenant faire quelques versements sur la façon dont grPC est utilisé dans le monde réel. Dans cet épisode de la série ProgrammableWeb sur gRPC, nous allons voir comment la plate-forme de messagerie en tant que service Ably.io utilise gRPC pour optimiser les capacités de streaming de son service. Nous fournirons un bref aperçu de la pile technologique Ably.io, puis nous verrons comment gRPC est utilisé pour optimiser la communication dans le plan de contrôle du service.

Messagerie en tant que service sous Ably.io

Alors que les architectures événementielles continuent de gagner en importance dans le paysage informatique, les systèmes de messagerie efficaces jouent un rôle de plus en plus critique. Les architectures événementielles offrent un degré élevé de flexibilité pour créer des applications et des services qui nécessitent des données rapides et précises en temps réel.

Un bon exemple d'application événementielle est Uber ou Lyft. Le code qui salue un pilote pour un pilote attend essentiellement, sans rien faire, jusqu'à ce qu'un événement logiciel se produise. Cet événement logiciel se produit lorsqu'un cycliste sort son smartphone, ouvre l'application Uber et demande un trajet. Cet événement logiciel déclenche à son tour une série d'échanges de messages qui aboutissent finalement à l'exécution du code de télé-appel qui attendait d'être réveillé.

Cependant, des problèmes surviennent lorsque la livraison des messages est retardée ou corrompue. Les messages manqués peuvent entraîner des inexactitudes dans l'application ou, au pire, des pannes du système comme un cycliste qui ne fait pas son trajet. Ainsi, une application distribuée qui utilise une architecture événementielle n'est aussi bonne que le système de messagerie qui la prend en charge.

Ably.io a compris ce besoin lorsqu'il a créé son service de messagerie en 2016. Selon le directeur technique Paddy Byers, Ably.io a été conçu à partir de zéro pour «créer un service qui engloberait confortablement non seulement les demandes des applications grand public les plus populaires, mais cela ouvrirait la voie en permettant la croissance massive des échanges de données instantanés et de grande valeur entre les entreprises mondiales. "

En bref, Ably.io est un service de messagerie PubSub qui distribue des messages discrets à un volume élevé et à une faible latence réseau pour toute application nécessitant la livraison d'événements asynchrones. Ably.io prend en charge les modèles de distribution directe et en éventail. (Voir la figure 1 ci-dessous)

Figure 1: Les modèles de file d'attente de messages Direct et Fan Out

Figure 1: Les modèles de file d'attente de messages Direct et Fan Out

Le modèle direct est celui dans lequel un message est remis à une file d'attente de messages spécifique. Dans une distribution, un message est remis simultanément à plusieurs files d'attente. Le modèle direct est idéal pour une file d'attente de messages qui prend en charge un problème spécifique, tandis qu'un modèle de distribution est bien adapté aux applications qui prennent en charge une variété de parties intéressées telles que les événements sportifs et la diffusion à grande échelle.

Ably.io permet aux entreprises de profiter des avantages de la messagerie et du streaming de puissance industrielle sans avoir à faire l'investissement massif requis pour prendre en charge une telle infrastructure. Avec Ably.io, les entreprises ne paient que ce qu'elles utilisent.

gRPC est la clé de l'infrastructure Ably.io.

Comprendre le défi de la connexion

Ably.io avait un problème fondamental à résoudre pour que son service de messagerie prenne en charge l'ampleur requise pour ses clients professionnels. Le problème est centré sur la façon dont le système d'exploitation Linux gère les connexions réseau. Le noyau Linux prend en charge un nombre limité de descripteurs de fichiers par machine. Ceci est un problème car chaque connexion réseau sur une machine a un descripteur de fichier correspondant. Ainsi, le nombre de connexions réseau disponibles pour un système est limité.

Pour l'utilisateur ou le service informatique moyen, ce n'est pas un problème. Mais lorsque vous avez un système de messagerie qui peut avoir des millions d'utilisateurs connectés, épuiser la limite du descripteur de fichier est une réelle possibilité. Paddy Byers, CTO d'Ably.io a décrit le problème dans une récente interview avec ProgrammableWeb. Selon Byers, «Lorsque vous mettez à l'échelle un système qui est composé d'un cluster qui a une échelle arbitraire, vous devez être en mesure de tout faire fonctionner sans mettre à l'échelle le nombre de connexions individuelles que vous avez, car le nombre de connexions … est limité. Le noyau Linux a un nombre fixe de descripteurs de fichiers. "

Pour que le service de messagerie d'Ably.io fonctionne, l'entreprise avait besoin d'une solution de contournement. Le CTO Byers est tombé sur gRPC au début de 2015. L'une des choses intéressantes de Byers à propos de gRPC est que la technologie utilise HTTP / 2 comme protocole sous-jacent.

HTTP / 2 diffère de HTTP / 1.1 de manière significative. Chaque requête adressée au réseau via HTTP / 1.1 entraîne une nouvelle connexion réseau. Par exemple, il n'est pas inhabituel pour un site Web commercial d'engager une centaine de connexions ou plus pour charger une page Web typique, comme le montre la figure 2 ci-dessous.

Figure 2: Pages Web le HTTP / 1.1 entraînera une nouvelle connexion réseau pour chaque requête

Figure 2: Les pages Web HTTP / 1.1 entraîneront une nouvelle connexion réseau pour chaque requête

HTTP / 2 fait en sorte que plusieurs requêtes provenant de la même source d'origine puissent être effectuées sur une seule connexion. C'est une distinction importante avec HTTP / 1.1. Autoriser plusieurs demandes sur une seule connexion réduit l'utilisation du descripteur de fichier et améliore également les performances de l'application. De plus, HTTP / 2 prend en charge la diffusion bidirectionnelle. Tout ce qu'une application doit faire est d'établir une connexion réseau unique via HTTP / 2. Ensuite, des flux continus de données peuvent traverser la connexion dans les deux sens, du client au serveur et du serveur au client.

gRPC et HTTP / 2 étaient les technologies dont Ably.io avait besoin pour accomplir sa mission. Comme le rappelle Byers, «ce dont vous avez besoin, c'est d'un service RPC qui multiplexe plusieurs flux et plusieurs opérations sur une seule connexion. Et ce protocole n'existait pas vraiment avant l'arrivée de HTTP / 2».

À la fin de 2015, Ably.io avait intégré gRPC dans sa pile. Byers rapporte: "Nous avons été parmi les premiers à adopter. Je me suis intégré pendant un week-end. Il était soutenu par Google, donc il semblait techniquement qu'il allait dans la bonne direction. C'était une solution très crédible à l'époque. Nous avons donc décidé d'adopter il."

Comment Ably.io utilise gRPC

Ably.io utilise gRPC d'une manière très particulière. Tout d'abord, sa mise en œuvre gRPC n'est pas orientée client. L'interface publique d'Ably.io expose son service via des protocoles de messagerie standard tels que MQTT, AMQP, STOMP et WebSockets ainsi que HTTP / 1.1 en utilisant son API REST. Les activités gRPC d'Ably.io se déroulent dans les coulisses du côté serveur (de la même manière que de nombreuses API publiques de Google sont construites).

La proposition de valeur essentielle d'Ably.io est que les entreprises bénéficient de capacités de messagerie sans encourir le coût d'une infrastructure de messagerie de niveau entreprise. C'est la différence entre acheter de l'électricité à une compagnie d'électricité ou acheter une cargaison de générateurs qui fourniront de l'électricité. Certaines entreprises bénéficieront de la propriété des générateurs, la plupart ne le feront pas.

Cependant, quel que soit le propriétaire de l'infrastructure, celle-ci doit toujours exister et doit être gérée. Comme mentionné ci-dessus, Ably.io se charge de créer l'infrastructure et de la gérer. Les clients paient ce dont ils ont besoin.

Cependant, Ably.io va un peu plus loin dans la mesure où il optimise l'activité des messages en fonction de l'emplacement géographique. Au lieu de tous les messages allant et venant d'un emplacement commun, par exemple un centre de données à Chicago, Ably.io déplace l'émission et la consommation des messages aussi près que possible des emplacements source et cible. Si vous êtes à Perth en Australie, vous transmettez à l'emplacement le plus proche de Perth. Si vous êtes à Hong Kong, vous recevez vos messages d'un emplacement cible le plus proche de Hong Kong. Fournir une livraison immédiate améliore les performances. La latence diminue à mesure que vous vous rapprochez physiquement de la source de l'activité de messagerie. C'est la différence entre livrer un colis dans la rue et le livrer à travers la ville.

Faire tout cela – la gestion des messages, la gestion des files d'attente et de la distribution, la collecte des messages, les déplacer vers des emplacements d'émission optimaux, etc. sont des tâches herculéennes qu'Ably.io accomplit en interne dans l'infrastructure Ably.io. C'est là que gRPC joue un rôle essentiel.

Comme mentionné ci-dessus, l'interface publique d'Ably.io prend en charge les protocoles de messagerie typiques d'une architecture événementielle. Mais, en interne, les choses sont plus rationalisées. Ably.io condense tous les messages provenant de connexions réseau externes en un plus petit nombre de connexions HTTP / 2. En outre, Ably.io sépare l'activité en deux plans; données et contrôle. (Voir la figure 3 ci-dessous.)

Figure 3: L'architecture Ably.io s'appuie sur gRPC pour prendre en charge ses plans de données et de contrôle internes

Figure 3: L'architecture Ably.io s'appuie sur gRPC pour prendre en charge ses plans de données et de contrôle internes

Le plan de données contient les données utilisateur. Le plan de contrôle contient des données relatives à la gestion de la plate-forme de messagerie Ably.io en tant que service. Une fois à l'intérieur de l'infrastructure Ably.io, les données sont encodées au format binaire Protocol Buffer selon un schéma défini par Ably.io. Le traitement logique est effectué via des appels de méthode gRPC.

L'utilisation de gRPC rend l'échange de données rapide et efficace. Il a bien servi Ably.io au fil des ans. Cependant, cela ne veut pas dire que l'utilisation de gRPC au début était une entreprise facile. Il y avait des problèmes.

Douleurs de croissance

Les choses n'étaient pas faciles pour Ably.io lors de ses débuts avec gRPC. Il y avait beaucoup de bugs. CTO Bayers a déclaré ProgrammableWeb. «Au début, en particulier avec l'implémentation de Node.js, nous avons littéralement eu des plantages. Nous aurions des processus qui se terminaient juste lorsque le gRPC se bloque. Et puis, comme je l'ai dit, vous obtiendriez ces anomalies où les requêtes cesseraient de fonctionner dans une direction. des messages sauvegardés ou vous abandonneriez des événements ou ce genre de choses. Et, maintenant, je dirais que (les différentes implémentations de gRPC) se sont beaucoup améliorées. "

En plus des plantages, il y avait des moments où les demandes tombaient sans notification d'échec. Pour résoudre ce problème, la société a mis en œuvre des contrôles de pulsations et de vivacité pour surveiller l'état des différents composants gRPC au sein de son infrastructure. En outre, la société a veillé à ce que la dernière version de gRPC soit toujours installée. Comme le rapporte Byers, "Vous devez continuer à avancer avec les mises à jour."

Ben Gamble, responsable des relations avec les développeurs, a souligné au cours de l'entretien qu'un autre problème qu'Ably.io a rencontré avec gRPC était que leurs schémas de tampon de protocole gRPC devenaient difficiles à gérer avec le temps. Selon Gamble, "" … alors que vous continuez à incrémenter les systèmes, vous vous retrouvez avec ce problème de maintenance massif avec la façon dont vos protobufs sont même définis. Vous vous retrouvez avec le fait que vous ne pouvez pas facilement supprimer des éléments de la définition elle-même. … (Finalement) vous vous retrouvez avec cette surcharge massive dans chaque partie du Protocol Buffer. "

Gamble continue, "si vous organisez réellement votre protobuf par taille au fil du temps, il augmentera à moins que vous n'ayez effectué une réinitialisation matérielle à un moment donné. C'est génial si vous pouvez maintenir le fait que tous vos systèmes vont être pleinement opérationnels. date. Mais si quelque chose est hors de votre contrôle, vous vous retrouvez avec ces incréments constants (en) taille, ce qui signifie que la surcharge ne fait qu'augmenter. "

Un autre problème pour Gamble était que Protocol Buffers version 2 prend en charge l'étiquette requise sur les champs de données. Marquer un champ comme requis fait en sorte que les mécanismes de validation inhérents aux bibliothèques gRPC de la version 2 génèrent des erreurs lorsqu'un champ obligatoire ne contient aucune donnée. Cela rendait difficile la garantie de la compatibilité descendante lors de la modification du schéma. Gamble a déclaré à plusieurs reprises qu'il souhaitait apporter une modification au schéma, mais qu'il n'a pas pu le faire en raison d'un problème de champ obligatoire dans le schéma hérité. Byers et Gamble reconnaissent que les choses sont devenues beaucoup plus faciles pour les efforts de développement de l'entreprise avec l'introduction de Protocol Buffers version 3. La version 3 a supprimé l'étiquette requise. Au lieu de cela, les contrôles de validation doivent maintenant avoir lieu dans la logique métier de l'implémentation gRPC.

Mettre tous ensemble

Ably.io est toujours engagé dans gRPC. Les avantages qu'elle offre n'ont pas encore été égalés par d'autres technologies. La mise en œuvre a parcouru un long chemin depuis que Paddy Byers a effectué sa première implémentation de gRPC pendant un week-end en 2015. Aujourd'hui, gRPC est un pilier de la pile technologique de l'entreprise. Byers déclare sans ambiguïté que de son point de vue, "gRPC est le choix de facto pour toute interaction interne entre les composants".

L'interopérabilité était une attraction clé pour l'entreprise lorsqu'elle a adopté le gRPC pour la première fois. Byers a aimé l'idée qu'il ne serait pas contraint à un langage de programmation particulier pour continuer à avancer avec le développement gRPC d'Ably.io. Avoir accès à une grande variété de développeurs parmi lesquels embaucher est un plus.

L'implémentation actuelle de gRPC par Ably.ios est dans Node.js, mais ils font plus d'implémentations dans Go à l'avenir. Ably.io prévoit de continuer à utiliser gRPC en tant que technologie interne. Byers reconnaît que l'entreprise ne suscite pas beaucoup d'intérêt pour une API gRPC destinée au public. Cependant, un domaine dans lequel il voit un potentiel d'utilisation de gRPC sur le front-end est celui de l'Internet des objets.

Aujourd'hui, Ably.io gère des millions de messages par seconde pour des entreprises qui opèrent dans une variété de secteurs d'activité. Son utilisation du gRPC est un témoignage permanent de la puissance de la technologie. Mais, avec une grande puissance vient une grande complexité. Il a fallu quelques années à Ably.io pour que le gRPC fonctionne de manière fiable pour l'entreprise. Ils n'ont aucun regret, mais ils ont eu des douleurs de croissance. Les entreprises qui décident d'adopter le gRPC bénéficieront d'un chemin un peu plus facile maintenant que la technologie est plus mature et est plus largement adoptée. Mais, il y aura encore des défis. Heureusement, la voie vers une adoption efficace a été facilitée car des entreprises telles que Ably.io ont ouvert la voie.

Laisser un commentaire

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