Système de média cloud Gridwich

Les pipelines Gridwich ingèrent, traitent, stockent et livrent des ressources multimédias à l’aide de deux nouvelles méthodes, le sandwich Azure Event Grid et le sandwich Terraform.

Architecture

L’architecture Gridwich comprend deux sandwichs qui répondent aux exigences de traitement asynchrone des événements et d’infrastructure en tant que code :

• Le sandwich Event Grid isole les processus à distance et de longue durée, tel l’encodage multimédia, du système de flux de travail de saga externe, en les mettant en sandwich entre deux gestionnaires Event Grid. Ce sandwich permet au système externe d’envoyer un événement de demande, de surveiller des événements planifiés et d’attendre une réponse de réussite ou d’échec qui peut arriver entre quelques minutes et plusieurs heures plus tard.

  

  Téléchargez un fichier Visio de cette architecture.

• Le sandwich Terraform est un modèle Terraform à plusieurs étapes mis à jour pour prendre en charge une infrastructure en tant que de code. La séparation des mises en production de l’infrastructure et des logiciels signifie que l’application Azure Functions doit être mise en production et opérationnelles avant que Terraform puisse déployer l’abonnement Event Grid. Pour résoudre ce problème, le pipeline CI/CD inclut deux tâches Terraform :

  

  • Terraform 1 crée toutes les ressources à l’exception des abonnements Azure Event Grid.
  • Terraform 2 crée les abonnements Event Grid une fois que le logiciel est en cours d’exécution.

  De cette façon, Terraform peut entièrement gérer et déployer l’infrastructure de la solution, même si les ressources Azure ne peuvent pas toutes être créées avant le déploiement des artefacts logiciels.

Workflow

Le processus de demande et de réponse Gridwich couvre les demandes suivantes :

• Création
• Transport
• Réception
• Distribution aux composants Gridwich
• Accusé de réception et actions
• Réponses

Les étapes suivantes décrivent le processus de demande et de réponse entre un système externe et Gridwich. Dans Gridwich, le système externe est un système d’orchestration de flux de travail de GAM et de saga. Pour connaître les formats exacts des événements de message d’opérations Gridwich, consultez Formats de message Gridwich.

1. Le système externe crée une demande et l’envoie au répartiteur de demandes.

2. Le répartiteur de demandes est chargé de distribuer les demandes aux écouteurs de demande Gridwich dans un modèle de publication-abonnement traditionnel. Dans cette solution, le répartiteur de demandes est Azure Event Grid. Toutes les demandes sont encapsulées à l’aide du schéma d’événement Event Grid.

3. L’application Azure Functions Gridwich consomme les événements d’Event Grid. Pour un meilleur débit, Gridwich définit un point de terminaison HTTP en tant que un modèle d’envoi (push) qu’Event Grid démarre, plutôt que le modèle d’interrogation de liaison Event Grid fourni par Azure Functions.

4. L’application Azure Functions lit les propriétés d’événement et distribue les événements à des parties du code Gridwich qui gèrent ce type d’événement et cette version.

5. Tout gestionnaire opérant avec la demande en cours utilise la classe commune EventGridHandlerBase pour envoyer immédiatement un message Accusé de réception lors de la réception de la demande. Le gestionnaire distribue ensuite le travail à la classe dérivée.

   Les flux de travail de demande Gridwich peuvent être synchrones ou asynchrones par nature. Pour les demandes faciles à effectuer et rapides à exécuter, un gestionnaire synchrone accomplit le travail et retourne l’événement Réussite ou Échec presque immédiatement après l’envoi de l’Accusé de réception.

   Pour les demandes de longue durée, un gestionnaire asynchrone évalue la demande, valide les arguments et lance l’opération de longue durée. Le gestionnaire retourne ensuite une réponse Planifiée pour confirmer qu’il a demandé l’activité de travail. Lors de l’exécution de l’activité de travail, le gestionnaire de demandes est chargé de fournir un événement Réussite ou Échec terminé pour le travail.

   Le service de publication d’événements communique les messages Accusé de réception, Échec, Planification ou Réussite au répartiteur de demandes Event Grid.

