Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Focus sur Azure Service Bus

Poster un commentaire

Azure Service bus est un service de messagerie Azure sophistiqué que j’aimerai présenter à travers une série d’articles.

Celui va donner une vision large maille de l’outil. Il s’agit de comprendre de quoi il s’agit. Puis suivront des articles plus orientés développeurs.

Il y a tout de même une page dédiée:

https://azure.microsoft.com/en-us/documentation/services/service-bus/

On y trouve beaucoup d’information utiles.

Présentation générale

On s’intéresse au problème suivant:

Comment permettre à des applications de communiquer entre elles malgré diverses contraintes:

  • Connectées en permanence  ou pas
  • Flux de données plus ou moins important ou volumineux
  • Elles ne travaillent pas au même rythme
  • Système hybride déployé dans le cloud ou en on premise
  • Déploiement mondial et mobile
  • Panel d’application non homogène et très varié: SQL Server, SharePoint, LOB…
  • Couche de sécurité, pare-feu…

Azure Service Bus (ASB pour la suite) est un service Azure dédié à ce problème. Il ne s’agit en fait pas d’une technologie, mais d’un ensemble de 4 outils spécialisés :

  1. File d’attente (queue)
  2. Rubrique (topics)
  3. Relai (Relay Service)
  4. Concentrateur d’événement (event hubs)
    Flux ingress d’événements et de télémétrie à grande échelle, faible latence et haute disponibilité (SLA 99.9%)

Le service vous est facturé à l’usage, c’est à dire à la quantité de données qui circulent.

 

L’accès à ASB peut s’établir de différentes façons:

  • WCF (Windows Communication Framework)
  • Un SDK Service Bus qui existe pour .Net, Java ou Node…
  • Une Api REST

 

Pour finir sachez qu’ASB est proposé en 3 modes:

  1. Basic
  2. Standard
  3. Premium

Les options et les prix sont bien entendu différents, le mieux est de consulter la doc:

https://azure.microsoft.com/fr-fr/documentation/articles/service-bus-pricing-billing/

La file d’attente

Il s’agit d’un service de communication unidirectionnelle entre une source et une destination unique. Le service peut stocker les messages envoyés jusqu’à leur réception.

2016-04-02_18-31-48

Un émetteur déployé dans votre infra ou sur Azure pose des messages dans une queue. Ceux-ci sont entreposés jusqu’à ce qu’un récepteur les lisent dans l’ordre où ils sont arrivés. La pile est une pile FIFO.

Le message est donc lu de façon asynchrone par le client. C’est cet asynchronisme qui est intéressant dans le service.

 

Le message peut être lu en plusieurs modes:

  • ReceiveAndDelete
    Retire le message de la file d’attente pour le lire. Il est alors supprimé. Evidemment si le récepteur rencontre un problème, le message est définitivement perdu.
  • PeekLock
    La lecture peekLock retire le message de la file d’attente. Il n’est pas supprimé il est juste rendu invisible par les éventuels autres destinataires. Trois choses peuvent ensuite se passer:
  1. Le récepteur parvient à lire et traiter le message. Il est supprimé de la file d’attente
  2. Le récepteur ne peut pas traiter le message. Il est abandonné et remis à la disposition d’autres destinataires
  3. On a plus de nouvelles du récepteur depuis un certain temps. La file d’attente considère le message comme abandonné et il est replacé dans la pile.

 

Un message à la structure suivante:

2016-04-02_18-45-39

Un identifiant qu’il garde tant qu’il est vivant. Le message est ensuite structuré par une liste de propriétés et un corps qui peut contenir rien ou bien tout ce qui est pertinent comme une image.

Le message ne peut être lu que par un seul destinataire. Ce n’est pas du multicast comme le propose la rubrique.

Les rubriques

Service de communication unidirectionnelle lui aussi. La différence est que cette fois un même message peut être traité par plusieurs récepteurs, on est en multicast.

2016-04-05_23-44-34

Les émetteurs émettent des messages vers une rubrique (topic). Un récepteur peut créer un abonnement à tous ou partie des messages de la rubrique en fournissant un filtre, créant ainsi un abonnement. Chaque abonnement reçoit une copie des messages qui le concerne. L’abonnement lui-même fonctionne comme une pile.

