Migrer des notifications de modification d'objet vers les notifications Pub/Sub

Ce guide s'adresse aux utilisateurs de la fonctionnalité Notifications de modification d'objet obsolète de Cloud Storage. Les notifications Pub/Sub pour Cloud Storage sont l'outil recommandé pour générer des notifications qui suivent les modifications apportées aux objets de vos buckets Cloud Storage. Les notifications Pub/Sub sont plus rapides, plus flexibles, plus faciles à configurer et plus économiques. Ce guide explique les différences entre les notifications de modification d'objet et les notifications Pub/Sub pour Cloud Storage. Il fournit également des étapes de migration des notifications de modification d'objet vers les notifications Pub/Sub.

Présentation des notifications de modification d'objet

Les notifications de modification d'objet sont un ancien mécanisme de Cloud Storage permettant d'informer une application des modifications apportées aux objets d'un bucket. Lorsqu'une notification de modification d'objet est configurée, Cloud Storage envoie des requêtes HTTP POST (webhooks) à une URL d'application spécifiée chaque fois qu'un objet est ajouté, mis à jour ou supprimé. Les notifications de modification d'objet sont établies en envoyant une requête watchAll à Cloud Storage, à l'aide de l'API JSON, des bibliothèques clientes ou de la commande gsutil notification watchbucket. Il n'existe aucun mécanisme pull. Vous devez disposer d'un nom de domaine accessible publiquement, soutenu par un serveur HTTP, pour recevoir les messages de webhook. Nous vous recommandons d'utiliser les notifications Pub/Sub pour Cloud Storage pour les nouvelles implémentations en raison de leur fiabilité, de leur évolutivité et de leur flexibilité.

Pour en savoir plus, consultez Notifications de modification des objets.

Présentation des notifications Pub/Sub

Les notifications Pub/Sub pour Cloud Storage constituent un moyen moderne, évolutif et fiable de déclencher des actions en réponse aux modifications apportées à vos buckets Cloud Storage. Pour ce faire, elles envoient des informations sur les événements à un sujet Pub/Sub. Pub/Sub propose la distribution en mode push des messages sous forme de requêtes HTTP POST aux webhooks. Lorsque des objets sont créés, mis à jour ou supprimés, Cloud Storage publie des messages contenant des métadonnées d'objet dans un sujet Pub/Sub spécifié, qui peut ensuite être utilisé par différents abonnés tels que des fonctions Cloud Run, des pipelines de données ou des microservices. Cela permet de créer des architectures flexibles et basées sur des événements avec des fonctionnalités de distribution au moins une fois et de gestion des exceptions robustes.

Pour en savoir plus, consultez Notifications Pub/Sub pour Cloud Storage.

Comparer les notifications de modification des objets et les notifications Pub/Sub

Le tableau suivant compare les fonctionnalités de notifications de modification d'objet et de notifications Pub/Sub :

Fonctionnalité Notifications de modification d'objets Notifications Pub/Sub
Purpose Avertit une application directement par le biais de requêtes HTTP POST (webhooks) lorsque des objets d'un bucket sont modifiés. Envoie des informations sur les modifications apportées aux objets des buckets Cloud Storage à un sujet Pub/Sub.
Mécanisme de diffusion Envoi d'une requête HTTP POST directe (webhook) à une URL d'application spécifiée. Les messages publiés dans un sujet Pub/Sub peuvent ensuite être utilisés par différents abonnés, tels que des fonctions Cloud Run, d'autres applications et des pipelines de données.
Fiabilité La fiabilité de la distribution est privilégiée, mais la rapidité n'est pas garantie. Les notifications peuvent être retardées indéfiniment. Offre une distribution "au moins une fois", ce qui signifie que les messages peuvent être distribués plusieurs fois, mais ne sont pas perdus. Pub/Sub gère la persistance et les nouvelles tentatives des messages.
Évolutivité Moins évolutif, car il repose sur des Webhooks directs que votre application doit gérer. Hautement évolutif et conçu pour le traitement d'événements à grande échelle.
Flexibilité Limité à l'intégration directe de webhook. Très flexible. Les messages Pub/Sub peuvent déclencher des fonctions Cloud Run, alimenter des pipelines de données (Dataflow) et être utilisés par d'autres microservices.
Filtrage Aucun Des options de filtrage robustes sont disponibles au niveau de l'abonnement Pub/Sub, ce qui permet aux abonnés de ne recevoir que les messages qui répondent à des critères spécifiques.
Sécurité Nécessite que le point de terminaison de votre application soit accessible au public (HTTPS). Pub/Sub propose IAM pour un contrôle précis des accès aux sujets et aux abonnements. Pub/Sub vous aide à distribuer des messages de manière sécurisée, que vous récupériez les notifications directement ou que vous les fassiez envoyer à un point de terminaison public.
Complexité La configuration peut être plus simple pour les cas d'utilisation de base, mais la gestion d'une diffusion fiable et du scaling peut devenir complexe. Nécessite de comprendre les concepts Pub/Sub (sujets, abonnements), mais offre une solution plus robuste et gérable pour les architectures basées sur les événements.
État d'abandon Obsolète. Nous vous recommandons d'utiliser les notifications Pub/Sub pour les nouvelles implémentations. Actif. Il s'agit de la méthode principale et activement développée pour les notifications Cloud Storage.
Utilisation recommandée Non recommandé pour les nouveaux projets. Principalement pour les anciennes intégrations moins complexes que vous ne pouvez pas migrer. Fortement recommandé pour créer des architectures robustes, évolutives et basées sur des événements qui réagissent aux modifications de Cloud Storage.