6. L’éditeur d’événements dans la fonction Azure envoie l’événement de réponse à une rubrique Event Grid, qui fait office de répartiteur de messages fiable. Le système externe s’abonne à la rubrique et consomme les messages. La plateforme Event Grid fournit sa logique de nouvelle tentative normale pour la publication sur le système externe.

Ordre des messages

Si un Accusé de réception précède les réponses Réussite et Planifiée, Gridwich ne garantit pas qu’une réponse Planifiée précède toujours la réponse Réussite correspondante. Une séquence de réponse valide peut être Accusé de réception > Planifiée > Réussite ou Accusé de réception > Réussite > Planifiée.

Échecs des requêtes

Les échecs de demande peuvent être dus à des demandes incorrectes, à des conditions préalables manquantes, à des échecs de traitement, à des exceptions de sécurité ou à des exceptions non gérées. Presque tous les échecs ont le même formulaire de message, et incluent la valeur de contexte d’opération d’origine. La classe commune EventGridHandlerBase envoie généralement des réponses Échec à Event Grid via l’interface de l’éditeur d’événements de fonction Azure. Application Insights journalise également les échecs via une journalisation structurée.

Contexte de l’opération

Le système externe peut générer des milliers de demandes par jour, par heure ou par seconde. Chaque événement de demande envoyé à Gridwich doit inclure une propriété d’objet JSON nommée operationContext.

Si une demande contient un contexte d’opération tel que {"id"="Op1001"}, chaque réponse de Gridwich doit inclure un contexte d’opération opaque correspondant, que la demande soit de courte ou de longue durée. Ce contexte d’opération persiste pendant la durée de vie des demandes même de très longue durée.

L’exigence de réponse a trait à un objet JSON « correspondant » plutôt qu’« identique ». Des fonctionnalités de Gridwich telles que la mise en sourdine du contexte tirent parti du fait que le système externe traite l’objet JSON renvoyé de manière descendante.

Plus précisément, le système externe ne présente :

• Aucune dépendance du classement des propriétés. Gridwich peut donc renvoyer un objet avec les mêmes propriétés, éventuellement dans un ordre différent. Par exemple, {"a":1,"b":2} ou {"b":2,"a":1}.

• Aucun problème avec les propriétés supplémentaires présentes. Gridwich, après avoir reçu {"b":2,"a":1}, peut dont retourner {"a":1,"b":2,"~somethingExtra":"yes"} de manière valide. Pour réduire le risque de collisions, Gridwich préfixe les noms des propriétés ajoutées avec un tilde (~), par exemple ~muted.

• Aucune dépendance de la mise en forme du JSON. Par exemple, il n’existe aucune hypothèse quant à l’emplacement où un remplissage d’espaces blancs peut se trouver dans la représentation sous forme de chaîne du JSON. Gridwich s’appuie sur cette absence de dépendance de mise en forme en compressant les espaces superflus dans les représentations sous forme de chaîne des objets JSON. Consultez JSONHelpers.SerializeOperationContext.

Participants de saga et contexte d’opération

Dans le système d’orchestration de saga de Gridwich, chaque participant de saga contribue au système via une ou plusieurs activités de travail. Chaque participant de saga travaille indépendamment des autres, et plusieurs participants de saga peuvent agir sur une seule demande.

Chacun des participants de saga doit conserver le contexte de l’opération, mais peut l’implémenter différemment. Par exemple :

• Les opérations synchrones de courte durée conservent le contexte de l’opération.
• Le service Stockage Azure fournit une propriété de chaîne opaque appelée ClientRequestId pour la plupart des opérations.
• Certains services ont une propriété Job.CorrelationData.
• D’autres API cloud offrent des concepts similaires à un contexte d’opération opaque qu’ils peuvent retourner quand ils signalent la progression, l’achèvement ou l’échec.

