Windows Server AppFabric Caching (ex-“Velocity”)

  • Article

Une application classique a souvent une architecture à deux niveaux, par exemple Web (ASP.NET) + base de données. AppFabric Caching va aider à monter en charge sur ce type d’architecture, et également se protéger en partie des plantages.

AppFabric Caching est un cache mémoire distribué permettant de cacher tout type de données.

  • Partage de données entre applications (tout le monde tape dans le cache)
  • Performance 28.000 lectures/s, 20.000 écritures/s
  • Montée en charge linéaire: ajouter des noeuds
  • Haute disponibililté: les données sont disponibles en cas de perte de noeuds

dell.com utilise AppFabric Caching par exemple.

Coût: utiliser des machines de base, sera intégré à Windows Server.

AppFabric Caching en Beta actuellement (après 3 CTP), RTM en 2010. Puis version Azure à venir.

En termes de déploiement, on active simplement le rôle sur les serveurs et l’on indique une base de données pour stocker la configuration. Côté client, l’on a une librairie et un app.config pour indiquer l’adresse du cluster de cache.

L’on a des cmdlets PowerShell pour gérer les noeuds du cluster.

L’on a une API permettant d’obtenir un objet DataCache. L’API est très simple: cache.Put(clef,valeur), cache.Get(clef), cache.Remove(clef).

En Beta1, le cache est sécurisé par défaut, contrairement à la CTP3. Il faut autoriser l’accès au cache via une cmdlet.

L’API reste la même quel que soit le nombre de serveurs dans le cluster.

L’on peut néanmoins ajouter des régions, pour grouper des objets, et des tags pour effectuer des requêtes.

L’on stocke typiquement explicitement les valeurs dans le cache (si valeur pas dans le cache, récupérer valeur et l’ajouter au cache).

Les données sont réparties sur l’ensemble des serveurs. L’on peut ajouter des serveurs dynamiquement à tout moment, et les données seront re-partitionnées automatiquement. GridDynamics a également fait des tests intensifs de montée en charge.

Comment utiliser AppFabric Caching? Etudier les pré-requis sur les données:

  • Performance
  • Consistence
  • Eviction
  • Sécurité
  • Disponibilité

Reference Data (type catalogue): performance est généralement primordiale, mais mise à jour relativement rare. Le Local Cache peut aider: le client peut cacher les données localement pour encore accélérer l’accès, mais l’on peut avoir des données moins fraîches (mais l’on choisit le temps de rétention).

Données d’activité (type panier e-commerce): l’on utilise souvent le Session State ASP.NET, l’on a alors un custom Session Store Provider; le Session State sera alors automatiquement stocké dans AppFabric Caching.

L’on peut activer la haute disponibilité sur les caches, dans ce cas l’on stocke automatiquement les données sur deux serveurs différents (primaire et secondaire). En cas de panne, les requêtes sont automatiquement redirigées vers le noeud survivant pour l’objet demandé.

Données de ressources (lecture/écriture): l’on a du locking optimistic, mais également du locking explicite: GetAndLock().

L’on peut maintenant, en Beta, verrouiller une clé non existante: pour cacher des objets coûteux à récupérer et éviter que de multiples clients fassent cette même opération en même temps.

Tous les verrous ont un temps limité.

L’on peut également ajouter des callbacks pour être notifié de modifications.

La démonstration montre la mise en oeuvre de trois caches au sein d’une application de type e-commerce: Catalogue, Session et Rapports. L’on voit que la session est bien stockée en cache et accessible par tous les frontaux.

Via une cmdlet, l’on voit que les données sont bien dupliquées sur deux noeuds. Lorsque l’on éteind un noeud, l’on voit qu’après quelques secondes, les serveurs survivants sont devenus primaires pour les données.

AppFabric Caching et Azure

Montée en charge avec le cloud:

  • Application en local avec data dans SQL Azure
    • AppFabric Caching peut cacher les données au plus près du serveur applicatif
  • Application dans Azure et données en local (via le Service Bus)
    • Idem mais dans l’autre sens: AppFabric Caching dans Azure rapproche les données
  • Tout dans Azure
    • Pas besoin d’optimiser les temps d’accès dans ce cas, mais l’on a toujours des besoins de montée en charge
    • AppFabric Caching est montré déployé dans Windows Azure sous la forme d’un Worker Role, que l’on peut utiliser depuis un Web Role pour cacher les données SQL Azure.

L’on a donc une belle histoire Software + Services ici, avec la possibilité de faire tourner le service de cache aussi bien dans le nuage qu’en local!