Table of Contents

L'évolution vers des architectures multi-clouds

Les organisations opèrent aujourd'hui sur plusieurs fournisseurs de cloud pour éviter le verrouillage des fournisseurs, optimiser les coûts et obtenir une redondance géographique. À mesure que cette réalité multicloud arrive à maturité, les limites de la communication synchrone avec les demandes deviennent claires : couplage étroit entre les services, défaillances en cascade sous charge et intégrations fragiles qui se rompent quand un fournisseur change son API. L'architecture axée sur les événements (EDA) offre une alternative convaincante en découplant les producteurs des consommateurs par des flux d'événements asynchrones.

La principale promesse d'EDA dans un déploiement multicloud est la résilience : une panne sur un fournisseur n'interrompt pas le traitement des événements sur d'autres, et les événements peuvent être rejoués après la résolution des défaillances. Ce style architectural supporte également la latence variable entre les nuages, car les événements sont tamponnés par des courtiers plutôt que d'exiger des réponses immédiates. Cependant, pour atteindre ces avantages, il faut une conception soignée autour de l'interopérabilité, de la gestion de l'identité et de la cohérence opérationnelle.

Principes fondamentaux des systèmes multi-clouds à entraînement d'événements

Découplage par des contrats d'événements

Chaque événement est un message autonome qui décrit quelque chose qui s'est passé dans le passé. Dans un système multicloud, ces événements doivent voyager au-delà des limites du cloud, ce qui signifie que le contrat entre le producteur et le consommateur doit être agnostique de plate-forme. Utilisez des registres schéma avec CloudEvents comme format d'enveloppe standard. Cela garantit qu'un service fonctionnant sur Azure peut consommer un événement produit par un service sur AWS sans connaissance approfondie du protocole.

Limites asynchrones et irrégularité

Les partitions réseau entre les nuages ne sont pas des anomalies; elles sont une condition de fonctionnement normale. Chaque consommateur d'événements doit être idéopote : traiter le même événement deux fois doit produire le même résultat que le traiter une fois. Ceci peut être obtenu en incluant un ID d'événement unique dans la charge utile et en maintenant une fenêtre de déduplication du côté du consommateur. Par exemple, un service de paiement qui reçoit un événement "ChargeSucceeded" devrait vérifier si cet ID d'événement a déjà été traité avant d'appliquer une charge.

Livraison garantie et sémantique au moins une fois

La plupart des systèmes d'événements multicloud devraient viser la livraison au moins une fois. Cela signifie que le courtier ne reconnaît un événement qu'après qu'il a été durablement maintenu, et les consommateurs ne reconnaissent le traitement qu'après que l'événement a été manipulé en toute sécurité. Bien que la livraison exactement une fois est souhaitable, il est extrêmement difficile de garantir l'existence d'un certain nombre de fournisseurs de cloud hétérogènes et introduit une complexité importante.

Ordre de l'horloge et temporal

Les événements provenant de différents nuages peuvent porter des horodatages générés par des machines avec des horloges qui ne sont pas parfaitement synchronisées. Ne comptez pas sur des horodatages d'événements pour commander dans un système multi-cloud. Au lieu de cela, utilisez des horloges logiques ou des numéros de séquence attribués par le courtier lorsque l'événement est maintenu. Si l'ordre temporel est critique, faites passer les événements liés à une partition unique sur un courtier cloud-agnostique comme Apache Kafka, où l'ordre est conservé par partition, quelle que soit l'horloge du producteur.

Choisir des courtiers d'événements pour les déploiements multi-cloud

Courtiers en nuage et en agnostie

Apache Kafka et RabbitMQ sont les deux courtiers open-source dominants qui peuvent être déployés sur n'importe quel cloud. Kafka excelle dans la diffusion d'événements à haut débit, la rétention d'événements à long terme et les capacités de replay. Il est idéal pour les systèmes qui ont besoin de retraiter les événements historiques pendant le débogage ou pour la formation de modèles. RabbitMQ est mieux adapté pour les schémas de routage complexes, les scénarios de requête-réponse et la messagerie à basse latence où le débit est modéré.