Pour plus d’informations sur les sagas et les participants de saga, consultez Orchestration de saga.

Gestionnaires synchrones et asynchrones

Chaque gestionnaire d’événements dans le système utilise une classe commune EventGridHandlerBase pour fournir des services génériques tels que l’accusé de réception de demande, la gestion des échecs et la publication des événements de réponse. Le service de publication d’événements communique les messages Accusé de réception, Échec, Planification ou Réussite au répartiteur de demandes Event Grid.

Tout gestionnaire qui prévoit de travailler avec la demande actuelle doit fournir un accusé de réception quand il la reçoit. La classe de base envoie immédiatement un message Accusé de réception, puis distribue le travail à la classe dérivée.

Traitement d’événement synchrone

Pour les demandes faciles à effectuer et rapides à exécuter, le gestionnaire accomplit le travail de manière synchrone et retourne l’événement Réussite avec son contexte d’opération presque immédiatement après l’envoi de l’Accusé de réception.

.

Par exemple, le ChangeBlobTierHandler est un simple flux synchrone. Le gestionnaire obtient un objet de transfert de données (DTO) Demande, appelle et attend un service unique pour accomplir le travail, et retourne une réponse Réussite ou Échec.

Traitement d’événement asynchrone

Certaines demandes sont de longue durée. Par exemple, l’encodage de fichiers multimédias peut prendre des heures. Dans ces cas, un gestionnaire de demandes asynchrones évalue la demande, valide les arguments et lance l’opération de longue durée. Le gestionnaire retourne ensuite une réponse Planifiée pour confirmer qu’il a demandé l’activité de travail.

Lors de l’exécution de l’activité de travail, le gestionnaire de demandes est chargé de fournir un événement d’accomplissement Réussite ou Échec pour le travail. Bien qu’il reste sans état, le gestionnaire doit récupérer le contexte d’opération d’origine et le placer dans la charge utile de message d’événement Terminé.

Par exemple, le BlobCopyHandler affiche un simple flux asynchrone. Le gestionnaire obtient un objet de transfert de données (DTO) Demande, appelle et attend un service unique pour démarrer le travail, puis publie une réponse Planifiée ou Échec.

Pour accomplir le flux de demande de longue durée, le BlobCreatedHandler consomme l’événement de plateforme Microsoft.Storage.BlobCreated, extrait le contexte d’opération d’origine et publie une réponse d’accomplissement Réussite ou Échec.

Actions de longue durée

Quand Gridwich déploie une nouvelle application de fonction, celle-ci peut annuler des processus de longue durée en cours. Si ces processus se terminent brusquement, ils n’ont pas d’état et aucun rapport n’est renvoyé à l’appelant. Gridwich doit déployer de nouvelles applications de fonction tout en gérant en douceur la transition pour les fonctions de longue durée sans manquer de messages.

La solution doit :

• Ne pas conserver l’état des instances en cours d’exécution de l’application Gridwich.
• Ne pas interrompre pas des processus en raison d’un nouveau déploiement ou d’un nouveau message demandant la même activité.
• Ne pas appeler de charges de travail Azure supplémentaire, telles que Durable Functions, Function Apps, Logic Apps ou Azure Container Instances.

Gridwich utilise un déplacement d’emplacement et des jetons d’annulation Azure Functions pour répondre à ces exigences de fonctions de longue durée fiables.

Le diagramme suivant montre le fonctionnement de la plupart des tâches de Gridwich. La zone verte représente une tâche que Gridwich transmet à un service externe. Gridwich réagit ensuite à l’état d’une manière pilotée par l’événement. La zone rouge affiche une fonction de longue durée sur Gridwich.

Le runtime Functions ajoute le jeton d’annulation quand l’application s’arrête. Gridwich détecte le jeton et retourne des codes d’erreur pour toutes les demandes et les processus en cours d’exécution.

