Comment scaler une infrastructure AWS (Amazon Web Services) ? Je vais décrire dans cette deuxième partie de l’article le modèle de l’architecture et les composants techniques sous-jacents à adopter afin de mettre en place une infrastructure scalable. Nous aborderons tout particulièrement le sujet de l’optimisation de l’accès aux données dans les architectures de type scale-out propices à la distribution, autant au niveau du modèle de données que des couches basses pour l’optimisation des I/O. Nous verrons également les concepts de développement à privilégier tel que le stateless dans la plus pure tradition REST. Je terminerai par quelques trucs et astuces en fin d’article. Le but est de vous permettre de constituer et d’optimiser votre infrastructure en comprenant le fonctionnement des outils proposés par Amazon pour en tirer le meilleur parti.

Le scale-out
Le scale-out est à opposer au scale-up : ce dernier correspond à l’augmentation dynamique des ressources d’un serveur donné (ajout de RAM ou de CPU) à la volée. Ainsi l’application continue à s’exécuter sur une même machine dont le potentiel à augmenté. Le scale-out, lui, pour répondre à la montée en charge d’une application propose d’augmenter le nombre de serveurs. Au final, le potentiel global de l’infrastructure augmente aussi, mais est réparti entre plusieurs serveurs. Cela implique que l’application supportée sur le serveur ait été pensée en termes de distribution, c’est à dire qu’elle puisse s’exécuter en parallèle sur plusieurs serveurs sans que cela n’en corrompe la logique métier ou ne pose des problèmes d’accès aux ressources (qui doivent alors être disponibles via le réseau et non en local sur un serveur donné par exemple).

Le scale-out, c’est un peu l’agent Smith de Matrix. Pour le scale-up, pensez plutôt au gentil bibendum de Ghost Buster !

Stateless
Le meilleur moyen d’obtenir une application facilement distribuable et performante est de la penser en mode stateless. C’est à dire que c’est la requête du client qui doit contenir l’ensemble des informations qui vont permettre le traitement de ladite requête côté serveur, soit via un cookie ou bien via les paramètres de l’URL. Quand cela est possible il faut privilégier cette approche à tout prix par rapport au mode statefull dans lequel la partie serveur doit maintenir un contexte pour chaque client afin de pouvoir résoudre sa requête. La conception stateless fait parti des grands concepts du REST. A ce sujet, je ne peux que vous conseiller de lire cet excellent article sur REST de Jean-Paul Figer dans lequel vous pourrez comprendre toute la simplicité et la puissance du style.

Si vous êtes obligés de gérer du statefull, il vous faudra utiliser un cache réseau, tel que Memcached, pour partager les contextes entre vos différents serveurs. N’envisagez pas la formule cache local et sticky session, car vous aurez du mal à bénéficier d’une répartition fluide au niveau de votre load balancing. N’envisagez pas non plus un cluster qui communique en multicast car le réseau Amazon ne permet pas d’en faire… Ou bien alors il faudrait que tous les serveurs communiquent en unicast avec une gateway qui s’occupe de la redistribution des communications… Vous êtes sûr que vous ne préférez pas du stateless ? ;ob

La mise en place d’applications stateless n’est pas arrivée avec le Cloud Computing et les AWS, en revanche ne pas penser dans ce sens, vous empêcherait de bénéficier de tout le dynamisme et la souplesse proposés par ces services.

Optimisation de l’accès aux données
L’optimisation de l’accès aux données passe par 2 éléments :

• Le modèle de données et l’architecture logicielle que l’on retrouve dans les architectures scalables, que l’on soit sur une infrastructure AWS ou non.
• La gestion des I/O que l’on peut optimiser, notamment via une utilisation approfondie des AWS.

Le modèle scalable
Cela pourrait faire l’objet d’un article à part entière, mais correspond à un modèle assez classique au sein des applications de type casual gaming ou bien plus généralement liées à des applications basées sur les graphes sociaux ou bien centrées sur une notion métier forte en particulier.

Pour résumer, 2 méthodes de stockage de données :

• Un stockage de ce que l’on peut appeler le méta-modèle, qui n’a pas vocation à être distribué, basé sur une base relationnelle (même si essentiellement utilisée sous forme d’accès clé-valeur) structurée, indexée, contenant les informations générales de chaque utilisateur (dans la cas d’une application sociale, avec les informations nom, top score, gains de la veille, …), essentiellement accédées en lecture et dont il est possible d’alléger la charge via un Memcached en frontal. Il est donc possible d’effectuer des requêtes ensemblistes de type SQL et ainsi de récupérer des informations via l’utilisation de clauses (WHERE). Cette base peut être un MySQL ou un PgSQL par exemple. Je vous invite à lire ce comparatif très intéressant de Guillaume Plessis entre l’utilisation de MySQL installé sur un EC2 et l’utilisation du service RDS (Relational Database Service) d’Amazon. Je ne trahirai en rien le suspens en vous disant que la base de données c’est une histoire de barbus ! :o)
• Un stockage pour les données plus volatiles (comme les données de jeu, …), avec un fort rapport écriture/lecture, difficilement cachables, et pour lesquelles il faut opter pour une réelle solution de stockage structurée non relationnelle de type clé-valeur (NoSQL / Not only SQL diront certains), permettant ainsi de distribuer facilement les données sur X serveurs. On peut citer un nombre certain de candidats : Redis, Tokyo Tyrant/Tokyo Cabinet, MemcacheDB, … Et également les nouveaux modèles peer to peer tels que Cassandra, …

Tokyo Cabinet

