Une expérience très riche avec la mise en oeuvre d’instances Windows Azure, de SQL Azure, de DataSync, du service Azure Blob et l’intégration de Java, d’Apache Solr et de Tomcat sur des instances Azure sous forme de Web Roles et de Worker Roles.

Pour en savoir plus, regardez cette vidéo !

Si vous souhaitez en savoir plus, n’hésitez pas à nous contacter afin d’échanger sur vos projets.

Olivier LEAL

Des solutions de stockage suivant les même idées directrices que celles que l’on peut trouver dans les grands Cloud publics sont apparues depuis déjà quelques temps maintenant, et je me suis intéressé particulièrement à une solution de stockage orienté objet basée sur un système en anneaux. Cette solution de Scality nommée Ring Organic Storage, propose un système de stockage peu coûteux avec des fonctionnalités similaires à celles que l’on peut trouver sur S3. Il permet d’associer à une URL un objet stocké sous forme de binaire. On note que ce principe d’anneau est le même que l’on trouve sur des bases comme Cassandra, sauf que dans notre cas il s’agit de stockage orienté objet. Je me suis donc intéressé au fonctionnement de cette solution déjà déployée dans des productions chez des hébergeurs et des fournisseurs de service.

Cible
Il est indispensable, dans un premier temps, de prendre conscience que cette solution permettant de mettre en place un des composants d’un Cloud privé est réservée à des sociétés ayant un volume de données suffisamment important (à partir de 100To) ou rencontrant des problématiques de performances (quelques dizaines de To avec d’importants IOs). Il faut dans tous les cas atteindre une masse critique dans son infrastructure pour utiliser ce genre de produit, comme n’importe quel composant de Cloud Computing que l’on souhaite déployer en privé.

Architecture
L’architecture du système de stockage en anneaux est constituée d’un anneau primaire permettant de servir les requêtes vers les objets définis comme accédés les plus fréquemment (performance privilégiée) et d’un ou plusieurs autres anneaux servant de stockage sur le long terme servant pour la reprise d’activité en cas de problèmes (disaster recovery). Cette réplication peut s’effectuer en off-site sur un autre data center ou bien même sur des services de stockage sur des Cloud publics type… Mmmh… Disons S3 ! :o)

Cette architecture privilégie la disponibilité et la durabilité des données via un surcoût en disques durs puisque le principe est de redonder la donnée entre plusieurs noeuds de stockage écrivant sur des sets de disques différents. Ce choix est basé sur le fait que le disque dur n’est pas un composant très coûteux dans la mise en place d’une infrastructure.

Les noeuds fonctionnent sur un système de peer-to-peer, il n’y a donc pas de SPOF (Single Point Of Failure) ou d’engorgement et un load-balancing naturel s’effectue.

A noter que la cohérence de ce système est configurable de manière à ce que l’on puisse atteindre une cohérence forte ou une cohérence à terme : à vous de définir votre niveau de cohérence ou quorum. Par exemple, si W+R > N, alors le jeu d’écritures et le jeu de lectures se recouvrent toujours et l’on peut garantir une cohérence forte, avec :

• N = le nombre de nœuds qui stockent les répliques des données
• W = le nombre de répliques qui doivent accuser réception de la mise à jour avant que celle-ci ne soit complétée
• R = le nombre de répliques qui sont contactées quand un objet de données est consulté via une opération de lecture

La gestion des clés
La répartition des données s’effectue sur l’anneau via une clé unique (20 octets) définie soit par vos applications elles-même, soit par le système qui se base sur un ensemble d’éléments. Chaque noeud s’occupant d’un range de clés bien défini, la donnée est donc inscrite sur le noeud correspondant, puis répliquée sur d’autres noeuds définis par algorithme : par exemple dans le cas où on choisit de répliquer 2 fois la donnée (donc de la stocker en 3 exemplaires), une donnée stockée sur un noeud x le sera également sur les noeuds x + Pi/3 et x + 2Pi/3.

En plus, les voisins directs d’un noeud dans l’anneau peuvent reprendre la responsabilité des données de leur voisin si il « venait à disparaître » de l’anneau afin de proxyfier les requêtes vers les données redondées (via l’algorithme).

Le but est de pouvoir accéder aux données que l’on cherche à partir de n’importe quel point d’entrée (c’est-à-dire à partir de n’importe quel noeud de l’anneau) en un minimum de sauts. Par exemple pour ce système, le nombre de sauts annoncé est de :

