Windows Azure évolue, OGDI DataLab aussi :)

  • Article

image

Le 7 juin 2012 dernier, Scott Guthrie a annoncé lors de la conférence Meet the New Windows Azure les nouvelles fonctionnalités mises à disposition par Windows Azure. Parmi les plus attendues, nous pouvons citer l’ouverture vers l‘IaaS (Infrastructure as a Service) avec la possibilité de créer des machines virtuelles possédant un stockage persistant, les Sites Web pour un hébergement mutualisé et plus simple à mettre en place ou encore un nouveau système de cache permettant d’accroître la vélocité des applications.

Arrêtons-nous justement un instant sur les nouvelles possibilités de cache Windows Azure. Avant cette version, il était possible d’utiliser un cache distribué puissant mais couteux et pouvant se révéler fastidieux à mettre en place. Avec le nouveau service cache il est à présent possible d’utiliser 2 autres types de cache, le cache distribué et le cache partagé, regroupés sous le nom Windows Azure Caching:

  • Le cache distribué permet de dédier un rôle entier au système de cache. Celui-ci sera utilisé pour garder en mémoire les données transmises par le site Web pour un rapatriement plus rapide lorsque les applications en ont besoin. Si vous créez plusieurs Cache Worker Roles, ceux-ci seront regroupés en un seul cache distribué ;
  • A l’instar du cache distribué, le cache partagé ne nécessite la création d’aucun rôle supplémentaire pour sa mise en place. Il va au contraire utiliser et regrouper la mémoire non allouée de vos instances pour créer un système de cache distribué accessible à toutes les instances de votre service et élimine les quotas et goulots d’étranglement. Cerise sur le gâteau, l’utilisation du cache partagé est gratuite, il n’y a pas de coûts occasionnées par son utilisation. Vous payez seulement pour l’utilisation de vos instances hébergeant vos applications.

Mise en place de Windows Azure Caching dans OGDI DataLab

Avec l’objectif de maintenir OGDI DataLab dans l’ère du temps et surtout d’optimiser les coûts occasionnés par Windows Azure, nous allons voir comment mettre en place un système de cache partagé au sein de la solution OGDI DataLab.

L’avantage ici d’utiliser le système de cache partagé est double :

  1. Il n’occasionne aucun coût supplémentaire dans l’utilisation d’OGDI DataLab ;
  2. Il permet de diminuer le nombre de requêtes effectuées entre le service de données (DataService) et le browser de données (DataBrowser).

La résultante est une baisse des coûts de transactions et de bande passante qui seront bien entendu répercutés sur la facture finale.

Avant de commencer, faisons un état des lieux sur le fonctionnement d’OGDI DataLab, principalement sur la table EntityMetadata et le cache actuel.Cette table est le cœur de la solution et permet au DataBrowser d’afficher l’ensemble des catalogues et jeux de données présents dans l’application au travers d’un flux xml contenant les métadonnées de ces tables.

Chaque table contient une entrée et chaque entrée possède pour chacune des colonnes de la table référence une colonne portant le même nom et ayant pour valeur le type de cette colonne. Nous pouvons ici réduire le nombre de requêtes effectuées sur celles-ci en créant un système de cache.

Pour mémoire, les tables de stockage Azure ne possèdent pas de typage fort pour les colonnes. Un autre point important à considérer côté DataBrowser est la présence d’un système stockant les métadonnées évoquées précédemment dans un cache de session propre à chaque utilisateur.

L’intérêt ici est donc d’utiliser un cache global donc accessible à toute l’application et aussi de réduire le nombre de requêtes effectuées sur le DataService. Cette mise en cache est efficace dans le cas présent du fait que le flux renvoyé est identique pour tous les utilisateurs.

Maintenant que le contexte est posé, voyons comment mettre en place le cache partagé de Windows Azure Caching. Pour cela, vous devez dans un premier temps installer le nouveau SDK Windows Azure 1.7 (Juin) disponible ici et si ce n’est déjà fait mettre à jour les projets Windows Azure dans la version du SDK Windows Azure 1.7 (Juin).

Ouvrez ensuite la solution OGDI DataLab puis déroulez le projet DataBrowser.WebRole. Faîtes un clic droit sur References puis Add Library Package Reference. Dans la fenêtre de recherche, tapez « Microsoft.WindowsAzure.Caching » et installez le paquet Microsoft.WindowsAzure.Caching.

image

A ce stade, vous venez d’installer les dépendances pour utiliser le cache Windows Azure. Déroulez ensuite le projet DataBrowser.Cloud et ouvrez le rôle DataBrowser.WebRole.

image

Vous pouvez noter qu’un nouvel onglet est apparu : Caching.

image

 

