Service à Haute Disponibilité et Forte Montée en charge avec Azure ServiceBus (AppFabric)

“High Availability and highly scalable web service with Windows Azure ServiceBus (AppFabric)”

 

La version “November 2011” du SDK Windows Azure fusionne les deux principaux SDK (Le SDK Azure ainsi que les librairies de développement AppFabric ServiceBus et AppFabric Caching). Ce SDL apporte le support de nouveaux types de projets (MVC3, Silverlight RIA, HPC Preview, …)

Téléchargement : http://www.microsoft.com/windowsazure/sdk/

Outre ce packaging plus simple, cette nouvelle version apporte son lot de nouveautés techniques (http://msdn.microsoft.com/en-us/library/windowsazure/gg441573.aspx)

En parallèle avec l’évolution du SDK, l’implémentation du ServiceBus au sein d’Azure accueille une nouvelle fonctionnalité très attendue : la répartition de charge. Cette nouvelle caractéristique est indépendante des SDK. Elle est automatiquement disponible dès qu’on utilise le ServiceBus (à partir du SDK v1.5).

 

Azure Service Bus

Pour rappel, le ServiceBus Azure est bus de service fournissant des fonctionnalités de sécurité,  d’agrégation, de répertoire et d’exposition des services. Une société peut ainsi agrégé l’ensemble de ses services (publiques ou privés) en un point fédérateur unique hébergé par Windows Azure et accessible à partir d’une url racine unique et stable dans l’espace et le temps (par exemple : services.masociete.com), les services s’agrégeant en sous url (services.masociete.com/compta/ , sercices.masociete.com/catalogue/product, …)

Bien que supportant de multiples technologies clientes, l’intégration du service bus au sein du framework .Net est particulièrement propre et simple par l’utilisation de Binding WCF spécifiques.

Pour une explication sur les bases du ServiceBus AppFabric et de sa mise en œuvre, je vous conseille la lecture de l’article que j’ai publié dans la revue Programmez n° 131 (http://www.programmez.com/magazine_articles.php?titre=Windows-Azure–le-cloud-computing-pour-les-developpeurs&id_article=1393&magazine=131). Si vous souhaitez recevoir les sources de l’exemple envoyez moi un email (nclerc [at] quidmind.com).

 

La haute disponibilité avec Azure

Windows Azure est une plateforme fiable, hautement disponible, redondante. Chaque brique composant Windows Azure met en œuvre des mécanismes de redondance et/ou de répartition de charge apportant haute disponibilité et performances à vos applications :

Azure Compute :

• Load Balancing en entrée des WebRole,
• Load Balacing sur les endpoint exposés par des WorkerRole,
• Load Balancing pour les communications entre Web et Worker
• Routing via le DNS pour une répartition multi datacenter dynamique de la charge

Azure Storage :

• Stockage dupliqué
• Load balancing pour le requêtage client
• Augmentation du nombre de serveurs de requêtage en fonction de la charge
• Partitionnement des tables

SQL Azure :

• Triple réplication de la base de données avec reconstruction automatique des réplicas pour une continuité de service.

L’ensemble de ces fonctionnalités permet ainsi à Microsoft de vous garantir contractuellement un SLA (niveau de disponibilité contractuellement garanti).

Haute disponibilité avec le ServiceBus

En interne le service bus met en œuvre des mécanismes de haute disponibilité garantissant que votre namespace (l’url racine d’agrégation des services) est disponible et tient la charge contractuellement définie.

Par contre, dans toute chaine, la résistance totale est égale à la résistance du maillon le plus faible … Et dans le cas du serviceBus, le maillon le plus faible est (la plupart du temps) le service qui lui est connecté : soucis de stabilité, de montée en charge, de disponibilité, problème de connectivité, …

 

Dans une architecture orienté services, la haute disponibilité passe par l’utilisation d’éléments redondés sans état (pas de persistance de contexte entre deux appels). Or jusqu’a présent, la redondance devait être géré au niveau du service exposé sur le service bus. Ce qui dans la plupart des cas se traduit par … “aucune redondance”

Depuis novembre 2011, le ServiceBus supporte une fonctionnalité de répartition de charge piloté par le service bus. Il suffit ainsi de déclarer plusieurs services (n instances du même services, plusieurs services différents mais implémentant les mêmes contrats) sur la même url d’agrégation, le services bus répartira ensuite la charge de connexion/session entre les différentes instances disponibles.

Auparavant l’inscription multiple d’un service sur une uri précise déclenchait une exception “Endpoint not available” si un service était déjà déclaré. Depuis novembre, cette inscription est accepté et active la répartition de charge entre les services inscrits.

Il est ainsi possible de répartir les services dans des zones géographiques (datacenter azure, hébergement privé, …) distinct afin de limiter le risque d’interruption de service lié à une coupure réseau, tout en augmentant dynamiquement le nombre d’instance de service pour absorber la charge.

 

Un peu de pratique

Dans l’exemple suivant je prend le cas d’un service destiné à géré des prises de commandes. Le service permet de créer une commande et d’ajouter des lignes de commandes. Il est écrit en C# et exposé sous la forme d’un service WCF hébergé dans une application ligne de commande. Comme il se doit, ce service se doit d’être fiable et tenir la charge.

Ce service est exposé en nettcp et agrégé sur un namespace du service bus : sb://quidminddemoservices.servicebus.windows.net/GestionCommande.

Deux instances sont lancés :

 

L’application cliente permet de créer une commande puis de saisir des lignes de commandes :

 

Le résultat au niveau des services est bien une répartition équitable des appels entre les différentes instances déclarées :

 

Vous n’avez plus aucune excuse pour ne pas redonder vos services !