Principales fonctionnalités d'Azure Service Bus

Azure Service Bus offre des fonctionnalités de messagerie robustes pour les applications cloud, permettant une communication fiable et une architecture pilotée par messages.
Voici quelques-unes de ses principales fonctionnalités :

• Livraison de messages garantie : les messages sont livrés de manière fiable même en cas de perturbations du réseau.

• Ordre des messages et sessions : maintient l’ordre des messages au sein d’une session.

• Modèle de publication-abonnement : prend en charge l'envoi de messages à plusieurs abonnés.

• Report et Dead-lettering : gère les messages non traitables et permet une récupération ultérieure.

• Geo-Disaster Recovery : garantit une haute disponibilité avec des sauvegardes régionales.

• Intégration : Azure Service Bus s'intègre de manière transparente à d'autres services Azure tels que Azure Functions, Azure Logic Apps et Azure Event Grid, permettant aux développeurs de créer des applications cloud évolutives et fiables.

Aide au choix du SKU

Privatisation d’un Azure Service Bus avec Logic App

Description des Composants

• VNET & Subnet : Un réseau virtuel (VNET) permet de créer un réseau isolé dans Azure, tandis que les sous-réseaux (Subnet) permettent de segmenter ce réseau pour une gestion plus fine des ressources.

  • Peering : Une fonctionnalité qui permet de connecter deux réseaux virtuels Azure pour qu'ils puissent communiquer entre eux de manière sécurisée.

• Service Plan : Un plan de service qui définit les ressources et les capacités d'un service Azure, permettant de gérer les coûts et les performances.

• Logic App Standard : Un service qui permet de créer des workflows automatisés pour intégrer des applications et des services, facilitant ainsi l'automatisation des processus métiers.

• Azure Service Bus : est un service de messagerie cloud qui permet de déconnecter les applications et les services. Il facilite la communication entre différentes applications en utilisant des messages, ce qui permet une architecture plus flexible et évolutive. Ce service est particulièrement utile pour les applications distribuées, où la résilience et la scalabilité sont essentielles.

Sécurité

Utilisation d'Azure Entra ID

• Azure Entra ID: Azure Service Bus prend en charge l'authentification via Azure Entra ID, permettant ainsi une gestion centralisée des identités et un contrôle d'accès robuste.

• Authentification des Applications : Les applications peuvent utiliser Azure Entra ID pour s'authentifier auprès de Service Bus, éliminant ainsi le besoin de gérer manuellement des clés d'accès partagées.

• Principaux de Service : Les applications s'authentifiant via Azure Entra ID peuvent utiliser des principaux de service ou des identités gérées pour accéder aux ressources Service Bus.

Role-Based Access Control (RBAC)

• RBAC : Azure RBAC permet une gestion fine des autorisations en assignant des rôles spécifiques aux utilisateurs ou aux applications, définissant ainsi les actions autorisées.

• Rôles Prédéfinis : Azure propose des rôles prédéfinis pour Azure Service Bus simplifiant la délégation des accès :

• Assignation de Rôles : Les rôles peuvent être assignés à différents niveaux permettant une gestion granulaire des permissions.
  La liste suivante décrit les niveaux auxquels vous pouvez étendre l’accès aux ressources Service Bus, en commençant par la plus petite étendue :

  • File d’attente, rubrique ou abonnement : l’attribution de rôle s’applique à l’entité Service Bus spécifique.

  • Espace de noms Service Bus : l’attribution de rôle couvre toute la topologie de Service Bus sous l’espace de noms.

  • Groupe de ressources : l’attribution de rôle s’applique à toutes les ressources Service Bus sous le groupe de ressources.

  • Abonnement: l’attribution de rôle s’applique à toutes les ressources Service Bus dans tous les groupes de ressources de l’abonnement.

Chiffrement

En Transit (TLS/SSL)

• TLS/SSL : Tous les messages transmis entre les clients et Azure Service Bus sont sécurisés en utilisant TLS (Transport Layer Security). Cela garantit que les données sont protégées contre les interceptions ou modifications durant le transit.

• Chiffrement Automatique : Le chiffrement en transit est activé par défaut et ne nécessite aucune configuration supplémentaire de la part des utilisateurs.

Au Repos (Azure Storage Service Encryption)

• Chiffrement au Repos : Les données stockées dans Azure Service Bus, telles que les messages en attente dans les files d'attente ou les topics, sont chiffrées au repos en utilisant Azure Storage Service Encryption.

• Chiffrement Géré par Microsoft : Par défaut, Azure gère les clés de chiffrement, utilisant des algorithmes de chiffrement solides comme AES-256.