En l’occurrence, Tokyo Tyrant / Tokyo Cabinet est une solution que j’ai mise en place et qui me semble bonne. C’est un couple gérant respectivement les requêtes à partir de serveurs distants (interface réseau) et les accès au système de stockage. 6 APIs sont disponibles afin de stocker les données :

1. On memory Hash,
2. On memory B+tree,
3. File Hash,
4. File B+tree,
5. Fixed-length Array,
6. Table.

Chacune d’entre elles a ses propres spécificités et répond à des besoins particuliers en termes de performances et de fonctionnalités.

Au niveau performances, outre ses performances naturelles, il a l’avantage, notamment, de ne pas gérer l’authentification (standard chez les systèmes de stockage clé-valeur, la sécurité est censée être assurée au niveau réseau pour les accès au système de stockage et au niveau applicatif pour les accès à la donnée – pour ne récupérer que ce qui vous concerne), ce qui allège le nombre d’accès (pas besoin de requêtes d’authentification) par rapport à une base de données classique. De plus, pas de gestion d’index lourds à reconstruire (possible cependant sur l’API « Table » de la Tokyo Team), … Est-il nécessaire de préciser que ce qui vous prendra du temps sur l’accès à la donnée via le réseau (entre le serveur web ou applicatif et Tokyo Tyrant) c’est… Le réseau ! Donc dans tous les cas, préférez l’utilisation au niveau client (API) de « mget » (multi get), par exemple, en positionnant en paramètre le tableau de clés que vous souhaitez récupérer, plutôt que d’effectuer N fois un « get » à partir du client, donc N accès réseau. « mget » se résoudra, lui, au niveau de Tokyo Tyrant.

Ces raisonnements appliqués sur cet outil doivent être appliqués à tout stockage de type clé-valeur.

La gestion des I/O
Venons-en à la spécificité des AWS en termes de stockage : les EBS (Elastic Block Store). Les EBS sont des disques réseau optimisés en I/O, faciles à manipuler, permettant d’assurer la durabilité des données qui ne doivent pas être perdues lors de l’arrêt d’un EC2 (volatile). J’ai cependant constaté de manière empirique des écarts de latence : pas énormes, mais sur une application réellement sollicitée, il y a un ressenti. Ce n’est pas rédhibitoire, il faut juste en tenir compte. Si le Load Average de vos serveurs augmente, ce n’est pas forcément le CPU en cause… Pensez I/O ! ;ob

Tout d’abord penser striping, donc RAID0. Pas besoin de mirroring (RAID1), la durabilité des EBS est déjà assurée par Amazon, de manière transparente, par réplication réseau : tirons parti de ce service et concentrons nous sur le striping. Pensez également à répartir les écritures des différents fichiers physiques (données, updates logs, …) sur différents disques (dans le cas d’outils utilisant des update logs, et c’est le cas pour MySQL et Tokyo Tyrant par exemple, pensez à bien paramétrer leur taille). C’est ce qui permet d’avoir les meilleures optimisations. Ensuite, choisissez bien votre système de fichier par rapport à votre outil (EXT3, XFS, …) et pensez aux options de montage (noatime, nodiratime, …). Finalement vérifiez bien le scheduler/ordonnanceur par défaut sur les instances EC2 que vous démarrez : par défaut, il s’agit de l’ordonnanceur NOOP (requêtes I/O dans une simple file FIFO). Envisagez quelque chose de plus performant comme CFQ (Completely Fair Queuing) par exemple… Enfin je dis ça, mais cela dépend toujours de la couche logiciel au-dessus et si et comment elle gère les priorités : dans cet exemple (qui n’est pas sur EBS) sur MySQL Performance Blog, il apparaît que les ordonnanceurs NOOP et DEADLINE peuvent être de meilleure facture pour améliorer les I/O InnoDB. Comme quoi, il faut quand même mieux tester dans son propre cas ! ;ob

Logical Volume Management

Un autre outil que j’ai utilisé avec les EBS et qui fonctionne très bien est LVM2 (Logical Volume Management, version 2). Je ne l’ai pas utilisé dans le cadre d’une architecture avec un nombre élevé d’IOPS (I/O operations Per Second) et n’ai donc pas testé les possibilités de striping (RAID0) offertes par l’outil. En revanche, je l’ai utilisé dans le cadre d’une infrastructure nécessitant de pouvoir supporter des augmentations conséquentes du volume de données et ceci sans interruption de service. L’opération de snapshot d’un EBS et de recréation du volume est trop longue. LVM est la solution, puisque cette couche d’abstraction permet de gérer des volumes logiques de manière indépendante des ressources physiques : il suffit de lever une nouvelle ressource EBS (une ligne de commande), de l’associer à l’instance EC2 (une autre ligne de commande) et d’ajouter cette ressource au pool de ressources LVM. Il suffit alors d’agrandir le volume logique (toujours transparent et sans arrêt du service), puis d’étendre le système de fichiers. C’est la dernière opération (qui est commune avec celle de la recréation du volume EBS) qui peut nécessiter d’arrêter le service quelques instants (une dizaine de secondes). A noter qu’il est possible d’étendre son système de fichiers à chaud avec EXT3, personnellement, je préfère une interruption de service de quelques secondes sur ce genre d’opérations très courtes mais cruciales. ;ob En prime, il est facile de d’effectuer des backups sur un système LVM qui propose une option de snapshot différentiel que l’on peut monter comme un volume logique indépendant : lorsqu’il y a une modification sur le volume origine, la valeur initiale est copiée dans le volume snapshoté, donc on peut snapshoter des volumes importants sur un espace réduit car seule la fréquence de modification est importante. Vous pourrez trouver de plus amples informations sur LVM2 et EBS en consultant ce très bon article de Laurent Roux.