Pourquoi migrer vers les notifications Pub/Sub ?

La migration des anciennes notifications de modification d'objet vers Pub/Sub pour les notifications Cloud Storage est une étape importante pour une gestion robuste des événements. Pub/Sub est recommandé pour les architectures basées sur des événements dans Google Cloud. Il offre des avantages techniques et opérationnels importants par rapport aux notifications de modification d'objet.

Voici les avantages de la migration vers les notifications Pub/Sub :

  • Distribution fiable : Pub/Sub distribue chaque message publié au moins une fois pour chaque abonnement, ce qui garantit que les événements parviennent à vos consommateurs. La fiabilité de la diffusion minimise la perte de données et améliore la fiabilité de vos workflows par rapport au modèle de diffusion moins robuste des notifications de modification d'objet.
  • Scalabilité : conçues pour un débit élevé, les notifications Pub/Sub peuvent gérer automatiquement de grands volumes d'événements. Les notifications Pub/Sub vous permettent d'éliminer les goulots d'étranglement des performances que vous pourriez rencontrer avec les notifications de modification d'objet à mesure que la fréquence de vos données ou événements augmente.
  • Intégration aux services Google Cloud  : Pub/Sub s'intègre parfaitement à plusieurs services Google Cloud , ce qui permet de créer des workflows automatisés à l'aide de Cloud Run Functions, Cloud Run et Dataflow, et d'améliorer l'observabilité grâce à Cloud Logging et Cloud Monitoring.
  • Contrôle précis : avec Pub/Sub, vous pouvez filtrer les messages au niveau de l'abonnement. Cela permet aux consommateurs de ne recevoir que les événements pertinents, ce qui réduit le traitement et le trafic réseau inutiles.
  • Compatibilité avec les plates-formes : les notifications Pub/Sub sont le service de messagerie compatible. La migration vous permet d'utiliser une technologie qui reçoit des améliorations continues, des mises à jour de sécurité et une documentation complète, contrairement aux notifications de modification d'objet obsolètes.

Procédure de migration

Les notifications de modification des objets et les notifications Pub/Sub pour Cloud Storage peuvent parfois envoyer des messages en double. Par conséquent, votre code consommateur doit être conçu pour gérer les messages en double de manière sécurisée.

Pour migrer des notifications de modification des objets vers les notifications Pub/Sub, procédez comme suit :

  1. Commencez à utiliser les notifications Pub/Sub pour Cloud Storage en plus de la configuration existante des notifications de modification des objets. Pour savoir comment configurer les notifications Pub/Sub, consultez Configurer les notifications Pub/Sub pour Cloud Storage.

  2. Testez et vérifiez que le workflow de traitement des notifications Pub/Sub de votre application fonctionne correctement. Pour savoir comment surveiller un abonnement Pub/Sub, consultez Surveiller les abonnements dans Pub/Sub.

  3. Arrêtez le traitement des messages reçus d'un canal de notifications de modification d'objet. Pour arrêter un canal de notification, envoyez une requête stop.

Points à prendre en compte pour l'abonnement push Pub/Sub