Services d'événements en nuage gérés

Chaque fournisseur de cloud majeur offre un service d'événement natif : AWS EventBridge, Google Cloud Pub/Sub et Azure Event Grid. Ces services permettent une intégration étroite avec l'écosystème de chaque cloud, réduisant ainsi les frais généraux d'exploitation. Cependant, ils introduisent le couplage avec les API propriétaires et les modèles de facturation. Pour les utiliser dans un système multicloud, vous devez construire des connecteurs qui traduisent entre le format natif et un schéma commun comme CloudEvents. Certaines équipes déploient un courtier unique comme Kafka dans un cloud central et utilisent des relais d'événement pour relier des services gérés dans d'autres nuages, créant une fédération plutôt qu'un mesh homogène.

Fédération des courtiers et modèles de mesh événementiel

Chaque nuage gère sa propre instance de courtage, et les événements de maillage avancent entre eux en fonction des règles de routage. Ce modèle réduit les coûts de bande passante entre nuages et permet à chaque région de fonctionner indépendamment. Des outils comme Apache Pulsar, Solace PubSub+ et Confluent Cluster Linking supportent la géo-réplication et la fédération natives. Lors de l'utilisation de Kafka, vous pouvez configurer MirrorMaker pour reproduire des sujets à travers des grappes dans différents nuages, bien que cela introduit une cohérence éventuelle entre les régions.

Conception des schémas et des contrats d'événements

Les événements Cloud comme enveloppe standard

CloudEvents, une spécification hébergée par le CNCF, définit un ensemble standard d'attributs pour décrire les événements : , , , , et . En appliquant CloudEvents à chaque événement d'un système multicloud, vous obtenez un moyen uniforme de parcourir, filtrer et vérifier les événements entre différents courtiers et les frontières du cloud. Tous les grands services d'événements cloud prennent maintenant en charge CloudEvents nativement, et de nombreux SDK fournissent des sérialisateurs pour les protocoles tels que HTTP, AMQP, MQTT et Kafka.

Registre du schéma et version

Sans un registre de schéma partagé, les producteurs et les consommateurs dans différents nuages peuvent s'écarter silencieusement. Un producteur peut ajouter un nouveau champ à un événement auquel un consommateur s'attend, mais comme le consommateur ne sait pas ce changement, il peut abandonner l'événement. Utilisez Apache Avro, Protocol Buffers ou JSON Schema avec un registre central qui renforce la compatibilité avec les données en arrière. Chaque type d'événement doit porter un numéro de version dans l'extension CloudEvents ou dans la charge utile elle-même.

Règles de compatibilité au niveau du terrain

Lorsque vous évoluez dans les nuages, suivez ces règles pour éviter de briser les consommateurs :

  • Les nouveaux champs doivent être optionnels avec des valeurs par défaut qui maintiennent le même comportement que le schéma précédent.
  • Les champs ne doivent jamais être supprimés, car ils sont considérés comme facultatifs et ne peuvent être retirés de la documentation.
  • Les types de données ne doivent pas changer. Si un champ était entier, il doit rester entier.
  • Si des changements structurels sont nécessaires, créez un nouveau type d'événement avec un nouvel attribut de type CloudEvents plutôt que de modifier celui existant.

Modèles de mise en œuvre pour les systèmes d'événements multi-cloud

Événement secouant à travers les nuages

Dans un environnement multicloud, ce modèle permet à différents services de reconstruire leur état indépendamment en rejouant le même flux d'événements. Un magasin d'événements central, généralement soutenu par Kafka ou une base de données durable, persiste le journal des événements. Chaque service maintient son propre modèle de lecture, qu'il peut reconstruire en rejouant les événements à partir du journal central. Cela élimine le besoin de transactions réparties entre les nuages, car chaque service converge finalement vers l'état correct.

Ségrégation des responsabilités des commissions

