Accueil Technologies Amazon Web Services : AWSome Day 2016 Partie 2

Amazon Web Services : AWSome Day 2016 Partie 2

par Jérémy PASTOURET
Publié : Mis à jour le

Bienvenue en 2017, j’espère que je ne vous ai pas trop manqué pendant ces vacances et que vous vous êtes bien amusés et reposés. Je vous propose de conclure le dossier AWSome Day par ce dernier chapitre. Si vous n’avez pas lu la première partie, je vous conseille de la lire, il y a plein de choses intéressantes sur Amazon Web Services. Voici l’adresse : Partie 1 – AWSome Day Paris 2016.

Pour commencer l’année en beauté, je vous propose de démarrer en parlant de sécurité.

La sécurité appliquée à l’accès aux Datacenters

L’accès aux Datacenters est très réglementé. D’ailleurs peu de personnes salariées d’Amazon connaissent la localisation exacte des Datacenters. Si un employé doit y réaliser une intervention, il peut le faire uniquement deux fois par trimestre. Pas plus.

Quand un employé Amazon rentre dans un Datacenter, il doit vider ses poches et passer par un portail de sécurité – comme à l’aéroport. Les employés de la sécurité comptent le nombre d’objets qu’il a sur lui. Si au moment de sortir il a plus d’objets qu’au départ, ils détruisent immédiatement les objets en plus… sans se poser de question. S’il repart avec moins d’objets, pas de souci. Il a peut-être ajouté une pièce manquante sur un serveur.

Par contre, s’il a malencontreusement oublié les clés de sa Porsche (ce qui n’arrive pas souvent j’espère 😉) et qu’il revient les récupérer… eh bien c’est perdu ! Ces clés seront détruites, rapport à la règle des surplus. Si vous souhaitez obtenir plus d’informations, Amazon a réalisé un whitepaper sur la sécurité bien sympa.

Passons maintenant à un gros client d’AWS, qui utilise beaucoup les Datacenters d’Amazon. Je vais tenter de vous le faire deviner : l’entreprise concernée représente à elle seule 70% du traffic internet fixe au Etats-Unis la nuit (source : 01.net). Impressionnant, non ? Leur service est utilisé par leurs abonnés à hauteur de 15 heures de visionnage par semaine.

Vous avez trouvé ?

Le cas Netflix

On ne s’en rend pas forcément compte, mais de gros moyens sont déployés pour offrir un service de haute qualité aux client. Et Netflix y va très fort. En effet, cette entreprise feffectue des tests en continu. Il s’agit principalement de tests de charge. Certains de leurs outils sont même publiés sur Github.

Notamment ChaosMonkey, qui permet de détruire de manière aléatoire une machine virtuelle en production n’importe où dans le monde. Objectif : vérifier que leur configuration sur Amazon est parfaite, et qu’a chaque fois qu’une machine tombe, le système en recrée une et déplace les clients qui étaient en cours de visionnage de leur contenu sur une autre machine (directement pour ne pas voir de coupure). L’intelligence réside dans le logiciel client et dans la gestion du AWS Cloud qui va aiguiller l’utilisateur dans la bonne direction. D’un côté, on a le client logiciel installé sur le PC qui stocke du cache afin de parer à une coupure. Côté serveur, le flux est redirigé si une machine tombe. Si vous avez envie delire de la documentation technique de haut niveau, Netflix en a rédigé une que je vous conseille : Chaos Monkey Released Into The Wild.

La société exploite aussi un autre outil qui se nomme Chaos Gorillas. Il est encore plus important et anéantit tout une zone Amazon pour vérifier si le système réagit correctement.

Petite définition made by Netflix :

Chaos Gorilla is similar to Chaos Monkey, but simulates an outage of an entire Amazon availability zone. We want to verify that our services automatically re-balance to the functional availability zones without user-visible impact or manual intervention.

Oui, Netflix est barbare. Mais c’est pour le bien de ses utilisateurs s’il mène des tests si puissants. Si les tests étaient trop simples, ils ne serviraient à rien… non ?