• 3 pour 100 noeuds,
• 5 pour 1000 noeuds,
• 7 pour 10000 noeuds,
• …

Pour accéder au noeud contenant la donnée cherchée, on y arrivera donc en moins de log(n) sauts (avec n le nombre de noeuds). A noter que pour de meilleurs temps d’accès (diminution du nombre de sauts), la topologie de l’anneau est cachée au niveau des connecteurs (cf. accès aux données) au fur et à mesure de sa découverte.

A noter que la répartition des clés s’effectue via un « Consistent Hash » : cela permet lors de l’ajout ou de la suppression d’un noeud de n’affecter que « (1/n) x nb total clés » clés (avec n… toujours le nombre de noeuds ;ob).

On peut aussi utiliser les clés pour identifier le type de données stockées (via un des éléments composant la clé) et les affecter vers des disques (harware) sous-jacents particuliers (SATA, SAS, SSD, …) en fonction des ressources que l’on souhaite affecter à ce type de données. Cela offre des possibilités intéressantes.

A noter également qu’en fonction de la taille des fichiers stockés, il est prévu des optimisations autant pour la manipulation de plein de petits fichiers (écriture en série dans des fichiers/blocs plus importants) que pour la manipulation de fichiers de grande taille (découpage en blocs et parallélisation des lectures/écritures). Il faut penser que pour ce genre d’utilisation, il faudra réfléchir également au niveau des composants hardware : par exemple pour des gros fichiers, il faudra envisager une bande passante suffisante pour permettre un bon débit, de même que pour beaucoup de petits fichiers, il faudra optimiser les IOs et prévoir un ratio disques/serveurs convenable et utiliser des disques adaptés (SAS ou SSD).

L’accès aux données
Les données peuvent être accédées via différentes interfaces (connecteurs) permettant d’émuler des fonctionnalités particulières (cf. schéma d’architecture) :

• connecteurs mails (pour des produits comme Zimbra, Dovecot, Cyrus, …) permettant d’aller chercher le contenu (corps, pièces jointes, …) des messages stockés dans l’anneau correspondant aux meta-data (identifiants, objets, …) contenus dans une base de données,
• connecteur REST (S3-like) pour accéder aux objets via le protocole HTTP en REST,
• connecteur FUSE (Filesystem in Userspace) permettant d’émuler un système de fichiers et d’accéder dans ce mode aux objets stockés pour des programmes nécessitant une telle visibilité (c’est à dire ne permettant pas d’accéder aux objets via des requêtes HTTP),
• connecteur de type Gateway (pour des produits comme TwinStrata, CTERA, …) permettant d’accéder à ce que l’on pourrait appeler un Cloud Attached Storage via des protocoles type iSCSI, NFS/CIFS, … (à voir la liste des protocoles actuellement pris en charge par le connecteur de Scality). Cela permet de conserver une partie de ses données dans l’infrastructure locale de son datacenter et de stocker la totalité sur un système distant. On bénéficie alors d’un système de cache sur les données les plus actives et d’une durabilité sur l’ensemble (il est aussi possible de conserver l’ensemble de ses données en local et de ne bénéficier que du backup distant). D’ailleurs, AWS vient de sortir il y a peu le service AWS Storage Gateway, sur le même principe.

En plus du type de connecteur, il est intéressant de voir les fonctionnalités d’authentification qui sont implémentées (pouvant interroger un système local en XML/RPC), les systèmes d’ACLs et les mécanismes de facturation. Tout à fait le genre d’éléments que l’on retrouve dans les Cloud IaaS type AWS.

Conclusion
Il est intéressant de regarder des solutions qui s’offrent à nous pour répondre à des problématiques de stockage en mettant en place des composants de Cloud, mais en privé. La distribution de l’Organic Ring Storage proposé par Scality permet à la solution de présenter un modèle décentralisé peu sensible à la panne, notamment grâce à l’utilisation de ses algorithmes de répartition et de recherche de données. La diversité des connecteurs en font une solution polyvalente, même si réservée à un stockage de données qui se compte en dizaines de To au minimum.

Il est possible de sélectionner le hardware sous-jacent qui servira à stocker un type d’objets en fonction d’éléments composant sa clé de stockage pour optimiser l’accès à ces données. De plus, en fonction de ce que l’on recherche avec ce système (bande passante, IOs ou stockage pur), il faut penser à privilégier les éléments hardware nécessaires.

J’espère que ce sujet vous aura intéressé et n’hésitez pas à nous contacter pour plus d’informations sur ce produit.