Tous ces exemples, pour montrer que les EBS sont une ressource très intéressante : il faut les considérer tout d’abord comme un moyen d’assurer la durabilité des ressources importantes avant de considérer l’aspect performance. En effet, la performance n’est pas forcément meilleure sur un EBS que sur les disques locaux d’une instance EC2 (Cf. un test simple et intéressant de Charles-Christian Croix ou bien encore des tests un peu plus complexes que vous pourrez retrouver en tapant « performance ephemeral disk ebs volume raid » dans Goggle, il y en a un certain nombre de très intéressants et je dois avouer que j’ai du mal à faire mon choix ;ob). Cependant, quand on prend le parti d’assurer la durabilité de ses données et donc d’utiliser un EBS (qui, pour ceux qui connaissent, est comparable à un LUN sur un SAN), il y a divers moyens d’optimiser leur performance.

Il est à noter que les utiliser pour répartir les fichiers (et donc les I/O) sur plusieurs disques EBS peut être une solution de performance pure.

A noter tout de même que la bande passante de l’EC2 est forcément limitant arrivée à un certain seuil : ajouter des EBS est intéressant pour lisser les écarts de variance (en RAID0) ou bien pour optimiser le débit, mais il n’en reste pas moins que si vous ajoutez plusieurs EBS à votre instance EC2 et qu’ils sont tous sollicités fortement… C’est la bande passante de l’EC2 qui bloque. Il va falloir ajouter un nouvel EC2 (scale-out pour augmenter les ressources, en l’occurrence la bande passante), lui attacher de nouveaux EBS (n’oubliez pas qu’un EBS ne peut être attaché qu’à un et un seul EC2) et distribuer la donnée dessus (sharding).

Dans tous les cas, la manipulation des EBS est aisée et cette souplesse est un atout.

Tips & tricks
Cette dernière partie regroupe quelques trucs et astuces.

Alias & IPs
Pensez sur une infrastructure AWS à positionner des alias correspondant aux IPs privées de vos instances dans le fichier des « hosts », que vous pouvez déployer ensuite via Puppet pour plus de réactivité vu que les IPs sont « variables » (lorsque vous arrêtez une instance et que vous en redémarrez une juste après, vous ne conservez pas la même IP). L’utilisation du fichier « hosts » évite des résolutions DNS internes chez Amazon.

CDN & S3 Headers
Pour les CDN (Content Delivery Network) que vous utilisez obligatoirement dans une architecture scalable, pensez à utiliser S3 afin de mettre à disposition les images et autres contenus statiques. Inutile de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Pensez également dans certains cas où votre trafic est plus modéré et que vous ne souhaitez pas passez sur un CDN (pour des questions de coût par exemple ;ob), que vous pouvez toujours optimiser la gestion de vos ressources sur S3 en utilisant les méta-données attribuées aux dites ressources sur S3, en positionnant, par exemple, les headers de type Cache-Control ou Expires. Vous pouvez visualiser ces méta-données via le nouvel onglet S3 de la console d’administration Amazon.

Backups… What else ?
S3 est également la solution pour les backups. Je n’ai pas trouvé d’outils intégré satisfaisant pour cette tâche : j’utilise simplement un outil en ligne de commande « s3cmd » afin de stocker mes backups. J’ai intégré cet outil dans des tâches Capistrano appelées par cron. Très simple d’utilisation, s3cmd permet de consommer les services de S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Conclusion
Il y aurait encore beaucoup de choses à dire sur ce sujet, mais ce sont à mon avis les principales, en tout cas par rapport à l’utilisation des services mis à disposition par les AWS. Ce qu’il en ressort, c’est :

• Le stateless et REST de manière générale, sont d’autant plus adaptés aux AWS qu’ils permettent de distribuer aisément la charge sur une infrastructure s’adaptant à la montée en charge sur un modèle scale-out.
• L’accès aux données est toujours le goulet d’étranglement des applications distribuées devant scaler. Il s’agit de travailler à ce niveau le modèle de données et de tirer parti des systèmes de stockage adéquates :
  • Technologies SQL pour les méta-données pouvant nécessiter du requêtage ensembliste et de la mise en  relation, tout en utilisant au maximum un cache réseau pour les informations avec un fort ratio lecture sur écriture.
  • Technologies NoSQL / Not only SQL / clé-valeur pour les informations pouvant être accédées par une clé unique, et ainsi bénéficier de la distribution inhérente au scale-out.
• Penser finalement aux couches basses en sélectionnant convenablement le système de fichiers et l’ordonnanceur. Pensez également RAID (striping) et LVM (extension de volume et snapshot différentiel) pour tirer parti de la souplesse d’utilisation des EBS et répartition des I/O sur différents devices (en prenant toujours garde à votre bande passante, au niveau EC2, qui peut devenir limitant : dans ce cas ajouter une ou plusieurs instances EC2 pour gagner en bande passante et distribuer – sharder – la donnée sur de nouveaux EBS).

J’espère que ce deuxième volet de mon retour d’expérience sur la scalabilité des infrastructures AWS vous aura intéressé.

Frédéric FAURE @Twitter @Ysance

Pour servir de support à cet article, je vous propose de regarder cette vidéo très intéressante de Ilya Grigorik, fondateur et CTO de AideRSS, que vous pourrez retrouver sur son blog igvita.com (un blog très intéressant que je vous conseille de lire).