Tout ces outils font partie de la SimianArmy. Si vous avez envie de vous plonger plus en avant sur les techniques de tests, Netflix est un bon parti : The Netflix Simian Army.

Ce qui m’impressionne, c’est que ces outils ne datent pas d’hier. L’article qui en parle date de 2011, et Chaos Monkey est accessible sur GitHub depuis 2012 : voici son code.

On continue avec des cas concrets, mais dans un domaine différent : celui du médical.

Cas d’un besoin important en ressources matérielles pour effectuer de gros calculs

L’entreprise dont je vais décrire la problématique a souhaité rester anonyme. Donc je ne pourrais pas vous rediriger vers leur page web pour avoir plus d’informations.

Cette société travaille dans la conception de nouveaux médicaments. Elle avait besoin de réaliser beaucoup de calculs pour vérifier certaines interactions avec des molécules. Ce qui n’est pas à prendre à la légère.

Avant de lancer le programme de calcul sur leur propre Datacenter, ils ont calculé une estimation du temps de réalisation de l’opération, et surtout du coût. Ils ont estimé qu’en utilisant leur Datacenter, il faudrait pas moins de 150 ans pour un coût total de 60 000$ (machine, éléctricité,…). Vous vous doutez bien qu’à cause de cette lenteur un concurrent aurait sorti le produit bien avant eux.

Ils se sont donc tournés vers Amazon pour obtenir de l’aide, et obtenir une puissance de calcul supérieure à ce qu’ils possédaient.

Amazon leur a proposé d’utiliser la formule enchère de leur service. Le principe est simple : vous décidez d’un budget par rapport à la tâche à effectuer. Admettons qu’on mette une enchère à 50$ par heure, au lieu de 150$ en temps normal. En fonction de l’offre et de la demande, le prix va varier. Dès que le prix est inférieur ou égal à votre enchère, Amazon vous alloue une machine au tarif souhaité.

Cependant, dès que le prix est dépassé, vous recevez un mail ou un SMS qui vous informe qu’il vous reste deux minutes avant qu’Amazon détruise votre machine. Au bout de deux minutes, Amazon est tellement gentil qu’il vous envoie encore un petit rappel. Lorsque ces deux minutes supplémentaires sont écoulées, AWS détruit totalement votre machine sans plus attendre. Ce qui fait que vous avez en tout 4 minutes avant que votre machine soit clôturée. Il faut donc bien préparer son coup.

Revenons à notre société anonyme qui a proposé une enchère basse. A un certain moment, Amazon lui a alloué une machine. Les employés ont installé leur programme et l’ont configuré de façon à permettre au serveur « d’enchères » de réaliser des calculs, puis de les sauvegarder sur un serveur AWS S3 pour ne pas perdre les données. Quand Amazon « tue » la machine des chercheurs, ceux-ci conservent leurs données. Et quand Amazon leur redonne une machine, celle-ci reprend le travail de son prédécesseur, et ainsi de suite….

Le résultat est là : l’entreprise a réussi son projet en l’espace de 10 heures, pour un coût de 30 000$, grâce à des machines dont vous n’imaginez pas la puissance. Bluffant, non ? Elle a gagné du temps et de l’argent (divisé par deux).

Si la formule enchère vous intrigue, ou que vous souhaitez avoir plus d’informations, n’hésitez pas à aller faire un tour sur cette page d’Amazon : Les instances ponctuelles d’AWS.

Passons maintenant à une dernière formule AWS, j’ai nommé :

Les instances réservées

L’idée, c’est de réserver à l’avance des machines auprès d’Amazon. Pourquoi faire ça ? Car on peut économiser jusqu’à 75% (c’est pas mal, non ?). Mais comment réserver ? Si vous avez tout le temps des utilisateurs, sachez tout de suite que ce n’est pas la bonne offre pour vous.

