Decrypt

Décidemment, encore un article sur les AWS (Amazon Web Services). Au-delà du fait que ce sont de bons composants dans le cadre de la mise en place d’une infrastructure, il faut noter qu’ils couvrent un scope complet de ce que l’on peut trouver dans une infrastructure en termes de fonctionnalités (gestionnaire de files de messages -SQS-, base de données non relationnelle -SimpleDB- et relationnelle -RDS- depuis peu, traitement massif de données -MapReduce, bonjour BI ?-, instances virtuelles -EC2-, VPN -VPC-, …), mais également en termes de « background technique ». Je m’explique : prenons l’exemple de S3, qui sera notre sujet d’étude dans cet article d’ailleurs, quoi de plus simple qu’un système de stockage d’objets ? Ca se résume à « PUT », « GET » et « DELETE ». Et pourtant derrière cette apparente simplicité, se cache une complexité technique sous-jacente étonnante, qui reprend bons nombres de concepts « standards », mais que l’on implémente rarement soi-même, parceque complexes à mettre en place. On laisse donc cela aux outils que l’on utilise ou tout simplement on fait l’impasse dessus. Tout cela pour introduire les 9 principes sous-jacents au service S3 d’Amazon qui font de ce service apparemment succint, un bel exemple technique.

Je vais me baser pour cela sur une présentation de Simone Brunozzi à laquelle j’ai assisté au Luxembourg. Cette présentation a également eu lieu à Londres à la « Storage Expo ». Cette dernière ayant été filmée, je vous la laisse à disposition afin que vous puissiez voir et écouter Simone en live from London ! ;ob

Simone Brunozzi presents AWS and Amazon S3 at Storage Expo in London from Simone Brunozzi on Vimeo.

Chapitre I : Redundancy / Redondance
La redondance, un moyen efficace d’assurer la durabilité (pas de perte définitive) et l’accessibilité (pas de perte temporaire) des données. La redondance consiste donc à dupliquer les informations (objets) que vous stockez sur S3 dans plusieurs zones d’accessibilité d’une région donnée. Les zones d’accessibilité sont en fait des datacenter physiquement séparés dans la périphérie d’une agglomération donnée et reliés entre eux par un réseau privé. Un certain nombre de précautions sont prises lors de la mise en place de ces datacenters, depuis la vérification que les zones sont non sismiques et non inondables, jusqu’à l’alimentation électrique distincte pour chacun de ces datacenter. Les objets sont donc répliqués dans et entre ces datacenters en background (transparent pour l’utilisateur), ce qui permet d’assurer qu’ils seront accessibles, même sur la détérioration temporaire ou permanente desdits objets d’un datacenter donné (panne de courant sur une grille d’alimentation, …).

Cette redondance touche également au domaine de la scalabilité, puisque sur la détection d’une augmentation des accès sur un objet donné, celui-ci est dupliqué de manière plus importante de façon à répartir la charge sur un pool d’objets.

Il est à noter que la redondance a un coût et engendre une complexité et donc ne doit être mise en place que lorsque cela est nécessaire. Ce coût et cette complexité sont occultés, dans ce cas, par la simplicité d’utilisation du service S3 pour l’utilisateur final (vous et moi ! ;ob).

Chapitre II : Retry / Réessai
Le réessai est une technique afin de fournir une accessibilité maximale de la donnée et notamment de parer aux inaccessibilités temporaires. Un rejeu de la requête, « GET » par exemple, est effectué, de manière à réessayer de rapatrier l’information. Si cela n’est pas possible, un nouvel essai est réeffectué, mais un peu plus tard et ainsi de suite, avec un intervalle de temps croissant entre chaque essai de manière à ne pas surcharger le système. La requête peut également être rejouée plus tard. Ce qu’il est important de noter, c’est que les requêtes pouvant être rejouées automatiquement par S3 doivent être idempotent, c’est à dire ne pas avoir d’influence si elles sont jouées plusieurs fois, voire dans des ordres différents. De manière générale, une requête idempotent ne modifie pas le système cible (donc plutôt des « GET »).