Le déploiement d’emplacement déploie de nouvelles versions de logiciels. L’emplacement de production a l’application en cours d’exécution, et l’emplacement de préproduction a la nouvelle version. Azure effectue une série d’étapes de déploiement, puis permute les instances d’emplacement. L’ancienne instance redémarre à la dernière étape du processus.

Gridwich attend 30 secondes après le remappage des noms d’hôtes. Ainsi, pour les fonctions déclenchées par HTTP, Gridwich garantit qu’au moins 30 secondes s’écoulent avant le redémarrage de l’ancien emplacement de production. D’autres déclencheurs peuvent être contrôlés par des paramètres d’application qui n’ont pas de mécanisme d’attente sur des mises à jour de paramètres d’application. Ces fonctions risquent d’être interrompues si l’exécution démarre juste avant le redémarrage de l’ancien emplacement de production.

Pour plus d’informations, consultez Ce qui se produit lors d’un échange d’emplacement pour Azure Functions et Emplacements de déploiement Azure Functions.

Composants

La solution de traitement multimédia Gridwich utilise Azure Event Grid, Azure Functions, Stockage Blob Azure, Azure Logic Apps et Azure Key Vault. Les processus d’orchestration de CI/CD et de saga utilisent Azure Repos, Azure Pipelines et Terraform.

• Azure Event Grid gère le routage des événements Gridwich, avec deux tâches Event Grid en sandwich qui permettent le traitement asynchrone des événements multimédias. Event Grid est un point de terminaison de remise de demande extrêmement fiable. La plateforme Azure assure la durée de bon fonctionnement et la stabilité nécessaires du points de terminaison de remise de demande.

  Gridwich encapsule les événements dans l’objet de propriété Event.Data du schéma Event Grid, qui est opaque pour le répartiteur Event Grid et la couche de transport. Gridwich utilise également les champs d’objet eventType et dataVersion pour router les événements. Pour que le répartiteur de demande Event Grid puisse être remplacé par d’autres répartiteurs d’événements de publication-abonnement, Gridwich dépend le moins possible de champs d’événements et n’utilise pas les champs topic ou subject.

• Azure Functions vous permet d’exécuter du code déclenché par un événement sans approvisionner ou gérer explicitement l’infrastructure. Gridwich est une application Azure Functions qui héberge l’exécution de diverses fonctions.

• Le service Stockage Blob Azure offre un stockage cloud évolutif et rentable pour des données non structurées telles que des éléments multimédias. Gridwich utilise des conteneurs et des objets blob de blocs de Stockage Azure.

• La solution Azure Key Vault protège les clés de chiffrement, les mots de passe et autres secrets qu’Azure et des applications services tiers utilisent.

• Azure DevOps est un ensemble de services de développement et d’exploitation, incluant des dépôts de code basés sur Git et des pipelines de build et de mise en production automatisés, qui s’intègrent avec Azure. Gridwich utilise Azure Repos pour stocker et mettre à jour les projets de code, et Azure Pipelines pour les flux de travail de CI/CD et autres.

• Terraform est un outil open source qui utilise une infrastructure en tant que code pour approvisionner et gérer des infrastructures et des services.

Autres solutions

• L’extension Durable Functions, qui a un magasin d’état intégré pour les opérations de longue durée, peut également fournir un contexte d’opération opaque. L’extension Durable Functions pourrait créer une série de tâches au sein d’une opération, et enregistrer le contexte de l’opération en tant qu’entrée ou sortie pour l’opération. En fait, Gridwich pourrait utiliser l’extension Durable Functions pour toutes les activités de travail, mais cette approche augmenterait la complexité du code.

• Vous pouvez obtenir un meilleur découplage de l’infrastructure Event Grid en refactorisant la classe EventGridHandlerBase en une classe RequestHandlerBase, et en supprimant toute liaison à des objets ou types Event Grid. Cette classe refactorisée ne traiterait que des DTO de base, et non des types d’objets spécifiques du transport. De même, le IEventGridDispatcher peut devenir un IResponseDispatcher avec une implémentation de EventGridDispatcher spécifique.