La VIDEO.

Cette vidéo de 30 min, dans un anglais tout à fait abordable, est très intéressante, notamment sur les extensions de fonctionnalités rendues possibles par le langage de scripting Lua, intégrable au niveau de Tokyo Tyrant afin de permettre la mise en place de « user-defined fonctions » au niveau du serveur, centralisant les traitements et les rendant pseudo-atomiques. Je reviendrai dessus par la suite.

Les APIs
Comme je vous le précisais, Tokyo Tyrant/Tokyo Cabinet est un couple gérant respectivement les requêtes à partir de serveurs distants (interface réseau) et les accès au système de stockage. 6 APIs sont disponibles afin de stocker les données :

1. On memory Hash,
2. On memory B+tree,
3. File Hash,
4. File B+tree,
5. Fixed-length Array,
6. Table.

Chacune d’entre elles a ses propres spécificités et répond à des besoins particuliers en termes de performances et de fonctionnalités.

Je ne paraphraserai pas la vidéo de Ilya Grigorik qui explique déjà un certain nombre de choses, mais apporterai quelques précisions.

Sur la notion de complexité des mécanismes de stockage Hash et B+tree (On memory ou File), les fonctions O(1) et O(log N) représentent la complexité d’accès à la donnée en fonction du nombre d’occurences stockées dans le système. On comprend bien que le comportement O(1) correspond bien à celui d’une hashtable, puisque le temps d’accès à la donnée ne dépend pas du nombre d’occurrences. En effet, la donnée est accédée directement à partir du hash de sa clé. Eventuellement, cette complexité peut varier si des collisions sur le hash apparaissent (2 clés différentes peuvent donner le même hash, à ce hash correspond alors une liste chainée de valeurs possibles). Il n’y a pas non plus d’index et donc de reconstruction d’index sur les insertions : donc gain de rapidité par rapport à une base de données classique. Pour plus de détail sur le fonctionnement des hashtables suivez ce lien. Voici également 2 schémas issus de « Wikipedia, the free encyclopedia » expliquant la notion de hash et de collision :

Hashtable

Hashtable - Collisions

La notion permettant d’évaluer la probabilité de collision est ce que l’on appelle la dispersion… Mais cela est un autre sujet ! ;ob

On comprend que le B+tree est donc un peu moins performant car sensible dans une certaine mesure (O(log N)) au nombre d’enregistrements. B+tree trouve son utilité dans le fait que le stockage est moins volumineux sur disque (ou en mémoire). Dans le cas du B+tree, les clés ne sont pas nécessairement uniques et il y a une notion de tri.

Pour le détail sur ces APIs, vous pouvez consulter la spécification.

Les performances
Il est à noter que les performances atteintes par Tokyo Cabinet seront probablement limitées du fait de l’utilisation de Tokyo Tyrant, puisque dans la majorité des cas vous aurez probablement à accéder au système de stockage à partir d’un serveur distant. Partez donc sur les performances affichées par Tokyo Tyrant qui, soit dit en passant, sont déjà considérables. Lors d’un bench que j’ai effectué sur le produit, je me suis aperçu que le load average de mon serveur hébergeant Tokyo Tyrant et Tokyo Cabinet était anormalement élevé… Pas à cause du CPU, mais à cause du disque qui ne répondait pas assez vite aux I/O débités par la Tokyo Team… Pensez à bien choisir votre système de fichier dans ce cas (type – EXT3, XFS, … -, journalisé ou non, options de montage, …) et n’hésitez pas à mettre du RAID0, par exemple, pour optimiser les performances en lecture/écriture ou bien à répartir les écritures des différents fichiers physiques (données, ulogs, …) sur différents disques.

Est-il nécessaire de préciser que ce qui vous prendra du temps sur l’accès à une donnée via le réseau c’est… Le réseau ! Hé oui ! Donc dans tous les cas préférez l’utilisation au niveau client (API) de « mget » (multi get), par exemple, en positionnant en paramètre le tableau de clés que vous souhaitez récupérer, plutôt que d’effectuer N fois un « get » à partir du client, donc N accès réseau. « mget » se résoudra, lui, au niveau serveur (Tokyo Tyrant).

Les protocoles
Il est à noter que les protocoles HTTP et Memcached (et donc leurs APIs) sont directement utilisables afin d’accéder à Tokyo Tyrant, pas besoin de modifier le code de l’application pour passer d’un stockage on-memory sur Memcached à un stockage on-file sur Tokyo Tyrant/Tokyo Cabinet, par exemple. A noter que l’intégralité des fonctionnalités de Tokyo Tyrant ne seront donc pas forcément disponibles via le protocole Memcached ou HTTP, comme la concaténation, … Vous pouvez également utiliser le protocole natif binaire pour communiquer avec Tokyo Tyrant, ou bien avec Tokyo Cabinet si vous fonctionnez en « localhost ».

Le requêtage ensembliste
En utilisant l’API Table, vous remarquerez qu’à chaque clé correspond un ensemble d’attributs, pas forcément le même nombre pour chaque clé (ces attributs peuvent être ajoutés à la volée et pas forcément valorisés pour les clés « antérieures »… Ni « postérieures » d’ailleurs). Il n’y a donc pas de schéma figé et chaque attribut peut faire l’objet d’une clause de requête ensembliste de type « WHERE ». Vous pourrez donc récupérer une liste de valeurs correspondant à des conditions sur un attribut et n’avez pas besoin de nommer explicitement la clé ou un pattern de clé afin de récupérer votre objet ou votre liste d’objets (cela n’est possible qu’avec l’API Table). Ce fonctionnement est similaire à celui que l’on peut retrouver sur SimpleDB, par exemple. A noter qu’il est aussi possible de positionner un index sur un attribut (Cf. vidéo de Ilya Grigorik).

