Bonnes pratiques pour publier dans un sujet Pub/Sub

Lors de la publication, un client éditeur envoie un message à 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 ne connaissez pas Pub/Sub, consultez l'un des guides de démarrage rapide et apprenez à l'exécuter à l'aide de la console, de la gcloud CLI ou des bibliothèques clientes.

Associez un abonnement ou activez 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 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 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.

Dans Pub/Sub, il existe deux types de latence:

  • 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 constitue un compromis pour améliorer l'efficacité et le débit.

Vous pouvez regrouper les messages d'une bibliothèque cliente en fonction de la taille de la requête de message, du nombre de messages et de l'heure. Lors de la configuration des 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 remplie, la bibliothèque cliente publie le lot de messages suivant.

Pour configurer la messagerie par lot pour un client d'é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 les messages ne puissent pas être publiés avec une erreur Deadline exceeded.

Pour résoudre les pics temporaires de publication de messages, vous pouvez utiliser le contrôle de flux dans vos paramètres éditeur. Le contrôle de flux côté éditeur évite que les ressources client de l'éditeur ne soient submergées par un trop grand nombre de demandes 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 les 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 le configurer, consultez la page Contrôle de flux.

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

Le débit de votre éditeur est limité par votre bande passante réseau et le nombre de requêtes envoyées. Si votre bande passante est bonne, mais que la latence du réseau est élevée, ne submergez pas 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 vous disposez de cœurs de machine, vous pouvez définir un nombre de threads plus élevé pour un meilleur débit en publication. Pour mieux comprendre comment maximiser les performances de diffusion, consultez la page Tester des clients Cloud Pub/Sub pour maximiser 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 d'éditeur, la publication peut échouer. Ces défaillances sont généralement causées 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. Le publisher retry policy détermine le comportement en cas d'échec de la distribution d'un message. La stratégie de nouvelle tentative définit le nombre de tentatives de distribution du message par Pub/Sub et le délai entre chaque tentative.

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

  • initialRéessayerDelay. 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 tentatives. La valeur par défaut est 4. Cela signifie que le délai entre les tentatives est de 100 milliseconds * 4 = 400 milliseconds pour la deuxième tentative et de 400 milliseconds * 4 = 1600 milliseconds pour la troisième.

  • maxRéessayerDelay. Délai maximal d'attente de l'éditeur avant de retenter une opération de publication. La valeur par défaut est 60 seconds.

  • initialRpcTimeout. Délai avant expiration initial que l'éditeur attend 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 est maximal de 5 seconds * 4 = 20 seconds pour la deuxième tentative et de 10 seconds * 4 = 40 seconds pour la troisième.

  • maxRpcTimeout. Délai maximal pour lequel l'éditeur attend que l'appel RPC se termine. La valeur par défaut est 600 seconds.

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

N'ajustez les valeurs spécifiées que si 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 irrégulière ou à bande passante limitée, 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 DEADLINE_EXCEEDED.

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

La règle de stockage des messages par sujet de Pub/Sub permet de s'assurer que les messages publiés sur un sujet ne sont jamais conservés en dehors d'un ensemble de régions Google 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 la liste des 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. Cette 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 l'ensemble d'une organisation. Lorsqu'une règle d'administration est configurée, la stratégie d'un sujet individuel ne peut être modifiée que de manière à respecter la règle d'administration.

Par exemple, une entreprise opérant en Europe peut utiliser les règles de stockage des messages pour s'assurer que toutes les données sont stockées dans des régions de l'UE conformément à la législation locale.

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

Bonnes pratiques pour les messages ordonnés lors de la publication

Si vous triez les messages, vérifiez les points suivants:

  • Utilisez des points de terminaison de localisation. L'ordre des messages est préservé côté publication et dans 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, 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 publication de CV. Lorsqu'une bibliothèque cliente relance une requête et que le message dispose d'une clé de tri, la bibliothèque relance la requête à plusieurs reprises, indépendamment des paramètres de nouvelle tentative. Si une erreur ne pouvant pas faire l'objet d'une nouvelle tentative se produit, la bibliothèque cliente ne publie pas le message et cesse de publier les autres messages ayant la même clé de tri. Lorsque vous êtes prêt à poursuivre la publication 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.
Messages par lot dans une requête de publication Regroupez ou regroupez des messages pour accroître l'efficacité de l'éditeur et envoyez des messages à un débit plus élevé.
Contrôle de flux Configurez le contrôle de flux dans les paramètres de l'éditeur pour gérer les pics de trafic temporaires.
Tester des clients Pub/Sub pour maximiser les performances de traitement par flux Ajustez le débit de l'éditeur avec une augmentation des cœurs de machine et de la bande passante réseau disponibles.
Réessayer les requêtes Ne modifiez les valeurs spécifiées des règles relatives aux nouvelles tentatives de l'éditeur que si vous estimez que les paramètres par défaut ne sont pas suffisants pour votre cas d'utilisation.
Configurer les règles de stockage des messages Utilisez la règle de stockage des messages pour ne stocker les données des messages sur le disque que dans des emplacements spécifiques.
Utiliser un point de terminaison localisé lors de l'utilisation de clés de tri lors de la publication Lorsque vous utilisez une messagerie ordonnée, utilisez un point de terminaison de localisation et configurez une fonction de CV pour les échecs de publication.

Étapes suivantes