• La bibliothèque Gridwich.SagaParticipants.Storage.AzureStorage contient également des services de stockage que d’autres participants de la saga utilisent. Le fait d’avoir les interfaces dans un projet de base évite les problèmes d’inversion de contrôle (IoC), mais vous pourriez extraire les interfaces dans une bibliothèque de passerelle d’infrastructure de stockage principale distincte.

• L’application de fonction Gridwich utilise une injection de dépendance pour inscrire un ou plusieurs gestionnaires de demandes pour des types d’événements et des versions de données spécifiques. L’application injecte le EventGridDispatcher avec la collection de gestionnaires d’événements Event Grid, et le répartiteur interroge les gestionnaires pour déterminer ceux qui traiteront l’événement.

  Vous pourriez également utiliser le mécanisme d’abonnement et de filtrage des événements que la plateforme Event Grid fournit. Ce mécanisme impose un modèle de déploiement 1:1, où une fonction Azure héberge un seul gestionnaire d’événements. Bien que Gridwich utilise un modèle 1:plusieurs, son architecture propre signifie que la refactorisation de la solution pour 1:1 ne serait pas difficile.

• Pour obtenir un alternative aux microservices plutôt que l’architecture monolithique Gridwich, consultez Alternative aux microservices.

Détails du scénario

Un conglomérat bien connu dans le domaine des médias et du divertissement a remplacé son service de streaming vidéo local par une solution basée sur le cloud pour l’ingestion, le traitement et la publication de ressources vidéo. Les principaux objectifs de la société étaient de tirer parti de la capacité, du coût et de la flexibilité du cloud Azure aux fins suivantes :

• Ingérer des fichiers vidéo bruts, les traiter et les publier, et répondre à des demandes de médias.
• Améliorer à la fois l’encodage et les nouvelles fonctionnalités d’acquisition et de distribution à grande échelle, et avec une approche proprement architecturée.
• Implémenter l’intégration et la livraison continues (CI/CD) pour le pipeline de gestion des applications mobiles (GAM).

Pour atteindre ces objectifs, l’équipe d’ingénierie de Microsoft a développé Gridwich, une infrastructure de traitement d’événements sans état pilotée par un système d’orchestration de flux de travail de saga externe.

Cas d’usage potentiels

L’équipe d’ingénierie a développé Gridwich pour s’aligner sur des principes et des normes sectorielles dans les domaines suivants :

• Architecture monolithique propre
• Structure et dénomination des projets
• CI/CD
• Utilisation et mise à l’échelle du service Stockage Azure
• Logging

Le système Gridwich représente les meilleures pratiques pour le traitement et la livraison de ressources multimédias sur Azure. Bien que le système Gridwich soit spécifique au média, l’infrastructure de traitement des messages et de gestion des événements peut s’appliquer à tout flux de travail de traitement d’événements sans état.

Déployer ce scénario

• Accédez au dépôt Gridwich sur GitHub.
• Suivez toutes les procédures, en commençant par la configuration d’Azure DevOps.

Ressources associées

• Projet de démarrage de Terraform pour Azure Pipelines
• Exemple de fonction Azure avec Event Grid et sandwich Terraform. Abonnez une fonction Azure à des événements Event Grid via Terraform à l’aide d’un sandwich Terraform.
• MediaInfoLib avec Stockage Azure. Azure Functions et exemples de console qui utilisent .NET Core multiplateforme pour récupérer un rapport sur un fichier multimédia stocké dans le service Stockage Azure.
• Visionneuse Event Grid Blazor. Application de visionneuse Event Grid, utilisant Blazor et Signalr, avec la prise en charge d’autorisation Microsoft Entra.
• Fonction Azure avec identité du service géré pour Stockage Azure. Utilisez une identité de service géré entre Azure Functions et Stockage Azure.