Lua
Lua… Lua !!! Un langage de scripting léger et efficace et comme le dit Ilya Grigorik : « C’est un mélange de Ruby et de Javascript… Enfin… Les mauvaises choses des 2 ! ;ob ». Cela explique probablement sa popularité : facile à utiliser, simple, efficace, … que demander de plus ? Il permet, par comparaison avec MySQL, de mettre en place des « user-defined fonctions », à la différence qu’il s’agit d’un langage interprété qui ne provoquera pas le plantage du serveur Tokyo Tyrant sur une erreur ;ob. Il permet de mettre en place des opérations complexes comme par exemple :

• Renvoyer les données avec un format particulier (JSON, …).
• Implémenter des fonctionnalités pseudo-atomiques au niveau serveur (c’est à dire atomique vu par le client = un seul appel réseau) afin de reproduire des fonctionnements tels que ceux du composant Set de Redis, un autre système de stockage clé/valeur montant l’intégralité de son dataset en mémoire (il faut tenir compte de ce point quand on choisit Redis au regard du volume de données que l’on doit stocker, mais rien n’empêche de distribuer le dataset sur plusieurs Redis) et assurant la persistance des données en écrivant de manière asynchrone sur le disque (soit suivant un délai, soit suivant un nombre de modifications effectuées sur ledit dataset). Concernant les types de données natifs sous Redis, vous pourrez notamment trouver les « List » qui sont des séquences d’éléments ordonnées et les « Set » (évoqués dans la vidéo) correspondant à une collection non-ordonnée sur laquelle on peut appliquer des opérations de type intersection, union, différence, … avec d’autres « Set ». Pour terminer cette digression permettant de comprendre l’exemple donné au cours de la vidéo, vous pouver consulter la Page de référence des commandes Redis, ainsi que l’Introduction aux types de données Redis. Un exemple/tutoriel très intéressant est également disponible et présente la mise en place d’un clone de Twitter nommé Retwis : A case study: Design and implementation of a simple Twitter clone using only the Redis key-value store as database and PHP.
• Implémenter une notion de TTL (Time To Live) comme dans Memcached. Cet exemple est basé sur l’utilisation de la Table API, puisqu’il faut un attribut supplémentaire ( « l’expiration time » ) qu’il est commode d’indexer pour des questions de performances (la possibilité d’introduire des index est noter pour cette API).

A noter que ces implémentations, et notamment celle du Set, ne sont probablement pas aussi rapides qu’une fonctionnalité native, mais il est très pratique de pouvoir embarquer de la logique au niveau du serveur.
A noter également la possibilité de démarrer le serveur Tokyo Tyrant en demandant un appel périodique (pc = periodic call) à ces « user-defined fonctions » en background. Pratique pour des opérations de purge, …

MapReduce inside !
On note l’introduction du paradigm MapReduce à l’intérieur de Tokyo Tyrant, en natif, avec la possibilité de développer ses fonctions de Map et de Reduce en Lua.

Réplication
Il est également possible de mettre en place de la réplication master-slave simplement entre 2 serveurs : quel beau couple qu’un master « on-memory » permettant d’optimiser les accès et un slave « on-file » assurant la persistance des données.

Voici les commandes permettant de mettre 2 serveurs en master-slave :

ttserver -port 1978 -ulog ulog-1 -sid 1 casket-1.tch
ttserver -port 1979 -ulog ulog-2 -sid 2 -mhost localhost -mport 1978 -rts 2.rts casket-2.tch

Simple non ?

Conclusion
Tokyo Tyrant / Tokyo Cabinet est un outil de stockage clé/valeur très intéressant, d’une part par ses performances et d’autre part par les possibilités d’évolutions qu’il offre en termes de fonctionnalités et de logique embarquée.

Cependant au delà de l’outil lui-même, il faut se poser la question en amont du modèle que l’on souhaite adopter vis à vis du fonctionnel de son application. Il est évident que si votre application peut s’adapter à un modèle clé/valeur, il est indispensable d’envisager cette possibilité, et c’est une des premières étapes à envisager au niveau de la conception. Je cite un de mes articles concernant le Sharding et optimisation des accès aux données :

Le sharding est une des solutions possible pour l’amélioration des temps de réponse sur ladite source d’éléments. Mais avant d’envisager cette solution, il est intéressant d’envisager d’autres possibilités dans cet ordre :

• le concept du modèle non relationnel, hébergé ou non, en général, puisque de ce choix découlera un autre modèle de fonctionnement,

Le modèle clé/valeur est en effet un boost en termes de performances, si évidemment celui-ci correspond à votre fonctionnel. Cette question est à soulever rapidement et permettra de ne pas partir sur un modèle relationnel trop coûteux et sous exploité par certains types d’application.

Frédéric FAURE

Pourquoi est-il si méchant ?
Oui ? Pourquoi vouloir à tout prix découper cette pauvre donnée dans tous les sens ? Quel est le déclencheur de cet acte barbare ?

Cela se produit simplement quand les temps de réponse des opérations sur une table fortement peuplée deviennent trop importants. Nous prendrons comme exemple une table « utilisateurs » comportant plusieurs millions de lignes. Depuis de nombreux SELECT en concurrence, qui unitairement ne présentent pas de performances dégradées malgré le nombre d’enregistrements, mais qui, sur de nombreuses requêtes, accumulent les latences, jusqu’aux INSERT demandant de reconstruire des INDEX monstrueux, où quelques insertions en trop sature la base, il y a de nombreuses raisons évidentes de vouloir découper son pool de données afin de pouvoir les manipuler plus légèrement.