Frédéric FAURE @Twitter @Ysance

Modèle de données

C’est une base de données non relationnelle structurée ou NoSQL ou clé/valeur. Elle est basée sur le même modèle que SimpleDB (AWS) à savoir une table dans laquelle on insère des items. Chaque item est constitué d’une clé primaire obligatoire et d’un ensemble d’attributs facultatifs. Sous une représentation graphique, les items sont des lignes et les attributs des colonnes. Cependant, aucun attribut (sauf la clé primaire) n’est obligatoire. On peut donc avoir une table « CatalogueProduits » pour un site de e-commerce qui contient des livres, des aquariums, des voitures, … Chaque produit aura un « IdProduit » (clé primaire), pour le reste certains attributs seront communs comme « Prix », « CategorieProduit », « Disponibilite », … D’autres seront spécifiques à chaque type d’items (types définis par la « CategorieProduit » – livre, … – dans notre cas).

A noter que chaque attribut peut avoir comme valeur :

• String
• Number
• Tableau de String ou de Number (appelé aussi attribut multi-valué) => par exemple à l’attribut Couleur peut correspondre la valeur ["bleu", "rouge", "vert"]

A noter que la clé primaire peut être de 2 types :

• Hash : la clé primaire est constituée d’un attribut et un index non ordonné sur l’attribut est construit.
• Hash & Range : la clé primaire est constituée de 2 attributs (le hash et le range) et 2 index sont construits : le hash index non ordonné sur l’attribut défini comme hash et le sorted range index sur l’attribut défini comme range.

Ci-dessous un exemple illustratif tiré de la documentation de référence de l’API :

Et pour vous donner une idée des requêtes possibles sur le sorted range index, voici les options disponibles (tirées du SDK Ruby proposé par AWS) :

RANGE_KEY_OPTIONS =
{
:range_less_than => "LT",
:range_greater_than => "GT",
:range_lte => "LE",
:range_gte => "GE",
:range_begins_with => "BEGINS_WITH"
}

Accès aux données

L’accès s’effectue via des requêtes HTTP(S) qui peuvent être envoyées depuis le réseau AWS (à partir d’une instance EC2) ou bien de l’extérieur (attention au temps réseau HTTP(S)). Le service est donc accessible de partout sans limitation, pour peu que vous ayez un couple de clés access key / secret key associées aux bonnes credentials pour vous authentifier et que vous puissiez sortir sur le Net en 80 et/ou 443.

Le format des échanges au dessus du protocole HTTP(S) est en JSON, autant au niveau de la requête que de la réponse. Voici un exemple de réponse :

{"Items":
[{"date":{"S":1989},
"fans":{"SS":["Keneau","Alexis","John"]},
"name":{"S":"Bill & Ted's Excellent Adventure"},
"rating":{"S":"****"}}]
}

Cependant, les SDKs (fournis par Amazon ou par d’autres) intègrent déjà une interface plus fonctionnelle de communication avec les APIs AWS afin que vous n’ayez pas à vous occuper de la création des requêtes et du parsing des réponses. Les SDKs s’occupent donc de la couche transport basée sur le format JSON.

Différences avec SimpleDB

Tout est histoire de compromis : entre l’implémentation de SimpleDB et de DynamoDB, il a fallu choisir entre fonctionnalités et performances. SimpleDB privilégie plus les fonctionnalités, d’ailleurs certaines d’entre elles impliquent que toutes les données d’une table (appelée « domaine » dans SimpleDB) soient sur un même serveur… Donc pas de sharding possible et pas de forte scalabilité envisageable. De plus les APIs de SimpleDB partent du principe que tous les attributs des items soient automatiquement indexés (donc moins bonnes performances). DynamoDB fait le choix inverse en limitant les fonctionnalités de ses APIs et en ne conservant que un ou deux index (fonction du type de clé primaire) pour optimiser les performances.

Les différences principales sont les suivantes :

• Plus de limitation à 10GB par table.
• Pas d’indexation sur tous les attributs (colonnes) et moins de possibilités (fonctionnalités) en termes de requêtage via les APIs.
• Une garantie des performances : on choisit le nombre de requêtes/secondes dont on a besoin en écriture et en lecture sur chaque table.
• Le protocole de transport : JSON over HTTP(S) pour DynamoDB, REST style pour SimpleDB avec une réponse au format XML.
• Le pricing : les 2 ont une composante lié à la quantité de données stockées, plus éventuellement la quantité de données qui transitent hors du réseau AWS si on fait des appels depuis l’extérieur. La différence se fait entre :
  • La Machine Utilization de SimpleDB qui se base sur la consommation en ressources machine de chaque requête (SELECT, GET, PUT, …).
  • La Throughput Capacity de DynamoDB qui se base sur une capacité de requêtes par seconde que vous allez définir. Contrairement à SimpleDB, on est dans ce cas sur de l’alloué plutôt que du consommé (la même différence que l’on a entre le volume alloué que l’on paie sur les EBS et le volume utilisé que l’on paie sur S3).