Pour y voir plus clair, je vous propose de prendre un exemple concret. Prenons l’émission The Voice. Vous connaissez probablement le principe : des chanteurs chantent (normal) et des jurés les choisissent. Ensuite, le public vote par SMS, via une application mobile ou sur le site web. L’émission est diffusée le vendredi soir à partir de 20:50, jusqu’à minuit environ. On peut donc considérer qu’il y aura une grande demande de réponses sur le site ainsi que sur l’application le vendredi soir de 20h à minuit, à peu de choses près. Voilà pourquoi TF1 réserve des instances puissantes ce jour-là uniquement. Car comme tous les vendredis, ils ont prévu qu’il y aura du monde sur leur site.

Voilà pourquoi cette offre peut être intéressante. Vous spécifiez la plage horaire et le (ou les) jour(s) concerné(s) à Amazon, et celui-ci se charge de tout. Il lance vos instances et les coupe aux heures voulues.

Pour pouvoir bien paramétrer cette offre, je vous conseille de commencer par la formule d’instances à la demande, comme ça votre serveur n’est jamais à bout de souffle. Par contre, ça vous coûte plus cher. Ensuite, vous analysez les ressources utilisées pendant une période donnée. Si vous remarquez une certaine continuité, vous pouvez mettre en place ce genre de formule réservée. Puis vous ajustez au fur et à mesure. Si par mégarde vous avez un pic, vous pouvez demander des ressources supplémentaires. Par contre, si vous l’aviez prévu (par exemple les soldes), vous pouvez réserver à l’avance des instances supplémentaires pour un coût moindre.

Si vous avez besoin de plus d’information, je vous conseille de lire cette page.

La petite démo avec une belle machine

Après nous avoir parlé de la société pharmaceutique, le conférencier nous a ensuite proposé une petite démo pour nous prouver qu’Amazon possède des machines puissantes et déclenchables rapidement.

Son projet était simple : un serveur avec une très bonne configuration composé de 128 coeurs et de 2To de mémoire RAM. Pas grand chose, non ? Vous vous imaginez la tête du serveur ? Et sur ce serveur, il a installé un serveur Web pour faire marcher son site de photo grâce à un script particulier. Voici une petite photo pour illustrer et prouver qu’il a instancié une machine d’une telle puissance :

En moins de 3 minutes, le conférencier a demandé à Amazon de lancer la machine et d’y installer tout un tas de choses. Juste impressionnant.

Enfin, pour finir ce dossier sur AWS en beauté, j’ai décidé de vous parler de la destruction des disques dur chez Amazon.

La destruction des disques dur d’AWS

Vous vous doutez bien qu’avec la tonne de fichier écrits chaque jour sur les disques dur d’Amazon, ils finissent par rendre l’âme au bout d’un moment. Or le protocole de destruction de ces disques durs ne consiste pas simplement à les balancer dans un conteneur.

Pourquoi AWS possède-t-il un protocole de destruction des disques durs ?

Tout simplement parce que si quelqu’un trouve un disque dur (même HS), il peut récupérer certains fichiers existants grâce à de simples logiciels, vendus partout. On peut aussi récupérer des documents supprimés. La CIA arrive à récupérer les données jusqu’à 12 couches. C’est à dire qu’ils arrivent à retrouver un fichier qui a été supprimé et remplacé par 12 fichiers l’un après l’autre. C’est fort, non ? En vous racontant ça je repense à la première saison de Prison Break. Michael balance son disque dur contenant toutes les informations de son évasion à la flotte. Ensuite, le FBI retrouve le disque et extrait les données.

Mais revenons au disque dur. Quand il part en retraire chez Amazon, il passe un sale quart d’heure. En effet, les employés passent les disques durs dans un gros micro-ondes qui fait exploser leur tête de lecture. Ensuite, parce qu’ils sont sadiques, ils percent des trous a intervalles réguliers dans chaque disque dur. Et pour finir le massacre, ils les broient en confettis. Pour un magnifique résultat (malheureusement je n’ai pas pu récupérer la photo mais vous pouvez allez voir ce Tweet pour avoir une petite idée).

Voilà, c’est fini pour ce dossier AWS, près de 2000 mots… ouf ! J’espère que je ne vous ai pas épuisés, et que je vous ai appris plein de nouvelles choses.

Vous pourriez aussi aimer

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.