Bonnes pratiques de publication dans un sujet Pub/Sub

En publication, un client éditeur envoie un message dans un sujet Pub/Sub. Voici quelques bonnes pratiques pour publier des messages dans Pub/Sub.

Dans ce document, nous partons du principe que vous connaissez déjà le processus de publication de messages dans un sujet Pub/Sub.

Si vous débutez avec Pub/Sub, consultez l'un des guides de démarrage rapide et découvrez comment exécuter Pub/Sub à l'aide de la console, gcloud CLI, ou des bibliothèques clientes.

Passez à l'action en fonction de la réponse de la publication

Lorsque l'appel de publication de la bibliothèque cliente de haut niveau se termine, il renvoie un objet futur contenant le résultat de l'opération. Pour éviter de bloquer les requêtes de publication individuelles, gérez le résultat de manière asynchrone. Vous devez déterminer la meilleure façon de gérer l'échec pour votre cas d'utilisation. Vous disposez notamment des possibilités suivantes :

  • Consignez l'erreur et ne faites rien d'autre (si votre cas d'utilisation ne nécessite pas la publication réussie de tous les messages).
  • Réessayez de publier en cas d'échec potentiellement temporaire, comme une erreur Deadline exceeded.
  • Conservez le message dans un fichier ou un espace de stockage pour réessayer de le publier ultérieurement, en particulier en cas d'erreur nécessitant une intervention de l'utilisateur, comme Not found ou Permission denied.
  • Propagez les erreurs au service en amont qui vous a envoyé le message que vous avez tenté de publier.

Si vous pensez que Pub/Sub ne distribue pas les messages comme prévu à vos abonnés, vérifiez que vous suivez les résultats des publications et qu'elles ont réussi.

Joindre un abonnement ou activer la conservation des sujets avant de commencer la publication

Si vous commencez à publier dans un sujet auquel aucun abonné n'est associé, les messages ne sont pas conservés. Ces messages ne peuvent pas être distribués aux abonnements associés ultérieurement. Par conséquent, avant de commencer à publier des messages, effectuez l'une des opérations suivantes :

Configurer la messagerie par lots

Dans Pub/Sub, la messagerie par lots fait référence au processus de combinaison de plusieurs messages en un seul lot qui est publié dans une seule requête de publication. Si vous utilisez des bibliothèques clientes pour publier vos messages, le traitement par lots est activé par défaut. Le traitement par lots (ou le regroupement) des messages permet à l'éditeur d'améliorer son efficacité et d'envoyer des messages avec un débit plus élevé. Le traitement par lots réduit le coût de publication des données. Toutefois, il crée également une latence pour les messages individuels, car l'éditeur attend que le lot soit rempli avant de le publier.

La latence dans Pub/Sub peut être de deux types :

  • La latence de bout en bout correspond au temps nécessaire pour qu'un message soit publié par un éditeur et distribué aux abonnés correspondants pour traitement.

  • La latence de publication correspond au temps nécessaire pour publier un message.

Lorsque vous utilisez le traitement par lots, l'augmentation des deux types de latence est un compromis pour améliorer l'efficacité et le débit.

Vous pouvez traiter les messages par lots dans une bibliothèque cliente en fonction de la taille de la requête de message, du nombre de messages et du temps. Lorsque vous configurez les paramètres de traitement par lots, vous pouvez trouver le juste équilibre entre le coût, le débit et la latence pour répondre à votre cas d'utilisation.

Les valeurs par défaut des variables de messagerie par lots et les noms des variables peuvent différer d'une bibliothèque cliente à l'autre. Vous pouvez spécifier une, deux ou les trois valeurs dans la bibliothèque cliente. Si l'une des valeurs des variables de messagerie par lots est atteinte, la bibliothèque cliente publie le lot de messages suivant.

Pour configurer la messagerie par lots pour un client éditeur, consultez la section Traiter les messages par lots dans une requête de publication.

Configurer le contrôle de flux pour les pics de messages temporaires

Si le client éditeur doit traiter un grand nombre de messages, les requêtes de publication peuvent commencer à s'accumuler en mémoire jusqu'à ce que les messages ne puissent plus être publiés avec une erreur Deadline exceeded.

Pour gérer les pics temporaires de publication de messages, vous pouvez utiliser le contrôle de flux dans les paramètres de votre éditeur. Le contrôle de flux côté éditeur empêche les ressources du client éditeur d'être submergées par un trop grand nombre de requêtes en attente. Si le client éditeur est limité en termes de mémoire, de processeur ou de threads, un grand nombre d'erreurs Deadline exceeded sont générées.

Pour configurer le contrôle de flux dans la bibliothèque cliente, définissez des valeurs appropriées pour les variables nombre maximal de messages en attente et nombre maximal d'octets de messages en attente. Ces valeurs équilibrent le débit des messages et la capacité du système.

Pour vérifier si votre bibliothèque cliente est compatible avec le contrôle de flux de l'éditeur et pour configurer le, consultez la section Contrôle de flux.

Comprendre la bande passante et la latence de votre réseau

Le débit de votre éditeur est limité par la bande passante de votre réseau et le nombre de requêtes envoyées. Si votre bande passante est bonne, mais que la latence de votre réseau est élevée, vous ne devez pas surcharger le système avec de nombreuses petites requêtes. Le contrôle de flux côté éditeur peut vous aider à résoudre les problèmes de réseau côté client.

Le débit de votre éditeur est également lié au processeur et à la mémoire. Plus de cœurs de machine disponibles vous permettent de définir un nombre de threads plus élevé pour un meilleur débit de publication. Pour en savoir plus sur l'optimisation des performances de diffusion, consultez la section Tester les clients Cloud Pub/Sub pour optim101}iser les performances de diffusion.

Ajuster les variables de requête de nouvelle tentative pour les publications ayant échoué

Lorsqu'un message est publié par un client éditeur, vous pouvez constater des échecs de publication. Ces échecs sont généralement dus à des goulots d'étranglement côté client, tels que des processeurs de service insuffisants, un mauvais état de thread ou un encombrement du réseau. La publisher retry policy détermine le comportement en cas d'échec de distribution des messages. La stratégie de nouvelle tentative définit le nombre de fois que Pub/Sub tente de distribuer le message et la durée entre chaque tentative.

Par exemple, dans la bibliothèque cliente Java pour Pub/Sub, le client éditeur contient les valeurs suivantes :

  • initialRetryDelay. Délai initial pendant lequel l'éditeur attend avant de réessayer une opération de publication. La valeur par défaut est 100 milliseconds.

  • retryDelayMultiplier. Facteur de multiplication utilisé pour calculer le délai entre les nouvelles tentatives. La valeur par défaut est 4. Cela signifie que le délai entre les nouvelles tentatives peut atteindre 100 milliseconds * 4 = 400 milliseconds pour la deuxième tentative et 400 milliseconds * 4 = 1600 milliseconds pour la troisième.

  • maxRetryDelay. Délai maximal pendant lequel l'éditeur attend avant de réessayer une opération de publication. La valeur par défaut est 60 seconds.

  • initialRpcTimeout. Délai avant expiration initial pendant lequel l'éditeur attend la fin de l'appel RPC. La valeur par défaut est 5 seconds.

  • rpcTimeoutMultiplier. Facteur de multiplication utilisé pour calculer le délai avant expiration du RPC. La valeur par défaut est 4.0. Cela signifie que le délai avant expiration de l'appel RPC peut atteindre 5 seconds * 4 = 20 seconds pour la deuxième tentative et 10 seconds * 4 = 40 seconds pour la troisième.

  • maxRpcTimeout. Délai avant expiration maximal pendant lequel l'éditeur attend la fin de l'appel RPC. La valeur par défaut est 600 seconds.

  • totalTimeout. Délai avant expiration total pour l'opération de publication. Cela inclut le temps d'attente de la fin de l'appel RPC et le temps d'attente entre les nouvelles tentatives. La valeur par défaut est 600 seconds.

N'ajustez les valeurs spécifiées que si vous constatez que les paramètres de nouvelle tentative par défaut ne sont pas suffisants pour votre cas d'utilisation. Par exemple, la publication d'un grand nombre de messages ne nécessite pas d'augmenter les valeurs initialRetryDelay et maxRetryDelay. Toutefois, vous pouvez ajuster le contrôle de flux et le traitement par lots dans de telles circonstances. Si vous publiez à partir d'une connexion Internet instable ou d'une connexion dont la bande passante est limitée, vous pouvez tester les valeurs des variables initialRpcTimeout, maxRpcTimeout et rpcTimeoutMultiplier. Pour connaître les valeurs recommandées, consultez la section Les opérations de publication échouent avec DEADLINE_EXCEEDED.

Utiliser une règle de stockage des messages pour garantir la localité des données

La règle de stockage des messages des sujets Pub/Sub permet de garantir que les messages publiés dans un sujet ne sont jamais conservés en dehors d'un ensemble de Google Cloud régions que vous spécifiez, quelle que soit l'origine des requêtes de publication.

Utilisez la règle de stockage des messages pour spécifier une liste de Google Cloud régions dans lesquelles Pub/Sub est autorisé à stocker des données de message sur disque. Lorsqu'un message est publié dans une région qui ne figure pas dans cette liste, la requête est transmise à la région autorisée la plus proche pour traitement. La règle peut être configurée sur un sujet ou en tant que règle d'administration pour un projet, un dossier de projet ou une organisation entière. Lorsqu'une règle d'administration est configurée, la règle de sujet individuelle ne peut être modifiée que de manière à ne pas enfreindre la règle d'administration.

Par exemple, une entreprise opérant en Europe peut utiliser la règle de stockage des messages pour s'assurer que toutes les données sont stockées dans des régions de l'UE afin de se conformer aux lois locales.

Pour en savoir plus, consultez la section Configurer des règles de stockage des messages.

Bonnes pratiques pour la messagerie ordonnée dans la publication

Si vous utilisez le tri des messages, assurez-vous des points suivants :

  • Utilisez des points de terminaison locaux. L'ordre des messages est conservé côté publication et dans une région. En d'autres termes, si vous publiez des messages dans plusieurs régions, seuls les messages de la même région sont distribués dans un ordre cohérent. Si tous vos messages sont publiés dans la même région, mais que vos abonnés sont répartis dans plusieurs régions, ils reçoivent tous les messages dans l'ordre. Utilisez un point de terminaison local pour publier des messages dans la même région.

  • Configurez une fonction de reprise de la publication. Lorsqu'une bibliothèque cliente relance une requête et que le message comporte une clé de tri, la bibliothèque cliente relance à nouveau la requête de façon répétée, indépendamment des paramètres de nouvelle tentative. Si une erreur ne permettant aucune autre tentative se produit, la bibliothèque cliente ne publie pas le message et cesse la publication d'autres messages avec la même clé de tri. Lorsque vous êtes prêt à reprendre la publication sur une clé de tri dont la publication a échoué, appelez la resumePublish méthode.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :

Sujet Tâche
Configurer la conservation des messages Joignez un abonnement avant de publier ou d'activer la conservation des messages
Traiter les messages par lots dans une requête de publication Traitez ou regroupez les messages par lots pour augmenter l'efficacité de l' éditeur et envoyer des messages avec un débit plus élevé.
Contrôle de flux Configurez le contrôle de flux dans les paramètres de votre éditeur pour gérer les pics de trafic temporaires.
Tester les clients Pub/Sub pour optimiser les performances de diffusion Faites évoluer le débit de l'éditeur en augmentant le nombre de cœurs de machine disponibles et la bande passante du réseau.
Nouvelles tentatives de requêtes N'ajustez les valeurs spécifiées de la stratégie de nouvelle tentative de l'éditeur que si vous constatez que les paramètres par défaut ne sont pas suffisants pour votre cas d'utilisation.
Configurer des règles de stockage des messages Utilisez la règle de stockage des messages pour stocker les données de message sur disque uniquement dans des emplacements spécifiques.
Utiliser un point de terminaison local lors de l'utilisation de clés de tri dans la publication Lorsque vous utilisez la messagerie ordonnée, utilisez un point de terminaison local et configurez une fonction de reprise de la publication en cas d'échec de publication.

Étape suivante