Les éléments à prendre en compte

Il faut faire attention à un certain nombre d’éléments plus ou moins mis en valeur afin de faire une bonne utilisation du produit :

• Il s’agit de la première release et il faut suivre la roadmap du produit qui va permettre au service de s’étendre en termes de couverture géographique (le service est actuellement disponible sur une seule région : US East (N. Virginia)) et en termes de fonctionnalités (par exemple celle de backup/restauration, actuellement absente, est dans les priorités).
• La disponibilité et la durabilité des données sont assurées sur le même scope que les services de type S3 ou SimpleDB (entre autres) : il y a une réplication multi zones d’accessibilité sur la région du service.
• La modification de l’allocation des ressources n’est pas instantanée : si l’action de diminution de la capacité en lecture ou en écriture est une question de secondes ou de minutes, l’augmentation de cette capacité se compte en minutes ou en heures en fonction de la taille de la base (la croissance n’est pas forcément proportionnelle car met en place des mécanismes de parallélisation). Il faut donc s’y prendre à l’avance ! On ne peut donc pas, par exemple, lisser l’allocation de la capacité sur la journée pour une application qui a des pics d’utilisation sur une période donnée de la journée (une application de jeu qui voit son trafic exploser le midi et le soir par exemple). La fréquence des pics de charge serait trop importante. En revanche cela est tout à fait envisageable pour une utilisation avec des pics plus espacés (période de soldes sur l’année pour un site de e-commerce).
• Autre point important à prendre en compte sur l’augmentation de la capacité en lecture ou en écriture : le facteur maximum d’augmentation est de 2. Donc au maximum on double sa capacité en une demande au service DynamoDB. Si on veut multiplier sa capacité en lecture ou/et en écriture par 8, il faudra donc effectuer 3 requêtes successives (2 x 2 x 2), avec entre chaque demande un temps de mise en application de la capacité allant de quelques minutes à quelques heures.

• Il est possible également de diminuer cette capacité de la quantité souhaitée (pas de facteur) avec un minimum de 5 unités de capacité de débit pour la lecture et/ou l’écriture. Attention cependant, une seule diminution de la capacité est autorisée par jour : cela ne me semble pas poser de problème sur une vraie utilisation (c’est-à-dire autre que des tests :o)).
• Durant cette modification de capacité, il est important de noter qu’il n’y a pas d’interruption du service sur cette table : il est toujours possible de la requêter en lecture et en écriture.
• La taille maximale d’un item à stocker est de 64KB, ceci inclut le nom et la valeur des attributs. Il n’y a pas de limite sur le nombre d’attributs d’un item (tant que l’on reste dans la limite des 64KB en taille totale de l’item).
• On peut créer jusqu’à 256 tables pour un compte donné, avec 2 limitations sur les unités de capacité (ces 2 limitations sur la capacité de débit peuvent être dépassées en remplissant ce formulaire) :
  • 10,000 unités en capacité de débit en lecture par table et pareil en écriture.
  • 20,000 unités en capacité de débit en lecture sur le compte, réparties entre toutes les tables et pareil en écriture.
• Les temps de traitements indiqués pour les requêtes « in the single-digit milliseconds » correspondent aux temps de traitements côté service (DynamoDB). Pensez à ajouter le temps réseau pour le transport (JSON over HTTP(S)) des informations de requêtes/réponses.
• Concernant la composante du prix liée à la capacité de débit des requêtes (Throughput Capacity), on a actuellement les tarifs suivants :
  • « Write Throughput: $0.01 per hour for every 10 units of Write Capacity »
  • « Read Throughput: $0.01 per hour for every 50 units of Read Capacity »
• Mais qu’est ce qu’une unité de capacité ?

Il s’agit d’une requête (lecture ou écriture) par seconde pour un item de 1KB ou moins.

Voici un petit exemple de calcul de la capacité que vous allez devoir réserver (attention : on parle toujours de « réservé » ou « alloué » et pas de « consommé ») :