Pour résumer, le besoin peut provenir de la masse de données elle-même ou bien du nombre/type de requêtes sur cette masse.

Il existe à ce niveau 2 techniques de sharding : le découpage en tranches et en lamelles…

Découpage en tranches… ou horizontal
Le sharding horizontal consiste à répartir les données (lignes) d’une table cible entre plusieurs selon un critère basé sur une information liée à la donnée, par exemple un modulo sur l’identifiant qui permet de répartir les données sur X tables. Le tout est de savoir, au niveau de l’application cliente, sur quelle table aller chercher l’information. La clé et le plan de répartition sont , en effet, des éléments déterminants. La clé étant l’élément (ou les éléments) de la donnée à répartir sur lequel (ou lesquels) va porter le plan.

Plusieurs plans de répartition sont possibles sur une clé donnée :

• Le modulo comme cité précédemment, ou autre fonction mathématique adaptée, est une option possible. Cependant, un changement du nombre de shard implique une redistribution complète. C’est cependant pratique si on doit définir la répartition sur un identifiant que l’on ne maitrise pas (récupéré d’un autre système ou fournisseur par exemple).

• Dans la même idée, on peut répartir selon un algorithme de hash à définir soigneusement sur des valeurs non modifiables pour un objet donné à répartir et de telle manière que le calcul du hash soit rapide, le nombre de collisions entre 2 résultats minimum et la dispersion bonne. De même que précédemment, un changement du nombre de shard peut impliquer une redistribution complète. Cependant, des algorithmes appelés « consistants » existent. En utilisant des algorithmes de hash consistants, seulement K/n clés doivent être redistribuées en moyenne, où K est le nombre total de clés et n le nombre de shards.

• Un « range », c’est-à-dire un intervalle, est aussi une solution. Pratique pour étendre le nombre de shard, il faut cependant maitriser l’identifiant retenu, un incrément par exemple, afin d’avoir une diffusion correcte.

D’autres méthodes peuvent êtres envisagées. Celles que j’ai citées sont les plus communes et les plus utilisées car elles répondent en général au besoin. La diffusion de la méthode retenue sur le critère choisi est dans tout les cas à vérifier pour une répartition efficace des données, c’est-à-dire qu’une répartition efficace aboutit à l’obtention de shards de tailles équivalentes. Le critère choisi pour répartir est généralement un identifiant, en effet, toute modification de la valeur déterminant la répartition, dans le cas d’un range ou bien intégrée dans le calcul d’un hash ou d’une fonction mathématique, ferait que l’objet ne serait plus accessible car pas enregistré dans le shard lui correspondant ou alors il faudrait le redispatcher…

Cette répartition peut se faire sur X tables dans une même base ou serveur ou bien sur 1 table dans Y bases ou serveurs (ou les 2 ;ob). Tout dépend du point d’engorgement. Est-ce purement le temps de réponse dû au volume de la table ? Ou bien atteint-on la limite physique du serveur qui peine à répondre à toutes ces requêtes ?

On en vient à la limitation de ce modèle pour lequel les requêtes ensemblistes posent problème. Je m’explique : on répartit les utilisateurs dans 2 tables en fonction du sexe : homme / femme. Je souhaite récupérer via une requête unitaire le Monsieur dont l’identifiant est X. Pas de problème je « SELECT * FROM UTILISATEUR_HOMME WHERE id=X ». Maintenant je souhaite récupérer toutes les personnes possédant un numéro de portable… Il va falloir faire la requête sur les 2 tables et corréler les résultats au niveau applicatif… dans des requêtes plus compliquées, notamment incluant des jointures, ce n’est pas forcément bénéfique. La parallélisation des requêtes, sur un sharding, au niveau applicatif est possible (quand le modèle de données le permet bien sûr), mais doit rester, à mon avis, mineur afin de ne pas perdre le bénéfice du sharding sur le temps de réponse pour une base donnée, en multipliant le nombre d’accès/connexions sur X sources et en traitant les résultats obtenus au niveau applicatif.

La répartition peut également engendrer des problèmes d’intégrité au niveau des données : la gestion des commit et des rollback est effective sur une connexion/transaction sur une base donnée. Comment gérer une transaction fonctionnelle qui s’étendrait sur plusieurs shard ? Commiter/rollbacker unitairement et prendre le risque d’une problématique d’intégrité ? Commiter/rollbacker chacune des connexions à la fin de la transaction fonctionnelle et conserver les connexions sur les X shards durant la transaction fonctionnelle et donc diminuer les capacités de connexions des X bases ?

Le problème de l’intégrité se pose également au niveau des backup/sauvegardes journalières, qui devront par conséquent s’effectuer lors d’une période de mise en maintenance (pas forcément longue) du site, nocturne par exemple. Il en va de même pour la restauration qui devra être effectuée, en cas de problème sur l’un des shards, sur l’ensemble des shards pour des problèmes d’intégrité.

On arrive enfin à la notion de « Single Point of Failure » dont le nombre augmentera avec le nombre de shards que vous mettrez en place sur des serveurs/machines différentes… A moins que vous ne fassiez de la réplication sur chacun des shards… Mais souvenez-vous qu’une solution efficace est bien souvent simple (ou tout du moins minimaliste) ! Alors…

