Eventarc vous permet de créer des architectures basées sur des événements, sans avoir à implémenter, à personnaliser ou à gérer l'infrastructure sous-jacente.
Eventarc est disponible en deux éditions: Eventarc Advanced et Eventarc Standard. Les deux éditions proposent une solution d'événements évolutive, sans serveur et entièrement gérée qui vous permet de router de manière asynchrone des événements de sources vers des cibles. Pour en savoir plus, consultez la page Choisir Eventarc Advanced ou Eventarc Standard.
Eventarc Standard offre une solution standardisée pour gérer le flux des changements d'état, appelés événements, entre les microservices découplés. Lorsqu'il est déclenché, Eventarc Standard achemine ces événements vers différentes destinations (dans ce document, consultez la section Destinations d'événements) tout en gérant la diffusion, la sécurité, les autorisations, l'observabilité et la gestion des erreurs.
Vous pouvez gérer Eventarc à l'aide de la console Google Cloud, de la ligne de commande avec gcloud CLI ou de l'API Eventarc.
1 Les événements des fournisseurs Google sont envoyés directement depuis la source (Cloud Storage, par exemple) ou via des entrées de Cloud Audit Logs, et utilisent Pub/Sub comme couche de transport. Les événements de sources Pub/Sub peuvent utiliser un sujet Pub/Sub existant ou Eventarc crée automatiquement un sujet et le gère pour vous.
2 Les événements pour les destinations Google Kubernetes Engine (GKE), y compris les services Knative serving exécutés dans un cluster GKE, utilisent le redirecteur d'événements d'Eventarc pour extraire les nouveaux événements de Pub/Sub et les trénsférer à la destination. Ce composant agit en tant que médiateur entre la couche de transport Pub/Sub et le service cible. Il fonctionne avec les services existants et prend en charge les services de signalement (y compris ceux qui ne sont pas exposés en dehors du cluster entièrement géré) tout en simplifiant la configuration et la maintenance. Notez que le cycle de vie du redirecteur d'événements est géré par Eventarc. Si vous supprimez accidentellement le redirecteur d'événement, Eventarc restaurera ce composant.
3 Les événements d'exécution d'un workflow sont transformés et transmis au workflow en tant qu'arguments d'exécution. Les workflows peuvent combiner et orchestrer des services d'API basés sur Google Cloud et HTTP dans un ordre que vous définissez.
4 Toutes les fonctions basées sur des événements dans les fonctions Cloud Run utilisent des déclencheurs Eventarc pour diffuser des événements. Vous pouvez configurer des déclencheurs Eventarc lorsque vous déployez une fonction Cloud Run à l'aide de l'interface de fonctions Cloud Run.
Principaux cas d'utilisation
Eventarc est compatible avec de nombreux cas d'utilisation des applications de destination. En voici quelques exemples :
| Configurer et surveiller |
|
| Harmoniser |
|
| Analyser |
|
Événements
Un événement est un enregistrement de données exprimant une occurrence et son contexte. Un événement correspond à une unité discrète de communication, indépendante des autres événements. Par exemple, un événement peut indiquer une modification apportée aux données d'une base de données, l'ajout d'un fichier à un système de stockage ou une tâche planifiée.
Consultez la section Types d'événements Google compatibles avec Eventarc.
Fournisseurs d'événements
Les événements sont acheminés d'un fournisseur d'événements (la source) aux consommateurs intéressés. Le routage est effectué en fonction des informations contenues dans l'événement, mais un événement n'identifie pas de destination de routage spécifique. Eventarc accepte les événements provenant de plus de 130 fournisseurs Google. Ces fournisseurs envoient des événements (par exemple, une mise à jour d'un objet dans un bucket Cloud Storage ou un message publié dans un sujet Pub/Sub) directement depuis la source ou via des entrées de Cloud Audit Logs.
Destinations des événements
Les événements sont acheminés vers une destination spécifique (la cible) appelée récepteur d'événements (ou consommateur) via des abonnements push Pub/Sub.
Cloud Run
Apprenez à créer un service récepteur d'événements pouvant être déployé sur Cloud Run.
Pour déterminer la meilleure façon d'acheminer les événements vers un service Cloud Run, consultez la page Routes d'événements.
Fonctions Cloud Run
Toutes les fonctions basées sur des événements dans les fonctions Cloud Run utilisent des déclencheurs Eventarc. Un déclencheur Eventarc permet de déclencher une fonction par n'importe quel type d'événement compatible avec Eventarc. Vous pouvez configurer des déclencheurs Eventarc lorsque vous déployez une fonction Cloud Run à l'aide de l'interface de fonctions Cloud Run.
GKE
Eventarc accepte la création de déclencheurs qui ciblent les services Google Kubernetes Engine (GKE). Cela inclut les points de terminaison publics des services privés et publics s'exécutant dans un cluster GKE.
Pour qu'Eventarc cible et gère les services d'un cluster donné, vous devez accorder au compte de service Eventarc toutes les autorisations nécessaires.
Vous devez activer Workload Identity Federation for GKE sur le cluster GKE sur lequel le service de destination s'exécute. Workload Identity Federation for GKE est requis pour configurer correctement le redirecteur d'événements. Il s'agit de la méthode recommandée pour accéder aux services Google Cloud à partir d'applications exécutées dans GKE en raison de ses propriétés de sécurité renforcée et de sa facilité de gestion. Pour en savoir plus, consultez la page Activer Workload Identity.
Points de terminaison HTTP internes d'un réseau VPC
Vous pouvez configurer le routage des événements vers un point de terminaison HTTP interne dans un réseau cloud privé virtuel (VPC). Pour configurer le déclencheur, vous devez également fournir un ID de rattachement réseau. Pour en savoir plus, consultez la section Router des événements vers un point de terminaison HTTP interne dans un réseau VPC.
Workflows
Vous pouvez déclencher l'exécution d'un workflow. Workflows nécessite l'adresse e-mail d'un compte de service IAM que votre déclencheur Eventarc utilisera pour appeler les exécutions de workflow. Nous vous recommandons d'utiliser un compte de service ne bénéficiant que des privilèges les plus faibles nécessaires pour accéder aux ressources requises. Pour en savoir plus, consultez la page Créer et gérer des comptes de service.
Format des événements et bibliothèques
Eventarc envoie les événements, quel que soit leur fournisseur, à la destination cible dans un format CloudEvents via une requête HTTP portant sur du contenu binaire. CloudEvents est une spécification décrivant les métadonnées d'événements de manière courante.
Selon le fournisseur d'événements, vous pouvez spécifier l'encodage des données de la charge utile de l'événement en tant que application/json ou application/protobuf. Les tampons de protocole (ou protobufs) sont un mécanisme extensible indépendant du langage et de la plate-forme, qui permet de sérialiser des données structurées. Veuillez noter les points suivants :
- Pour les sources personnalisées ou les fournisseurs tiers, ou pour les événements directs de Pub/Sub, cette option de formatage n'est pas prise en charge.
- Une charge utile d'événement au format JSON est plus grande qu'une charge utile au format Protobuf, ce qui peut avoir un impact sur la fiabilité en fonction de votre destination d'événement et de ses limites de taille. Pour en savoir plus, consultez la section Problèmes connus.
Les destinations cibles telles que les fonctions Cloud Run, Cloud Run et GKE consomment des événements au format HTTP. Pour les destinations Workflows, le service Workflows convertit l'événement en objet JSON et le transmet à l'exécution du workflow comme argument d'exécution.
L'utilisation d'une méthode standard pour décrire les métadonnées d'événements garantit la cohérence, l'accessibilité et la portabilité. Les consommateurs d'événements peuvent lire ces événements directement. Vous pouvez également utiliser les bibliothèques clientes Cloud dans différents langages (y compris C++, C#, Go, Java, Node.js, PHP, Python et Ruby) pour lire et analyser les événements. Il existe également un ensemble de SDK CloudEvents spécifiques à chaque langage.
La structure du corps HTTP de tous les événements est disponible dans le dépôt GitHub Google CloudEvents.
Rétrocompatibilité
Eventarc prend en compte l'ajout des attributs et champs suivants compatibles avec les versions antérieures :
- Attributs de filtrage facultatifs ou attributs de sortie uniquement
- Champs facultatifs dans la charge utile de l'événement
Déclencheurs Eventarc
Des événements se produisent, qu'une destination cible réagisse ou non. Vous pouvez créer une réponse à un événement avec un déclencheur. Un déclencheur vous permet d'indiquer que vous souhaitez surveiller un ou plusieurs événements. Lorsque vous créez un déclencheur, vous spécifiez des filtres qui vous permettent de capturer ces événements spécifiques et de les utiliser, ce qui inclut leur routage d'une source d'événement vers une destination cible. Pour en savoir plus, consultez la représentation REST d'une ressource de déclencheur et les fournisseurs et destinations d'événements.
Notez que les abonnements Pub/Sub créés pour Eventarc persistent indifféremment de l'activité et n'expirent pas. Pour modifier les propriétés de l'abonnement, consultez la section Propriétés de l'abonnement.
Eventarc est compatible avec les déclencheurs pour les types d'événements suivants :
| Événements Cloud Audit Logging (CAL) | |
|---|---|
| Description | Cloud Audit Logging fournit des journaux d'audit Cloud pour les activités d'administration et l'accès aux données pour chaque projet, dossier et organisation Cloud.
Les services Google Cloud écrivent des entrées dans ces journaux. Vous pouvez créer des filtres pour les déclencheurs Eventarc à l'aide des valeurs serviceName et methodName dans les journaux d'audit. Pour connaître les valeurs exactes, consultez la section Services Google Cloud avec journaux d'audit.
Pour en savoir plus, consultez la section Déterminer des filtres d'événements pour Cloud Audit Logging. |
| Type de filtre d'événement | Les déclencheurs Eventarc avec type=google.cloud.audit.log.v1.written envoient des requêtes à votre service ou workflow lorsque vous créez un journal d'audit correspondant aux critères de filtrage du déclencheur. |
| Événements directs | |
| Description | Eventarc peut être déclenché par divers événements directs, tels qu'une mise à jour d'un bucket Cloud Storage, une mise à jour d'un modèle Firebase Remote Config ou des modifications apportées aux ressources
sur les services Google Cloud.
Eventarc peut être déclenché par les messages publiés dans les sujets Pub/Sub. Pub/Sub est un service de messagerie distribué dans le monde entier qui effectue un scaling automatique en fonction des besoins. Eventarc pouvant être appelé par des messages sur un sujet Pub/Sub, vous pouvez l'intégrer à tout autre service acceptant Pub/Sub comme destination. |
| Type de filtre d'événement | Les déclencheurs Eventarc avec des types de filtres d'événements spécifiques envoient des requêtes à votre service ou workflow lorsqu'un événement correspondant aux critères de filtre du déclencheur se produit. Par exemple, type=google.cloud.storage.object.v1.finalized (lorsqu'un objet est créé dans un bucket Cloud Storage) ou type=google.cloud.pubsub.topic.v1.messagePublished (lorsqu'un message est publié dans le sujet Pub/Sub spécifié).
|
Emplacement du déclencheur
Les services Google Cloud, tels que Cloud Storage, peuvent être configurés pour être régionaux ou multirégionaux. Certains services, tels que Cloud Build, peuvent être configurés à l'échelle mondiale.
Eventarc vous permet de créer des déclencheurs régionaux ou, pour certains événements, vous pouvez créer un déclencheur global et recevoir des événements de toutes les régions. Pour en savoir plus, consultez la section Comprendre les emplacements Eventarc.
Vous devez spécifier l'emplacement du déclencheur Eventarc pour qu'il corresponde à celui du service Google Cloud qui génère des événements. Cela évite les problèmes de performances et de résidence des données occasionnés par un déclencheur global.
Vous pouvez spécifier des emplacements de déclencheur en ajoutant une option --location à chaque commande.
Pour les destinations Cloud Run, si l'option --destination-run-region n'est pas spécifiée, le service est supposé se trouver dans la même région que le déclencheur. Pour en savoir plus, consultez la documentation de référence de Google Cloud CLI.
Fiabilité et diffusion
Les attentes en termes de diffusion sont les suivantes :
- Les événements utilisant les journaux d'audit Cloud sont diffusés en moins d'une minute. Remarque : Bien qu'un déclencheur Cloud Audit Logs soit créé immédiatement, la propagation et le filtrage des événements par le déclencheur peut prendre jusqu'à deux minutes.
- Les événements utilisant Pub/Sub sont diffusés en quelques secondes.
Il n'existe pas de fonctionnalité de diffusion prioritaire "premier entré, premier sorti". Notez qu'un ordonnancement strict irait à l'encontre des garanties de disponibilité et d'évolutivité offertes par Eventarc, qui correspondent à celles de sa couche de transport, Cloud Pub/Sub. Pour en savoir plus, consultez la page Trier des messages.
La latence et le débit sont les meilleurs possible. Ils varient en fonction de plusieurs facteurs, y compris si le déclencheur Eventarc est régional, multirégional ou mondial, la configuration d'un service particulier et la charge réseau sur les ressources dans une région Google Cloud.
Notez que des quotas et limites d'utilisation s'appliquent généralement à Eventarc. De plus, certains quotas et limites d'utilisation spécifiques s'appliquent également aux workflows.
Stratégie de nouvelle tentative pour les événements
Les nouvelles caractéristiques d'Eventarc correspondent à celles de sa couche de transport, Cloud Pub/Sub. Pour en savoir plus, consultez les sections Requêtes de nouvelle tentative et Intervalle entre les tentatives push.
La durée de conservation par défaut des messages définie par Eventarc est de 24 heures avec un intervalle exponentiel entre les tentatives.
Vous pouvez mettre à jour la stratégie de nouvelle tentative via l'abonnement Pub/Sub associé au déclencheur Eventarc :
- Ouvrez la page de détails du déclencheur.
- Cliquez sur le thème.
- Cliquez sur l'onglet Abonnements.
Tout abonnement créé automatiquement par Eventarc aura le format suivant : projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Pour en savoir plus sur les limites d'abonnement, consultez la page Limites de ressources dans Pub/Sub.
Si Pub/Sub tente d'envoyer un message, mais que la destination ne peut pas en accuser réception, Pub/Sub renvoie à nouveau le message avec un intervalle exponentiel minimal entre les tentatives de 10 secondes. Si la destination continue de ne pas accuser réception du message, du temps est ajouté à chaque nouvelle tentative (jusqu'à 600 secondes) et le message est renvoyé à la destination.
Notez que Workflows accuse réception des événements dès le début de l'exécution du workflow.
Files d'attente de lettres mortes
Si la destination ne reçoit pas le message, vous pouvez transférer les messages non distribués vers une file d'attente de lettres mortes (également appelé sujet de lettres mortes). Une file d'attente de lettres mortes peut stocker des messages que la destination ne peut pas confirmer. Vous devez définir une file d'attente de lettres mortes lorsque vous créez ou mettez à jour un abonnement Pub/Sub, et non lorsque vous créez un sujet Pub/Sub ou lorsque Eventarc crée un sujet Pub/Sub. Pour en savoir plus, consultez la page Gérer les échecs de message.
Erreurs qui ne justifient pas de nouvelles tentatives
Lorsque les applications utilisent Pub/Sub comme source d'événements et que l'événement n'est pas diffusé, l'événement est automatiquement relancé, sauf pour les erreurs qui ne justifient pas de nouvelles tentatives. Les événements de la destination du workflow, quelle que soit leur source, ne seront pas relancés si le workflow ne s'exécute pas. Si l'exécution du workflow démarre, mais échoue ultérieurement, elle n'est pas relancée. Pour résoudre ces problèmes de service, vous devez gérer les erreurs et les nouvelles tentatives dans le workflow.
Dupliquer des événements
Des événements en double peuvent être distribués aux gestionnaires d'événements. Selon la spécification CloudEvents, la combinaison des attributs source et id est considérée comme unique. Par conséquent, tous les événements ayant la même combinaison sont considérés comme des doublons.
Nous vous recommandons de mettre en œuvre des gestionnaires d'événements idempotents.
Observabilité
Des journaux détaillés pour Eventarc, Cloud Run, fonctions Cloud Run, GKE, Pub/Sub et Workflows sont disponibles via Cloud Audit Logs.
Reprise après sinistre
Vous pouvez exploiter les zones et les régions pour améliorer la fiabilité en cas d'indisponibilité. Pour en savoir plus sur la façon d'atteindre les objectifs RTO (objectif de temps de récupération) et RPO (objectif de point de récupération) pour les temps de sauvegarde et de récupération lors de l'utilisation d'Eventarc, consultez la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud.
Normes de conformité
Eventarc est conforme à ces certifications et normes.
Étape suivante
- En savoir plus sur le traitement des événements sans serveur
- Suivre l'atelier de programmation
- Créer un déclencheur pour un fournisseur, un type d'événement et une destination spécifiques
- Résoudre les problèmes