Si vous avez des items de 512 bytes (rentre dans la catégorie des 1KB ou moins) et que vous souhaitez lire (ou écrire) 100 items/secondes, vous allez devoir provisionner 100 unités de capacité de lecture (ou d’écriture). Ce qui donne en termes de prix :

Lecture : 100 unités de lecture / 50 unités de lecture (unité de base de la facturation) = 2, soit 2 x $0.01 = $0.02 par heure pour réserver une capacité de lecture de 100 unités (100 requêtes/secondes pour des items de 1KB ou moins).

Ecriture : 100 unités d’écriture / 10 unités d’écriture (unité de base de la facturation) = 10, soit 10 x $0.01 = $0.10 par heure pour réserver une capacité d’écriture de 100 unités (100 requêtes/secondes pour des items de 1KB ou moins).

Voici un autre exemple avec des items de taille plus importante :

Si vous avez des items de 14.5KB et que vous souhaitez lire (ou écrire) 100 items/secondes, vous allez devoir provisionner 15 (la taille est arrondie à l’entier supérieur) x 100 requêtes/secondes = 1500 unités de capacité de lecture (ou d’écriture). Ce qui donne en termes de prix :

Lecture : 1500 unités de lecture / 50 unités de lecture (unité de base de la facturation) = 30, soit 30 x $0.01 = $0.30 par heure pour réserver une capacité de lecture de 1500 unités (100 requêtes/secondes pour des items de 14KB+ à 15KB).

Ecriture : 1500 unités d’écriture / 10 unités d’écriture (unité de base de la facturation) = 150, soit 150 x $0.01 = $1.50 par heure pour réserver une capacité d’écriture de 1500 unités (100 requêtes/secondes pour des items de 14KB+ à 15KB).

A noter que vous pouvez choisir de requêter votre table en lecture selon 2 modes :

• cohérence à terme (par défaut au niveau de l’API DynamoDB)
• cohérence forte (à spécifier dans votre requête à l’API quand vous voudrez lire de la sorte : par exemple dans le SDK Ruby ajoutez :consistent_read => true)

En choisissant la cohérence à terme, vous pourrez ne provisionner que la moitié du nombre d’unités que vous avez calculé pour obtenir le même résultat en terme de requêtes (lecture) par seconde.

Ne pas oublier d’ajouter à ces exemples le stockage de la donnée (« Storage: $1.00 Per GB-month ») et éventuellement la quantité de données échangées si vous dialoguez avec le service depuis une application hors du réseau AWS (c’est-à-dire qui n’est pas sur une instance EC2 ou bien qui est sur une instance EC2 dans une autre région que le service DynamoDB que vous utilisez).

2 notes concernant les données stockées :

• Contrairement à la capacité de débit des requêtes qui correspond à de l’alloué/provisionné/réservé, la capacité de stockage correspond à du consommé en termes de facturation.
• DynamoDB est une base de données indexées et la quantité d’espace disque correspond à la taille des données que vous avez chargées plus un overhead par item de 100 bytes pour l’indexation.

Bench

J’ai effectué un mini bench à partir d’une instance EC2 m1.large dans la même région que le service DynamoDB : j’ai lancé un script Ruby qui insère 10000 éléments de moins de 1Ko dans une table vide dont j’ai fait varier la capacité de débit de requêtes en écriture. Entre chaque test, j’ai détruit/recréé la table.

Voici le code que j’ai utilisé basé sur le SDK Ruby (que je vous recommande par ailleurs) proposé par AWS :

require 'rubygems'
require 'aws'

dynamo_db = AWS::DynamoDB.new(
:access_key_id => 'XXXXXXXXXXXXXXXXXX',
:secret_access_key => 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')

table = dynamo_db.tables['TestFredTableForDecrypt']
table.hash_key = [:ImageID, :string]

10000.times do |i|
    item = table.items.create(
    :ImageID => "img-#{i}",
    :name => "name-#{i}",
    :other => ["nothing", "NA", "nada", "nil", "other-#{i}"])
end

Le résultat de ce test est le suivant :

On constate que le débit en écriture correspond bien à ce que nous attendions :

• 10000 w / 5 w/s = 2000 s = 33,33 min
• 10000 w / 20 w/s = 2000 s = 8,33 min
• 10000 w / 40 w/s = 250 s = 4,17 min
• …

Une dérive apparaît à partir de 160 unités, mais cela n’est pas représentatif car le test est effectué à partir d’un seul thread Ruby (l’instance EC2 m1.large elle-même n’était pas beaucoup sollicitée – CPU, Load Average, …) qui a du rencontrer sa propre limite. :o)