Il n’y a pas de contre indication au sharding, il doit simplement être mesuré et prendre en compte les aspects précités afin d’être sûr que votre cas fonctionnel, et plus généralement votre besoin métier, accepte bien ce principe ou tout du moins en retire suffisamment de bénéfices pour valoir le jeu et être mis en place.

Découpage en lamelles… ou vertical
Le sharding vertical se base sur une notion de temporalité. Plus simple à comprendre et à mettre en place, il dépend surtout de la typologie de votre site : un site marchand où 90% des visites du jour sont effectuées par des utilisateurs dont la connexion précédente à moins de 7 jours ou bien une administration dont 80% des dossiers consultés du jour l’ont déjà été dans les 2 dernières semaines. Ce n’est pas nécessaire de s’embêter à sharder si il n’y a pas de problématique de volumétrie, cependant, si le nombre d’informations trop important dans la table provoque des lenteurs sur la récupération/mise à jour/ajout d’informations et que la majeure partie des informations n’est que rarement utilisée… Bingo ! Il est intéressant de pouvoir donner à 90% (dans le premier cas) de vos visiteurs une expérience nettement meilleure tandis que les 10% restants auront une expérience quasi similaire, voire un peu dégradée dans le pire des cas.

L’étape la plus sensible sera de déterminer et d’ajuster au mieux la « coupure » de façon à satisfaire le plus grand nombre avec des performances optimales. C’est le moment d’analyser vos données et vos statistiques de fréquentation ! ;ob

Le mécanisme est très simple : quelque soit l’utilisateur, vous cherchez l’information dans la première table réduite contenant les données les plus accédées en un temps record, si elle y est tant mieux, sinon on requête dans la seconde table, celle des « archives ». il ne reste plus qu’à lancer un batch la nuit qui redispatche les éléments qui ont expiré de la table « courante » vers la table « archive » et de ramener les éléments archivés consultés ce jour vers la table courante.

Cette technique n’est absolument pas faite pour parer au problème du nombre d’accès/connexions à la base comme peut l’être le sharding horizontal, puisque le but est justement de satisfaire le plus rapidement possible la majeure partie des connexions à la dite base. Le but est purement de limiter la volumétrie d’une source de données pour en accélérer les traitements/requêtes dessus.

De plus, dans le cas de requêtes ensemblistes portant sur les 2 « zones », le problème est similaire à celui du découpage horizontal.

Un petit cube, 2 petits cubes, …
Et les 2 en même temps ? Oui c’est possible ! Mais il faut satisfaire aux pré-requis des 2 cas et en accepter les bénéfices et inconvénients.

Alternatives
Les alternatives proviennent du fait que le sharding répond à un besoin : celui d’améliorer les temps de réponse sur les accès aux sources de données. Mais d’autres solutions existent…

L’essentiel tuning de base
Avant de se lancer dans du sharding et autres solutions plus complexes… Avez-vous paramétré convenablement votre base en fonction de l’utilisation que vous en faites ? Vous seriez surpris des différences que l’on peut obtenir… C’est LA première étape avant d’aller plus loin et d’envisager le sharding ou une autre solution. Une base convenablement tunée vous suffira peut-être.

Ensuite intéressez-vous au type de stockage. Il influe sur les performances en fonction des opérations effectuées. J’ai étudié le problème sur MySQL et constaté les différences flagrantes, en pratique, entre InnoDB et MyISAM. Pour les tables essentiellement accédées en lecture, MyISAM est fait pour. En revanche, pour celles accédées en écriture, InnoDB, avec son système de row locking, vous donnera bien meilleure satisfaction.

C’est LE conseil que je peux vous donner à cette étape : maitrisez d’abord votre outil de base (sans jeu de mots) avant de vouloir ajouter une couche de complexité, parfois nécessaire… Mais pas tout le temps.

Le classique Master-Slave
Le classique Master-Slave, encore appelé réplication, vous permettra d’optimiser des problèmes de temps de réponse dus au nombre de connexions/requêtes sur une table à forte volumétrie, où l’écriture peut prendre du temps du fait de la reconstruction d’index sur les INSERT par exemple et ce faisant influant sur les temps de réponse des lectures (SELECT) et vice-versa , en séparant la lecture de l’écriture : typiquement l’écriture s’effectuera sur le master et la lecture sur le slave (ou les slaves).

L’éventuel partitionnement MySQL
Depuis la version 5.1, MySQL propose un partitionnement (ou sharding) géré nativement. Ne l’ayant pas testé par moi-même, je ne pourrais vous donner de retour sur le sujet. Le partitionnement proposé par l’outil est horizontal. Il est à noter que la notion de partitionnement vertical est différente de celle que je vous est présentée dans la sémantique MySQL : il s’agit de pouvoir stocker sur différentes partitions les colonnes d’une même table, par exemple les colonnes de type standard d’une table donnée sur une partition et la colonne de type BLOB sur une autre. Dans tous les cas, le partitionnement vertical n’est pas assuré dans la version 5.1 de MySQL. Même si cela peut paraître attrayant, je pense qu’il est moins limitant de sharder soi-même et qu’il est rassurant de conserver la main sur la répartition des données que l’on souhaite et de pouvoir intervenir en toute connaissance de cause, sans se soucier, par exemple, de la version de la base et donc de la version de la fonctionnalité de partitionnement associée qui sous-tend la répartition des données, lors d’une montée de version… Je ne pense pas non plus qu’il soit possible d’effectuer un partitionnement « multi serveurs » afin de répartir le nombre de connexions entre diverses machines… Mais bon j’ai pas testé alors…

