Cloud Pub/Sub : un service de messagerie à l'échelle de Google

Présentation

Cloud Pub/Sub est un service de messagerie asynchrone conçu pour être extrêmement fiable et évolutif. Le service repose sur un composant d'infrastructure de base de Google sur lequel s'appuient également de nombreux produits Google depuis plus de 10 ans. Les produits Google tels que Google Ads, la recherche et Gmail se servent de cette infrastructure pour envoyer plus de 500 millions de messages par seconde, représentant un débit total de plus de 1 To/s de données. Cet article décrit les principales caractéristiques de conception permettant à Cloud Pub/Sub de fournir un service fiable à une telle échelle.

Les bases d'un service de publication et d'abonnement

Cloud Pub/Sub est un service de publication et d'abonnement (publish/subscribe ou Pub/Sub), c'est-à-dire un service de messagerie où les expéditeurs de messages sont découplés des destinataires. Un service Pub/Sub repose sur quelques concepts clés :

  • Message : les données qui transitent par le service

  • Sujet : une entité nommée qui représente un flux de messages

  • Abonnement : une entité nommée qui représente un intérêt à recevoir les messages associés à un sujet particulier

  • Éditeur (également appelé producteur) : crée des messages et les envoie au service de messagerie (c'est-à-dire les publie) dans un sujet spécifié

  • Abonné (également appelé consommateur) : reçoit des messages dans le cadre d'un abonnement spécifié

Le diagramme suivant donne une vue synthétique du flux de base des messages via Cloud Pub/Sub :

Dans ce scénario, deux éditeurs publient des messages dans un même sujet. Il existe deux abonnements au sujet. Le premier abonnement a deux abonnés, ce qui signifie que la charge des messages sera équilibrée entre eux, chaque abonné recevant un sous-ensemble de messages. Le deuxième abonnement a un abonné qui recevra tous les messages. Les lettres en gras représentent des messages. Le message A provient de l'éditeur 1. Il est envoyé respectivement à l'abonné 2 via l'abonnement 1 et à l'abonné 3 via l'abonnement 2. Le message B provient de l'éditeur 2. Il est envoyé respectivement à l'abonné 1 via l'abonnement 1 et à l'abonné 3 via l'abonnement 2.

Évaluer les performances d'un service de messagerie

Un service de messagerie tel que Cloud Pub/Sub peut être jugé sur ses performances suivant trois aspects : l'évolutivité, la disponibilité et la latence. Ces trois critères sont souvent contradictoires et nécessitent des compromis sur l'un pour améliorer les deux autres.

Les termes "évolutivité", "disponibilité" et "latence" peuvent désigner différentes propriétés d'un système. Par conséquent, les sections suivantes décrivent leur définition dans le contexte de Cloud Pub/Sub.

Évolutivité

Un service évolutif doit pouvoir gérer les augmentations de charge sans dégradation notable de la latence ou de la disponibilité. La "charge" peut faire référence à différentes dimensions d'utilisation dans Cloud Pub/Sub :

  • Le nombre de sujets

  • Le nombre d'éditeurs

  • Le nombre d'abonnements

  • Le nombre d'abonnés

  • Le nombre de messages

  • La taille des messages

  • Le débit (ou taux) de messages publiés ou consommés

  • Le volume en attente sur un abonnement donné

Disponibilité

Dans un système distribué, les types de problèmes rencontrés et leur gravité peuvent varier considérablement. La disponibilité d'un système est évaluée suivant sa capacité à traiter différents types de problèmes et à gérer une panne de manière optimale et transparente pour les utilisateurs finaux. Des défaillances peuvent survenir au niveau du matériel (par exemple, des pannes de disques durs ou des problèmes de connectivité réseau), au niveau logiciel, ou à cause de la charge. Une défaillance due à la charge peut survenir lorsqu'une augmentation soudaine du trafic au sein du service (ou dans d'autres composants logiciels s'exécutant sur le même matériel, ou dans des dépendances logicielles) entraîne une pénurie de ressources. La disponibilité peut également se dégrader du fait d'une erreur humaine, par exemple lors de la création ou du déploiement de logiciels ou de configurations.

Latence

La latence est une mesure temporelle de la performance d'un système. Un service cherche généralement à minimiser la latence autant que possible. Pour Cloud Pub/Sub, les deux mesures de latence principales sont les suivantes :

  1. La durée nécessaire pour accuser réception d'un message publié

  2. La durée nécessaire pour distribuer un message publié à un abonné

Architecture Cloud Pub/Sub de base

Dans cette section, nous expliquons la conception de Cloud Pub/Sub pour montrer comment le service atteint son évolutivité et sa faible latence tout en conservant sa disponibilité. Le système est conçu pour être évolutif horizontalement, c'est-à-dire qu'il peut gérer une hausse du nombre de sujets, d'abonnements ou de messages en augmentant le nombre d'instances de serveurs en cours d'exécution.

Les serveurs Cloud Pub/Sub sont hébergés dans plusieurs centres de données de Google répartis dans le monde entier. Chaque centre de données contient une ou plusieurs instances d'un cluster, un groupe logique de machines partageant généralement le même domaine de défaillance (par exemple, un réseau local partagé et une alimentation partagée). Cloud Pub/Sub est un service global : les clients ne sont pas conscients de l'emplacement physique des serveurs ou des données, ou du centre de données qui les héberge, et ils peuvent publier et s'abonner depuis partout dans le monde vers n'importe quel endroit.

Cloud Pub/Sub est organisé en deux grandes parties : le plan de données, qui gère le transfert de messages entre les éditeurs et les abonnés, et le plan de contrôle, qui gère l'affectation des éditeurs et des abonnés aux serveurs du plan de données. Les serveurs du plan de données sont appelés des redirecteurs, et les serveurs du plan de contrôle sont des routeurs. Lorsque les éditeurs et les abonnés sont connectés aux redirecteurs auxquels ils sont affectés, ils n'ont pas besoin d'informations provenant des routeurs (tant que ces redirecteurs restent accessibles). Par conséquent, il est possible de mettre à jour le plan de contrôle de Cloud Pub/Sub sans perturber les clients déjà connectés et qui envoient ou reçoivent des messages.

Plan de contrôle

Le plan de contrôle Cloud Pub/Sub distribue les clients aux redirecteurs de manière à assurer adaptabilité, disponibilité et faible latence pour l'ensemble de ces clients. Tout redirecteur est capable de diffuser n'importe quel sujet ou abonnement aux clients. Lorsqu'un client se connecte à Cloud Pub/Sub, le routeur décide à quels centres de données le client doit se connecter en fonction de la distance réseau (mesure de la latence de la connexion entre deux points) la plus courte. Dans un centre de données particulier, le routeur tente de répartir la charge globale sur l'ensemble des redirecteurs disponibles. Pour cette tâche, le routeur doit atteindre un équilibre entre deux objectifs différents : (a) l'uniformité de la charge (idéalement, chaque redirecteur reçoit une charge égale) ; et (b) la stabilité des affectations (idéalement, un changement au niveau de la charge ou de l'ensemble de redirecteurs disponibles impacte un nombre minimal d'affectations existantes). Le routeur utilise une variante du système de hachage cohérent développé par Google Research pour atteindre un équilibre ajustable entre cohérence et uniformité. Le routeur fournit au client une liste ordonnée de redirecteurs auxquels il peut envisager de se connecter. Cette liste ordonnée peut changer suivant la disponibilité des redirecteurs et la forme de la charge émanant du client.

Un client reçoit cette liste de redirecteurs et se connecte à un ou plusieurs d'entre eux. Le client se connecte de préférence aux serveurs les plus recommandés par le routeur, mais il peut également prendre en compte toute défaillance survenue. Ainsi, il peut décider d'essayer les redirecteurs d'un centre de données différent si plusieurs tentatives auprès de centres plus proches ont échoué. Pour que ces détails de mise en œuvre soient cachés aux clients Cloud Pub/Sub, il existe un proxy de service entre les clients et les redirecteurs, qui réalise cette optimisation de la connexion pour le compte des clients.

Plan de données – La vie d'un message

Le plan de données reçoit les messages des éditeurs et les envoie aux clients. La meilleure façon de comprendre le plan de données de Cloud Pub/Sub consiste probablement à observer la vie d'un message, du moment où il est reçu par le service au moment où il n'est plus présent dans le service. Suivons donc les étapes du traitement d'un message. Pour les besoins de cette section, nous supposons que le sujet dans lequel le message est publié est associé à au moins un abonnement. En général, un message passe par les étapes suivantes :

  1. Un éditeur envoie un message.

  2. Le message est enregistré dans l'espace de stockage.

  3. Cloud Pub/Sub envoie un accusé de réception à l'éditeur indiquant qu'il a bien reçu le message et garantit sa distribution à tous les abonnements associés.

  4. En même temps qu'il enregistre le message dans son espace de stockage, Cloud Pub/Sub le distribue aux abonnés.

  5. Les abonnés envoient un accusé de réception à Cloud Pub/Sub indiquant qu'ils ont traité le message.

  6. Une fois qu'au moins un abonné de chaque abonnement a accusé réception du message, Cloud Pub/Sub supprime le message de son espace de stockage.

Pour commencer, un éditeur envoie à Cloud Pub/Sub un message dans un sujet. Ce message est chiffré par la couche proxy et envoyé à un redirecteur de publication, auquel l'éditeur est connecté. Pour en garantir la distribution, le message est immédiatement enregistré dans l'espace de stockage. Le redirecteur écrit initialement le message vers N clusters (N étant un nombre impair) et considère le message comme persistant lorsqu'il a été écrit dans au moins ⌈N/2⌉ clusters. Une fois le message persistant, le redirecteur de publication accuse réception du message auprès de l'éditeur et, à ce stade, Cloud Pub/Sub garantit que le message sera distribué à tous les abonnements associés. Un processus en arrière-plan écrit régulièrement les messages qui ne figurent pas dans chacun des N clusters vers tous les clusters où ils manquent.

Au sein de chaque cluster, le message est écrit sur M disques indépendants (où M est un nombre impair), ce qui nécessite que les données figurent sur [M/2] disques pour être considérées comme persistantes sur ce cluster. Au total, tout message publié sera écrit sur au moins [M/2] disques indépendants dans [N/2] clusters avant d'être considéré comme persistant, et finira par être répliqué sur N*M disques.

Le redirecteur de publication possède une liste de tous les abonnements associés à un sujet. Il est responsable de la persistance des messages publiés ainsi que des métadonnées décrivant quels messages ont fait l'objet d'un accusé de réception par chaque abonnement. L'ensemble de messages reçus et stockés par un redirecteur de publication pour un sujet donné, ainsi que ce suivi des messages ayant fait l'objet d'un accusé de réception, est appelé "source des messages à publier". Suivant les exigences de débit pour le sujet, un même éditeur peut envoyer ses messages à plusieurs redirecteurs de publication et stocker des messages dans plusieurs sources des messages à publier. Différents éditeurs travaillant sur le même sujet peuvent également envoyer des messages à différents redirecteurs de publication. Chaque message est envoyé à un seul redirecteur chargé de publication. Cloud Pub/Sub ajuste de manière dynamique, à mesure que le débit change, le nombre de redirecteurs de publication recevant des messages pour un sujet particulier.

Les abonnés reçoivent des messages en se connectant aux redirecteurs d'abonnement, par lesquels les messages émis par les éditeurs sont transmis aux abonnés. Dans le cas d'un abonné pull, le concept de "connexion" signifie l'émission d'une requête pull.Dans le cas d'un abonné push, le concept de "connexion" signifie que son point de terminaison push est enregistré auprès de Cloud Pub/Sub. Une fois qu'un abonnement est créé, il est garanti que tous les messages publiés après ce moment lui seront remis : c'est ce que nous appelons une garantie de point de synchronisation.

Chaque redirecteur d'abonnement doit demander des messages aux redirecteurs de publication disposant de sources des messages à publier pour le sujet. Comme les éditeurs, les abonnés peuvent se connecter à plusieurs redirecteurs d'abonnement pour recevoir des messages. Ainsi, les redirecteurs d'abonnement n'ont pas tous besoin de connaître ou recevoir des messages de chaque source des messages à publier pour un sujet. Il s'agit d'une propriété importante qui contribue à l'évolutivité horizontale de Cloud Pub/Sub. Suivant le débit des messages distribués aux abonnés, Cloud Pub/Sub ajuste de manière dynamique, à mesure que le débit change, le nombre de redirecteurs d'abonnement par l'intermédiaire desquels les abonnés reçoivent des messages liés à un sujet particulier.

Pour demander les messages dont il a besoin, un redirecteur d'abonnement adresse des requêtes à un ou plusieurs redirecteurs de publication disposant de sources des messages à publier dans un sujet donné. Le redirecteur de publication envoie les messages non confirmés au redirecteur d'abonnement, qui les relaie ensuite à un abonné.

Une fois qu'un abonné a traité un message, il envoie un accusé de réception au redirecteur d'abonnement. Le redirecteur d'abonnement relaie cet accusé de réception au redirecteur de publication, qui enregistre l'accusé de réception dans la source des messages à publier. Après que tous les abonnements d'un sujet ont accusé réception d'un message, celui-ci est supprimé de manière asynchrone de la source des messages à publier et de l'espace de stockage.

La vie d'un message est assez complexe, car plusieurs connexions sont nécessaires pour envoyer des messages des éditeurs vers les abonnés. Le flux de messages à travers les connexions entre éditeurs, abonnés et redirecteurs est le suivant :

Garder Cloud Pub/Sub opérationnel

Pour qu'un système distribué tel que Cloud Pub/Sub reste opérationnel et serve efficacement tous les clients, il faut beaucoup de visibilité et de contrôle sur le système. La maintenance du service incombe à nos ingénieurs en fiabilité des sites (SRE, Site Reliability Engineers). Pour Cloud Pub/Sub, ces ingénieurs sont répartis dans le monde entier afin d'être disponibles 24h/24, 7j/7.

Environnements

La maintenance d'un système tel que Cloud Pub/Sub implique tout d'abord de pouvoir tester le logiciel avant son utilisation par les clients. Pour cela, il existe trois environnements Cloud Pub/Sub: test, préproduction et production. Les environnements de test et de préproduction ne reçoivent aucun trafic client. Ils ne contiennent que nos tests et notre surveillance fonctionnant en continu pour détecter tout problème avec les versions. Ces environnements reçoivent les nouvelles versions du logiciel avant la mise en production. La différence entre les environnements de test et de préproduction réside dans le fait que ce dernier est une réplique exacte de ce qui figure actuellement (ou figurera très bientôt) dans l'environnement de production, y compris la version du logiciel et les indicateurs de ligne de commande. L'environnement de test peut comporter des fonctionnalités actives, mais faisant encore l'objet d'un travail de développement, et dont le déploiement est prévu par la suite.

Déploiement

La procédure de déploiement et de test de Cloud Pub/Sub est conçue pour minimiser l'impact potentiel. Voyons les étapes typiques du déploiement d'une nouvelle version de Cloud Pub/Sub :

  1. Vérification de la réussite de tous les tests unitaires et d'intégration

  2. Compilation d'une nouvelle version de tous les serveurs

  3. Déploiement des nouveaux serveurs dans les environnements de test et de préproduction

  4. Exécution des serveurs dans les environnements de test et de préproduction pendant plusieurs jours

  5. S'il n'y a pas de problème connu, déploiement des serveurs dans une version Canary, qui correspond à un sous-ensemble de l'environnement de production hébergeant un trafic client limité

  6. Si aucun problème n'est détecté dans la version Canary, déploiement progressif des serveurs dans l'environnement de production sur plusieurs jours, jusqu'au déploiement complet

Cloud Pub/Sub étant conçu pour résister aux pannes (par exemple grâce à la séparation entre le plan de contrôle et le plan de données), le déploiement de nouvelles versions de serveurs est transparent pour les clients et ne devrait avoir aucun impact sur les performances perçues.

Surveillance

Pour garder Cloud Pub/Sub opérationnel, il est essentiel de détecter et de résoudre automatiquement les problèmes avant qu'ils n'affectent les clients de manière visible. Cela nécessite une surveillance approfondie du système. Les ingénieurs SRE gèrent un ensemble d'indicateurs de niveau de service (SRI, Service level indicators) qui sont des métriques bien définies décrivant le comportement du système. Les métriques peuvent inclure le "temps requis pour effectuer une requête CreateSubscription" ou le "taux d'erreurs générées par les requêtes de publication". Ces métriques sont mesurées de différentes manières. Certaines sont strictement internes à nos redirecteurs et routeurs. Ils mesurent, par exemple, le temps nécessaire pour écrire des messages sur le disque. Au total, il existe 10 SLI et des centaines de métriques complémentaires qui sont utilisées dans le but de surveiller l'état de Cloud Pub/Sub.

Toutes ces mesures permettent de définir des objectifs de niveau de service (SLO, Service Level Objectives) internes, qui sont des objectifs spécifiques pour chaque SLI. Par exemple : "une requête CreateSubscription ne devrait pas prendre plus de cinq secondes". Les ingénieurs SRE sont alertés en cas de non-respect de SLO et ils doivent y répondre dans les cinq minutes.

Un contrat de niveau de service répertorie les SLO qui définissent nos garanties de performance vis-à-vis de nos clients et les conséquences si nous ne les respectons pas. Vous pouvez consulter le contrat de niveau de service de Cloud Pub/Sub.

Nous assurons la maintenance d'un ensemble de tâches jouant le rôle de clients et réalisant des publications et abonnements appelées probers de façon prévisible. Les probers existent à la fois pour le plan de données et le plan de contrôle. Chacun de nos 10 types de probers réalise des actions spécifiques, exactement comme le ferait un client, et mesure la durée de l'opération. Ainsi, nous avons un prober qui génère un abonnement, publie un message et observe le temps nécessaire pour créer l'abonnement et recevoir le message. Si les probers déterminent qu'une des 30 métriques mesurées ne correspond pas aux attentes, les ingénieurs SRE sont alertés.

Les métriques utilisées pour nos serveurs et nos probers sont visibles dans plusieurs tableaux de bord internes, ce que consultent en premier nos ingénieurs SRE lorsqu'ils diagnostiquent des problèmes potentiels. Ces pages permettent d'accéder rapidement aux statistiques et graphiques relatifs à l'ensemble du service, comme illustré ci-dessous. Ils peuvent également être décomposés par sujet, par centre de données ou par tâche individuelle.

Les métriques les plus intéressantes pour les utilisateurs du service sont accessibles via Google Cloud Monitoring. De fait, même nos propres probers disposent de tableaux comme celui-ci :

Commandes

Nous disposons de plusieurs commandes pour nous aider à optimiser les performances de Cloud Pub/Sub. Certaines de ces commandes sont conçues pour l'assistance en cas de panne au niveau d'un centre de données ou d'une machine. Nous pouvons placer des contraintes de routage sur tout ou partie des sujets. Il s'agit de règles spécifiant des ensembles de clients autorisés ou non à se connecter à certains ensembles de redirecteurs. Nous utilisons des contraintes de routage afin de dévier le trafic associé à des tâches de redirecteurs individuels ou à des centres de données entiers si ceux-ci ne fonctionnent pas comme prévu.

Le contrôle de flux est une autre fonctionnalité réglable à notre disposition. Cette fonctionnalité nous permet d'optimiser le débit tout en évitant les surcharges du service. Le contrôle de flux est une forme de gestion du trafic permettant de lisser au cours du temps les pics de charge soudains et inattendus, dans le but d'améliorer la stabilité du service. Le contrôle de flux fonctionne au niveau du système entier, ou bien par sujet ou par abonné, pour limiter le nombre de messages ou le nombre d'octets transférés ou en attente. Dans ce contexte, "en attente" signifie que le message a été remis au client, mais que celui-ci n'en a pas encore accusé réception. Le contrôle de flux et les contraintes de routage nous permettent d'optimiser les performances de Cloud Pub/Sub sans que les clients n'aient à s'inquiéter de ces détails de bas niveau.

Résumé

Les avantages en termes d'évolutivité, de disponibilité et de latence d'un service tel que Cloud Pub/Sub définissent la proposition de valeur pour les clients qui envisagent de passer à des services gérés dans le cloud. Un service de messagerie asynchrone doit être créé avec, dès le départ, ces fonctionnalités comme points de référence. Forte d'une expérience de plus de 10 ans dans la distribution fiable et rapide de nombreux messages, l'équipe Cloud Pub/Sub a développé et continue de maintenir un service capable de répondre aux exigences des produits les plus fondamentaux de Google. Désormais, ce même service est disponible pour tous nos clients externes qui souhaitent envoyer leurs messages dans le monde entier sans se soucier de savoir si leur système de messagerie peut gérer 2, 10 ou 100 fois leur charge actuelle.

Glossaire

Terme Description
cluster Regroupement logique de machines partageant généralement le même domaine de défaillance (par exemple, un réseau local partagé et une alimentation partagée)
Plan de contrôle Couche de Cloud Pub/Sub qui gère l'affectation des éditeurs et des abonnés aux serveurs du plan de données
Plan de données Couche de Cloud Pub/Sub qui gère le transfert de messages entre les éditeurs et les abonnés
Redirecteur Serveur du plan de données
Service global Service n'exigeant pas des clients qu'ils connaissent ou spécifient la région (ou le centre de données) à laquelle se connecter pour l'utiliser
Évolutif horizontalement Capacité d'un service à gérer de manière transparente une charge accrue en augmentant le nombre d'instances de composants du service
Message Données qui transitent par Cloud Pub/Sub
Distance réseau Mesure de la latence de la connexion entre deux points
Prober Tâche jouant le rôle d'un client et effectuant de manière prévisible une ou plusieurs actions sur les serveurs Cloud Pub/Sub
Sources des messages à publier Ensemble de messages reçus et stockés par un redirecteur de publication, accompagné d'un ensemble d'ID de messages confirmés par tous les abonnements associés
Service de publication et d'abonnement (Cloud Pub/Sub) Service de messagerie où les expéditeurs de messages sont découplés des destinataires
Éditeur Client de Cloud Pub/Sub qui crée des messages et les envoie (les publie) dans un sujet spécifié
Routeur Serveur dans le plan de contrôle
Contraintes de routage Liste de règles indiquant quels redirecteurs les routeurs peuvent envoyer aux clients en tant que points de terminaison auxquels se connecter
Contrat de niveau de service Liste des SLO définissant les performances d'un système garanties aux clients et décrivant les conséquences si ces objectifs ne sont pas respectés
Indicateur de niveau de service (SLI) Métrique bien définie décrivant le comportement du système
Objectif de niveau de service (SLO) Objectif spécifique pour un indicateur de niveau de service
Abonné Client de Cloud Pub/Sub recevant des messages sur un abonnement spécifié
Abonnement Entité nommée qui représente un intérêt à recevoir tous les messages associés à un sujet particulier
Garantie de point de synchronisation Heure à laquelle un abonné est créé, à partir de laquelle tous les messages publiés seront distribués à cet abonné
Sujet Entité nommée qui représente un flux de messages
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…