Le détail du fonctionnement n’est évidemment pas divulgué par Amazon et ce que nous voyons là sont les grands principes du fonctionnement du service S3. Cela est confidentiel car, tout d’abord c’est leur « business », mais aussi pour des questions de sécurité, évidemment, et cela est encore plus vrai pour les « chapitres » à venir. Mais bon… Au-delà de la frustration de ne pas connaître un peu plus en détail l’implémentation de ces standards de la haute-disponibilité / scalabilité, cela fait toujours une bonne révision, intéressante, de ce qu’il y a à prendre en compte dans la mise à disposition d’un tel système de stockage. Allez… Fini ces digressions, continuons !

Le « niveau » de redondance, cité plus haut et permettant d’augmenter la taille du pool d’objets disponibles, rentre également dans cette optique de réessai. S3 permet ainsi d’éviter une inaccessibilité temporaire en augmentant le nombre d’objets disponibles afin de servir le maximum de requêtes concurrentes.

Chapitre III : Surge Protection / Protection contre les (D)DOS
Et oui ! Un service exposé sur le net est donc potentiellement livré en pâture à de terribles botnet, une armée de zombies prêts à déferler sur votre pauvre service… Mais là aussi des parades sont possibles.

Il y a le « rate limiting », où sur un « sur-accès » au service à partir d’IPs qui semblent être fautives, seule une partie des requêtes de ces machines seront traitées. De même que pour le réessai, il y a ce que l’on appelle « l’exponential back-off », où les temps de réponse sont de plus en plus espacés afin de laisser le système respirer. Finalement, le « Cache TTL » (Time To Live) de chaque objet est augmenté avant son rafraichissement.

Un déni de service est bien sûr distingué d’une utilisation intensive de la ou des ressources, sachant que la cible n’est pas un pool d’objets défini mais bien le service dans son intégralité (saturation de la bande passante, …).

De même que précédemment, pour le détail des algorithmes… ;ob

Chapitre IV : Eventual Consistency / Consistance éventuelle (des données)
La consistance éventuelle revient sur la problématique de la redondance (Chapitre I). En effet, le service S3 se doit d’assurer la sauvegarde des données par redondance, leur accessibilité à tout instant et… Leur consistance. C’est-à-dire que du fait de la redondance, il faut bien propager les modifications effectuées sur un objet donné à ces réplicats. Cela amène la question, « est-ce qu’un système peut à la fois être redondant (donc durable), disponible (donc accessible) et consistant (donc intègre – tous les réplicats d’un même objet sont identiques) à un instant donné ? ». La réponse est… presque. C’est pour cela que l’on parle de consistence éventuelle, la même notion que l’on retrouve dans les concepts de SimpleDB. Ces 3 éléments font obligatoirement l’objet d’un compromis et ne peuvent être assurés entièrement ensemble à un instant « t ». Par exemple, si on veux assurer la durabilité (donc redondance) et la consistance, il faut à un instant « t » rendre le service non accessible afin de propager les modifications… On peut retourner le problème dans tous les sens, on ne peut tout avoir à un instant « t ». Cela se traduit par le fait que sur un accès quasi simultané à un objet, un « PUT » suivi d’un « GET » par exemple, il se peut que l’on récupère l’ancienne version de l’objet sur le « GET », parce que la propagation n’est pas (encore) effective. Ce fonctionnement est normal. Pensez à vos problématiques de réplications sur bases de données dans le cas où vous auriez des accès en continu très rapprochés !

C’est la notion de consistance éventuelle.

Vous pourrez retrouver un article Eventually Consistent – Revisited sur le sujet sur All Things Distributed, Werner Vogels’ weblog on building scalable and robust distributed systems.

Eventually Consistent – Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.

Chapitre V : Routine Failure / Processus en cas de panne
Comme disait justement Simone lors de la présentation : « Viagra ? Cialis ? It will fail anyway ! ». C’est la routine ! Enfin bon… Je parle pour la défaillance des composants hardware tout du moins ! :ob Disques, serveurs, datacenters, … Tout composants harware doit arriver un jour ou l’autre à terme (et oui !), alors… « just unplug it ! ». Puisque tout est redondé et en haute disponibilité, pas de problème.

