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

Prendre des mesures 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 Future contenant le résultat de l'opération. Pour éviter de bloquer les demandes de publication individuelles, gérez le résultat de manière asynchrone. Vous devez décider de la meilleure façon de gérer l'échec pour votre cas d'utilisation. Vous disposez notamment des possibilités suivantes :

  • Enregistrez 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.
  • Propager les erreurs au service en amont qui vous a envoyé le message que vous avez essayé 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 que celles-ci ont bien été effectuées.

Associez un abonnement ou activez la conservation des sujets avant de commencer à publier.

Si vous commencez à publier des messages dans un sujet auquel aucun abonné n'est associé, ils 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 la messagerie par lot

Dans Pub/Sub, la messagerie par lot 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 lot est activé par défaut. Le regroupement des messages aide l'éditeur à améliorer son efficacité et à envoyer des messages à un débit plus élevé. Le traitement par lot réduit le coût 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 les messages 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 lot, vous pouvez trouver le juste équilibre entre coût, débit et latence pour l'adapter à 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, deux ou les trois valeurs dans la bibliothèque cliente. Si l'une des valeurs des variables de messagerie par lot est atteinte, la bibliothèque cliente publie le lot de messages suivant.

Pour configurer la messagerie par lots pour un client éditeur, consultez 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 pas être publiés et qu'une erreur Deadline exceeded s'affiche.

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 du 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 du flux dans la bibliothèque cliente, définissez les valeurs appropriées pour les variables maximum outstanding messages (nombre maximal de messages en attente) et maximum outstanding message bytes (nombre maximal d'octets de messages en attente). Ces valeurs permettent d'équilibrer le débit de 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 le configurer, consultez Contrôle de flux.

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

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

Le débit de votre éditeur est également limité par le processeur et la mémoire. Plus vous disposez de cœurs de machine, plus vous pouvez définir un nombre de threads élevé pour améliorer le débit de publication. Pour mieux comprendre comment optimiser les performances de streaming, consultez Tester les clients Cloud Pub/Sub pour optimiser les performances de streaming.

Ajuster les variables de la demande de réessai pour les publications ayant échoué

Lorsque le client d'un éditeur publie un message, 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 l'envoi 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 de l'é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 tentatives. La valeur par défaut est 4. Cela signifie que le délai entre les tentatives est de 100 milliseconds * 4 = 400 milliseconds maximum pour la deuxième tentative et de 400 milliseconds * 4 = 1600 milliseconds maximum pour la troisième tentative.

  • maxRetryDelay. Délai maximal d'attente de l'éditeur 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 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 réessai par défaut ne sont pas suffisants pour votre cas d'utilisation. Par exemple, la publication d'un grand nombre de messages ne vous oblige pas à augmenter les valeurs initialRetryDelay et maxRetryDelay. Toutefois, vous pouvez ajuster le contrôle du flux et le traitement par lot dans de telles circonstances. Si vous publiez à partir d'une connexion Internet instable ou 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 Échec des opérations de publication avec erreur DEADLINE_EXCEEDED.

Utiliser une règle de stockage des messages pour assurer la localisation 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 deGoogle 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 où Pub/Sub est autorisé à stocker les données des messages sur le disque. Lorsqu'un message est publié dans une région qui ne figure pas dans cette liste, la requête est transférée vers la région autorisée la plus proche pour traitement. La règle peut être configurée sur un thème 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, les règles individuelles des sujets ne peuvent être modifiées 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 respecter les lois locales.

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

Bonnes pratiques pour la messagerie ordonnée dans l'édition

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

  • Utilisez des points de terminaison localisés. 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 recevront tous les messages dans l'ordre. Utilisez un point de terminaison géographique pour publier des messages dans la même région.

  • Configurer une fonction de publication de CV. 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 dont 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.
Regrouper des messages dans une requête de publication Regroupez les messages par lots 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 Augmentez le débit des éditeurs en augmentant le nombre de cœurs de processeur et la bande passante réseau disponibles.
Demandes de réessai N'ajustez les valeurs spécifiées de la stratégie de réessai 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 le disque uniquement dans des emplacements spécifiques.
Utiliser un point de terminaison localisé lorsque vous utilisez des clés de tri pour 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.

Étapes suivantes