Durant la Build, Microsoft a annoncé la preview d’une fonctionnalité très attendue (en tout cas par moi) de Windows Azure : l’autoscaling. Voici un petit résumé du besoin auquel répond cette nouvelle fonctionnalité, et les possibilités offertes. Voila “l’AutoScaling as a Service” !

L’autoscaling ?

Le scaling (mise à l’échelle en Français), c’est la possibilité d’augmenter manuellement la capacité d’absorption de charge d’un site, d’un service ou d’une machine dans le Cloud ; le tout sans interruption de service.

Il existe plusieurs modes de scaling parmi lesquels :

• Le scaling “horizontal” : la puissance augmente en ajoutant des machines – souvent utilisé pour les serveurs Web ou de calcul
• Le scaling “vertical” : la puissance augmente en augmentant la taille et la puissance des machines – plutôt utilisé sur les serveurs de base de données
• Des modes mixtes

L’autoscaling, c’est donc la possibilité d’augmenter automatiquement la capacité d’un environnement dans le Cloud, sans aucune intervention humaine :

• Ma plateforme monte en puissance automatiquement quand elle atteint ses limites : cela me permet d’avoir une qualité de service très importante
• Ma plateforme baisse en puissance automatiquement quand elle est sous utilisée : cela me permet de faire des économies de machines (et donc d’argent)

Comment cela fonctionnait avant ?

A mes yeux, on ne peut dire que l’on fait du “cloud” sans qu’un système d’autoscaling soit en place – c’est vraiment l’automatisation de l’informatique par excellence.

Avant le service fraichement proposé par Microsoft, il était bien sur déjà possible de faire de l’autoscaling. Cependant, la mise en place de ce type de scénario n’était pas forcement accessible aux novices, car demandait une architecture spécifique et pas mal de code pour manipuler les APIs Windows Azure.

Concrètement il fallait faire :

• Un Worker Role hébergé dans Azure chargé de “surveiller” les instances / machines à autoscaler – en utilisant les APIs de monitoring de Windows Azure
• Définir dans ce rôle des seuils d’actions, par exemple :
• Si la moyenne d’utilisation de mes CPUs est supérieure à 70%, j’ajoute des machines, si elle est au dessous de 20% j’en enlève en en gardant toujours au moins 2
• J’agis si j’ai des requêtes en attente dans IIS, si les pages répondent en plus de 2 secondes, si la mémoire de ma machine est pleine…
• Et enfin, dans ce rôle, il fallait manipuler en .NET les APIs d’Azure pour pouvoir agir dynamiquement sur les services hébergés ou bien écrire des scripts Powershell pour manipuler les machines virtuelles

Comment on va pouvoir faire maintenant ?

Avec la preview de l’autoscaling, l’onglet “mise à l’échelle” (qui permet de contrôler le nombre d’instances et de faire du scaling horizontal) évolue avec des options complémentaires pour l’autoscaling.

Deux options sont proposées : “Unité centrale” et “File d’attente”.

Unité centrale :

En mode “Unité Centrale”, l’autoscaling est simplifié au maximum et se base uniquement sur la surveillance du processeur (qui reste toutefois un des indicateurs de scaling les plus utilisés).

Ce mode est à utiliser pour les rôles de type Web.

Une fois cette option enclenchée il est ainsi possible de :

• Définir un nombre minimal et maximal d’instances pouvant être activées par l’autoscaling (afin de s’assurer que le service tourne toujours et éviter qu’en cas de soucis, un nombre trop important d'instances s’active) :

• Définir les bornes de surveillance de l’utilisation du CPU sur les instances actives (a partir de combien il faut ajouter / enlever des instances) :

• Le nombre d’instances à ajouter / enlever lorsque le seuil est atteint, ainsi qu’une durée minimale d’action (pour laisser le temps aux nouvelles instances d’absorber la charge avant d’en ajouter de nouvelles) :

En résumé, cela donne le schéma suivant :

File d’attente :

En mode “file d’attente”, l’autoscaling se base sur une liste de tâches à effectuer. Ce mode permet d’augmenter ou de réduire le nombre de Worker Role en fonction d’une liste de tâches à effectuer, afin d’accélérer une durée de traitement. Si la file d’attente de tâches à effectuer devient trop longue, il faut ajouter des Worker. Si la file d’attente est vide ou quasiment vide, il faut en enlever.

Une fois cette option enclenchée il est ainsi possible de :

• Comme pour le mode “unité centrale”, définir un nombre minimal et maximal d’instances pouvant être activées par l’autoscaling
• Configurer le nom de file d’attente à surveiller (dans le compte de stockage Azure)

• Définir le seuil par machine de messages en attente pouvant être traité. Ici Windows Azure va faire en sorte d’ajuster le nombre de Worker Role pour faire en sorte d’atteinte de seuil. Par exemple, si la limite est configurée à 2000 messages et que la file d’attente est de 6000 messages, l’autoscaling fera en sorte de maintenir 3 instances (2000 messages max chacune).

• Et enfin, il est également ici possible de définir le nombre d’instances à ajouter / enlever lorsque le seuil est atteint, ainsi qu’une durée minimale d’action.

En résumé, cela donne le schéma suivant :

Le seul regret dans ce mode là est qu’il s’appuie sur le système de Queue de Windows Azure Storage, qui devient obsolète au profit de celui du Service Bus !

Bref, c’est clairement la fonctionnalité que j’attendais dans Windows Azure pour offrir très simplement ce scénario, donc une excellente surprise !

Elle répond à un premier besoin d’autoscaling simplifié qui sera utile dans une grande partie des cas. Toutefois, pour de l’autoscaling optimisée et plus fin (par exemple, agir en fonction des temps de génération / réponse des pages Web), la mise en place d’un autoscaling sur mesure reste bien sur possible (et très fun)