Dans un système d'événements multicloud, les commandes sont produites dans un flux d'événements et une ou plusieurs commandes de services traitent les commandes pour mettre à jour le modèle d'écriture. Les modèles de lecture sont construits à partir du flux d'événements et peuvent être déployés dans plusieurs nuages pour un accès à faible latence par les consommateurs régionaux. Le modèle d'écriture a besoin de solides garanties de cohérence, de sorte qu'il est généralement déployé dans une seule région nuageuse. Les modèles de lecture peuvent être reproduits globalement en utilisant le flux d'événements comme source unique de vérité.

Modèle de Saga pour les transactions distribuées

Les processus commerciaux à long terme qui couvrent plusieurs nuages ne peuvent pas compter sur les transactions ACID. Au lieu de cela, utilisez le modèle de saga, où chaque étape du processus publie un événement qui déclenche l'étape suivante. Si une étape échoue, un événement compensatoire est publié pour faire reculer les étapes précédentes. Par exemple, une saga de réservation à travers AWS et Azure pourrait fonctionner comme suit:

  • Service sur AWS publie l'événement "Réservation demandée" à Kafka.
  • Service on Azure traite l'événement, tient un inventaire et publie l'événement "InventoryHeld".
  • Service sur AWS traite "InventoryHeld", crée un ordre, et publie "OrderCreated" événement.
  • Si la création de l'ordre échoue, un événement « CompenserInventory » est envoyé pour libérer l'inventaire détenu.

La saga assure que chaque participant dans chaque nuage exécute son action exactement une fois, avec des actions de compensation pour maintenir la cohérence.

Considérations de sécurité pour les systèmes multi-clouds

Chiffrement en transit et au repos

Tout le trafic d'événements entre les nuages doit être chiffré avec TLS 1.2 ou plus. Les liens de réplication entre courtiers doivent utiliser l'authentification mutuelle TLS. Les événements persistants dans le journal de courtage ou dans les magasins en aval doivent être chiffrés au repos à l'aide de clés gérées par un fournisseur de cloud ou de clés gérées par le client (CMK).

Authentification et autorisation entre les nuages

Chaque fournisseur de cloud possède son propre système d'identité : IAM sur AWS, Azure Active Directory et Cloud IAM sur GCP. Pour authentifier un producteur dans un cloud à un courtier dans un autre, utilisez soit des jetons à courte durée de vie générés par l'identité du producteur et validés par le courtier, ou utilisez un certificat client partagé. Évitez les lettres d'identité statiques à longue durée de vie telles que les clés API qui sont intégrées dans le code d'application.

Vérification Logging et traçabilité des événements

Chaque événement franchissant une limite nuageuse devrait porter un identifiant de trace qui se propage dans tout traitement en aval. Utilisez l'extension CloudEvents ou un mécanisme similaire pour le traçage distribué. Les journaux de vérification centralisés devraient capturer l'identifiant de l'événement, le nuage source, le nuage cible, l'horodatage et le résultat du traitement.

Surveillance et observation dans les limites des nuages

Statistiques centralisées des événements

Les mesures globales des courtiers en événements dans tous les nuages dans un seul système de surveillance.

  • Taux de production des événements par producteur et par type
  • Le retard par groupe de consommateurs et par partition
  • Latences croisées de la production à la consommation
  • Taux de défaillance et raisons de l'échec
  • Utilisation du disque par les courtiers et débit du réseau

Utilisez Prométhée avec Thanos ou Grafana Mimir pour interroger les métriques sur plusieurs déploiements cloud sans perdre de contexte.

Traçage distribué pour les événements à travers le nuage

Lorsqu'un événement provient d'un nuage et déclenche une chaîne de traitement dans d'autres nuages, il est difficile de déboguer les problèmes de performance sans tracer distribué. Déployer des collecteurs OpenTelemetry dans chaque nuage qui font passer les données de trace à un backend central comme Jaeger ou Grafana Tempo. Assurez-vous que chaque gestionnaire d'événements propage le contexte de trace, même lorsque le gestionnaire est une fonction sans serveur qui s'équilibre entre les invocations.

Vérifications de santé de bout en bout