Comme on le voit, plusieurs récepteurs peuvent s’abonner à un même abonnement.

Imaginons un message structuré ainsi:

2016-04-02_19-44-24

On pourrait parfaitement imaginer des filtres du style:

  • Société == Fabrikam AND Ville != Paris
    Les messages qui concerne la filiale parisienne de Fabrikam
  • Pays == France
    Les messages concernant la France
  • Ville != Londres
    Tous les messages, saufs ceux concernant Londres
  • True
    Tous les messages

Comme pour la file d’attente, on peut faire des lectures ReceiveAndDelete et PeekLock dans les abonnements.

 

Note: on doit prendre au moins un abonnement standard pour disposer des rubriques

Relais

La communication est bidirectionnelle cette fois. Le relais, comme l’indique son nom, est un intermédiaire entre services dans une architecture hybride. Il fournit un point de terminaison dans Azure à un service éventuellement dans votre infra. Par ce point de terminaison des clients répartis dans le monde entier accèdent à votre service:

2016-04-02_16-48-21

Un tel service est intéressant lorsque la communication entre l’émetteur et le récepteur est compliquée par la présence de pare-feu, lorsque l’un des agents n’a pas une IP fixe, problème de traduction d’adresse réseau… Le relais offre un point de terminaison fixe à travers lequel la communication pourra s’établir de façon sécurisée.

Contrairement aux autres services, il s’agit d’une service synchrone.

 

Un exemple classique c’est le cas des systèmes de réservation. On souhaite y accéder depuis le monde entier à travers des périphériques très divers et en général mobiles. Le relais est une solution de choix à ce problème.

Concentrateur d’événements

Le service est spécialisé dans la réception de flux ingress d’événements ou d’information de télémétrie à grande échelle, faible latence et haute disponibilité (SLA 99.9%).

2016-04-02_17-24-59

Le service a été validé par Microsoft pour ingérer plusieurs millions d’événements par seconde. Le cas d’usage typique est bien entendu la télémétrie et les objets connectés.

Lettre morte et messages empoisonnés

On a constaté la similitude entre la file d’attente et la rubrique. Toutes deux peuvent faire face à un même problème: que faire des messages que personne ne parvient à traiter et qui finit par bloquer la pile?

Il existe en fait une deuxième file d’attente appelée pile lettre-morte (dead letter queue ou DLQ)  automatiquement créée par le Framework ASB dans laquelle ce type de message peut être routé. Le message sort ainsi de la pile courante et ne sera donc pas réexaminé sans fin bloquant ainsi tout le processus de traitement de la pile.

 

Un message reçoit une propriété indiquant le nombre de fois où il a été traité. Cette propriété est incrémentée à chaque lecture PeekLock qui se traduit par un abandon ou une expiration. Une fois un seuil (ajustable) atteint, le message est poussé automatiquement dans la DLQ.

D’autres mécanismes automatiques existent: un message put être envoyé dans la DLQ parce qu’il commence à être trop ancien ou parce qu’il provoque une erreur d’évaluation d’un filtre.

L’application elle-même peut pousser un message dans la DLQ.

 

Dernier point, la DLQ n’est pas automatiquement nettoyée. C’est à vous de le faire.

Azure Queues et Service Bus Queue

Azure propose un autre service similaire: Azure Queues qui fait partie des storages. On peut trouver une documentation détaillée ici:

https://azure.microsoft.com/fr-fr/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted/

 

On peut au moins retenir ceci:

Azure Queues est une infrastructure fonctionnellement plus simple et légère qu’ASB. Pour l’essentiel: Get, Put, Peek. ASB est une solution de messagerie beaucoup plus large et sophistiquée.

Il y a des différences sur la durée de vie des messages ainsi que leur taille.

ASB

  • Taille maxi file d’attente: 1Go eà 80 Go
  • Taille message maxi: 256 Ko
  • Durée de vie maxi: Illimitée

Azure Queues

  • Taille maxi file d’attente: Capacité de stockage du compte
  • Taille maxi message: 64 Ko
  • Durée de vie maxi: 7 jours

 

La sémantique « une fois maximum » n’est pris en charge que par ASB. c’est à dire la garantie qu’un message ne sera délivré qu’une seule fois.

Bibliographie

https://azure.microsoft.com/fr-fr/documentation/articles/event-hubs-overview/

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s