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 sur 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.

Agir en fonction de la réponse de la publication

Lorsque l'appel de publication de la bibliothèque cliente de haut niveau est terminé, 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écider de 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 l'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 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 réussi.

Si la publication réussit, le résultat de l'appel de publication est l'ID de message du message publié.

Conserver les ID de message

Pour faciliter le dépannage, les éditeurs et les abonnés doivent conserver les ID des messages publiés. Vous pouvez stocker l'ID de chaque message publié ou activer la journalisation des ID de message si nécessaire. La conservation des ID de message facilite la résolution des problèmes de messages en double, de nouvelles livraisons, de perte de données et d'autres problèmes courants. Pour en savoir plus, consultez Gérer les doublons.

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

Si vous commencez à publier dans un sujet qui n'est pas associé à un abonné, 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 lot

Dans Pub/Sub, la messagerie par lot désigne le processus consistant à combiner 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 traitement par lot (ou 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.

Il existe deux types de latence dans Pub/Sub :

  • 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 est le 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 de l'heure. Lorsque vous configurez les paramètres de traitement par lot, vous pouvez trouver le bon équilibre entre coût, débit et 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 différer d'une bibliothèque cliente à l'autre. Vous pouvez spécifier une 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 Traiter des 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 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 les paramètres de l'é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 maximum outstanding messages (nombre maximal de messages en attente) et maximum outstanding message bytes (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 le configurer, consultez 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 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 en savoir plus sur l'optimisation des performances de streaming, consultez Tester les clients Cloud Pub/Sub pour optimiser les performances de streaming.

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 rencontrer des échecs de publication. Ces échecs sont généralement causés par des goulots d'étranglement côté client, tels qu'un nombre insuffisant de processeurs de service, un mauvais état des threads ou une congestion du réseau. publisher retry policy détermine le comportement en cas d'échec de distribution du message. La règle de nouvelle tentative définit le nombre de fois où Pub/Sub tente de distribuer le message et le délai 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 que 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 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 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 que le publisher attend pour que l'appel RPC se termine. 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 de 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 lot 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 Échec des opérations de publication 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 d'un sujet Pub/Sub permet de s'assurer que les messages publiés dans un sujet ne sont jamais conservés en dehors d'un ensemble de régionsGoogle Cloud que vous spécifiez, indépendamment de 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 le disque. Lorsqu'un message est publié dans une région ne figurant 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 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 d'un sujet individuel ne peut être modifiée que d'une manière qui ne va pas à l'encontre de 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 Configurer des règles de stockage des messages.

Bonnes pratiques pour la messagerie ordonnée dans la publication

Si vous utilisez le séquencement des messages, assurez-vous de respecter les points suivants :

  • Utilisez des points de terminaison localisés. L'ordre des messages est conservé côté publication et au sein d'une région. En d'autres termes, si vous publiez des messages dans plusieurs régions, seuls les messages d'une même région sont distribués dans un ordre cohérent. Si vos messages sont tous publiés dans la même région, mais que vos abonnés sont répartis dans plusieurs régions, les abonnés reçoivent tous les messages dans l'ordre. Utilisez un point de terminaison d'emplacement 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 la requête de manière répétée, indépendamment des paramètres de nouvelle tentative. Si une erreur non renouvelable se produit, la bibliothèque cliente ne publie pas le message et arrête de publier les autres messages ayant 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 :

Sujet Tâche
Configurer la conservation des messages Associez un abonnement avant de publier ou d'activer la conservation des messages.
Regrouper les messages dans une requête de publication Regroupez les messages pour augmenter l'efficacité du diffuseur et envoyer des messages à 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 maximiser les performances de streaming Augmentez 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 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