Scalez de 0 a 10 millions d utilisateurs avec AWS

Transcript

Bonjour, vous m'entendez bien ? Oui, ok, très bien. Je vais me présenter très vite, c'est marqué sur le slide, donc très rapidement. Je m'appelle Julien, je suis Technical Evangelist chez AWS, que j'ai rejoint il y a un peu plus de six mois. J'ai fait plein d'autres choses avant, ce n'est pas le sujet de la discussion, mais ça me permet d'avoir un petit regard sur comment on construit des plateformes web et comment on les scale. Ce qui tombe bien, parce que c'est le sujet de ma présentation. J'ai remplacé le titre parce que j'avais envie d'un titre un peu plus sympa, mais on va bien parler de scaling et comment scaler une plateforme web de un utilisateur à beaucoup plus d'utilisateurs. Voilà, donc j'ai rajouté un agenda. Je me suis dit que c'était pas mal. Donc on va commencer par voir comment on faisait les choses jusque-là. Ce que j'entends par « the old way », ça ne veut pas dire que c'est une façon périmée de le faire. C'est toujours très valable pour beaucoup de plateformes. Si c'est comme ça que vous faites aujourd'hui, pas de panique, ça marche toujours. Par contre, il y a une nouvelle façon de le faire qui est intéressante et que je vais vous présenter. On finira par une démo dans laquelle j'aurai besoin de votre aide, puisqu'on fera une démo en live sur Google, sur une API que j'ai publiée. Tous les gens qui ont un mobile ou qui sont en wifi en général pourront m'aider à faire un petit test de charge sur cette appli. Commençons par le commencement. Vous avez une idée, un site web, une appli quelconque. Vous avez envie très vite de commencer à la tester, à la déployer. Ça commence le premier jour avec un utilisateur, vous. Il est probable que vous adoptiez une architecture toute simple, à ce stade le problème c'est pas du tout de scaler, à ce stade le problème c'est de faire un truc qui marche, ce qui est déjà pas mal. Et donc il est assez probable que vous commenciez tout simplement avec une instance EC2, une machine virtuelle, et que vous mettiez tout dessus parce que c'est plus facile, c'est plus facile de développer comme ça, vous n'avez pas à gérer de multiples composants. Vous allez déployer votre web app dans la techno qui vous plaît, vous allez déployer une base localement sur cette instance, tous vos outils, une instance, un utilisateur, peut-être un nom de domaine quand même, un nom de domaine pourquoi pas dans Route53 qui est notre service de DNS, puis une IP publique qui vous permet d'accepter. Je pense qu'il y a plein de gens dans la salle qui ont commencé comme ça, il y a peut-être encore plein de gens dans la salle qui fonctionnent comme ça. Ça marche très bien, c'est hop en cinq minutes et on peut commencer à développer et à publier des services. Très bien, seulement il va falloir que ça grossisse. Au début vous allez prendre une instance toute petite parce que forcément c'est les moins chères et c'est exactement ce qu'il faut faire, il faut toujours commencer le plus petit possible et puis au fur et à mesure vous allez rajouter des fonctionnalités, rajouter des composants, peut-être commencer à avoir un peu de trafic, vous allez avoir besoin d'avoir une instance plus grosse. Donc vous allez faire ce qu'on faisait dans le monde des serveurs physiques, c'est-à-dire j'ai besoin d'un plus gros serveur. Donc on va faire du scale up et vous allez prendre une plus grosse instance. Alors ça tombe très bien parce qu'on a de nombreux types d'instances disponibles chez AWS qui vont de T2, NAP, qui est minuscule, à des choses très très très grosses, des m4 10x large des monstres. En montant en gamme sur les instances vous allez avoir plus de RAM, plus de CPU, plus d'IO, plus de réseau, etc. Magnifique, le problème c'est que comme dans le monde des serveurs physiques, ce fonctionnement-là s'arrête parce qu'il y a un moment où il n'y a pas plus gros. Il y a un moment où même avec de très grosses instances vous allez avoir un problème de il n'y a pas plus gros. Donc il va falloir penser un peu différemment. Et puis surtout, au-delà du problème de perf, il y a un gros problème d'architecture qui est qu'évidemment il n'y a aucune forme de redondance, il n'y a aucune forme de haute disponibilité sur ce genre d'architecture. Donc rassurez-moi, personne n'est en prod juste avec une instance. Si ? Non ? Levez la main ? Non, on laisse jamais la main dans ces cas-là. Voilà, donc le problème c'est si jamais l'instance a un problème quelconque ou si même votre appli se casse la figure, ce qui peut arriver, un petit bug, un petit crash, vous avez tout perdu. Donc il y a juste tous vos œufs dans le même panier et ça c'est pas possible. Il va falloir à la fois adresser le problème de scalabilité horizontale et de haute disponibilité. En supposant que vous ayez déjà un peu de trafic, vous commencez à bâtir votre petite communauté, vous avez une centaine d'utilisateurs maintenant, et même si 100 personnes ce n'est pas beaucoup, vous avez quand même envie d'avoir un truc qui marche et de ne pas passer pour un rigolo. Probablement la première chose que vous allez faire, c'est sortir la base de données de l'instance. Et donc là on a pas mal de choix pour faire ça au sein d'AWS. Le choix le plus simple et le plus fréquent, c'est d'utiliser RDS, Relational Database Service, qui est notre base de données managée qui fonctionne avec MySQL, Postgre, Oracle, SQL Server, MariaDB et quelques autres. La première chose à faire, ça va être ça, déjà de sortir la base de données de votre instance web et d'avoir par exemple RDS, mais on pourra avoir d'autres choix. Donc ça c'est le premier choix déjà. Alléger un petit peu votre instance web. Et puis vous continuez à grossir. Donc super, et là vous dites maintenant 1000 utilisateurs, ça devient un peu plus sérieux, il faut vraiment que je règle ce problème de disponibilité. Donc assez facile à faire au sein d'AWS, puisqu'on a ce qu'on appelle dans notre infrastructure des availability zones, qui sont des zones de disponibilité distinctes, qui s'appuient sur des data centers différents, et qui utilisent tout ce qui est fait pour qu'un éventuel problème d'infrastructure sur une AZ n'impacte pas l'autre AZ. Donc vous allez avoir deux instances web que vous allez mettre dans des AZ différentes. Vous allez mettre un petit lot de balancer devant, histoire que ça soit transparent pour votre utilisateur. Et puis tant qu'à faire, vous allez aussi avoir de la haute disponibilité sur RDS. Si vous utilisez par exemple MySQL, vous aurez une architecture master-slave classique, une instance maître dans une AZ et puis une instance répliquée dans une autre AZ. Donc voilà, déjà là on a vachement progressé par rapport au premier modèle, on a un peu de haute disponibilité, on a allégé nos instances web et on est un petit peu plus résistant aux pannes. Si on perd la base maître, la base slave prendra la main, si on perd une instance web, il reste l'autre, le load balancer fera son boulot, etc. Donc voilà, premier début d'architecture raisonnable. Et en fait, je pourrais arrêter la présentation là, parce que le reste n'est que finalement une généralisation de ça. Cette architecture-là, scalée, elle constitue la base de très nombreuses plateformes et elle peut vous emmener très loin. Et donc mon conseil là-dessus, c'est commencer par ça, commencer par une architecture comme ça, monter en charge, simplifier-vous la vie avec quelque chose de simple et de facile à manager, avant d'aller dégainer, je ne sais pas, Cassandra ou même DynamoDB, ou même des architectures comme ça. Ce genre d'architecture que vous allez étendre comme ça, elle peut vous emmener à des dizaines voire des centaines de milliers d'utilisateurs. On a des exemples de clients qui fonctionnent vraiment comme ça, sans recourir à des technologies exotiques, compliquées. Et donc là, qu'est-ce qui a changé par rapport au schéma d'avant ? C'est simplement le fait que vous voyez qu'on a plus de web, on a rajouté des serveurs web, on a rajouté des répliques en lecture sur RDS, mais fondamentalement c'est le même schéma. Et fondamentalement, je reviens juste là, pour passer de ça à ça, soit vous aimez cliquer dans la console et vous cliquez dans la console, soit vous le scriptez et c'est quelques lignes de script. Donc il n'y a pas de complexité particulière à passer sur ces modèles et à rajouter des instances. Donc effectivement on peut aller très très loin sur ce modèle là, mais on peut quand même améliorer encore deux trois trucs. Alors on va aller regarder. Alors déjà le premier point, on va voir si vous êtes encore réveillés vendredi après-midi. Qu'est-ce qu'on aurait envie de faire ? J'ai rien à vous faire gagner, c'est juste vous gagnez ma considération, c'est déjà beaucoup. On pourrait mettre une... alors on On pourrait avoir une deuxième, une troisième AZ. En Irlande, on a trois AZ, on pourrait travailler sur les trois. C'est une bonne remarque. Je pense que c'est plutôt là en terme d'allègement des instances. Que fait le web qui ne devrait strictement pas faire ? Non, pas encore. On va le faire aussi, il y a un autre truc avant. Alors ouais c'est un peu comme auto-scaling, ouais on va voir ça après. Load balancer devant la base, non on n'en a pas besoin, mais on pourrait, mais là en l'occurrence on n'a pas besoin. Voilà, bravo. C'est là que je voulais en arriver. Donc effectivement, là mon web il sert tout, 100% du contenu, y compris si j'en ai du contenu statique. Donc les CSS, le JS, les images, les vidéos, tout ce qu'on peut imaginer, des documents, des PDF, tout ce qui est contenu statique, on n'a aucune raison de le servir à partir d'un web et on n'a aucune raison d'aller charger nos instances web avec ça. Donc le premier truc qu'on va faire, et ça c'est pareil, ça se fait à peu près en 10 minutes, c'est d'utiliser CloudFront qui est notre CDN pour servir à partir de CloudFront le contenu statique qui sera stocké dans S3 qui est notre serveur de système de stockage. J'espère que je n'ai pas à présenter S3. Il a été lancé en 2006 donc les gars je pense que vous êtes à jour, j'espère. Et donc là l'objectif de ça, c'est que l'intérêt de ça c'est que CloudFront on a 54 points de présence dans le monde y compris en France et que par exemple on a un point de présence à Marseille et à Paris d'ailleurs comme ça il n'y a pas de jaloux et ce qui veut dire que si vous avez un internaute à Marseille qui se connecte sur votre plateforme hébergée en Irlande vous allez servir tout le contenu statique à partir du point de présence de Marseille donc vu de votre internaute il va avoir un temps de réponse, une latence qui sera beaucoup plus faible, surtout sur des gros fichiers qui sont longs et pesants à télécharger. Et votre serveur web se contentera lui de servir le trafic dynamique. Donc la mise en place du CDN, si vous avez beaucoup de contenu statique, lourd, c'est indispensable. Alors on va faire un deuxième truc, quelqu'un l'a mentionné, effectivement on va mettre du cache. On va mettre du cache pour plusieurs raisons. Qu'est-ce qui a dit cache ? Tu pensais plutôt performance à mon avis. C'est vrai que mettre du cache au lieu d'aller relire en base de données en permanence, c'est une bonne pratique. On pourrait utiliser par exemple ElastiCache qui est notre service de cache managé qui marche soit avec Memcached, soit avec Redis, et on supporte la réplication dans Redis. C'est vrai qu'il y a l'aspect performance, mais il y a une autre raison de le faire. Au sein d'un cloud, contrairement à une infrastructure physique, on considère que les serveurs sont absolument jetables. On a toujours cette comparaison qui est de dire que quand vous faites de l'infra physique, vous traitez vos serveurs comme des animaux domestiques. Vous en prenez soin, il faut qu'ils sentent bon, vous les brossez, vous voulez qu'ils vivent longtemps, vous les amenez chez le vétérinaire et quand malheureusement ils meurent, vous êtes très triste. Dans le monde du cloud, on traite les instances comme du bétail. On en a besoin, on les consomme et quand on n'en a plus besoin, on les détruit. Et donc on tient absolument pas à ce que créer une instance et éteindre une instance soit un process compliqué. On ne veut pas avoir à dire mince je ne peux pas éteindre cette instance parce qu'il faut que je récupère des données stockées localement. Ah mince j'ai tous mes cookies, j'ai tous mes trucs stockés localement sur l'instance, je ne peux pas l'éteindre. Donc il faut que les instances soient le plus stateless possible. Et donc ça, ça milite aussi pour dire que tout ce qui est contenu, tout ce qui est données de session, tout ce qui est état, vous le stockiez en dehors de l'instance. Il y a une raison performance et il y a une raison élasticité de la plateforme, à la hausse et à la baisse. Et donc là, la pratique qu'on voit souvent chez nos clients, c'est d'utiliser DynamoDB qui est notre base de données NoSQL, donc PutGet, qui est très escalable et qui est bien adapté au stockage de données de session, de cookies et des choses comme ça. Et puis il y a un troisième truc qu'on va faire, c'est qu'en fait CloudFront il peut aussi gérer du contenu, il peut aussi cacher du contenu dynamique. Après à vous de voir si c'est pertinent ou pas, quelle est la fraîcheur que vous voulez avoir sur certaines pages dynamiques ou pas, mais vous avez la possibilité de le faire. Vous pourriez aussi distribuer via CloudFront le résultat de pages dynamiques cachées. Donc vous mettez CloudFront vraiment devant votre load balancer, ce qui fait qu'il va offloader une partie importante du trafic de votre web. Ce qui permet toujours pareil d'avoir des instances plus petites, des instances web plus petites donc moins chères, mais peut-être d'en mettre plus en parallèle. Ce qui est là aussi une bonne chose. Donc là on a quelque chose d'assez efficace. Maintenant qu'on a vraiment dégraissé la couche web, on va pouvoir se dire, ok, maintenant si mon trafic augmente, je vais pouvoir en mettre plein. Parce qu'avant, on avait des grosses instances web, et si jamais il fallait en mettre 50 ou 100 d'un coup, ça coûte un peu. Donc on a envie de contrôler la façon dont ça grossit. On a peut-être envie de le faire manuellement, on a peut-être envie de faire attention. Maintenant que ces instances-là sont beaucoup plus légères, on peut se dire, ok, si j'ai un pic de trafic, je peux les créer à la demande, je peux en créer autant que nécessaire, ça créera plein de petites instances, c'est pas grave, elles ne sont pas très chères, et puis quand j'en ai plus besoin, elles s'éteindront. Donc là on a deux mécanismes super pour faire ça, donc l'autoscaling qui a été mentionné tout à l'heure. Donc l'autoscaling c'est tout simple, c'est sur la base de métriques de monitoring que vous définissez, qui vont être la charge CPU, la consommation mémoire, le débit réseau, on a une liste assez longue dans laquelle vous pouvez choisir. Vous allez dire voilà, quand ça dépasse un certain seuil, si mon CPU dépasse 70% pendant deux minutes, je veux rajouter des instances. Donc le système de monitoring d'AWS va envoyer une alarme à votre plateforme et automatiquement va rajouter des instances. Et puis pareil à la baisse, si vous êtes en dessous de 10% pendant cinq minutes, vous allez dire ok, le trafic a baissé, j'ai besoin de moins d'instances et je peux donc en supprimer. Et ça se combine bien avec un mécanisme qui est un peu méconnu, mais qui est pourtant super économique, qui s'appelle les instances spot. Les instances spot sont des instances EC2, c'est de la capacité EC2 qui est inutilisée. Parce qu'à tout instant dans AWS, il y a de la capacité inutilisée. Histoire qu'elle serve quand même un petit peu à quelque chose, on la propose aux clients avec un système d'enchères. Vous pouvez enchérir en disant, voilà, moi cette instance-là, ce type d'instance là, je suis prêt à le payer X centimes de l'heure. Et si jamais le prix que vous proposez est supérieur au prix moyen de l'enchère, vous gagnez. Donc vous avez la main sur l'instance, vous pouvez l'intégrer dans vos groupes d'autoscaling, etc. Et si jamais le prix du marché spot augmente et dépasse votre prix d'enchère, vous allez perdre l'instance. Vous avez une notification et deux minutes après, l'instance est terminée. C'est pour ça que quand je disais tout à l'heure qu'il ne faut pas mettre d'état dans les instances, c'est aussi une des raisons de le faire. Il ne faut évidemment pas mettre toute sa plateforme en instance spot. J'espère que je n'ai pas besoin d'expliquer pourquoi. Si quelqu'un n'ose pas lever la main, on peut en parler dehors. Bon. Mais par contre, ce qu'on voit beaucoup de clients faire, c'est utiliser des instances classiques à la demande, un socle on va dire incompressible dont ils ont besoin tout le temps, et puis d'avoir au-dessus de ça une couche d'instances spot qui vient se greffer, et je n'ai pas précisé, mais c'est écrit sur le slide, que ces instances-là, typiquement, vous allez les payer à peu près 80% moins cher. Voilà, donc c'est 8 à 10 fois moins cher que le prix on demand. C'est pour ça que c'est super intéressant. Mais c'est bien en complément, ce n'est pas à la place de... Ces deux mécanismes-là vont vous permettre, en dormant la nuit, en n'étant pas en astreinte le week-end, etc. En arrivant à aller au cinéma avec vos enfants, si vous en avez, ou votre copine, si vous en avez, voir les deux, d'avoir une plateforme qui va scaler en fonction de votre trafic à la hausse et à la baisse. Et donc une fois de plus, qu'est-ce qu'on a changé sur ce schéma par rapport au précédent ? Et bien, voilà ça marche mon petit pointeur, donc ce qu'on a changé c'est ce qu'on a rajouté c'est ça, ce petit pointillé là, qui représente le groupe d'autoscaling. Donc en fonction du trafic qui va arriver, en fonction de la charge qui va être monitorée sur vos groupes d'autoscaling, vous allez être capable de les faire grossir et rétrécir à la demande, sans aucune forme d'intervention. Ce qui permet d'encaisser les pics de trafic, d'être réactif, de ne pas avoir de time out, de ne pas avoir de problème. Et puis ça vous permet d'être économique parce que vous avez une capacité qui est bien ajustée à votre trafic. Donc vous n'avez pas besoin de surprovisionner. Si vous avez un pic violent, vous n'êtes pas en défenseur de capacités. Donc l'autoscaling c'est important et voilà l'autoscaling plus les instances spot ça va permettre de le faire avec un coût qui est bien maîtrisé qui est intéressant. Et donc ça voilà une fois de plus ces chiffres là c'est pas du pipeau, on a des gens qui font tourner des plateformes de millions d'utilisateurs avec ce genre d'architecture. J'ai un client, c'est une compagnie aérienne islandaise avec qui je discute en ce moment dont l'architecture, donc eux ils ont beaucoup de trafic et beaucoup de frontaux et leur plateforme c'est ça, enfin vraiment c'est ça, c'est le design on va dire canonique d'une archi web sur AWS. Donc ça, ça peut aller très très loin et on pourrait continuer comme ça des heures et puis raffiner, raffiner et puis arriver à des millions et des millions et des millions d'utilisateurs. Le truc c'est que ça, toutes ces technos là, elles sont éprouvées, elles existent depuis des années, elles continuent à être améliorées, etc. Mais le monde continue de changer. Et il y a d'autres façons de le faire maintenant. Il me reste quand même une remarque sur ce truc, c'est qu'on a beau dire que ce sont des machines virtuelles, ça reste quand même des serveurs. Donc mes boîtes orange, là, elles ont un Linux, parce que je ne vois pas ce qu'elles pourraient avoir d'autres. Il va falloir les patcher, les maintenir, il va falloir déployer le code. Ils vont vous pousser des jars, des war, des zips, des je sais pas quoi. Et puis il va falloir les déployer, puis il va falloir les rollbacker aussi, parce que des fois ça arrive. Bon donc il va falloir gérer tout ça et c'est quand même du travail. Donc l'élasticité du cloud vous apporte plein d'avantages, mais ça reste des serveurs à manager. Et donc quand vous commencez S'il y en a trois de chaque côté, ça va. S'il y en a des centaines, ça reste un vrai travail. Est-ce qu'on a vraiment envie de gérer toutes ces instances-là ? Vous allez me dire qu'on n'a pas le choix. Oui, on les gère. En fait, si, on a le choix maintenant. Pour les francophones, ce n'est pas instantané comme citation. Il n'y a pas de serveur plus facile à gérer que pas de serveur. C'est plus clair en anglais, non ? Ce que ça veut dire, c'est que si on arrivait à se débarrasser des serveurs, on serait content. Et quand c'est le CTO d'Amazon qui le dit, M. Werner Vogels, que vous avez peut-être déjà vu, qui vient souvent, qui sera à Paris le 31 mai pour notre Summit, rassurez, il faut que je vous en reparle à la fin. Et bien on écoute. Et qu'est-ce que ça veut dire ? Comment on pourrait ne plus avoir de serveur dans une architecture ? Ça paraît bizarre. J'entends mal. Alors, ok, provocation. Ça va, j'ai du temps. Pour moi, un container, ça reste un serveur. Et vous avez tous le droit de ne pas être d'accord. Mais ce que je veux dire par là, c'est qu'un container, ça reste un OS, ça reste des librairies, ça reste des dépendances. Je n'ose pas parler de la sécurité parce que ça va nous emmener loin. Et ça reste une préoccupation. J'adore les containers et quand j'ai mon cerveau devs qui fonctionne, j'ai envie de faire ça. Quand j'ai mon cerveau prod, ops, sécurité qui fonctionne, j'ai pas du tout envie de faire ça parce que c'est presque pire qu'avant en fait. Parce qu'on laisse les devs construire des containers dont on sait très bien qu'ils vont pas tellement se soucier de la sécurité, de la configuration, etc. Et puis après ils vont vouloir ça en prod tout de suite parce que tu comprends c'est à ça que ça sert les containers. Sauf qu'avec ma casquette ops, il n'est pas question que ça se passe comme ça. Donc il va falloir avoir des process d'industrialisation, de sécurité, etc. Je ne dis pas qu'il n'y a pas de façon de le faire, je ne suis pas là pour troller. Je dis simplement que ça reste du travail. Et moi, ce que je voudrais, quand mon cerveau développeur fonctionne, c'est juste déployer du code. Et jamais avoir à me poser la question de quel libc j'ai, et quel rubis j'ai, et est-ce que j'ai patché le 58e bug de OpenSSL de la semaine. Là j'ai trollé. Là j'ai trollé. Mais chez AWS on le fait pour vous. Voilà. Ok. Eh oui, sur Network Load Balancer on le fait pour vous en tout cas. Sur les serveurs ça reste à vous de le faire. Ok donc, c'est vrai que je ne parle pas de containers aujourd'hui, je saute un peu l'étape containers. Les containers résolvent plein de problèmes mais à mon avis pas celui-là. Pas le problème de la gestion fine de la configuration. Ce qu'on propose maintenant c'est une architecture radicalement différente qui est basée sur deux choses. Qui est basée sur des services managés de haut niveau, dont je vais vous en présenter plusieurs dans la démo et j'ai entendu quelqu'un dire lambda donc bravo, tu as gagné un tee-shirt virtuel et ma considération. Qui est un produit qu'on a lancé il y a un peu plus d'un an et demi maintenant et sur lequel on voit une adoption extraordinaire et j'espère que vous allez comprendre pourquoi dans cinq minutes. Donc la combinaison de le code uniquement du code dans lambda et des services managés, ça fait qu'on a une architecture où il n'y a plus de serveurs. Il n'y a plus de machines virtuelles, il n'y a plus d'instances, il y a un petit peu de code, un peu de configuration et ça suffit. Et ça sera le but de ma démo tout à l'heure. Alors pour essayer de vous convaincre, ce n'est pas du pipeau, je suis allé chercher quelques cas clients. Il y a des gens qui sont en production sur ces solutions-là. Il y a un premier client qui s'appelle Localytics, qui est une boîte qui fait de l'analytics sur le web et sur le mobile pour les apps. Je vous ai mis à chaque fois les références clients détaillées, vous pourrez aller voir ça. Ils ont un trafic qui est assez sympa, ils ont 100 milliards d'événements mensuels, donc ce n'est pas négligeable. Ils s'intègrent avec les applis mobiles et puis ils collectent tout un tas d'infos et puis ils vont proposer des analytics à leurs clients. Ils ont une architecture des clients avec leur SDK j'imagine et leur tracker intégré. Ils rentrent sur du load balancer, ils rentrent dans SQS. Simple Queue Service, c'est un des plus vieux services d'AWS, mais qui est encore très très utilisé. C'est une file de messages, tout simplement. Par contre, c'est une file de messages AWS, donc ça veut dire hautement disponible, scalable, je rajoute pas les adverbes à chaque fois, parce qu'il y a des adjectifs, sinon ça saoule. Mais voilà, donc SQS. Derrière ils ont un petit service qui va, j'imagine, j'ai pas de détails particuliers sur cette boîte, qui va traiter les données, les normaliser, sûrement les nettoyer un petit peu. Ensuite il est réenvoi dans Kinesis. Alors Kinesis c'est une autre file de messages, beaucoup plus moderne. Si vous connaissez Kafka, on va dire que c'est quelque chose de similaire, mais managé, donc facile à vivre. Contrairement à Kafka qui peut être un petit peu dur à opérer. Je sais de quoi je parle. Et donc dans cette file de messages, où les messages vont persister assez longtemps, je crois qu'ils peuvent rester plus d'une semaine si nécessaire. Au bout de cette file, on va mettre lambda, donc on va mettre des petites fonctions puisque c'est ça. S'il y a des gens qui connaissent la programmation fonctionnelle, c'est exactement de ça qu'on parle. La fonction lambda s'appelle comme ça parce que c'est une fonction lambda. Donc c'est des fonctions pures qui prennent une entrée, qui génèrent un résultat, qui ne stockent aucun état et qui font juste un petit traitement. Et donc ils implémentent en fait tous leurs microservices avec une archi lambda. Et ils ont quelque chose d'assez escalable. Ce qui leur permet par exemple quand ils veulent rajouter une nouvelle fonctionnalité, de dire ok on va envoyer un nouveau type d'événement dans la file de messages, puis on va juste rajouter une lambda supplémentaire qui va implémenter un microservice supplémentaire. Donc ça permet d'avoir une archi extrêmement découpée, extrêmement découplé et assez scalable. J'ai un deuxième exemple qui est Nordstrom. Nordstrom, si vous êtes allé aux Etats-Unis, vous les connaissez probablement, c'est un très gros retailer américain. Je ne sais pas à quoi on pourrait les comparer en France, peut-être les Galeries Lafayette ou quelque chose comme ça. Un grand magasin plutôt haut de gamme. Et alors eux ils ont fait un truc assez incroyable, ils ont évidemment un site web et ils avaient un moteur de recommandation fait par un partenaire, un fournisseur. Et ils n'étaient pas très contents de la façon dont ça marchait parce qu'effectivement le temps de recommandation c'était 15-20 minutes. Donc ça veut dire entre la visite de l'internaute sur leur site et le moment où on pouvait afficher des recommandations, il s'est coulé 15 à 20 minutes. Qui reste 15 à 20 minutes sur un site e-commerce ? Bon, personne. C'est sûr. Donc voilà, je pense qu'ils sont arrivés à cette conclusion-là. Ils se sont dit, il faut qu'on ait un modèle où, à partir du web ou du mobile, on sait générer des recommandations en quelques secondes. Comme sur d'autres sites e-commerce plutôt bien faits. Et donc, oui, il y en a un. Je n'en citerai pas. Je peux vous citer ceux qui sont mal faits, j'ai même travaillé pour eux dans le temps. Si ils existent encore. Et blague à part. Donc ils vont envoyer toutes les données dans Kinesis, toujours pareil dans leur fil de messages. Derrière ils ont des fonctions lambda, donc ils vont aller piocher des messages dans cette file. Et puis, alors ils les copient dans Redshift qui est le Data Warehouse d'AWS, donc ça j'imagine c'est vraiment pour faire de l'analytics, et puis ils vont les stocker dans DynamoDB, donc dans notre base NoSQL, et puis retraiter ça encore avec des fonctions lambda, donc j'imagine qu'elles vont générer la reco, et puis après on peut exposer ça vers tout un tas de back-ends, de cache, pour que les applis web puisse s'en servir. Et donc voilà, ça donne ça. Ça, c'est des copies d'écran que j'ai fait, effectivement. Je suis allé vérifier que ce n'était pas du pipo, leur truc. Vous allez sur Nordstrom, vous regardez nordstrom.com, vous regardez quelques produits, effectivement, vous avez une recours qui commence à apparaître en quelques secondes. Voilà. Donc c'est plutôt sympa. Donc effectivement, voilà, en termes de perf, ils sont passés de 15 minutes, je ne sais pas combien ça fait de secondes, 800, c'est ça ? C'est à 800 secondes à quelques secondes. Ils ont divisé par 300, 400, le temps de la reco, c'est plutôt bien. Et surtout, ils le font de manière hyper économique. Ils ont divisé par deux ordres de magnitude, en gros ça veut dire à peu près par 100, le coût de la solution. Leur partenaire devait leur coûter cher, ça veut dire autre chose. Et puis surtout, l'avantage de lambda, c'est que c'est facturé par tranche de 100 millisecondes. Contrairement à une instance EC2 où vous payez à l'heure, qu'elle soit utilisée ou pas. Lambda, vous payez à l'invocation, donc ça veut dire pas de trafic, on ne paye pas. Et on paye par tranche de 100 millisecondes. Ça veut dire que si votre fonction dure 120 millisecondes, vous payez 200, c'est arrondi. Donc vous pouvez aller voir vos développeurs en disant « c'est possible de le faire en 90 ? » En frappant assez fort, c'est toujours possible. Rires Et donc si vous arrivez à faire ça, cette fois cette fonction vous coûte 100 millisecondes. Elle vous sera facturée 100 millisecondes. Ce qui veut dire que grâce à cette optimisation, cet usage irraisonné de la violence sur vos développeurs, vous avez réussi à diviser le coût du traitement par deux. Donc ça valait la peine. Ça permet de leur payer des bières et de se faire pardonner après. Moi je trouve intéressant qu'une boîte comme Nordstrom, qui est un retailer, qu'on ne voit pas forcément comme une boîte de techno, se disent, tiens, ce truc de reco qui est souvent considéré comme ésotérique, etc. je vais le faire moi-même. Et en fait, ils y arrivent et ils ont une super solution. Et puis le dernier dont je veux parler, avant de faire la démo, c'est une boîte qui s'appelle Adroll. Adroll, c'est une société d'adtech qui travaille dans le retargeting. Donc, il y a peut-être des gens qui font de la pub dans la salle. Ils font notamment ce qu'on appelle du real-time bidding, vous connaissez maintenant ce système, c'est assez répandu, où des sociétés comme Adroll vont enchérir en temps réel sur de l'espace publicitaire vu par des internautes pour leur afficher des bannières. Donc le système c'est au moment où vous chargez une page, l'espace où il y a une bannière, ça va provoquer un appel sur un des gros ad exchange, qui lui-même va appeler quelques partenaires, Adroll et d'autres, et ces partenaires-là ont 100 millisecondes pour répondre le prix de leur enchère. Après il y a un gagnant, et puis le gagnant envoie sa bannière, le real-time bidding en 30 secondes. Adroll fait ça, ils font ça 60 milliards de fois par jour, parce que forcément c'est du gros volume, alors ils gagnent pas tout, mais en tout cas ils enchérissent 60 milliards de fois par jour. Ils ont une architecture, ça a été un des premiers gros clients à utiliser Lambda et ils le font à une échelle qui est vraiment très importante. Je ne vais pas vous détailler tout le schéma, mais ils sont dans plusieurs régions AWS, ils sont US-West, West 2, donc ça c'est la côte ouest, East 1 c'est à côté de New York, EU-West 1 par là, donc c'est l'Irlande, etc. Ils ont 300 milliards d'items dans DynamoDB et plusieurs centaines de Tera dans S3. Lorsque j'évoquais des services managés, c'est-à-dire qu'on ne gère pas d'instances, il n'y a pas d'instance EC2 dans ce système. Après tout le back-end, Lambda est un service managé, SQS est managé, et Dynamo est managé. Il n'y a plus aucun serveur derrière, ils utilisent nos services, les combinent et les configurent, et se concentrent sur la création d'applications et de valeur. Voilà un bel exemple, il y a une très belle vidéo qui explique un peu plus en détail ce qu'ils font. Je vous la recommande. Je pense que vous aurez les slides un peu plus tard. Tout ça est bien, mais on a envie de le voir marcher. Donc, on va le voir marcher. Je vais expliquer en une ou deux minutes ce que je vais vous montrer, puis après je vous montrerai les étapes. Ensuite, vous allez m'aider en bourrant la F5, F5, F5, ça va vous plaire. Ce que je vais faire, c'est créer une API, une API REST sur laquelle on va poster un petit document JSON, dont le contenu n'a pas beaucoup d'intérêt, juste pour poster quelque chose. Je simule une API de logging ou un tracker web quelconque, que tout le monde a dans ses applications : une API que vous appelez pour logger des trucs, pour suivre telle ou telle donnée de navigation. Cette API va appeler une première fonction Lambda qui va écrire dans Kinesis et retourner. Du point de vue du client, l'appel se termine dès que Lambda a posté dans Kinesis, ce qui fait un appel assez court. Kinesis stocke les messages en attendant qu'ils soient dépilés. C'est toujours une bonne pratique de mettre des files de messages pour découpler ces traitements. J'aurai une deuxième fonction Lambda dont le rôle sera de lire les messages depuis Kinesis et de les écrire dans DynamoDB. L'avantage de faire ça, c'est que, une fois que la donnée est dans DynamoDB, je peux la requêter, même si c'est du NoSQL, je peux faire des "get" et aller chercher cette info. Cela signifie que, en très peu de temps, j'ai ma donnée en temps réel, disponible pour des applications. Si j'avais une application web qui voulait faire en temps réel ce qu'elle veut faire sur ces données, elle l'aurait immédiatement à disposition dans un système très scalable. À chaque écriture dans DynamoDB, dans cette table qui s'appelle Event Table, je vais utiliser un mécanisme appelé DynamoDB Streams, qui est un trigger, pour appeler une troisième fonction Lambda. Cette fonction recevra les items qui ont été écrits ou modifiés dans DynamoDB et les poussera dans Kinesis Firehose, qui est un gros tuyau. Firehose est une abstraction de niveau plus élevé que Streams. Streams, on peut gérer des shards et des choses assez complexes, comme Kafka. Firehose, c'est une abstraction de niveau plus élevé, un gros tuyau. Vous écrivez, et ça se déverse soit dans S3, soit dans Redshift, soit dans Elasticsearch. Si vous voulez indexer les données et les rechercher, vous pouvez le faire car nous avons un service managé Elasticsearch. L'avantage de ce tuyau, c'est qu'il fait de la compression, de l'encryption, donc c'est un gros tuyau mais relativement intelligent. Juste une dernière fois, on va faire un post, on va appeler une API, une première Lambda, ça part là-dedans, hop, ça revient, et ensuite tout le reste est de la programmation événementielle où on réagit à ces événements. Ok ? Alors, go ! Je n'ai pas le temps de vous montrer les étapes de création, j'ai préparé tout ça, ça se scripte, ce n'est pas très compliqué. J'ai une autre présentation où je vous montre comment le faire, mais ce n'est pas le but du jeu. Voici donc API Gateway, j'ai créé mon API qui va faire un post. Je n'ai pas mis d'authentification sur l'API car ce n'était pas totalement indispensable. Cette API appelle une fonction Lambda qui s'appelle WriteToKinesis. Cette fonction va écrire dans Kinesis et retourner un résultat. On va regarder la fonction. Vous verrez, elle est vachement compliquée. C'est peut-être un peu petit là. Les gens du fond, il faut crier. Ça va ? Ouais, c'est bon ? Ouais, si j'entends rien, c'est que ça va. J'ai développé ça en Python. Lambda, on peut faire du Python, du Node, ou du Java. Quand je parlais d'une fonction, c'est ça : j'ai une fonction qui reçoit un événement. Le contexte, je n'en parle pas, je n'en ai pas besoin ici. Et je ne déploie que ça. Quand je disais que je ne déploie plus aucune forme d'environnement, c'est mon unité de déploiement. J'écris cette fonction, je la teste, et je l'upload dans le service Lambda qui va ensuite l'exécuter. C'est tout ce que je fais. Il n'y a plus d'OS, il n'y a même pas d'environnement Python, il n'y a rien du tout. Quand je dis serverless, c'est serverless. C'est tout ce que j'ai à faire pour que mon API fonctionne. Qu'est-ce que ça fait ? Ça fait print, c'est toujours bien. Je rajoute un petit timestamp dans mon document JSON et puis je fais put record dans Kinesis, dans un stream qui s'appelle API to DynamoDB. Ça tombe bien, c'est ce qu'on fait. Je peux vous montrer le stream Kinesis, c'est passionnant. Là, il n'y a pas beaucoup de trafic dessus. J'ai un shard, le nombre de shards va conditionner la quantité de trafic que je peux envoyer. Je pense que là, aujourd'hui, un shard va nous suffire. De l'autre côté de ce shard, j'ai une deuxième fonction qui s'appelle Kinesis String to DynamoDB. J'ai été inspiré pour les noms. C'est toujours en Python. Qu'est-ce qu'elle fait ? Elle récupère une référence sur ma table Dynamo. Ensuite, elle va itérer sur chacun des records, car ils peuvent être batchés. Quand j'écris dans Kinesis, je les écris un par un, mais quand je les lis, je crois que c'est 10 par 10, histoire de batcher un peu. Donc, j'itére, je décode parce que dans Kinesis c'est encodé en base 64. Là, c'est juste pour convertir un string en int parce que j'en ai besoin, et je fais table put item, donc j'écris mon document JSON dans DynamoDB. Et c'est tout. À ce stade, j'ai appelé mon API, elle a appelé une Lambda qui a mis dans Kinesis, qui a réveillé l'autre Lambda qui écoute, et j'ai écrit dans DynamoDB. DynamoDB dit : "Tiens, j'ai une écriture dans la table, donc je vais faire un trigger sur ma troisième Lambda qui s'appelle DynamoDB to Firehose." Elle est aussi vachement compliquée, elle récupère une référence sur Firehose. Elle va itérer sur les records, faire print, ce qui n'est pas totalement indispensable, et surtout elle va faire Firehose PutRecord, donc elle va écrire dans le tuyau le record qu'elle a reçu de DynamoDB. Firehose, qui est bien sympathique, va faire quoi ? On lui a demandé de vider dans S3. Voilà, c'est à peu près tout ce qu'il y a à configurer. Je lui ai dit : "Voilà, tu écris dans ce bucket, tu écris soit toutes les 60 secondes, soit tous les 1 mégaoctet, tu gzip ce que tu écris, tu ne fais pas l'encryption." À la fin, je devrais voir débarquer mon contenu dans S3. Donc, je vais voir un fichier, on va se mettre là et puis on va voir le truc. Ok, donc voilà ce qu'on va faire. Je vais vous montrer que ça marche, puis après vous allez m'aider. Faites chauffer le wifi. Ok, donc là je suis sur une instance EC2 quelconque et j'ai écrit un magnifique programme de tests en Python qui va faire quoi ? Qui va juste faire mille fois, créer un document bidon et appeler l'API que j'ai créée, dont l'URL est là. En avant, on va peut-être pas faire mille fois, on va faire dix fois, ça suffirait. Je vois mes 10 appels d'API, ça va vite. Si je regarde ce qu'il y a dans ma table DynamoDB, je réduis un tout petit peu. Là, je vois mes 10 items. Je vous montre la première moitié du pipeline, et la deuxième moitié, comme il y a une petite latence de 60 secondes parce que je lui ai dit d'envoyer toutes les 60 secondes, on va attendre un tout petit peu. Ça va arriver. Pendant ce temps, on va commencer à tabasser. Il en reste un peu de temps, impeccable. Vous pouvez tous aller sur cette URL-là, api.julien.org, 2.8080. On va vérifier qu'elle marche. Ah, elle ne marche pas parce que je n'ai pas lancé mon serveur. Eh oui, j'ai bien fait de vérifier. Voilà, hop. Comment il s'appelle ? Ouais. Voilà, c'est parti. Voilà, ça y est, en voiture, ça bourrine. Bien, c'est bien. Ok. Bien les gars, bien, bien. Allez-y. F5, contrôleur, tout ce que vous voulez. Je pense que vous allez faire tomber mon Python avant de faire tomber Kinesis. C'est devenu dommage, vous allez trop vite, vous ne voyez même pas les images de chats. Bon, voilà, ça marche. C'est pas mal quand même, blague à part, c'est Flask en threading, avec du threading activé. J'ai fait un petit test de charge et j'étais étonné de ce que ça pouvait encaisser. Ça faisait longtemps que je n'avais pas joué avec ça. Petit commentaire. C'est pas mal. Bon, donc là on était à 10 items. On les voit par 100, mais ça se remplit. On doit pouvoir voir le timestamp qui change. Si je les triais par timestamp. Ah non, là je les ai dans le mauvais sens. Ça se remplit. Alors, est-ce qu'on commence à avoir des fichiers qui arrivent ? Ah ouais, ça se précise. Voilà, donc là je commence à voir mes fichiers qui arrivent. Comme on n'a pas assez de données, on avait dit toutes les 60 secondes ou tous les 1 mégaoctet, en fait c'est toutes les 60 secondes, donc c'est pour ça qu'on va avoir un fichier toutes les minutes. On n'a pas assez de data pour aller plus vite que ça. Ça prend, ça prend. Il râle de temps en temps, mais ça prend. Le but, ce n'est pas de faire des pitons non plus. Si je regarde dans un de ces documents-là, j'aimerais bien voir un troisième qui arrive. Allez, 15h42. Voilà, ok. J'ai toutes les minutes. Refaites le petit schéma dans votre tête. Toutes les minutes, paf. Firehose va se vider dans S3. Donc, si je regarde ce qu'il y a là-dedans... Ouais, il y a le mec qui a lancé des scripts, hein ? Ah oui, bien sûr, bien sûr. Allez, attendez. Prenez pour qui ? C'est bien, on est là pour Rigo. Alors, faites-vous plaisir, c'est vendredi. Et donc là, c'est bien illisible parce que c'est du JSON, donc normal. Mais donc là, on voit bien, on voit tous les événements qui ont été postés. Voilà, donc on voit le timestamp, on voit le user ID, on voit... C'est un trigger, donc c'est comme dans les systèmes traditionnels de trigger, on pourrait avoir l'ensemble de la nouvelle valeur, pour ceux qui connaissent ça. C'est assez illisible, mais on pourrait parser ça. Il ne s'est pas encore cassé la figure, incroyable. Ça marche bien. Et donc on pourrait faire plein de choses. Dernier chat pour la route. Ça y est, là je crois qu'il est... J'ai dû épuiser les threads là. Ouais, ouais. Ouais, ouais, ouais, il n'y a pas beaucoup de... D'accord ? Non mais c'est le wifi là. C'est bon. Allez, tac. Voilà, je l'arrête. Il va avoir du mal à s'arrêter. Voilà le chat. Donc on finit juste là-dessus. Vite fait. Voilà, on a fait ça. Combien de serveurs on a installés, combien de serveurs on a gérés, combien de serveurs on a monitorés ? Zéro. Combien de lignes de vrai code on a à écrire ? J'ai été honnête, je n'ai pas compté les prints. Il y a 16 lignes. Et tous ces services-là, ils vont scaler très, très, très loin. Bien plus loin que ce que vous n'arriveriez à faire en construisant vous-même cette infrastructure. Voilà, donc si on continue comme ça, on peut aller très haut et on peut même être capable d'encaisser un succès catastrophique. Et si jamais les barbares arrivent, vous me voyez venir, et bien en fait ils arrivent puisque un de nos clients, Supercell, a annoncé le 7 mars qu'ils avaient eu 100 millions de joueurs le même jour, c'était la première fois. Je crois que c'est la première fois qu'une plateforme a 100 millions de joueurs le même jour. Ils utilisent la plupart de nos services, ils ont 45 milliards d'événements par jour, ils utilisent Kinesis, ils utilisent DynamoDB, enfin voilà. C'est une très belle référence, je vous laisserai regarder ça en détail. Je voulais juste finir sur cette citation du CTO d'Airbnb, qui connaît un peu les problèmes de scalabilité, disant que AWS est vraiment la meilleure façon pour une startup de scaler. On les remercie de nous faire confiance. À vous de jouer, à vous de scaler, et pour vous aider à bien démarrer, j'ai juste deux ou trois petites choses à vous dire. Si vous vous intéressez à Lambda, il y a un bouquin qui est en cours d'écriture par un de mes collègues. Il n'est pas encore publié, mais vous pouvez déjà l'acheter et télécharger les chapitres disponibles sur le site de Manning. Vraiment excellent livre, il y a à peu près la moitié du bouquin qui est disponible. Si vous voulez nous revoir, on sera lundi à DotScale pour ceux qui y vont. Il y a des gens qui y vont à DotScale ? Ouais, quoi ? Un traître ? Pas avec ce t-shirt. Et puis surtout, je plaisante, on adore les autres aussi. Et on a deux événements qui arrivent très prochainement. On a le Summit AWS qui est donc le 31 mai. C'est notre conférence technique annuelle. Elle est gratuite, j'insiste là-dessus, c'est intéressant. C'est une journée de sessions techniques et de use cases clients autour d'AWS. Il y a le CTO d'Amazon qui sera là en keynote. C'est toujours sympa de le voir présenter. Et puis on a un autre événement qui s'appelle le Awesome Day, qui est un événement de formation qui dure une journée, qui est à Paris. Vous avez les dates, qui est lui aussi gratuit. C'est très bien pour les gens qui débutent ou qui veulent découvrir. Vous avez une journée avec un panorama de nos différents services. Et puis, la dernière chose que je voulais vous dire, c'est qu'il doit y avoir des gens de province dans la salle. Allez, ouais, levez la main. Voilà, magnifique, très bien. Je ne suis pas parisien non plus. Donc on a des user groups. Merci d'être venus. Merci d'avoir pris le train. On a des user groups en province, donc Lille, Rennes, Nantes, Bordeaux, Lyon, Montpellier. On a aussi un groupe à Paris qui est assez actif. Vous les trouverez tous sur Meetup. Donc, si vous êtes dans ces villes-là et que vous voulez continuer à bosser avec AWS, je vous encourage à les rejoindre. Si vous êtes dans une ville de taille importante qui n'est pas sur cette liste et que vous avez envie de démarrer un groupe AWS, n'hésitez pas à me contacter, je serai ravi de vous aider à le faire. Grenoble, Toulouse, Aix-Marseille, voilà. Et puis dans l'Est aussi, il doit se passer des choses dans l'Est. Strasbourg, voilà. Donc voilà. Et puis voilà, c'est tout ce que j'ai à vous dire. Voilà mes coordonnées, n'hésitez pas à rester en contact. Merci beaucoup. Et merci à Devox pour ce bel événement. Merci beaucoup.