Planifiez des événements synthétiques qui traversent l'ensemble du pipeline d'événement de la production dans un nuage à la consommation dans un autre. Mesurez le temps de trajet aller-retour et signalez toute anomalie. Si l'événement synthétique n'arrive pas dans la fenêtre prévue, déclenchez une alerte. Ce type de contrôle de santé capture des défaillances silencieuses telles qu'une règle de pare-feu mal configurée, un disque de courtage en état complet, ou une incompatibilité de schéma qui ne serait pas visible à partir des seules mesures.

Cas d'utilisations réelles dans le monde

Orchestration de l'ordre multi-cloud

Une entreprise de commerce électronique mondial traite les commandes qui impliquent la gestion des stocks sur AWS, le traitement des paiements sur Azure et la logistique d'expédition sur GCP. Chaque étape du cycle de vie de commande est un événement qui se déroule à travers un cluster Kafka partagé déployé sur trois nuages. Une commande passée dans la région de l'Ouest américain produit un événement «OrderPlaced» qui est consommé par les services d'inventaire sur AWS, qui produit ensuite des événements «InventoryAlloted». Le service de paiement sur Azure consomme l'événement d'allocation et traite la charge, produisant «PaiementSettled». Le service d'expédition sur GCP consomme enfin le règlement et prévoit la livraison.

Ingestion de données IoT multi-cloud

Chaque usine envoie des données à la région cloud la plus proche, qui peut être AWS en Amérique du Nord, Azure en Europe ou GCP en Asie. Chaque courtier régional ingère les données brutes du capteur et les publie dans un flux local d'événements. Un maillage d'événements global reproduit les événements clés à un cluster central de Kafka où les data scientists utilisent des modèles de détection d'anomalies. Les résultats traités sont ensuite publiés par le maillage aux courtiers régionaux, qui envoient des commandes aux actionneurs d'usine. L'ensemble du pipeline doit gérer la latence variable entre les régions tout en assurant que les événements de commande soient livrés pour chaque capteur.

Pièges courants et comment les éviter

En supposant une latence homogène entre les nuages

La latence réseau transcloud peut varier de 10ms à plus de 500ms selon la distance géographique, la congestion d'Internet et les accords de pairage de fournisseurs de cloud. Concevoir des délais d'événement, réessayer les intervalles et les délais de consommation basés sur des mesures plutôt que sur des hypothèses.

S'appuyer sur la géoréplication du courtier pour une forte cohérence

Si un producteur d'un nuage écrit un événement et lit immédiatement depuis un consommateur dans un autre nuage, le consommateur peut ne pas voir l'événement pendant des secondes ou des minutes. Ne pas concevoir des workflows qui nécessitent une forte cohérence de lecture après écriture au-delà des limites du nuage. Au lieu de cela, acheminer le consommateur du producteur vers le même intermédiaire pour cette opération spécifique, ou accepter éventuellement la cohérence comme une contrainte de conception.

Visibilité des coûts de la négation des coûts de la lutte contre les nuages croisés

Chaque événement qui traverse une frontière nuageuse entraîne des frais d'évacuation du fournisseur source et des frais d'entrée du fournisseur de destination. Estimez le volume mensuel de l'événement et la taille moyenne de la charge utile pour calculer les coûts projetés. Considérez des stratégies comme la compression des charges utiles d'événements, la réduction de la fréquence des événements ou l'exécution d'un circuit de connexion directe dédié entre les principaux déploiements de cloud pour réduire les taux d'évacuation d'Internet public.

Conclusion

La conception de systèmes axés sur les événements pour les déploiements multiclouds nécessite un passage de la pensée axée sur l'infrastructure à la conception contractuelle. Les schémas normalisés, les consommateurs idéopontes et la fédération de courtiers forment la base de systèmes qui peuvent survivre à des pannes de fournisseurs, des partitions de réseau et des modèles de charge imprévisibles.

Commencez par adopter CloudEvents comme enveloppe universelle, déployez un courtier en cloud-agnostic comme Apache Kafka ou Pulsar dans au moins deux nuages, et construisez des contrôles de santé synthétiques qui valident le pipeline de bout en bout. Au fil du temps, prolongez le système avec des services d'événements gérés où ils fournissent un avantage opérationnel clair, mais gardez toujours le contrat d'événement indépendant de tout fournisseur.