Le « hors sujet » MySQL Proxy
Compatible avec les versions 5.0.x de MySQL, cet outil est en version alpha et donc ne convient pas à un environnement de production. Mais le « hors sujet » ne provient pas de là mais du fait que cet outil traite de load balancing sur plusieurs backend (probablement des réplicats d’un master servant à une optimisation en lecture sur X slaves), de failover, et d’« injection SQL » permettant au niveau du proxy d’ajouter des clauses d’analyse aux requêtes ou bien de filtrer les résultats, … C’est l’équivalent d’un proxy web qui répartit la charge, gère le statut des backends et modifie les requêtes. Alors pourquoi est-ce que je parle de ça ? Hors sujet : 0/20 ! C’est uniquement parce que j’en ai entendu parler plusieurs fois de la part de clients et qu’il y avait une confusion sur son utilité. Le Proxy MySQL NE permet PAS de faire de la répartition de données.

L’indispensable cache mémoire
Je prendrai l’exemple de Memcached qui est un cache de données réseau pour objets génériques. Memcached est le cache que j’utilise et qui a fait ses preuves. Maintenant, libre à vous d’utiliser d’autres outils ou bien même de réaliser vous-même votre système de cache mémoire adapté à votre utilisation, pour peu que vous en ayez l’envie et le temps. Dans tout les cas, votre cache mémoire vous permettra de limiter le nombre d’accès au système de stockage plus lent qu’est la base de données, en conservant un certain nombre de résultats dans une « hashtable géante ». En diminuant le nombre de requêtes sur vos tables volumineuses, cela suffira peut-être à obtenir des temps de réponse convenables et à ne pas saturer votre serveur en connexions, vous permettant ainsi de ne pas avoir à sharder.

Le surprenant modèle non relationnel hébergé et SimpleDB
Et oui ! Remis au goût du jour par Google avec BigTable et Amazon avec SimpleDB, le modèle non relationnel prouve toute son efficacité et sa scalabilité. Si vous n’avez effectivement pas besoin des jointures et autres relations, c’est peut-être votre solution. Et pourquoi pas utiliser l’API Amazon pour SimpleDB et profiter de l’infrastructure et des services Amazon ?

Les prometteuses innovations distribuées et Cassandra
A rapprocher de SimpleDB car développé sur un modèle similaire à Dynamo, la technologie qui sous-tend simpleDB. Cassandra est un système de stockage de données, structuré mais non relationnel, basé sur un réseau P2P (« peer to peer » ou « pair à pair » en Français ;ob). Il s’agit d’un système distribué sous forme de nodes, fortement scalable, et dont la particularité est qu’il est actuellement accessible au format Open Source. Développé par Facebook et actuellement en production chez eux, Cassandra est en version Beta et accessible dans le projet « Apache incubator » (Cf. liste de liens de la rubrique « Outils » de Decrypt : « Cassandra »). Vous pouvez également consulter cette note http://www.facebook.com/note.php?note_id=24413138919 pour de plus amples informations. Il est surtout intéressant que l’explosion des applications et réseaux sociaux ait un impact sur la mise à disposition d’outils de stockage et de gestion de données fortement scalables. Cette tendance (augmentation de la volumétrie des données) va s’étendre à d’autres domaines du fait de la croissance des sources de données informatisées et de l’évolution des services. Les architectures distribuées se propagent jusqu’à la source… de données, dernier goulet d’étranglement des architectures scalables. Je pense cependant que le sujet de la scalabilité du système de stockage de données restera encore le point le plus ardu à mettre en place, pour un bout de temps, dans toute architecture.

Conclusion
On constate que le sharding répond à un besoin bien particulier. Il concerne dans tous les cas une ou des tables contenant un volume important de données. Les lenteurs au niveau des temps de réponse peuvent être induites par le volume de données lui-même ou bien/et par le nombre d’utilisateurs s’y connectant de ce fait (dans le cas d’un site grand public). Le sharding est une des solutions possible pour l’amélioration des temps de réponse sur ladite source d’éléments. Mais avant d’envisager cette solution, il est intéressant d’envisager d’autres possibilités dans cet ordre :

• le concept du modèle non relationnel, hébergé ou non, en général, puisque de ce choix découlera un autre modèle de fonctionnement,

• le tuning de la base de données pour optimiser le socle de votre problématique,

• le cache mémoire, simple de mise en place et terriblement efficace pour limiter les connexions inutiles sur votre source de données et livrer les informations en un temps record,

• la réplication master-slave, classique mais efficace, dans la même optique de limitation du nombre de requêtes sur une base donnée,

• les fonctionnalités de partitionnement livrées en natif avec le produit, potentiellement utiles, potentiellement limitées…

• finalement le sharding (ou partitionnement) fait main ou plutôt les sharding, vertical et horizontal, pour limiter la volumétrie de la ou des tables, et par là même limiter le nombre de requêtes sur ladite ou lesdites tables dans le cas du sharding horizontal.

Il est tout à fait possible de composer en utilisant le cache mémoire avec la réplication, ou bien le cache mémoire avec un ou les 2 sharding… Le tout est de cibler son problème, le point d’engorgement et donc son besoin, pour utiliser la ou les techniques adéquates. Si une seule suffit, tant mieux.

Le sharding de données fait donc partie intégrante d’un problème plus global et est une solution tout à fait viable, demandant tout de même « un peu » de réflexion et de temps de mise en place et impactant dans la conception et la maintenance de l’infrastructure. Il est donc à utiliser à bon escient, mais se révèle fort utile et très efficace.

Frédéric FAURE