Cet onglet permet de configurer le cache, notamment la mémoire maximale allouée au cache, un compte de stockage permettant de maintenir l’état du cluster de cache ou encore de rajouter des caches logiques dans le cluster.

Cochez Enable Caching (Preview Release) et Co-located Role pour activer le cache partagé.

Ensuite ouvrez le fichier Web.config du projet DataBrowser.WebRole et recherchez la partie dataCacheClients. Vous pouvez voir que l’attribut identifier de l’élément autoDiscover doit être configuré.

Vous devez spécifier le nom du rôle sur lequel le cache est utilisé en l’occurrence DataBrowser.WebRole.

<dataCacheClients>

  <tracing sinkType="DiagnosticSink" traceLevel="Error" />

  <dataCacheClient name="default">

    <autoDiscover isEnabled="true" identifier="DataBrowser.WebRole" />

    <localCache isEnabled="true" sync="TimeoutBased" objectCount="100000" ttlValue="300" />

  </dataCacheClient>

</dataCacheClients>

Le cache est maintenant configuré. Il ne reste plus qu’à l’utiliser. Pour cela, ouvrez le fichier Cache.cs situé dans DataBrowser.Mvc_WebRole/Helper/.

image

Vous pouvez voir dans la méthode statique EntitySets que la mise en cache se fait dans le contexte de session de l’application. Afin de rendre ce cache accessible à l’ensemble de l’application et non plus à une session en particulier, nous allons utiliser le cache partagé.

Voici le code utilisant le cache partagé :

static public IEnumerable<EntitySet> EntitySets(String container)

{

DataCacheFactory factory = new DataCacheFactory();

DataCache cache = factory.GetDefaultCache();

var cachedData = cache.Get("EntitySetCache") as IDictionary<string, IEnumerable<EntitySet>>;

 

IDictionary<string, IEnumerable<EntitySet>> entitySets;

 

if (cachedData == null)

{

cachedData =

entitySets = new Dictionary<string, IEnumerable<EntitySet>>();

}

else

{

entitySets = cachedData;

}

 

if (!entitySets.ContainsKey(container))

{

entitySets[container] = GetEntitySets(container);

cache.Put("EntitySetCache", entitySets);

}

 

return entitySets[container];

}

Vous noterez l’utilisation de la classe Cache se référant directement au cache partagé et qui permet de récupérer via une clé les données stockées dans ce cache.

Votre DataBrowser est maintenant configuré pour être utilisé avec le cache partagé et non plus le cache de session ; ce qui a pour conséquence de réduire le nombre de requêtes effectuées sur le DataService et donc de diminuer les coûts de bande passante et de transaction.

Pour plus d’information sur Windows Azure Caching rendez-vous ici. Enfin si vous désirez en apprendre plus sur les nouveautés Windows Azure, n’hésitez pas à visiter le site dédié https://www.windowsazure.com/fr-fr/ et à faire le cas échéant un essai gratuit de 90 jours.

image 

 

 

Quelques bonnes pratiques sur le multi-catalogue dans OGDI DataLab

Après avoir illustré comment configurer le nouveau cache de Windows azure vis-à-vis des catalogues de données existant, il peut être bon de rappeler dans ce contexte les avantages de l’utilisation d’OGDI DataLab avec la prise en charge du multi-catalogue.

Pour mémoire et comme rappelé dans la seconde partie de notre Foire aux questions, la configuration du kit de démarrage OGDI DataLab reposant sur la notion de catalogues (d’ensembles) de données mis à disposition par l’entrepôt de données, il est possible de déclarer simultanément plusieurs catalogues (d’ensembles) de données qui seront ensuite exploités par le DataService et le DataBrower de la plateforme OGDI DataLab.

Chaque catalogue ou source/conteneur de données correspond à une collection au sens du protocole OData en termes de points de terminaison.  Le but est donc de segmenter les données pour améliorer l’expérience utilisateur lors de la navigation dans le DataBrower d’OGDI DataLab mais aussi d’obtenir une meilleure organisation des données dans les comptes de stockage.

En résumé il est conseillé d’utiliser plusieurs catalogues de données lorsque :

  • Vous utilisez aujourd’hui des préfixes pour identifier et classer vos jeux de données dans les noms de catégories ;
  • Vous souhaitez utiliser un 2ème niveau de catégorie ;
  • La catégorie contient un très grand nombre de jeux de données que vous pouvez regrouper en plusieurs catégories ;
  • Vous possédez trop de catégories et un seul fournisseur de données rendant l’expérience utilisateur moins probante sur le kit de démarrage OGDI DataLab.

En combinant le cas échéant les deux approches, vous pouvez tirer le meilleur parti de la fondation OGDI DataLab disponible sur la forge GitHub.