Ce guide présente les fonctionnalités de fiabilité de Pub/Sub et vous offre une vue d'ensemble. Ce document traite des sujets suivants:
- Pourquoi Pub/Sub ?
- Basculement
- Optimiser l'expérience des éditeurs
- Ajuster les abonnés
- Utiliser un instantané et rechercher des déploiements sécurisés
Pourquoi Pub/Sub ?
En tant que paradigme de messagerie, la méthode "publish-subscribe" est conçue pour dissocier les producteurs de messages des consommateurs de ces messages. Au lieu d'envoyer des requêtes directes aux producteurs de données, ces producteurs publient ces données sur un service Pub/Sub tel que Pub/Sub. Le service distribue ces messages de manière asynchrone aux consommateurs intéressés qui se sont abonnés.
Résultat : le service absorbe toutes les subtilités de la recherche de consommateurs intéressés par les données. Le service gère également la fréquence à laquelle les clients reçoivent les données, en fonction de leur capacité. Le découplage permet aux producteurs de données d'écrire des messages à grande échelle avec une faible latence, indépendamment du comportement des consommateurs.
Pub/Sub offre une distribution des messages hautement évolutive et fiable. Bien que le service gère une grande partie de cette procédure automatiquement, vous contrôlez différents aspects de vos éditeurs et de vos abonnés qui peuvent affecter la disponibilité et les performances. Le reste de ce guide fournit des détails sur ces aspects
Basculement
Pub/Sub est un service mondial: les sujets et les abonnements ne sont pas intrinsèquement liés à des régions spécifiques, et les messages circulent dans le service Pub/Sub entre régions si nécessaire. Lorsque vous utilisez le point de terminaison mondial, pubsub.googleapis.com, les éditeurs et les abonnés se connectent à la région du réseau la plus proche où Pub/Sub s'exécute. Lorsque vous utilisez des points de terminaison régionaux, par exemple
us-central1-pubsub.googleapis.com, les éditeurs et les abonnés se connectent à Pub/Sub dans la région spécifiée. Lorsque vous exécutez des éditeurs ou des abonnés en dehors de Google Cloud, il est préférable d'utiliser des points de terminaison régionaux afin de vous assurer que les messages circulent systématiquement entre les régions attendues. Le reste de cette section explique comment créer des sujets et des abonnements. Vous découvrirez également comment placer des éditeurs et des abonnés afin de permettre différents types de basculement et de redondance des données.
Sémantique de basculement par défaut
Prenons l'exemple d'un sujet avec un seul sujet et un seul abonnement. Les éditeurs sont situés en Australie et aux États-Unis, tandis que les abonnés se trouvent en Australie et en Europe. Dans le cas où tous les abonnés disposent d'une capacité suffisante pour recevoir des messages, le flux de messages se présente comme suit:
Les P représentent les éditeurs, les S représentent les abonnés. L'hexagone bleu représente le service Pub/Sub. Les cylindres représentent les emplacements où les messages sont stockés (les messages sont toujours conservés dans plusieurs zones de la région où ils sont publiés). Pub/Sub préfère envoyer des messages dans la région où ils ont été publiés lorsque les abonnés sont disponibles. Sinon, il envoie les messages à la région la plus proche du réseau avec des abonnés disposant d'une capacité suffisante. Par conséquent, comme illustré ci-dessus, les messages publiés aux États-Unis sont distribués aux abonnés en Europe, tandis que les messages publiés en Australie restent en Australie.
Examinons ce qui se passe dans différents scénarios d'échec.
Les abonnés en Europe ne sont pas disponibles
Supposons que les abonnés en Europe ont été désactivés ou plantent fréquemment et ne parviennent pas à maintenir une connexion à Pub/Sub. Dans ce cas, le service commence à distribuer des messages aux abonnés situés en Australie:
Les abonnés en Australie et en Europe ne sont pas disponibles
Si tous les abonnés ne sont pas disponibles, Pub/Sub stocke les messages jusqu'à la durée de conservation des messages configurée.
Une fois les abonnés reconnectés, les messages sont distribués, sauf si l'indisponibilité dépasse la durée de conservation configurée. Par défaut, la durée de conservation des messages d'abonnement est définie sur sept jours. Vous pouvez également configurer la conservation des messages par sujet pendant 31 jours maximum. Ne choisissez pas une durée de conservation des messages inférieure à la latence maximale attendue ou tolérée.
Pub/Sub n'est pas disponible en Europe
Bien que cela soit rare, vous voudrez peut-être également gérer les cas où Pub/Sub lui-même n'est pas disponible. L'indisponibilité de Pub/Sub se traduit par des périodes étendues d'erreurs inattendues sur les requêtes de publication ou d'abonnement, ou par l'impossibilité de distribuer des messages publiés aux abonnés. Par exemple, si Pub/Sub était en région en Europe, le scénario ressemble beaucoup à celui des abonnés:
Notez que dans ce cas, les abonnés en Europe ne basculent pas vers une autre région, même s'ils utilisent le point de terminaison mondial. Pub/Sub ne bascule pas intentionnellement automatiquement. Imaginez que les abonnés eux-mêmes entraînent un problème inattendu dans Pub/Sub qui entraîne une indisponibilité. Un tel problème est considéré comme une indisponibilité majeure. Toutefois, le champ d'application de l'impact de la panne peut être limité à la région à laquelle les abonnés se sont connectés. Si le service leur permettait de basculer vers une autre région, les abonnés pouvaient également être indisponibles à cet endroit, ce qui pouvait entraîner une défaillance en cascade sur l'ensemble du service.
Les éditeurs en Australie ne sont pas disponibles
Si les éditeurs d'une région deviennent indisponibles, les messages déjà publiés sont toujours distribués aux abonnés les plus proches:
À terme, tous les messages sont consommés et confirmés par les abonnés. Lors de l'envoi de messages, Pub/Sub tente de réduire la distance réseau. Par conséquent, les abonnés en Australie peuvent ne plus recevoir de messages s'ils disposent d'une capacité suffisante pour traiter tous les messages publiés aux États-Unis.
Pub/Sub n'est pas disponible aux États-Unis
Pub/Sub écrit de manière synchrone les messages dans plusieurs zones d'une région. Par conséquent, une panne zonale ne suffit pas pour empêcher la distribution des messages. Toute la région doit être indisponible. Si Cloud Pub/Sub devient indisponible dans une région où les éditeurs envoient des messages, il se peut que les messages de cette région ne soient pas distribués tant que le service n'est pas entièrement restauré:
Le message est toujours distribué (en supposant que la durée de conservation des messages n'ait pas expiré), retardée par la durée de l'interruption. Comme pour les abonnés, les éditeurs situés aux États-Unis ne font pas de basculement vers une autre région en cas de défaillance du service. Ce comportement permet d'éviter les risques de défaillances d'une région à l'autre en raison d'un éditeur ou d'un abonné défaillant.
Isolation
La sémantique de basculement par défaut affecte l'isolation de données et l'impact de l'indisponibilité des éditeurs, des abonnés ou de Pub/Sub lui-même sur le flux de messages. Votre cas d'utilisation peut nécessiter différents niveaux d'isolation, par exemple pour garantir la distribution intrarégionale de tous les messages.
Si vous ne souhaitez pas isoler les données, la sémantique de basculement par défaut est suffisante. Vous devez créer un seul sujet et un seul abonnement, et placer les éditeurs et les abonnés dans toutes les régions souhaitées. Si les abonnés deviennent indisponibles ou que Pub/Sub est indisponible dans la région à laquelle ils se connectent, la distribution bascule vers les abonnés d'une autre région.
Pour l'isolation régionale, qui garantit que les données ne quittent pas une région, créez un sujet et un abonnement afin de gérer les messages dans chaque région. Recherchez les éditeurs et les abonnés dans chacune de ces régions, et demandez-leur de publier le sujet et l'abonnement régionaux correspondants, respectivement. Vous devez également utiliser des points de terminaison régionaux pour vous assurer que les données ne se déplacent que dans la région. En cas de défaillance de l'éditeur, de l'abonné ou de Pub/Sub dans une seule région, la distribution des messages s'arrête dans cette région. La distribution des messages sur les sujets et les abonnements pour les autres régions n'est pas affectée.
Enfin, l'isolation zonale, qui garantit que les données restent dans une seule zone, n'est pas possible dans Pub/Sub. Si vous souhaitez que chaque zone soit indépendante, utilisez Pub/Sub Lite.
Basculement et redondance contrôlés par le client
La sémantique de basculement par défaut de Pub/Sub peut ne pas garantir que les messages peuvent toujours circuler des éditeurs vers les abonnés en cas d'interruption quelque part. Les pannes peuvent survenir à différents endroits, y compris chez vos clients, dans le service où vos éditeurs ou abonnés s'exécutent, sur le réseau ou même rarement dans Pub/Sub. Si vos services doivent être résilients à de telles pannes, vous devez implémenter vos propres redondances. En général, ces redondances impliquent l'utilisation de plusieurs instances de clients éditeurs et abonnés, chacune utilisant un point de terminaison régional différent.
Vous souhaitez peut-être être résilient à deux niveaux d'impact différents : zonal ou régional. Voici les options de configuration pour chacun d'eux.
Résilience zonale
Pub/Sub intègre une réplication interzone. Aucune action particulière n'est requise pour gérer les pannes affectant une seule zone qui affectent le service lui-même. Toutefois, pour assurer la résilience aux pannes de vos clients ou de votre réseau, il est préférable d'exécuter les éditeurs et les abonnés avec une capacité suffisante dans plusieurs zones de la région. Si une seule zone est indisponible, les clients de l'autre zone peuvent prendre en charge le trafic et traiter les messages. Il est recommandé de ne pas déployer les modifications à ces clients simultanément afin que, si un bug est introduit, les autres zones non modifiées puissent continuer à traiter les messages.
Résilience régionale
Afin de résister aux défaillances régionales, configurez des redondances supplémentaires au niveau de vos éditeurs et de vos abonnés. Vous pouvez gérer les éditeurs et les abonnés dans plusieurs régions pour faire face aux risques de pannes au niveau de ces clients ou de la mise en réseau.
Si vous souhaitez être résilient face aux défaillances Pub/Sub potentielles dans une région, vous devez disposer d'un mécanisme de basculement prêt à faire face à une telle interruption. Les approches possibles sont un compromis entre la latence de distribution des messages de bout en bout et votre coût.
Pour minimiser la latence dans le cas où le coût ne pose pas de problème, la meilleure stratégie consiste à toujours publier et s'abonner simultanément dans différentes régions. Commencez par choisir le nombre de régions dans lesquelles vous souhaitez bénéficier de la redondance. Ensuite, bien que cela ne soit pas absolument nécessaire, vous pouvez configurer un sujet et un abonnement pour chacune de ces régions.
Chaque éditeur crée autant de clients éditeurs que de régions (une pour chaque région) et utilise un point de terminaison régional différent pour s'assurer que les messages sont dirigés vers des régions distinctes. Si vous utilisez des sujets distincts, chaque client éditeur doit publier dans le sujet par région correspondant. Pour chaque message, l'éditeur appelle la publication sur chaque client. Avec les publications redondantes, il n'est pas nécessaire de réessayer les publications si une seule échoue.
De même, chaque abonné crée ce nombre de clients abonnés (un pour chaque région) et utilise un point de terminaison régional pour se connecter à une autre région. Si vous utilisez des abonnements différents pour chaque région, chaque client abonné doit utiliser l'abonnement correspondant. Notez que les régions utilisées pour les éditeurs et les abonnés ne doivent pas nécessairement être identiques. Les abonnés reçoivent des messages sur les trois abonnements et les traitent.
Cette configuration présente plusieurs fonctionnalités clés et exigences:
- Toute indisponibilité dans une seule région n'affecte pas le traitement des messages déjà publiés, ni ceux publiés pendant l'interruption. Étant donné que les messages ont été publiés dans plusieurs régions, ils restent disponibles dans d'autres régions en cas de panne d'une région. Pendant l'interruption, les appels de publication échouent dans la région affectée, mais réussissent dans les autres.
- La latence de traitement des messages n'est pas affectée tant que les régions dans lesquelles les messages sont acheminés sont disponibles.
- Le traitement du message doit être idempotent. Étant donné que chaque message est distribué plusieurs fois, le traitement des messages doit être résilient aux doublons. En cas de panne régionale, certains de ces doublons peuvent apparaître beaucoup plus tard que la première distribution du message. Ces doublons provenaient probablement d'une autre région qui n'a pas subi de panne.
L'exécution avec ce type de redondance offre la plus haute résilience à tous les types de pannes. Pour les services Google internes qui reposent sur Pub/Sub et nécessitent la plus haute disponibilité, cette configuration est préférable. Cette configuration implique toutefois de multiplier le coût de distribution des messages par le nombre de régions utilisées. Le coût d'utilisation du réseau interrégional pour les messages devant être déplacés d'une région à une autre entraîne également un coût supplémentaire.
Une autre approche de la redondance consiste à ne basculer que lorsque les requêtes échouent ou que les messages ne circulent pas comme prévu entre les éditeurs et les abonnés. Dans ce scénario, vous disposez d'une région principale vers laquelle vous dirigez vos éditeurs et abonnés via des points de terminaison régionaux. Comme précédemment, il ne doit pas nécessairement s'agir de la même région. Vous disposez également d'une région de remplacement pour les éditeurs et les abonnés, qui est utilisée lorsque la région principale est indisponible.
Les éditeurs ne publient du contenu que dans la région principale (via le point de terminaison régional) lorsque ses requêtes sont bien envoyées. Lorsqu'il est établi que la région est en panne, les éditeurs commencent à publier dans la région de remplacement. Il existe deux façons de déterminer que la région est indisponible et de basculer. Elle peut être exécutée manuellement, et la configuration est mise à jour de manière dynamique dans les éditeurs. Les éditeurs peuvent également mettre à jour la configuration eux-mêmes si le taux d'erreur dans les requêtes de publication est suffisamment élevé.
Les abonnés doivent toujours se connecter à la région principale via le point de terminaison régional. Vous pouvez décider que l'abonné peut utiliser la région de remplacement avec un ou plusieurs des déclencheurs suivants:
- Abonnez-vous toujours à la région de remplacement. Dans ce cas, l'abonné conserve une connexion à la fois à la région principale et à la région de remplacement à tout moment. Vous pouvez utiliser les mêmes régions pour la région principale et la création de remplacement pour les éditeurs et les abonnés. Dans ce cas, l'abonné ne doit recevoir les messages via la région de sauvegarde que si l'éditeur a basculé.
- Détectez et basculez manuellement les abonnés vers la région de remplacement via une configuration. Si vous détectez une panne, vous pouvez basculer vers la région de secours, puis revenir à la région principale une fois la panne résolue.
- Basculez en cas d'erreur d'abonné. Si les requêtes d'abonné renvoient des erreurs, vous pouvez vous en servir pour indiquer que vous devez basculer vers la région de remplacement. Notez que les bibliothèques clientes Pub/Sub relancent en streaming les requêtes d'extraction en interne lors d'erreurs temporaires. Il est donc possible que vous ne puissiez pas détecter de longues périodes d'erreurs inattendues. De plus, le taux d'erreur d'extraction en streaming devrait être de 100%, même en fonctionnement normal.
- Basculement en cas de délais inattendus de l'abonné sans réception de messages Si les messages sont publiés de manière cohérente, les abonnés peuvent toujours en recevoir. S'ils passent un certain temps sans recevoir de messages, il peut y avoir un problème côté abonnement dans Pub/Sub dans la région principale. Ce problème est résolu en basculant vers la région de remplacement.
Parmi les quatre options proposées, la première est idéale. Une connexion d'abonné ne coûte rien si aucun message n'y transite. Le seul coût est dans l'empreinte de l'instance supplémentaire de la bibliothèque cliente des abonnés, qui peut être négligeable. Vous devez également tenir compte du nombre de connexions pull en streaming par région.
L'avantage de ce second modèle est qu'il n'y a pas de multiplicateur pour le coût Pub/Sub, car les messages ne sont publiés qu'une seule fois. Toutefois, pour certains types d'interruptions, les messages publiés avant le début de l'interruption peuvent ne pas être disponibles avant la résolution de l'interruption. Les messages stockés dans une région indisponible peuvent ne pas être distribués aux abonnés, quel que soit l'endroit où ils sont connectés. Les messages publiés pendant l'indisponibilité vers la région de remplacement peuvent être disponibles. En outre, il peut y avoir une période d'indisponibilité avec des taux d'erreur plus élevés pour les éditeurs ou les abonnés. Cela dépend de la méthode utilisée pour détecter une panne et du temps de basculement vers la région de remplacement.
Quelle que soit l'option que vous choisissez, sachez que cette opération peut interagir avec les fonctionnalités de Pub/Sub. La livraison commandée et la livraison "exactement une fois" offrent toutes deux des garanties au sein d'une région. Par exemple, si vous utilisez la technique de redondance de basculement, la distribution des messages n'est garantie que pour les messages publiés dans la même région. L'abonné peut recevoir des messages publiés dans la région de remplacement avant ceux publiés dans la région principale, même s'ils ont d'abord été publiés dans la région principale.
Optimiser l'expérience des éditeurs
Quelles que soient les options de basculement que vous choisissez, vous devez effectuer des réglages supplémentaires au sein des éditeurs. Le réglage du comportement de l'éditeur garantit des performances optimales en cas de charge élevée. Les messages par lot sont un moyen de compenser la latence à moindre coût, mais ce n'est pas une problématique en termes de fiabilité et n'est donc pas abordé ici. Concentrez-vous plutôt sur certains des autres paramètres utiles pour optimiser la fiabilité, y compris les paramètres de nouvelle tentative et les paramètres de contrôle de flux.
Les publications peuvent échouer pour différentes raisons, y compris des facteurs temporaires tels que l'indisponibilité du réseau ou ceux qui nécessitent une intervention de l'utilisateur, comme des modifications d'autorisation. La bibliothèque cliente Pub/Sub relance les erreurs temporaires à l'aide des paramètres spécifiés dans les paramètres de nouvelle tentative. Ces paramètres contrôlent le comportement de l'intervalle exponentiel entre les tentatives lors de nouvelles tentatives de publication de RPC qui échouent pour des raisons temporaires. Bien que les paramètres par défaut puissent généralement bien fonctionner dans la plupart des scénarios, il peut arriver que vous souhaitiez ajuster ces valeurs.
Les deux propriétés que vous souhaiterez probablement régler sont le délai d'expiration RPC initial et le délai d'expiration total. Le délai d'attente RPC initial correspond à la durée de la première publication RPC à terminer. En cas d'échec ou de dépassement du délai avant expiration d'un RPC, une autre tentative est rallongée jusqu'à ce que le nombre total de requêtes ou le délai d'expiration total soit dépassé.
Le délai d'expiration initial peut être ajusté si votre éditeur est limité par le réseau ou éloigné du centre de données Google Cloud le plus proche qui exécute Pub/Sub. Les contraintes réseau peuvent être des limitations de débit de la machine sur laquelle l'éditeur s'exécute, ou être liées au fonctionnement d'autres services qui s'exécutent sur la même machine et sont gourmandes en réseau. Lorsque le délai avant expiration est trop court, les RPC initiaux peuvent échouer à plusieurs reprises, ce qui entraîne des tentatives supplémentaires (avec des délais plus longs) pour la publication réussie. La nécessité répétée de nouvelles tentatives augmente la latence de publication. Dans ce cas, l'augmentation du délai initial peut accélérer les publications.
Si la connexion réseau n'est pas fiable, il peut être utile d'augmenter le délai avant expiration total, ainsi que le délai d'expiration initial. L'augmentation du délai avant expiration du délai de publication permet au RPC de publier plus de temps. Lorsque les RPC de publication échouent systématiquement avec des erreurs de dépassement de délai, envisagez d'ajuster ces valeurs.
Les erreurs de dépassement de délai continu lors de la publication peuvent également indiquer la nécessité d'ajuster le contrôle du flux de l'éditeur. Ces paramètres vous permettent de vous assurer que vos éditeurs sont résilients aux pics de trafic entrant qui génèrent d'autres messages à envoyer à Pub/Sub. Une augmentation importante du nombre de requêtes sortantes peut surcharger le processeur, la mémoire ou la capacité du réseau de l'éditeur. Lorsque la publication est surchargée, elle ne peut pas traiter les requêtes de publication ni les réponses avant l'expiration du délai. Cela entraîne l'augmentation du nombre de requêtes de publication et, au final, le dépassement du délai d'inactivité total. Le contrôle de flux d'éditeur limite le nombre de messages ou d'octets pouvant être en attente sans réponse de la requête de publication. Limiter le nombre de requêtes de cette manière maintient l'utilisation des ressources à un niveau gérable, même pendant les pics Selon le mode de fonctionnement de votre éditeur, vous pouvez autoriser les RPC ultérieurs à publier la capacité en autorisant la publication à bloquer d'autres requêtes. Vous pouvez également transmettre une requête aux appelants de votre service en laissant le contrôle de flux renvoyer une erreur une fois la capacité atteinte. Vous configurez la manière dont la bibliothèque cliente de l'éditeur répond avec le comportement de dépassement de limite.
Ajuster les abonnés
Vous devrez peut-être aussi régler les abonnés pour vous assurer qu'ils fonctionnent de manière fiable. Comme pour les éditeurs, vous pouvez ajuster les paramètres de contrôle de flux des abonnés pour éviter de les submerger. La bibliothèque cliente des abonnés utilise le mode pull en streaming, où le client ouvre un flux persistant sur le serveur et celui-ci envoie des messages dès qu'ils sont disponibles. En cas d'augmentation importante du nombre de messages publiés, l'abonné peut recevoir plus de messages qu'il ne peut en traiter. Une fois le contrôle de flux en place, le nombre de messages non confirmés en attente pour le client est limité. Cela réduit le nombre de messages traités simultanément et retarde leur traitement sur une période plus longue. La répartition de la charge permet aux abonnés de respecter les limites de ressources qui affectent le traitement des messages, ce qui peut entraîner un effet de cascade qui se traduit par une incapacité à traiter les messages.
À lui seul, le contrôle de flux est suffisant si vous ne vous attendez à ce que la quantité de données à traiter augmente en conséquence. Si le trafic augmente généralement avec le temps en raison d'une utilisation accrue, le contrôle de flux protège les abonnés. Toutefois, il est possible qu'un volume de messages en attente continue de s'accumuler et que les messages ne puissent pas être distribués avant la fin de la durée de conservation des messages. Dans ce cas, vous pouvez également configurer l'autoscaling pour augmenter le nombre d'abonnés en réponse à un nombre croissant de messages non confirmés. La configuration dépend de la plate-forme de calcul que vous utilisez pour vos abonnés. Par exemple, l'autoscaler de Google Compute Engine vous permet d'effectuer un scaling basé sur des métriques telles que le nombre de messages non distribués. L'autoscaling et le contrôle de flux vous permettent de vous assurer que vos abonnés sont résilients aux autres pics à court terme du débit des messages et à une croissance à plus long terme qui nécessite davantage de puissance de calcul.
Utiliser des instantanés et rechercher des déploiements sécurisés
La perte de messages est généralement un événement catastrophique. Pub/Sub garantit une distribution "au moins une fois" pour tous les messages publiés. Toutefois, le traitement approprié de ces messages dépend du comportement des abonnés. Si les messages sont correctement confirmés, Pub/Sub ne les redistribue pas. Par conséquent, un bug introduit dans le nouveau code d'abonné que vous déployez et qui accuse réception des messages sans les avoir correctement traités peut entraîner une perte de messages due à l'abonné. Pub/Sub propose la fonctionnalité d'instantanés et de recherche, qui peut vous aider à traiter correctement chaque message, même en cas de bug des abonnés.
Le modèle de déploiement de chaque abonné doit être le suivant:
Le temps d'attente avant de déterminer si le nouvel abonné fonctionne peut varier en fonction de votre cas d'utilisation. Le seul moyen de quitter le flux d'étapes est lorsqu'un abonné est considéré comme fonctionnel, auquel cas l'instantané peut être supprimé.
L'utilisation d'instantanés et de recherches n'a pas vocation à remplacer les bonnes pratiques liées à la première exécution d'un logiciel dans un environnement hors production et à un déploiement progressif en production. Elles fournissent simplement un niveau de protection supplémentaire pour garantir un traitement fiable des données. En contrepartie, la recherche de l'instantané peut entraîner une double distribution des messages traités par votre abonné. Cependant, étant donné que Pub/Sub offre une sémantique de distribution de type "au moins une fois" par défaut, vos abonnés sont déjà résilients à la remise des messages.