• Customer-Managed Keys : Les utilisateurs ont également la possibilité d'utiliser des clés gérées par le client (Customer-Managed Keys) stockées dans Azure Key Vault pour un contrôle accru sur le chiffrement.

Cas d’utilisation

Azure Service Bus prend en charge deux principaux modèles de messagerie :

• Messagerie point à point (files d'attente) : adaptée à la messagerie un à un où un seul consommateur traite chaque message.

• Messagerie de publication-abonnement (topic et subscription) : idéale pour les scénarios de type un-à-plusieurs, permettant à plusieurs consommateurs de recevoir et de traiter des messages de manière indépendante.

Files d'attente

Les files d'attente Service Bus constituent le mécanisme de messagerie le plus simple dans Azure Service Bus, fonctionnant selon le principe du premier entré, premier sorti (FIFO) . Chaque message est remis à un seul récepteur, ce qui rend les files d'attente idéales pour les tâches qui doivent être traitées par un seul consommateur, comme le traitement des commandes ou la journalisation des activités.

Caractéristiques de la file d'attente

• Prend en charge la conservation des messages jusqu'à 14 jours.

• La messagerie transactionnelle permet le traitement par lots.

• Prise en charge de la file d'attente de lettres mortes (DLQ) pour les messages non traitables.

Topics et subscriptions

Les rubriques et les abonnements dans Azure Service Bus fournissent un modèle de publication-abonnement , dans lequel les messages envoyés à une rubrique peuvent être remis à plusieurs abonnés de manière indépendante. Chaque abonnement peut appliquer un filtrage pour spécifier les messages qu’il reçoit.

Caractéristiques des rubriques et des abonnements

• Plusieurs abonnés : Un sujet peut avoir plusieurs abonnés.

• Règles de filtrage : les abonnés peuvent appliquer des règles de filtrage pour recevoir uniquement les messages pertinents.

• Communication découplée : les éditeurs n’ont pas besoin de connaître le nombre ou l’identité des abonnés.

Combiner les services

L’Azure Service Bus peut émettre des événements vers Event Grid lorsqu'il existe des messages dans une file d'attente ou un abonnement lorsqu'aucun récepteur n'est présent. Vous pouvez créer des abonnements Event Grid à vos espaces de noms Service Bus, écouter ces événements, puis réagir aux événements en démarrant un récepteur. Grâce à cette fonctionnalité, vous pouvez utiliser Service Bus dans des modèles de programmation réactive. Le scénario clé de cette fonctionnalité est que les files d'attente ou les abonnements Service Bus avec un faible volume de messages n'ont pas besoin d'avoir un récepteur qui interroge les messages en continu.

Pour activer la fonctionnalité, vous avez besoin des éléments suivants :

• Un espace de noms Service Bus Premium avec au moins une file d’attente Service Bus ou une rubrique Service Bus avec au moins un abonnement.

• Accès contributeur à l’espace de noms Service Bus. Accédez à votre espace de noms Service Bus dans le portail Azure, puis sélectionnez Contrôle d’accès (IAM) et sélectionnez l’onglet Attributions de rôles . Vérifiez que vous disposez de l’accès contributeur à l’espace de noms.

• De plus, vous avez besoin d'un abonnement Event Grid pour l'espace de noms Service Bus. Cet abonnement reçoit une notification d'Event Grid indiquant qu'il y a des messages à récupérer. Les abonnés typiques peuvent être la fonctionnalité Logic Apps d'Azure App Service, Azure Functions ou un webhook contactant une application Web. L'abonné traite ensuite les messages.

Avantages

• Découplage : Les différents services (commande, inventaire, notification) sont découplés, ce qui permet de les faire évoluer et de les maintenir indépendamment.

• Scalabilité : Azure Service Bus et Azure Event Grid permettent de gérer un grand nombre de messages et d'événements, ce qui aide à faire face à des charges variables de travail.

• Résilience : La gestion des erreurs avec des files d'attente d'erreurs permet de traiter les problèmes de manière asynchrone sans interrompre le flux principal de traitement.

• Réactivité : Azure Event Grid permet une notification en temps quasi-réel aux services abonnés, ce qui améliore la réactivité du système global.

Intégration app centrique dans un SI

L'intégration du service Azure Service Bus dans un SI peut se faire avec une approche app centric, voici quelques points à considérer :

1. Approche App Centric
   Isolation des Applications : Chaque application devrait avoir son propre espace de noms Service Bus pour éviter les interférences entre les applications et garantir une gestion indépendante des messages.
   Configuration Spécifique : Permettre à chaque application de configurer ses propres files d'attente, rubriques et abonnements selon ses besoins spécifiques.

2. Éviter le Throttling
   Scalabilité : Utiliser des files d'attente et des rubriques pour gérer les charges de travail de manière indépendante. Cela permet de répartir les messages et d'éviter la surcharge d'un seul point de terminaison.
   Limitation des Débits : Configurer des limites de débit pour chaque application afin de contrôler le nombre de messages traités par seconde, réduisant ainsi le risque de throttling.
   Surveillance et Alertes : Mettre en place des outils de surveillance pour suivre les performances et détecter les problèmes de throttling avant qu'ils n'affectent les utilisateurs.

3. Privatisation des services
   Pour renforcer la sécurité des communications, tous les messages seront acheminés et traités au sein d'un réseau privé Azure. Ce choix architectural permet de limiter l'exposition des données sensibles aux menaces externes en les maintenant à l'intérieur d'un environnement contrôlé et sécurisé. L'utilisation d'un réseau privé Azure assure une confidentialité accrue et une protection contre les accès non autorisés.

4. Sécurité et Gestion des Accès
   RBAC : Utiliser le contrôle d'accès basé sur les rôles (RBAC) pour gérer les permissions d'accès aux ressources Service Bus, garantissant que seules les applications autorisées peuvent envoyer ou recevoir des messages.
   Authentification via Azure Entra ID : Assurer que toutes les applications s'authentifient via Azure Entra ID pour une gestion centralisée des identités.

5. Intégration avec d'autres Services Azure
   Logic Apps et Azure Functions : Intégrer Azure Service Bus avec Logic Apps et Azure Functions pour automatiser les flux de travail et traiter les messages de manière asynchrone.
   Event Grid : Utiliser Azure Event Grid pour notifier les applications en temps réel des événements importants, améliorant ainsi la réactivité du système.

Côté infrastructure via Terraform

Voici un exemple simplifié pour déployer votre premier service bus sur Azure en utilisant l’IaC Terraform.

1. Le fichier de variables.tf à utiliser

variable "resource_group_name" {
  description = "Name of the resource group"
  type        = string
  default     = "resource-group-name"  # Default value can be overridden
}

variable "location" {
  description = "Azure location for the resources"
  type        = string
  default     = "West Europe"  # Default location
}

variable "service_bus_namespace_name" {
  description = "Name of the Service Bus namespace"
  type        = string
  default     = "servicebus-namespace-name"  # Default namespace name
}

variable "service_bus_topic_name" {
  description = "Name of the Service Bus topic"
  type        = string
  default     = "topic-name"  # Default topic name
}

variable "service_bus_subscription_name" {
  description = "Name of the Service Bus subscription"
  type        = string
  default     = "subscription-name"  # Default subscription name
}

2. Le fichier service_bus.tf

# Configure the Azure provider
provider "azurerm" {
  features {}
}
# Create a resource group
resource "azurerm_resource_group" "resourcegroup" {
  name     = var.resource_group_name
  location = var.location
}
# Create an Azure Service Bus namespace
resource "azurerm_servicebus_namespace" "namespace" {
  name                = var.service_bus_namespace_name
  location            = azurerm_resource_group.resourcegroup.location
  resource_group_name = azurerm_resource_group.resourcegroup.name
  sku                 = "Premium"
}
# Create a Service Bus Topic
resource "azurerm_servicebus_topic" "topic" {
  name                    = var.service_bus_topic_name
  namespace_id           = azurerm_servicebus_namespace.namespace.id
  max_size_in_megabytes   = 1024
  requires_duplicate_detection = true
  support_ordering       = true
}
# Create a Subscription for the Topic
resource "azurerm_servicebus_subscription" "subscription" {
  name                = var.service_bus_subscription_name
  topic_id            = azurerm_servicebus_topic.topic.id
  max_delivery_count  = 10 
  lock_duration       = "PT5M"
}
# Create a Shared Access Policy for the topic
resource "azurerm_servicebus_topic_authorization_rule" "rule" {
  name                = "${var.service_bus_subscription_name}-policy"
  topic_id            = azurerm_servicebus_topic.topic.id
  listen              = true
}

# Outputs
output "topic_name" {
  value = azurerm_servicebus_topic.topic.name
}
output "subscription_name" {
  value = azurerm_servicebus_subscription.subscription.name
}

Côté application

Voici deux exemples essentielles dans l’usage du service bus avec un élément clé sur la gestion des traces pour assurer le monitoring et un second permettant de mettre en place facilement une première solution Pub/Sub.

Gestion des traces

Dans cet exemple, la télémétrie de requête est signalée pour chaque message traité, avec un horodatage, une durée et un résultat (succès). La télémétrie possède également un ensemble de propriétés de corrélation. Les traces imbriquées et les exceptions signalées pendant le traitement des messages sont également marquées de propriétés de corrélation les représentant comme des « enfants » du RequestTelemetry.

async Task ProcessAsync(ProcessMessageEventArgs args)
{
    ServiceBusReceivedMessage message = args.Message;
    if (message.ApplicationProperties.TryGetValue("Diagnostic-Id", out var objectId) && objectId is string diagnosticId)
    {
        var activity = new Activity("ServiceBusProcessor.ProcessMessage");
        activity.SetParentId(diagnosticId);
        // If you're using Microsoft.ApplicationInsights package version 2.6-beta or higher, you should call StartOperation<RequestTelemetry>(activity) instead
        using (var operation = telemetryClient.StartOperation<RequestTelemetry>("Process", activity.RootId, activity.ParentId))
        {
            telemetryClient.TrackTrace("Received message");
            try 
            {
            // process message
            }
            catch (Exception ex)
            {
                telemetryClient.TrackException(ex);
                operation.Telemetry.Success = false;
                throw;
            }

            telemetryClient.TrackTrace("Done");
        }
    }
}

Exemple End-to-End

Cet exemple complet montre comment créer une rubrique avec des filtres, traiter les messages dans une session et gérer les messages hors service avec report.

var connectionString = "<Your Service Bus Connection String>";
var topicName = "OrderProcessingTopic";
var queueName = "OrderProcessingQueue";
ServiceBusClient client = new ServiceBusClient(connectionString);
ServiceBusAdministrationClient adminClient = new ServiceBusAdministrationClient(connectionString);

// 1. Create Topic and Subscriptions with Filters
await adminClient.CreateTopicAsync(topicName);
await adminClient.CreateSubscriptionAsync(topicName, "HighPriorityNotifications");
var highPriorityFilter = new SqlRuleFilter("Priority = 'High'");
await adminClient.CreateRuleAsync(topicName, "HighPriorityNotifications", new CreateRuleOptions { Filter = highPriorityFilter });

// 2. Send Messages with Session ID and Sequence Property
ServiceBusSender sender = client.CreateSender(topicName);
await sender.SendMessageAsync(new ServiceBusMessage("Order 1") { SessionId = "OrderProcessingSession", ApplicationProperties = { ["Sequence"] = 1, ["Priority"] = "High" } });
await sender.SendMessageAsync(new ServiceBusMessage("Order 2") { SessionId = "OrderProcessingSession", ApplicationProperties = { ["Sequence"] = 2, ["Priority"] = "High" } });
await sender.SendMessageAsync(new ServiceBusMessage("Order 3") { SessionId = "OrderProcessingSession", ApplicationProperties = { ["Sequence"] = 3, ["Priority"] = "High" } });

// 3. Process Messages with Ordered Sequence and Deferral for Out-of-Order
ServiceBusSessionProcessor sessionProcessor = client.CreateSessionProcessor(queueName, new ServiceBusSessionProcessorOptions());
int expectedSequence = 1;
Dictionary<int, ServiceBusReceivedMessage> deferredMessages = new Dictionary<int, ServiceBusReceivedMessage>();

sessionProcessor.ProcessMessageAsync += async args =>
{
    int messageSequence = args.Message.ApplicationProperties.TryGetValue("Sequence", out object value) ? (int)value : 0;

    if (messageSequence == expectedSequence)
    {
        Console.WriteLine($"Processing Order {messageSequence}");
        expectedSequence++;
        await args.CompleteMessageAsync(args.Message);

        while (deferredMessages.ContainsKey(expectedSequence))
        {
            var deferredMessage = deferredMessages[expectedSequence];
            Console.WriteLine($"Processing deferred Order {expectedSequence}");
            await args.CompleteMessageAsync(deferredMessage);
            deferredMessages.Remove(expectedSequence);
            expectedSequence++;
        }
    }
    else
    {
        deferredMessages[messageSequence] = args.Message;
        await args.DeferMessageAsync(args.Message);
    }
};

await sessionProcessor.StartProcessingAsync();

Conclusion

En résumé, Azure Service Bus est une solution de messagerie cloud robuste et fiable, conçue pour faciliter la communication entre différentes applications et services. Il permet de découpler les composants de l'architecture, assurant ainsi une meilleure flexibilité et évolutivité des systèmes.

Grâce à ses fonctionnalités avancées telles que la gestion des files d'attente, les sujets et abonnements, ainsi que les transferts de messages sécurisés, Azure Service Bus offre une plateforme idéale pour les scénarios nécessitant une communication asynchrone et une tolérance aux pannes élevée.

En adoptant Azure Service Bus, les entreprises peuvent améliorer la résilience de leurs applications, optimiser les performances et réduire la complexité de leur infrastructure de communication.