J’ai bien entendu vérifié après chaque test que tout avait bien été inséré : table.items.count ! :o)

A noter que j’ai aussi essayé le même test en ne recréant pas la table et en doublant la capacité en écriture à chaque fois : le résultat est le même et chaque opération de modification de la capacité du débit a pris au maximum une minute pour ces 10000 éléments.

Comme précisé dans l’introduction, il s’agit d’un mini bench. Pour bien faire avec plus de temps, il faudrait refaire le même test en optimisant un injecteur (l’instance EC2) avec plusieurs threads et en multipliant ce nombre d’injecteurs pour bencher DynamoDB et pas le code Ruby ou l’OS. Il faudrait alors vérifier la tenue des performances en écriture et en lecture (fonction de la cohérence) et surtout voir si la modification de capacité du débit sur un gros volume de données est complètement transparente pour les requêtes en cours d’exécution et quelle est la durée nécessaire à cette augmentation.

Conclusion

DynamoDB est un outil intéressant car il s’inscrit dans un démarche de plus en plus packagée des services, plus proche d’un PaaS que d’un IaaS. Le modèle est similaire à celui de SimpleDB, mais le gros avantage réside dans la non limitation de la taille d’une table et de la garantie de la performance quel que soit le volume de données stockées (sans parler de la disponibilité et de la durabilité des données qui sont assurées de manière inhérente par Amazon). Ce point technique est réalisé par la répartition (sharding) des données sur plusieurs serveurs (plus le débit souhaité sera important, plus le nombre de serveurs le sera aussi) pour permettre l’exécution de requêtes en parallèle. On comprend bien alors que l’augmentation de cette capacité peut prendre du temps sur de gros volumes, cela ne me choque pas, d’autant plus que le service reste disponible pendant cette opération !

Je suis un peu plus embêté par la limitation à un facteur 2 d’augmentation de ce débit par opération. Je n’ai pas trouvé de formulaire pour upgrader cette limite. Même en s’y prenant à l’avance, cela peut être fastidieux de recommencer cette opération (avec le temps d’attente induit) si le site concerné attend un pourcentage d’augmentation significatif.

Dans tous les cas, il faut bien comprendre que cette scalabilité n’est pas instantanée, mais qu’il faut déterminer son capacity planning et ensuite l’appliquer : le très gros avantage c’est qu’il suffit pour le mettre en place d’envoyer une requête (ou quelques unes) aux AWS qui s’occupent de tout le reste.

Au niveau fonctionnalités/modèle on retrouve un classique du NoSQL avec ses choix propres et compromis entre complétude/performance. C’est donc un moteur de base de données non relationnel intéressant qu’il faudra prendre en compte dans les choix architecturaux de nos futures applications, au même titre que d’autres moteurs sur ce créneau (y compris SimpleDB qui conserve un intérêt du fait de fonctionnalités supplémentaires possibles via ses APIs par rapport aux APIs de dynamoDB). Il faudra suivre avec attention les prochaines releases du service pour voir les fonctionnalités qui seront embarquées en plus dans le produit.

Frédéric FAURE @Twitter @Ysance

Le fonctionnement

Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

Le principe de Varnish s’appuie sur la machine à état suivante :

Varnish permet d’intervenir au niveau de chacun des états pour effectuer des opérations sur HTTP ou sur lui-même. C’est cette finesse d’intervention qui permet à Varnish d’être véloce et complet.

Un client effectue une requête sur une ressource qui n’est pas en cache suivra le cheminement suivant :

Si cette ressource est demandée à nouveau, le chemin suivi change car la ressource est maintenant en cache :

Toutes ces étapes sont symbolisées en VCL par des “procédures standards” (vcl_recv, vcl_fetch, vcl_deliver… etc). Toutes ces procédures sont surchargables et nous pouvons aussi déclarer les nôtres qui seront appelées dans les procédures standards. Le langage VCL ne tolère aucun code orphelin, tout ce qui est déclaré doit être utilisé.

Le Cache