Pour plus d’informations sur la fin de vie du matériel chez Amazon et plus généralement sur la sécurité des services et la sécurité / confidentialité des données, vous pouvez consulter leur Livre Blanc sur le sujet sur leur site dans la rubrique Sécurité et le télécharger (format PDF).

Chapitre VI : Diversity / Diversité
« Diversifier pour mieux règner » pourrait-on dire. Et ce à 3 niveaux : Software, Hardware, Workload.

Pour éviter une panne généralisée du fait d’un composant matériel d’un fournisseur, un panel de composants physiques a été sélectionné à chaque niveau de l’infrastructure afin de s’assurer que si un des éléments est défaillant (mauvaise série, …), l’ensemble des composants entrant dans le cadre de la haute disponibilité ne tombent pas en panne en même temps.

Le principe est le même pour le software, pour le type et la version de l’OS des Hosts (les OS supportant les machines virtuelles) par exemple, pour les mêmes raisons (bugs, exploits, …).

Finalement la charge est elle aussi « diverse » en fonction des applications et des clients qui utilisent les services, permettant ainsi de lisser la charge et de ne pas saturer les services à certaines périodes.

Chapitre VII : Integrity Checking / Vérification de l’intégrité (des données)
La corruption est partout ! En découle donc la vérification de l’intégrité… Et oui ! Encore une autre tâche nécessaire pour assurer un stockage de données de qualité. Mais il faut faire attention au coût et à la complexité engendrés par ces traitements. Le mode opératoire utilisé sur S3 est un checksum au niveau applicatif. Si une corruption de l’objet est détectée sur un checksum, il est alors remplacé par une version « correcte » à partir d’un de ces duplicats. De la même manière que précédemment, cette fonctionnalité est assurée en background et ne laisse rien transparaître à l’utilisateur.

Chapitre VIII : Telemetry / Monitoring
Tout est dans le titre. Un monitoring est effectué sur le système afin de diagnostiquer son « état de santé ».

Chapitre IX : Autopilot / Automatisation
Par ce que les processus humains sont faillibles et que le temps de réponse humain est lent, il est préférable d’automatiser (tiens ça me rapelle des choses ça Cf. Puppet et Capistrano : la clé de l’automatisation). Cela paraît évident dès que l’on a eu à monter et surtout à maintenir une infrastructure ! Alors au niveau d’un datacenter…

Conclusion
Comme je vous l’ai dit dans l’article, ceux qui pensaient découvrir tous les secrets d’Amazon seront déçus. Pour des raisons évidentes de confidentialité et de sécurité, le détail et l’implémentation de chacun de ces principes n’est pas présenté. Je suis effectivement un peu frustré de ne pas en savoir plus, ne serait-ce que pour vérifier l’implémentation de tous les principes énoncés. Les constatations à notre niveau ne peuvent être qu’empiriques et, dans ce cadre, je suis entièrement satisfait du service, surtout quand on fait la relation entre le coût du service et sa qualité/fiabilité. Tous les mécanismes énoncés ne peuvent être mis en place qu’à une grande échelle, comme dans les datacenters d’Amazon, vu le coût en ingénieurie et matériel que cela engendre afin d’implémenter ces mécanismes (autant au niveau algorithmes/software qu’au niveau hardware).

De plus, les mêmes principes ont été apportés aux autres services (ou tout du moins des principes similaires fonction du service). Les Web Services Amazon sont fondés sur le même modèle et les mêmes règles de base. Cela nous laisse donc entrevoir une qualité de service, au niveau des différentes fonctionnalités que couvre le large scope Amazon, que nous ne pourrions nous offrir en interne ou chez certains de nos hébergeurs physiques.

Sorti de S3 (ou d’autres services Amazon), je trouve ces notions également intéressantes à prendre en compte dans nos infrastructures, à un moindre niveau bien sûr, car ces principes sont plein de bon sens et il est intéressant de se poser au moins les questions.

Vous pouvez également recevoir toutes les nouveautés sur AWS et autres sujets techniques (scalabilité, haute dispo, …) sur Twitter @fredericfaure.

Frédéric FAURE