Bien que les abonnements pull Pub/Sub offrent une flexibilité et un contrôle améliorés, les abonnements push Pub/Sub ressemblent beaucoup aux messages de notification de modification d'objet. Par conséquent, les abonnements push deviennent un chemin de migration plus rapide pour les utilisateurs existants des notifications de modification d'objets. Pour obtenir une comparaison détaillée des abonnements push et pull, consultez Choisir un type d'abonnement.

Si vous prévoyez d'utiliser l'abonnement push et de réutiliser le code de gestion des notifications existant, vous devrez tenir compte des différences entre les formats de requête push et les interprétations des codes de réponse des notifications de modification d'objet et des notifications Pub/Sub. Les différences sont décrites dans les sections suivantes.

Format des requêtes push

Cette section décrit les différences de format des requêtes push entre les notifications de modification d'objet et les notifications Pub/Sub.

  • Notifications de modification d'objet : une notification de modification d'objet est envoyée sous la forme d'une requête HTTP POST à l'URL de votre application, au format suivant :

    POST /ApplicationUrlPath
Accept: * / *
Content-Length: 1097
Content-Type: application/json; charset="utf-8"
Host: ApplicationUrlHost
X-Goog-Channel-Id: ChannelId
X-Goog-Channel-Token: ClientToken
X-Goog-Resource-Id: ResourceId
X-Goog-Resource-State: ResourceState
X-Goog-Resource-Uri: https://storage.googleapis.com/storage/v1/b/BucketName/o?alt=json

{
"kind": "storage#object",
"id": "BucketName/ObjectName",
"selfLink": "https://www.googleapis.com/storage/v1/b/BucketName/o/ObjectName",
"name": "ObjectName",
"bucket": "BucketName",
"generation": "1367014943964000",
"metageneration": "1",
"contentType": "application/octet-stream",
"updated": "2013-04-26T22:22:23.832Z",
"size": "10",
"md5Hash": "xHZY0QLVuYng2gnOQD90Yw==",
"mediaLink": "https://content-storage.googleapis.com/storage/v1/b/BucketName/o/ObjectName?generation=1367014943964000&alt=media",
"owner": {
  "entity": "user-jeffersonloveshiking@gmail.com"
},
"crc32c": "C7+82w==",
"etag": "COD2jMGv6bYCEAE="
}

  • Notifications Pub/Sub : lorsqu'une notification Pub/Sub est configurée pour la diffusion push, elle est envoyée sous forme de requête HTTP POST. Le champ data contient la charge utile de l'événement Cloud Storage encodée en base64. Une fois le champ de données décodé, il correspond au corps du message des notifications de modification des objets.

    POST /YourSpecifiedURL
Accept: * / *
Content-Length: 1097
Content-Type: application/json; charset="utf-8"
Host: ApplicationUrlHost
{
  "deliveryAttempt": 5,
  "message":
    {"attributes":
      {"notificationConfig":"projects/_/buckets/foo/notificationConfigs/3",
        "eventType": "OBJECT_FINALIZE",
        "payloadFormat": "JSON_API_V1",
        "bucketId": "foo",
        "objectId": "bar",
        "objectGeneration": 123456,
        "eventTime": "2021-01-15T01:30:15.01Z"
      },
    "data": "ewogImtpbm",
    "messageId": "2070443601311540",
    "message_id": "2070443601311540",
    "orderingKey": "key",
    "publishTime": "2021-02-26T19:13:55.749Z",
    "publish_time": "2021-02-26T19:13:55.749Z"
    },
  "subscription": "projects/myproject/subscriptions/mysubscription"
}

Code de réponse

Le tableau suivant décrit les différences d'interprétation des codes de réponse entre les notifications de modification d'objet et les notifications Pub/Sub :

Fonctionnalité Code de réponse Interprétation Action
Notifications de modification des objets
102, 200, 201, 202 et 204 Opération réussie Message traité
500, 502, 503, 504 Échec du traitement Réessayez plus tard
Délai d'attente dépassé, échec de la connexion, absence de réponse Échec du traitement Réessayez plus tard
Tout autre code HTTP. Par exemple : 404 Erreur permanente Ne pas renvoyer le message
Notifications Pub/Sub
102, 200, 201, 202 et 204 Opération réussie Message confirmé
Tous les autres codes de réponse, délais d'attente et échecs de connexion Échec Réessayez plus tard

Étapes suivantes