Varnish propose un cache en mémoire et un cache sur disque. Mais il faut faire un choix, les deux ne sont pas cumulables. Le cache accepte à peu près tout ce qui passe dans les mains de Varnish (pages HTML, fichiers statics, flux de données en JSON… etc), à partir du moment où l’on déclare l’objet cachable et qu’il a une TTL.
Le cache est alimenté juste après l’étape “Fetch”, en réalité c’est juste après la récupération de la donnée sur le backend. C’est à cet endroit que l’on va faire toutes les modifications de l’entête HTTP de la ressource cachée. Faire ces modifications au niveau du “Fetch” va permettre de garantir une entrée cache propre (ne pas avoir plusieurs entrées cache car une même ressource va avoir un payload différent). De plus l’objet est stocké dans le cache avec son entête HTTP, il est donc plus efficace de traiter une fois pour toute l’entête et la resservir avec l’objet.
Comme nous le verrons plus loin, la compression d’objet influe aussi sur les performances du cache. Il est préférable de stocker un objet compressé et laisser Varnish le délivrer compressé ou non suivant l’entête “Accept-Encoding”.

La définition correct de la TTL d’un objet pour manager le cache-control est un élément important de Varnish. Nous pouvons contrôler le cache de façon précise en définissant la TTL pour un type de ressource ou pour une url par exemple :

if(beresp.ttl > 0s){
  unset beresp.http.Expires;
  if ( req.backend == backend_S3 ) {
     set beresp.http.Cache-Control = "public, max-age=60";
     set beresp.ttl = 60s;
  } else {
     set beresp.http.Cache-Control = "public, max-age=7200";
     set beresp.ttl = 2h;
  }
}

Ici nous demandons à Varnish de cacher sur 60 secondes tout ce qui vient de le backend “backend_S3” et le reste sera caché deux heures.

Le cache peut se manager de deux façons différentes :

La Compression

Depuis la version 3.0, Varnish a la possibilité de compresser et décompresser des ressources. Cette fonctionnalité est importante pour 3 raisons :

Elle peut être activée simplement en harmonisant l’entête “Accept-Encoding” et en positionnant la variable “do_gzip” au niveau du backend ou de la réponse du backend. Pour le reste Varnish va adapter la réponse (objet compressé ou non) au client en s’appuyant sur le “Accept encoding” de la requête.
Il est bien sûr évident que la stratégie de compression doit être adaptée au type d’objet. On ne compressera pas un objet déjà compressé (gif, jpg…etc) :).

Le Loadbalancing

Varnish peut gérer des backends de tous horizons. Avec des sites de plus en plus chargés, il est capable d’offrir la possibilité de faire du loadbalancing. Varnish dispose de 3 types de loadbalancing qui sont appelés “Director” :

Varnish sait gérer l’éviction d’un backend lorsqu’il est indisponible. Cette fonctionnalité est d’autant plus utile quand nous activons le “probe” sur les backends.

backend server1 {
   .host = "server1.example.com";
   .probe = {
     .url = "/";
     .interval = 5s;
     .timeout = 1s;
     .window = 5;
     .threshold = 3;
   }
}

Varnish dispose aussi d’un mécanisme pour palier complètement à la défaillance d’un backend ou d’un Director. Nous appelons cela “Grace mode” ou “Saint mode”. Ces termes cachent la possibilité de servir un contenu caché même x minutes après la TTL en cas de non réponse d’un serveur. Il est aussi capable d’aiguiller une requête vers un autre serveur répondant correctement quand le serveur cible initial donne des réponses HTTP 500 à cause d’une trop grande charge par exemple.

Reverse Proxy

Nous avons vu que Varnish se place devant toute notre infrastructure. Il va permettre de masquer complètement l’architecture déployée en utilisant toute la puissance de Reverse Proxy qu’il met à notre disposition.

En fait, il nous permet de faire un découplage complet entre l’organisation des URIs d’appels et l’organisation de leurs traitements sur l’infrastructure.

Voici un exemple d’une requête cliente que nous arrivons à aiguiller avec Varnish vers un bucket S3 public du nom de “ressources” et l’aiguillage prend en compte ce qu’il y a dans le nom du host de la requete :

set req.backend = backend_s3;
if(req.url == "/ressources1.xml") {
  set req.url = regsuball(req.http.host,
              "^(?:.*[.])?([a-z]+)[.](?:net|com)$", "/ressource1.\1.xml");
}else if(req.url == "/ressource2.txt") {
  set req.url = regsuball(req.http.host,
              "^(?:([a-z]+)[0-9]*[.])(?:([a-z]+)*[.])[a-z]+$","/ressources.\1.\2.txt");
}
set req.http.host = "resources.s3.amazonaws.com";

