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 à suivre 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, de la gcloud CLI ou des bibliothèques clientes.

Associez un abonnement ou activez la conservation des messages par sujet avant de commencer à publier.

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

Configurer l'envoi de messages par lot

Dans Pub/Sub, la messagerie par lot fait référence au processus consistant à combiner plusieurs messages dans un 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 lot est activé par défaut. Le traitement par lot (ou regroupement) des messages permet à l'éditeur d'améliorer son efficacité et d'envoyer des messages à un débit plus élevé. Le traitement par lot réduit les coûts de publication des données. Toutefois, le traitement par lot 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 lot, l'augmentation des deux types de latence est un compromis pour améliorer l'efficacité et le débit.

Vous pouvez regrouper des messages dans une bibliothèque cliente en fonction de la taille de la requête de message, du nombre de messages et de l'heure. Lorsque vous configurez les paramètres de traitement par lot, vous pouvez trouver le bon équilibre entre les coûts, le débit et la latence en fonction de votre cas d'utilisation.

Les valeurs par défaut des variables de messagerie par lot et les noms des variables peuvent varier d'une bibliothèque cliente à l'autre. Vous pouvez spécifier une ou toutes les trois valeurs dans la bibliothèque cliente. Si l'une des valeurs des variables de messagerie par lot est remplie, la bibliothèque cliente publie le prochain lot de messages.

Pour configurer la messagerie par lots pour un client éditeur, consultez la section Messages par lot 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 la publication des messages échoue avec une erreur Deadline exceeded.

Pour gérer les pics temporaires de publication de messages, vous pouvez utiliser le contrôle de flux dans vos paramètres d'éditeur. Le contrôle de flux côté éditeur empêche les ressources client de l'éditeur d'être submergées par un trop grand nombre de requêtes en attente. Si le client de l'é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 les valeurs appropriées pour les variables Nombre maximal de messages en attente et Nombre maximal d'octets de message 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 la configurer, 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 votre latence réseau est élevée, vous ne devez pas submerger le système de nombreuses petites requêtes. Le contrôle de flux côté éditeur peut vous aider à résoudre les problèmes réseau côté client.

Le débit de votre éditeur est également limité par le processeur et la mémoire. Plus de cœurs de machine disponibles vous permet de définir un nombre de threads plus élevé pour améliorer le 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 optimiser 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, des échecs de publication peuvent se produire. 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. publisher retry policy détermine le comportement en cas d'échec de la diffusion du message. La stratégie de nouvelle tentative définit le nombre de fois où 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 que l'éditeur attend avant de relancer 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 est de 100 milliseconds * 4 = 400 milliseconds pour la deuxième tentative et de 400 milliseconds * 4 = 1600 milliseconds pour la troisième tentative.

  • maxRetryDelay. Délai maximal d'attente de l'éditeur avant de relancer 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 de l'appel RPC. La valeur par défaut est 4.0. Cela signifie que le délai avant expiration de l'appel RPC est de 5 seconds * 4 = 20 seconds pour la deuxième tentative et de 10 seconds * 4 = 40 seconds pour la troisième tentative.

  • 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 de l'opération de publication. Cela inclut le temps d'attente 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 du débit et le traitement par lot dans de telles circonstances. Si vous publiez à partir d'une connexion Internet instable ou limitée en bande passante, vous pouvez tester les valeurs des variables initialRpcTimeout, maxRpcTimeout et rpcTimeoutMultiplier. Pour connaître les valeurs recommandées, consultez la section Échec des opérations de publication avec erreur DEADLINE_EXCEEDED.

Utiliser une règle de stockage des messages pour assurer 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 régions Google Cloud 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 régions Google Cloud dans lesquelles Pub/Sub est autorisé à stocker les données des messages 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, vous ne pouvez modifier les règles de chaque sujet que de manière à ne pas enfreindre la règle d'administration de l'organisation.

Par exemple, une entreprise qui opère 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 respecter les lois locales.

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

Bonnes pratiques pour les messages ordonnés dans les publications

Si vous utilisez l'ordre des messages, assurez-vous que:

  • Utilisez des points de terminaison localisés. L'ordre des messages est préservé du côté de la 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 différentes régions, ils reçoivent tous les messages dans l'ordre. Utilisez un point de terminaison géographique 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 à continuer à publier sur une clé de tri pour laquelle la publication a échoué, appelez la méthode resumePublish.

Récapitulatif des bonnes pratiques

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

Thème Tâche
Configurer la conservation des messages Associez un abonnement avant de publier ou d'activer la conservation des messages.
Grouper des messages dans une requête de publication Envoyez des messages par lot ou en groupe pour augmenter l'efficacité de l'éditeur et envoyer des messages à un débit plus élevé.
Contrôle de flux Configurez le contrôle de flux dans vos paramètres d'éditeur pour gérer les pics de trafic temporaires.
Tester les clients Pub/Sub pour optimiser les performances de streaming Évoluez le débit de l'éditeur en augmentant le nombre de cœurs de machine et la bande passante réseau disponibles.
Réessayer les requêtes N'ajustez les valeurs spécifiées de la règle 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 des messages sur disque uniquement dans des emplacements spécifiques.
Utiliser un point de terminaison localisé lorsque vous utilisez des clés de tri lors de la publication Lorsque vous utilisez la messagerie ordonnée, utilisez un point de terminaison localisé et configurez une fonction de reprise de la publication en cas d'échec de la publication.

Étape suivante