backend  backend_s3 {
  .host = "ressources.s3.amazonaws.com";
  .port = "80";
  .connect_timeout = 5s;
  .first_byte_timeout = 3s;
  .between_bytes_timeout = 2s;
  .max_connections = 1000;
}

Sécuriser et nettoyage HTTP

Le protocole HTTP permet d’utiliser plusieurs types de méthodes (GET, POST, DELETE… etc). Ces méthodes peuvent être utilisées de différentes manières pour déclencher des actions spécifiques (cas de services REST) sur les services abrités sur les backends. Or la protection au niveau HTTP de ce genre de services est assez fastidieuse côté serveurs d’applications. Varnish va permettre de filtrer précisément ce qui doit passer et pour quelle utilisation. Nous allons donc limiter les effets de bords.
Imaginons que nous avons un service accessible uniquement en GET /service1/ et un deuxième /service2/ accessible lui en GET et POST nous allons écrire quelque chose comme ceci :

if (req.request != "GET" && req.request != "POST"){
  call error;
}

if (req.url ~ "^/service2"){
call service2;
}

if(req.request == "POST"){
  call error;
}

if (req.url ~ "^/service1"){
  call service1;
}

call error;

Dans cet exemple nous interdisons systématiquement tout ce qui n’est pas méthode GET ou POST. Ensuite pour une url qui commence par /service2 nous allons vers la routine qui va traiter le payload pour ce service. Puis nous bannissons la méthode POST et nous traitons les urls avec /service1 et enfin nous bannissons le reste.

Avec cette méthode aucune requête non prévue peut remonter vers un backend. Nous avons deux avantages :

Dans un deuxième cas de figure il peut être intéressant de normaliser les entêtes HTTP. Prenons l’exemple de l’Accept-Encoding. Varnish préconise de le normaliser ainsi :

if (req.http.Accept-Encoding) {
  if (req.http.Accept-Encoding ~ "gzip") {
    set req.http.Accept-Encoding = "gzip";
  } elsif (req.http.Accept-Encoding ~ "deflate") {
    set req.http.Accept-Encoding = "deflate";
  } else {
    remove req.http.Accept-Encoding;
  }
}

Tout simplement pour éviter de créer des entrées cache différentes pour un même payload uniquement parce que tous les clients n’écrivent pas cet entête de la même façon.

Nous pouvons aussi enlever certains headers qui peuvent donner trop d’informations sur l’infrastructure. Pour S3 par exemple nous allons passer ces commandes dans le fetch :

unset beresp.http.x-amz-id-2;
unset beresp.http.x-amz-request-id;
unset beresp.http.x-amz-meta-s3cmd-attrs;
unset beresp.http.x-amz-meta-s3fox-filesize;
unset beresp.http.x-amz-meta-s3fox-modifiedtime;

Ou positionner des entêtes plus personnelles :

set beresp.http.Server = « ServeurPerso »;

La dernière petite chose à penser pour le nettoyage réside dans le positionnement d’un content-type correct pour toutes des ressources. Cette opération se fait de la même manière que pour le nettoyage des headers en positionnant “set beresp.http.Content-Type” par groupe de ressources.

De par ces fonctionnalités, Varnish est capable d’assurer l’orchestration de la haute disponibilité d’une architecture. Il est capable de détecter les backends défaillants et même de les remplacer en s’appuyant sur son cache. Il va les protéger en prenant en compte une grande partie de la gestion des erreurs 404.

Uniformisation des Logs d’accès

Le process “varnishd” ne produit aucun log. Il se contente d’écrire les informations dans des segments de mémoire partagée. Ces segments sont consommés par des outils comme varnishadm, varnishlog ou encore varnishncsa. C’est principalement varnishncsa qui nous intéresse. C’est ce process qui va lire les informations et créer un fichier de log au format NCSA. L’avantage ici est énorme. Nous pouvons décharger les serveurs d’applications et front http de la production de ces logs. De plus ces logs seront moins éparpillés (quoi que, avec l’utilisation de syslog-ng ça ne soit pas un problème). Enfin les logs seront tous normalisés qu’ils soient sur Apache, Tomcat, JBoss ou encore lighttp et NginX. Nous pouvons donc penser uniquement aux traitements que nous allons bien pouvoir leur faire subir et ne plus passer du temps à tout reformater. Cette considération prend tout son sens quand on commence à atteindre plusieurs gigas de logs d’accès par jour.
Depuis la version 3.0, Varnishncsa permet de ne pas suivre la norme NCSA et nous laisse le choix du format de sortie.

Laurent ROUX