Choisir sa base de donnees sur AWS

Transcript

Voilà, avant qu'on commence, je voulais juste vous faire un petit coucou. Je voulais vous montrer la vue. On voit pas bien, mais on voit le soleil. Je vous avais dit qu'on verrait le soleil. Levé de soleil sur Las Vegas. C'est pas mal. Hier, il faisait 25 degrés. Il fait très beau. Et pour ceux qui n'auraient pas encore compris, je suis à re-invent. Non, vous êtes bien sur le webinaire AWS. Je suis bien Julie, et je suis en direct de Las Vegas où il va se passer beaucoup de choses dans les jours à venir. Je vais rétrécir cette petite fenêtre. Voilà. Et on va commencer. Plein écran. Voilà, c'est parti. Le premier sujet, ce matin, parce que pour moi il est 6h30, c'est de vous parler des différents back-ends qui existent sur AWS et de les comparer pour finalement vous aider à choisir celui qui est le plus approprié. Je vais m'appuyer sur un ensemble d'exemples et sur du code, comme d'habitude. Comme il faut bien choisir un langage, j'ai choisi de le faire en Java. Ceci étant dit, tous les conseils que je vais donner, toute la description qu'on va faire des back-ends, reste valable dans d'autres langages. Donc, pas de soucis, si vous développez dans d'autres langages que Java, tout ce qu'on va voir, tout ce qu'on va étudier, tout ce qu'on va tester, ça reste valable. On va refaire un petit point rapide sur le développement d'applications et en particulier sur la gestion de la sécurité. Vous verrez qu'on ne répète jamais assez ces points-là et je tenais à commencer par ça. Je tenais à commencer par la gestion des credentials, la gestion des permissions, etc. Ensuite on va parler de deux bases de données qui sont disponibles sur AWS. RDS pour les bases de données relationnelles et DynamoDB pour les bases dites NoSQL. Ensuite on regardera trois solutions pour l'Analytics : Hive sur Amazon EMR, Athena et Redshift. On comparera les fonctionnalités, mais surtout la façon dont on se sert de ces bases, la façon dont on se sert de ces services à partir du code. On exécutera des démos, on utilisera le même dataset à chaque fois, donc ça permettra un peu de comparer la simplicité ou la complexité, la rapidité de ces différentes solutions. On finira par un point sur la migration de base, on a là aussi des services qui peuvent vous aider à migrer vos bases vers AWS. On conclura et on gardera du temps pour les questions. Tous les codes que je vais vous montrer sur Github, n'hésitez pas à les récupérer et à vous en servir. Commençons par un bref rappel sur le développement d'applications sur AWS avec un angle Java. Vous le savez, si vous nous suivez régulièrement, il y a quatre façons de déployer du code sur AWS. On va aller de la plus ancienne à la plus récente. La plus ancienne, c'est évidemment de déployer sur des machines virtuelles, donc de créer une instance EC2 et de vous connecter dessus et de déployer ce que vous voulez, soit manuellement, soit de manière automatisée avec des outils de déploiement. Ça, c'est la solution qui existe depuis des années, quand on veut avoir le contrôle complet de l'instance et du serveur. La deuxième solution, c'est d'utiliser un service qui s'appelle Elastic Beanstalk, qui vous fournit des environnements préinstallés dans différentes technologies. Si on regarde spécifiquement Java, vous pouvez disposer à la demande d'un environnement Java Tomcat, Java Glassfish, dans différentes versions, sur lequel, en utilisant la ligne de commande Elastic Beanstalk, vous pouvez déployer en une commande votre application. Donc on va dire du plateforme as a service très simple, très orienté développeur où l'infrastructure est gérée pour vous et les environnements sont fournis pour vous. La troisième solution, c'est de déployer sur des containers. On en a parlé le mois dernier avec Amazon ECS. Vous allez dockeriser votre application et puis vous allez créer un cluster de nœuds EC2 avec Docker, avec une connexion sur le backend ECS, l'orchestrateur ECS qui va s'assurer que vous gérez, que vous avez en permanence le bon nombre de containers qui tournent, qui va relancer les containers s'ils tombent, etc. Donc pour les gens qui ont dockerisé leur application, voilà une bonne solution. Et puis la dernière en date, c'est Lambda, les architectures serverless, dont je pense qu'on va encore beaucoup parler ces jours-ci, qui vont vous fournir une infrastructure totalement abstraite, totalement cachée à vos yeux, et vous vous contentez de déployer des fonctions et de les déclencher via des événements qui peuvent être un appel d'API dans API Gateway, qui peuvent être un événement d'infrastructure, comme la création d'un fichier dans S3, ou l'utilisation d'un événement quelconque au sein de C2, le démarrage d'une instance, etc. pour faire du DevOps. Et donc là, bien sûr, Java fait partie depuis le début des langages supportés par Lambda. Il y a également un ensemble de frameworks open source dont on avait déjà parlé dans des webinaires, si le sujet vous intéresse, que je vous avais déjà montré, des frameworks comme Serverless, Gordon, Apex, etc., qui vous permettent aisément de déployer vos applis serverless et toutes les sources d'événements associées. Et bien évidemment, depuis longtemps, il y a un SDK Java qui vous permet d'invoquer toutes les API AWS pour les différents services, que ce soit les API EC2, Beanstalk, et toutes celles qu'on va utiliser aujourd'hui. Si vous utilisez Eclipse, ce qui sera mon cas aujourd'hui, il y a un plugin qui est maintenu par AWS, qui vous permet de faire deux choses : avoir des quick starts pour les différents types de projets AWS, ce qui est toujours sympa, et qui vous permet également, dans le cas de Lambda, de déployer vos Lambdas et d'exécuter vos Lambdas directement à partir de l'IDE. Et puis qui vous permet aussi d'explorer les ressources qui tournent dans votre compte. Je vous montrerai un exemple tout à l'heure avec Dynamo. C'est pratique, ça permet dans l'IDE de faire un certain nombre d'opérations et de ne pas aller dans la console pour démarrer une instance, arrêter une instance, etc. Pour IntelliJ IDEA, la situation est un peu moins bonne. Il y a deux plugins qui sont maintenus par la communauté : un qui fait l'intégration avec Elastic Beanstalk, un qui fait l'intégration avec CloudFormation. Mais en revanche, on n'a pas aujourd'hui d'équivalent de cet explorer que je vous ai montré à l'intérieur d'Eclipse. Il y a un vieux plugin qui s'appelle AWS Manager qui a deux ans, qui n'est plus du tout à jour. Malheureusement, les sources ne sont pas disponibles. Donc, si quelqu'un veut ressusciter ce projet ou en relancer un, je pense qu'il y a un vrai manque pour les utilisateurs d'IntelliJ qui sont nombreux. Il y a un vrai besoin d'avoir un plugin. Malheureusement, celui-là est trop vieux. Voilà. Donc, appel aux volontaires. Essayez de contacter le maintainer et essayons de ressusciter ce projet. Le point sur lequel je veux vraiment insister avant de rentrer dans le sujet sur les back-ends, c'est la gestion de la sécurité. Si j'avais pu faire des slides en rouge, gras, police 500 points, clignotante avec un gyrophare, je l'aurais fait. Vraiment, ce sont les deux erreurs absolues à ne pas faire lorsqu'on gère les credentials AWS. Je pense que vous avez écouté ce qu'il sait, vous suivez les news, vous avez entendu parler du problème qu'a eu Uber récemment, enfin qu'Uber vient de révéler parce que le problème est bien plus ancien que ça. La source du problème, c'est qu'ils ont laissé traîner des credentials AWS dans un repository GitHub qui était un repository privé, manifestement, mais qui a été hacké. Et une fois que les credentials sont dévoilés, je vous laisse imaginer ce qui se passe. Donc, c'est vraiment tragique de voir des gros clients sophistiqués comme eux faire ce genre d'erreur. Donc, par pitié, ne stockez pas les credentials AWS, que ce soit l'access key, la secret key, ne les stockez pas dans votre code. Si vous les mettez dans le code, ils vont arriver dans un repo, ils vont être partagés. Ce n'est pas une question de quand, ce n'est pas une question de est-ce que ça va se produire, c'est une question de quand ça va se produire. Donc ne le faites pas. Ne déployez pas vos credentials sur les instances EC2, parce que si jamais une instance est compromise, il suffit d'aller dans le fichier de configuration EC2 et de lire les credentials. S'il vous plaît, ne faites pas ça. Ça finit toujours mal. La bonne solution, c'est d'utiliser des rôles. Vous attachez des rôles à vos instances EC2, à vos fonctions lambda, etc. Et à l'intérieur de ces rôles, vous définissez les permissions minimales dont l'instance a besoin. C'est la seule solution et unique façon de faire. Tout le reste c'est du bricolage et ça vous explosera en pleine figure à un moment ou à un autre. Et je reste poli. Pour ce qui est des credentials applicatifs, par exemple un mot de passe, un login et un mot de passe MySQL, ou un login et un mot de passe applicatif, qui ne rentrent pas dans le cadre d'IAM, la bonne solution c'est d'utiliser un service dans EC2 System Manager, qui s'appelle le Parameter Store que je vais vous montrer tout à l'heure, qui permet de définir des couples clés-valeurs avec vos logins, vos passwords, qui sont chiffrés avec KMS lorsqu'ils sont stockés dans le Parameter Store et qui sont chiffrés en HTTPS quand vous faites les appels d'API pour les récupérer. Donc il n'y a aucune raison de ne pas utiliser ça. Vous allez voir à quel point c'est simple. C'est un appel d'API. Donc je résume, ne mettez jamais vos credentials, vos access keys, vos secret keys. Ils ne doivent pas être déployés sur AWS, ils doivent être dans IAM et c'est tout. Vous accédez aux permissions via les rôles et pour tous les autres passwords, pour tous les autres secrets, vous utilisez par exemple le parameter store qui garantit le chiffrement de bout en bout et la protection de vos secrets. Maintenant qu'on a dit ça, parlons un peu des back-ends. Et je tenais à adresser le point suivant qui est de dire, on voit encore des projets ou des sociétés qui vous disent qu'ils ont une solution qui sait tout faire. Ils ont une base de données ou un back-end qui sait faire du relationnel, du non relationnel, du clé-valeur, du map reduce, etc. Et que sais-je. Et bon, c'est le back end to rule them all. Le problème de ça, c'est... N'oubliez pas la suite de la phrase. C'est... Cet anneau unique, il va vous enchaîner dans l'obscurité pour l'éternité. Donc ici comme ailleurs, la promesse de la sauvegarde ultime qui domine toutes les autres, qui règle tous les problèmes, c'est un piège. C'est le syndrome du couteau suisse. Le couteau suisse, c'est rigolo, ça c'est tout faire sur le papier. Maintenant, le jour où on a besoin d'un très bon tournevis ou le jour où on a besoin d'une très bonne paire de ciseaux, on se rend compte que ce n'est pas vraiment le bon outil. Donc, ces approches-là qu'on continue malheureusement à entendre, je vous appelle à la méfiance et à bien challenger les différents use cases qui peuvent être satisfaits par ces outils et à vous assurer qu'ils vont vraiment faire le boulot et pas juste 10% du boulot. En ce qui concerne AWS et les clients d'AWS, au fil du temps, on a développé un ensemble de services qui savent faire une chose mais qui la font bien, qui sont spécialisés sur un type de stockage de données. Par exemple, S3 pour le stockage d'objets, RDS pour les bases de données relationnelles en SQL, DynamoDB pour des approches de type NoSQL, etc. Aujourd'hui, au sein d'AWS, on a quasiment une centaine de services. Le monde de bases de données back-end ne fait pas exception à la règle. On a pas mal de services, je pense qu'il en manque encore quelques-uns ici. Peut-être qu'on va encore en annoncer quelques-uns dans les jours à venir, allez savoir. Il faudra que je mette à jour ces slides. Mais en tout cas, le message important ici, c'est pour un cas d'usage précis, il y a un service. Par contre, ce service-là, il vous donnera le maximum d'efficacité et de performance sur ce use case là. Et donc aujourd'hui on va parler d'RDS, Dynamo, MapReduce avec Hive, Redshift et Athena. J'ai choisi ceux-là, ce sont les principaux mais il y en a d'autres et il faut bien se limiter un petit peu. Alors commençons par les bases de données. RDS, je pense que vous êtes nombreux à l'utiliser. RDS, c'est le service managé qui vous permet de démarrer des instances et des clusters basés sur des bases de données relationnelles comme MySQL, Postgre, SQL Server, etc. Et comme j'ai dit service managé, vous avez compris, vous n'avez pas à gérer l'infrastructure. Vous lancez votre instance ou votre cluster, soit dans la console, soit avec un appel d'API, vous attendez quelques minutes et puis vous avez une chaîne de connexion qui vous permet d'accéder à l'instance et à vos données. Malgré le fait qu'on vous simplifie l'infrastructure, on reste sur des solutions qui sont complètement standards et complètement compatibles. C'est-à-dire que quand vous lancez MySQL dans RDS, c'est MySQL. Il n'y a pas de surprise. Quand vous lancez Oracle, c'est Oracle. Il peut y avoir un certain nombre de petites restrictions, de choses qui sont un peu différentes. Je vous incite à aller voir dans la documentation. Mais on va dire 98% voire plus du fonctionnement est absolument identique. Le service, comme tous les services AWS, est un service de paiement à l'usage. Donc vous démarrez votre instance, vous vous en servez, vous payez à l'heure en fonction de la taille de l'instance et du moteur que vous utilisez, et puis ensuite quand vous avez fini, vous pouvez l'arrêter, faire un snapshot de vos données, récupérer vos données, éteindre le cluster et vous cesser de payer. Vous pouvez également redimensionner les clusters à la hausse et à la baisse si vous avez besoin de faire une grosse ingestion de données que vous voulez booster un peu la capacité de l'instance, vous pouvez changer le type de l'instance et puis une fois que vous avez fait l'ingestion, revenir sur quelque chose de plus petit. On retrouve les mécanismes traditionnels comme dans EC2. Et comme indiqué sur le slide, vous pouvez également utiliser RDS au sein du niveau d'usage gratuit, le fameux free-tier sur des petites instances, mais si vous voulez faire des tests, c'est une bonne solution. Je les ai mentionnés rapidement, on supporte 6 moteurs de base de données, donc 3 open source : MySQL, MariaDB et Postgre, avec pas mal de versions, y compris des versions assez anciennes. Deux moteurs commerciaux : Oracle et SQL Server. Et puis, on supporte également Aurora, qui est une implémentation haute performance faite par AWS, ou une réimplémentation haute performance de MySQL et de Postgre. Donc en fait, vous avez les mêmes interfaces, les mêmes API que sur MySQL et sur Postgre, mais vous avez un niveau de performance qui va être 5 à 10 fois supérieur en fonction des cas. Donc si vous êtes utilisateur de ces moteurs open source mais que vous heurtez à des problèmes de scalabilité ou de performance, Aurora peut être une solution intéressante dans la mesure où il suffit de démarrer un cluster, de bouger vos données vers Aurora et... et a priori sans aucune modification de votre code puisqu'on reste sur la compatibilité MySQL et Postgre. RDS, je dis toujours, je ne connais pas beaucoup d'applications qui n'ont pas besoin d'une base de données relationnelle et sans surprise RDS est un des services les plus populaires. Je vais juste donner un exemple que tout le monde connaît qui est Airbnb. Airbnb est né sur AWS dès le premier jour et Airbnb a géré dès le début ses bases de données sur RDS et a continué à le faire, ce qui leur a permis de se concentrer sur le développement du produit, le développement du service et pas sur la plomberie base de données. Je pense qu'on peut dire qu'Airbnb est ce qu'elle est de manière plutôt satisfaisante et ça doit vouloir dire quelque chose sur la scalabilité d'RDS également. Il y a des tonnes de use cases, je vous invite à aller les consulter sur notre site, vous verrez ce que les différents clients d'AWS peuvent faire avec RDS. Alors on va passer, maintenant on va rentrer un peu dans le code, donc moi j'ai choisi aujourd'hui de vous montrer Aurora au sein d'RDS, donc c'est Aurora MySQL, donc on va basculer vers... On va basculer vers Eclipse. Avant de vous montrer ça, j'utilise un dataset que j'ai généré, qui a une table, un milliard de lignes, quelques colonnes, des noms, des prénoms, des âges, des adresses, etc. Je vais utiliser ce dataset pour les différents tests à part sur DynamoDB où j'ai fait quelque chose de différent. Donc affichons tout de suite ce code. Comme ça vous verrez de quoi on parle. Voilà. Donc si vous êtes familier de MySQL, vous n'allez pas être dérouté. On utilise ici le driver standard JDBC MySQL pour se connecter à Aurora donc ça montre bien à quel point la compatibilité est forte. Je vais ensuite récupérer mes credentials donc je vais récupérer mon login password MySQL pour pouvoir me connecter et donc vous voyez que je le fais pas en hard codant les choses dans le code. Je le fais en utilisant le EC2 Parameter Store dont j'ai parlé tout à l'heure. Et donc ça s'utilise de manière super simple. Tout ce qu'on fait, c'est qu'on récupère un client EC2 System Manager. Et puis, on lui demande tout simplement de construire une parameter request avec le nom du credential qu'on veut récupérer. Et puis, on fait l'appel et on récupère la valeur. Donc ça, c'est deux credentials, qui s'appellent Backend User et Backend password, je les ai créés dans EC2 Parameter Store avec la bonne valeur. Et de cette manière-là, je peux les récupérer de manière complètement sécurisée. Quand les credentials sont au repos dans EC2, ils sont chiffrés. Là, je fais des appels d'API en HTTPS systématiquement, évidemment. Et donc, je récupère dans mon appli, de manière dynamique, ces deux paramètres sans avoir à coder quoi que ce soit, ou aller stocker de manière non sécurisée. Donc vous voyez, c'est vraiment super simple, il n'y a aucune raison de ne pas le faire. Donc je récupère mon user, je récupère mon password, je me connecte de manière très standard à ma base. On va regarder juste le connect, on va le regarder. Donc là c'est du code JDBC complètement standard si vous avez l'habitude de ça il n'y a aucune différence. Je charge le driver, j'appelle getConnection, c'est tout. Ensuite on va faire un petit appel sur le SDK Java pour décrire les instances qui tournent dans la région. On va afficher quelques infos et puis ensuite on va exécuter une requête donc là qui va être une requête simple, on va chercher toutes les personnes qui s'appellent Jones en Floride, et évidemment là je vais le faire en SQL, tout ce qu'il y a de plus standard, voilà, ok, avec un prepared statement, donc là aussi du code Java, JDBC, tout ce qu'il y a de plus normal, il n'y a absolument rien de spécifique à AWS là-dedans, ok, voilà, très simple, donc vous voyez, si vous avez du code applicatif qui utilise MySQL et que vous voulez migrer sur RDS, la seule chose qui va changer finalement, c'est la chaîne de connexion qui est là. Donc c'est le endpoint, on voit bien ici, donc je me connecte sur un endpoint USist. Donc au lieu d'aller taper votre base on-premise, vous allez taper un cluster hébergé dans AWS et c'est tout. Allez, on l'exécute. J'ai pas bien cliqué. Allez. Et bien, qu'est-ce que tu me fais maintenant ? Ah ! On va avoir envie de me recompiler un truc. Oui, voilà, ça y est, on peut avoir l'exécution. Allô, allô ? Oui, non, oui, ça y est voilà donc là on voit voilà on a récupéré où ça va vite on a récupéré les credentials dans le paramètre store on a à me la relancer une deuxième fois parce que oui bien sûr petit coup de l'eau sur mon Mac. Il affiche que j'ai effectivement une instance qui s'appelle Webinar et qui est de ce type là et puis ensuite il m'affiche les résultats de la requête. Donc rien d'extraordinaire si ce n'est que, il va me lancer dix fois maintenant, rien d'extraordinaire et c'est tout à fait l'objectif, c'est que ça ne soit pas extraordinaire. L'objectif c'est que ce soit simple, que ce soit compatible avec MySQL, que tout votre code existant soit réutilisable et que simplement vous soyez déchargé de la gestion de l'infrastructure. Que vous puissiez scaler les instances quand vous en avez besoin. Alors juste une remarque, vous voyez ici on fait un select sur une table qui fait un milliard de lignes, ça va vite. On va le refaire, maintenant qu'il a l'air décidé de le faire à la demande. Ça va vite, et pourtant on pourrait se dire, un milliard de lignes, c'est une grosse table, et jamais personne ne ferait du select sur un milliard de lignes avec du SQL. Et donc, il faut aller faire du NoSQL, et il faut aller chercher des bases différentes, etc. Ça dépend, c'est toujours la même histoire, si vous avez les bons index, si vous connaissez les requêtes, etc., et que vous pouvez les optimiser, SQL peut être une très bonne solution même si vous avez des grosses tables et des grosses jointures, etc. Donc voilà, un mot de prudence une fois de plus, ne jetez pas SQL et les relationnels à la poubelle. Si vos données sont globalement structurées, que vous connaissez les requêtes et la façon dont vous y accéder, une bonne vieille base Postgre et une bonne vieille base MySQL, ça peut très bien faire le boulot avec les bons index, avec les bonnes optimisations. Il n'y a pas de raison d'aller se jeter dans un projet risqué sur une techno que vous maîtrisez peut-être un petit peu. Voilà, juste mon avis personnel là-dessus. Donc voilà Aurora, RDS Aurora, super simple. Alors justement, parlons de l'alternative. Effectivement, tous les jeux de données ne vont pas rentrer forcément correctement dans des schémas et dans des relations, et on peut avoir besoin d'une base qui va gérer des données non structurées. En ce qui concerne AWS, le service concerné est DynamoDB. Il y a une base complètement managée où vous allez vous contenter, on va le faire tout à l'heure, de créer une table. C'est tout ce qu'on va faire. On va créer une table avec des attributs. On va définir les attributs importants pour cette table. On attend quelques secondes, la table est créée, et on peut commencer à faire put, get, etc. Donc là c'est vraiment le même niveau d'abstraction qu'S3. C'est-à-dire que dans S3 vous créez un bucket et puis vous écrivez vos objets dedans. Dans DynamoDB c'est du même ordre, vous créez une table et puis vous écrivez vos items dedans. Donc il n'y a vraiment aucune notion d'infrastructure dans DynamoDB. Il y a différents niveaux d'utilisation, on peut faire du key value, je vais vous le montrer. Donc des données vraiment très peu structurées, ça peut être des données de session, des cookies, des choses comme ça. On peut également stocker du JSON et on peut faire du stockage d'objets, au sens objet Java, et je vais vous montrer aussi comment le faire. On peut scaler DynamoDB jusqu'à des niveaux de scalabilité extrêmes, Amazon.com utilise DynamoDB en interne évidemment. Si vous êtes curieux, on a communiqué sur les chiffres d'utilisation de DynamoDB lors du dernier Prime Day. Vous trouverez l'article en ligne. Effectivement, on était en millions de lectures et écritures par seconde. C'était des chiffres vraiment incroyables. Dynamo est vraiment capable d'aller à des niveaux de performance très élevés. Expédia également utilise DynamoDB pour stocker tous les événements générés par ses A/B tests au quotidien, donc plus de 200 millions de messages et quand on fait des A/B tests, par définition on va générer beaucoup plus de données que d'habitude. On a envie d'effectuer beaucoup d'AB tests, on a envie de tester beaucoup de choses. Amazon le fait, Expedia le fait aussi. Donc on a des volumes de données qui sont vraiment énormes et sur lesquels ensuite on va vouloir appliquer des traitements pour comprendre justement est-ce que c'est le test A ou le test B qui était le meilleur. Et DynamoDB est une bonne plateforme pour faire ça. DynamoDB est vraiment beaucoup utilisé pour du stockage et pour de l'analyse de données non structurées. Plutôt que d'essayer d'aller les empiler dans une base relationnelle où le poids de la transaction, le poids de la relation va être trop important et finalement pas nécessaire, il vaut mieux aller écrire dans DynamoDB, scaler les écritures et puis ensuite scaler les lectures pour faire de l'analyse. C'est un cas d'utilisation qu'on voit souvent chez les clients. Alors je vais vous montrer les deux niveaux d'utilisation de DynamoDB. Donc d'abord le bas niveau qui s'appuie sur une API Key Value. Donc là on stocke vraiment des valeurs dans la table. Puis je vous montrerai après comment stocker des objets, des pojos dans DynamoDB. Donc ici je vais stocker, je ne vais pas utiliser mon dataset. Ici je vais utiliser des films. Chose que beaucoup de gens ignorent encore, de manière étonnante, c'est qu'il existe une version locale de DynamoDB que vous pouvez télécharger et installer, qui est bien pratique évidemment pour développer localement sur son poste sans avoir à se connecter à AWS, à tester, etc. Donc bien sûr elle n'a aucune des caractéristiques de scalabilité et de performance du service AWS, mais pour faire vos tests, c'est une bonne solution. Vous avez les infos sur cette page, et voilà comment vous pouvez le lancer. Moi, je vais me connecter au vrai DynamoDB, qui est en Irlande, pour cet exemple. Alors voilà ce qu'on va faire. En gros, je ne vais pas tout balayer, je vous laisserai regarder le code. Je vais juste vous montrer un ou deux exemples. Ça sera un peu long de lire tout ce code. Donc on va créer, je vais vous montrer comment on crée la table. Je vais vous montrer comment on fait un put et comment on fait un get. Et puis je vous laisserai lire le reste et puis me poser des questions sur Twitter ou ailleurs si vous en avez besoin. Donc on va créer la table. D'ailleurs, on va vérifier dans mon explorateur ici. Alors, on est bien, vous voyez, on peut choisir la région. Donc là, on est bien en Irlande. On va rafraîchir. Voilà, donc on voit, on peut voir les instances EC2, on peut voir les principaux services, on va dire AWS. Et donc, en ce qui me concerne, ok. Donc là, ma table DynamoDB, Movies n'est pas là. Donc, parfait. Donc on va la créer, on va ajouter des films, donc on va ajouter des films de Star Wars, on va en afficher un, on va en mettre à jour un, et puis ensuite on va faire des recherches, etc. Je vous donnerai quelques conseils pour faire ça. Donc voilà un peu ce qu'on fait. Alors commençons par la création de la table qui est sans doute l'opération la plus, à la fois la plus importante et la plus compliquée. Donc ça vaut la peine de passer un peu de temps. On est dans un environnement ici qui n'est pas un environnement SQL. Donc on ne va pas créer une table sur la base d'un schéma rigide, sur la base de relations, etc. Une table DynamoDB, c'est une abstraction qui va stocker des items. Qu'est-ce que c'est qu'un item ? Un item c'est un ensemble d'attributs. Par exemple pour le film ça va être le titre, la date de sortie, la note, la liste des personnages du film, etc. Si on définissait ça en SQL, on définirait une table, on définirait chacun des attributs, on les typerait, on créerait des clés, des relations, etc. Ici, on ne va pas faire ça comme ça. Ici, la seule chose qui est indispensable pour créer une table, c'est de déclarer un des attributs comme étant ce qu'on appelle la clé de hachage. C'est ce qu'on voit là. Ok, je vais surligner cette ligne. Cette clé de hachage, ici j'ai choisi le titre, c'est l'attribut qui va permettre de partager, d'étaler les insertions que vous allez faire sur la table entre les multiples nœuds de l'infrastructure DynamoDB. Parce qu'une des façons d'avoir de la performance, c'est de faire du scale out. Donc ici, on ne crée pas un serveur DynamoDB qui contient vos données, comme vous le feriez sur RDS, on se contente de créer une table, et les données de cette table, elles vont être étalées sur tous les nœuds de l'infrastructure DynamoDB. Ce qui va permettre, évidemment, de faire de la perf, et de ne pas être limité par la capacité d'un seul nœud. Et donc, j'insiste, cet attribut-là, c'est l'attribut qui va permettre de faire ce sharding, si vous préférez, des éléments sur l'infrastructure de DynamoDB. Donc il faut bien le choisir, parce qu'il faut qu'il soit suffisamment varié, suffisamment divers. S'il n'y a que 4 valeurs possibles pour cette clé, ça veut dire que tous vos éléments vont être étalés sur 4 nœuds, ce qui n'est pas la bonne solution. Donc il faut que ce soit quelque chose de très varié, avec une échelle de valeurs possibles, possible la plus importante possible. Bon, ici on est à toute petite échelle, ça a moins d'importance. Deuxième critère important pour choisir cet attribut, c'est que c'est l'unique attribut qui va vous permettre de faire des GET. C'est-à-dire que là, la seule façon d'aller récupérer mes FILM, c'est d'aller les chercher sur le titre. Donc je ne pourrais pas, en première analyse, si je me contente de faire ça, je ne pourrais pas lui dire « sors-moi le film qui est sorti en 1983 ». La seule clé d'accès à mes éléments, par défaut, c'est cette hash key. Donc ces deux raisons-là, la raison de sharder les éléments sur l'infra-dynamoDB et la raison de « je ne peux accéder à mes éléments que via cette clé » c'est vraiment les deux critères qui doivent vous faire réfléchir à quelle clé choisir. Ce n'est pas forcément simple, ce n'est pas forcément intuitif, je vous conseille d'aller plonger dans la doc dynamo db pour lire tous les conseils qui vous sont donnés. Ok, et une fois de plus c'est la seule chose que j'ai à fournir donc évidemment je donne un nom de table, je donne la hash key et c'est tout. Je pourrais m'arrêter là. Je donne des informations pour des indications de provisioning, donc quel volume de lecture, quel volume d'écriture je vais faire sur la table. Et ça c'est important parce que ça conditionne la facturation également. Alors ici, comme j'ai envie de faire plus que d'aller chercher mes items par titre, j'ai ajouté un index secondaire. C'est cette ligne que vous voyez là. J'ai créé un index qui s'appelle rating index, ici, et qui est défini ainsi. Donc lui, cet index, il a sa propre H key qui va être la note associée au film. Donc ça va me permettre de dire donne-moi tous les films notés trois étoiles, donne-moi tous les films notés une étoile, etc. Et puis, de manière optionnelle, je peux ajouter une range key qui va me permettre de trier et de lui dire « Je veux les films 3 étoiles qui sont sortis entre 83 et 89. » Ça va me permettre d'optimiser pour ça. Voilà comment on crée une table. On choisit un nom de table, on choisit une clé de hachage, on pourrait s'arrêter là. Et si on veut faire des accès et des requêtes sur... Une fois qu'on a fait ça, on crée la table, on attend quelques secondes qu'elle soit créée et on peut s'en servir. Ok ? Donc une fois qu'on a fait ça, on va regarder comment on fait un put. On va aller voir Add Movies to Table. Voilà, donc on va ajouter une série de films. Là, vous voyez, j'ajoute des attributs. Donc, bien sûr, le titre est obligatoire. J'ajoute la date de sortie, j'ajoute une note, j'ajoute une liste de personnages, etc. Mais l'avantage de Dynamo ici par rapport à une base relationnelle, c'est que, hormis la clé de hachage qui est indispensable, tous les autres attributs sont complètement optionnels. Dire que quand je crée ici, voyez, je crée mon item sur la base des paramètres qui sont passés. Le seul truc qui est vraiment indispensable, c'est la clé primaire, c'est la hash key. Tout le reste ce sont des couples de clés-valeurs des attributs. Donc, là, un attribut série, un attribut release date, un attribut rating, etc., mais qui sont optionnels. C'est-à-dire que je pourrais tout à fait avoir des films où je n'ai pas mis la liste des personnages. Je pourrais faire simplement New Item, mettre la clé primaire, mettre peut-être la date de sortie, et puis c'est tout. Donc il n'y a pas de schéma, donc on n'est pas contraint, on n'est pas obligé d'insérer des items qui ont tous les mêmes attributs. Ici, je le fais. En l'occurrence, il se trouve que tous les films n'auront pas le même nombre de personnages, mais j'ai cette flexibilité d'avoir des items qui ont peut-être des attributs supplémentaires par rapport à d'autres. Et l'insertion elle-même, elle se fait comme ça, donc sans surprise, c'est bien table.putItem et j'écris cet item, qui est un ensemble de couples attributs-valeurs, tout simplement. Alors je vais vous montrer comment on fait le get. On va faire print movie. Là, il n'y a pas de magie, c'est exactement ce qu'on pensait trouver. On fait table.getitem et on passe la clé de hachage. Une fois de plus, c'est la seule façon d'accéder à vos éléments. C'est avec la clé de hachage. Soit en faisant un get, soit en faisant des requêtes. Je ne rentrerai pas dans le sujet aujourd'hui. On a fait des webinars sur DynamoDB. On était rentrés dans les détails peut-être il y a deux ou trois mois. Donc, si vous voulez vraiment le détail complet de ce code, je vous renvoie sur ce webinar-là où j'explique les requêtes, etc. Ce qu'il faut retenir là, c'est très différent, ce n'est pas du SQL, mais on a une grande flexibilité, on n'est pas contraint par un schéma et on peut insérer et récupérer des éléments au gré des évolutions de format. Si j'ai envie soudainement de me mettre à insérer des films qui ont 10 attributs supplémentaires, ce n'est pas un souci, je le fais. J'aurai des films avec plus d'attributs, d'autres avec moins d'attributs, mais ce n'est pas grave. DynamoDB est capable de gérer ça. Alors on va l'exécuter. Donc on va devoir normalement voir la création de la table. Et j'ai manifestement un accès wifi qui est d'une lenteur atroce. Donc là, je crée la table, j'exécute cette requête que je vous ai montrée tout à l'heure. Donc là, je suis obligé d'attendre un petit peu, on va regarder dans l'explorer si on la voit arriver. Voilà, et on la voit là. Donc elle est en train d'être créée, ça ne va pas traîner, généralement c'est 10-20 secondes, un truc comme ça. Et c'est tout ce que je fais, je n'ai pas démarré de serveur, je n'ai pas démarré d'instance, je crée ma table, et puis ensuite je vais pouvoir continuer à exécuter le reste de mes appels. Donc les insertions, on va remonter sur le... Voilà. Sur ça, alors elle arrive cette table. Ah, ça y est, voilà. Ok, donc la table est créée. Voyons, on va dire 30 secondes, un truc comme ça. Ok, je décris la table, donc je vois ses attributs. J'ajoute mes items. Je les récupère. Ok. J'affiche tous les films 5 étoiles, manifestement. Oui, ça doit être celle-là. Donc là, je suis capable de faire une requête parce que j'ai rajouté un index qui me permet de chercher mes items autre chose que le titre, en l'occurrence ici sur la note. Je peux effacer les mauvais films, m'assurer que les mauvais films ont disparu, etc. Une fois de plus, si vous voulez tout le détail de tout ça, je vous renvoie sur les webinars Dynamo qu'on avait fait. Vous voyez cette API bas niveau, elle est vraiment bas niveau, c'est-à-dire que ici je manipule quelque chose qui est quand même, ça relève de l'objet métier, c'est un film, donc il y a quand même une entité qui est là, mais je la manipule uniquement comme une collection de couples clé-valeurs. Et c'est une API qui est un peu plus compliquée, un peu plus précise. Il y a un deuxième niveau d'utilisation, qui est de se dire, moi finalement, ce que je veux c'est stocker des objets métiers, ici c'est des films, j'ai défini ma classe, j'ai une classe qui s'appelle DynamoDB Movie, et puis elle a des attributs, il y a un titre, il y a une release date, etc. Et c'est ça que j'ai envie d'écrire dans Dynamo. J'ai envie de pouvoir faire load et save sur des objets, et pas sur des attributs. Est-ce qu'on peut faire ça avec Dynamo ? Alors la réponse est oui. Il suffit de prendre votre classe Java telle quelle, votre Pojo, et puis de la noter en disant, voilà, la hkey pour cette classe, ça va être le titre, la hkey de l'index, ça va être la note, la rangekey de l'index, ça va être la release date, donc on retrouve exactement les mêmes concepts que j'ai montré tout à l'heure, mais cette fois, je me contente de rajouter des annotations dans une classe Java, ok, je définis le nom de la classe dans laquelle ces entités qui vont être stockés, et c'est tout. Donc si vous avez l'habitude de travailler avec des ORM, du Hibernate, ou des choses comme ça, en Java et en d'autres technos, c'est le même principe, la seule différence étant que je ne peux pas appeler ça un ORM, parce que le R de ORM c'est Relational, et là il n'y a pas de relation, on reste sur une base de NoSQL. Mais vous voyez que par le jeu de quelques annotations, on va pouvoir stocker nos objets. Alors comment est-ce que ça se passe ? On va utiliser un objet qui s'appelle le DynamoDB Mapper. Si j'arrive à l'ouvrir... Donc là, cette fois... Alors on reprend à partir de là, on va refaire un clap. Voilà le sample pour le DynamoDBMapper, donc je me connecte à la région, je me connecte à la région et toujours EU-West, je vais créer cet objet DynamoDBMapper, et un des trucs sympas c'est que finalement je vais pouvoir réutiliser la table existante, ça aurait été du tout. Dommage que les deux API bas niveau et haut niveau ne soient pas compatibles. Donc ici la table a déjà été créée, donc je ne vais pas la créer. Je vais juste afficher la requête de création pour voir effectivement que les informations sont les mêmes, mais je m'appuie sur la table qui existe déjà. Et je vais donc ajouter un film supplémentaire et le recharger. Ok ? Alors on va exécuter ça et puis on va vérifier après que ça a fonctionné. Ok. Donc là, je vois ma requête de création qui est tout à fait la même que ce que j'aurais fait tout à l'heure. Cette requête-là, en fait, elle est générée sur la base des annotations que j'ai mises dans la classe DynamoDB Movie. Donc ça, c'est aussi un des avantages du DynamoDB Mapper, c'est que vous allez pouvoir, le simple fait d'annoter la table, ça va vous donner la requête de création de la table dans Dynamo. Donc ensuite j'ajoute le film, je le réaffiche, etc. Et j'affiche tous les films 5 étoiles. Alors évidemment ce qui est intéressant c'est de voir comment j'ai fait ça. Et donc je vois que, alors ici je passe les différents attributs de l'objet, j'instancie ma classe dynamo db movie puis je fais mapper.save(movie) voilà et là j'ai écrit mon film. Donc voyez là cette fois c'est bien un objet que j'écris et pour le récupérer, je crée une nouvelle instance de dynamo db movie, je lui passe la clé, qui est toujours le titre ici, qui me permet d'aller chercher l'objet. Et je récupère mon film. Vous voyez là cette fois les API sont beaucoup plus directes, c'est load save et au lieu de travailler sur des clés valeurs, on travaille sur les objets. Donc beaucoup plus simple. Vous pouvez utiliser Dynamo sur ce modèle type ORM mais un petit peu différent. Ok, allez, assez parlé de Dynamo, mais c'est un de mes sujets favoris. On va revenir sur notre dataset de départ et on va parler d'analytics. On a dit qu'on parlerait de Hive, on parlerait d'Athena et on parlerait de Redshift. Commençons par EMR. EMR, vous le connaissez, c'est l'environnement managé Hadoop qui vous permet d'exécuter MapReduce, Spark, Hive, etc. Service managé qui vous permet aisément de créer un cluster. Vous choisissez un type d'instances, un nombre de noeuds, etc. Et donc vous pouvez les démarrer, les arrêter, les redimensionner à chaud, etc. Plein d'avantages par rapport à installer manuellement des clusters Hadoop ou Spark évidemment. Alors pour vous montrer à quel point nos clients profitent de l'élasticité de MR, voilà un exemple qui est le plus gros régulateur privé du marché des marchés financiers américains. Ils observent toutes les transactions qui sont faites sur les marchés d'actions et d'options pendant la journée et des ingères, et ensuite la nuit ils font tourner des jobs d'analyse de machine learning pour détecter les problèmes, détecter les choses suspectes voire illégales, et ensuite ils les signalent aux autorités de régulation. Donc leur problématique est intéressante parce que pendant la journée, ils font quasiment exclusivement de l'ingestion, et par contre la nuit, il faut qu'ils fassent tourner les jobs quand le marché est fermé et il faut qu'ils observent ce qui se passe. Et ils utilisent EMR pour la majorité de ces traitements et ils montent jusqu'à 10 000 noeuds. Donc en journée, ils n'ont pas besoin de beaucoup d'infrastructures, donc les clusters sont éteints. Lorsqu'ils ont besoin de les lancer, ils les démarrent, ils les scalent très très haut, 10 000 nœuds, c'est énorme, ils font les gros travaux d'analyse de données, ils récupèrent les résultats et ils éteignent les clusters. Et sur ce projet là spécifiquement, FINRA a dit qu'ils économisaient plus de 20 millions de dollars annuellement grâce à l'élasticité en particulier de MR. Vous imaginez le coût d'un cluster Hadoop de 10 000 nœuds s'il fallait le construire et l'opérer soi-même. On va faire une petite démo avec Hive, qui est donc la base de données, je mets des guillemets autour de ça, la base de données d'Hadoop. On va aller dans notre code Hive. Il y a une petite différence par rapport au reste, c'est qu'on va se connecter, et j'espère que je vais réussir à le faire. Sinon, c'est pas grave, on va trouver d'autres moyens de montrer le code. Parce que là, c'est réellement compliqué à utiliser. On va utiliser Hive, on va s'authentifier sur Hive avec un tunnel SSH qui est toujours là, donc il n'y a pas de login et password sur Hive. On monte un tunnel SSH vers le cluster et le fait de s'être authentifié avec la bonne clé SSH vaut pour authentification. Bon, et je crois que je n'y arriverai pas, c'est embêtant, je suis obligé de rebooter ma machine, c'est la catastrophe. Première fois que ça me fait ça. J'ai plus la main du tout. Ok. Hugo, je sais pas, qu'est-ce que tu veux faire ? Je suis désolé, mais là je travaille par la technique. Donc ça marchait évidemment parfaitement bien tout à l'heure, c'est comme d'habitude. Mais j'ai l'impression que c'est OBS qui bouffe tout, je ne comprends pas ce qu'il se passe. J'arrive même pas à voir le moniteur d'activité, c'est généralement pas bon signe. Ouais là ça a l'air... Bon. Ça a l'air compliqué. Sincèrement Hugo, je proposerais bien d'arrêter là, parce que je vois pas comment je vais m'en sortir. Je ne vois pas comment je vais m'en sortir. Donc ce que je propose, je vais essayer de le relancer une dernière fois. On fait un dernier essai. Si ça ne marche pas, on va s'arrêter là. Et ce n'est pas grave, je réenregistrerai le bout qui manque. Et puis Hugo fera du copier-coller vidéo. Et voilà. Là, ça a l'air mort de chez mort. Ok. Incroyable. Bon. Donc, on va prendre les questions. On va prendre les questions. Et puis, on fera... C'est pas grave. On fera des copiers-coller de vidéos un peu plus tard. Désolé, mais là, je suis incapable de continuer. Je sais pas si c'est... Je ne sais pas si c'est OBS qui est mon enregistreur vidéo. Je ne sais pas. Alors... En avant, donc j'ai les questions sous les yeux. Alors il y a une question de Mohamed qui est intéressante sur Dynamo. Au cas où on a beaucoup de données initiales à charger, est-ce qu'il y a un mode batch ou une utilisation ETL ? Alors non, il n'y a pas... Dans Dynamo, il y a vraiment l'API telle que je vous l'ai montrée. En revanche, on peut interfacer d'autres services avec Dynamo. On peut interfacer Data Pipeline, par exemple, ou on peut interfacer Glue, qui est un nouveau service d'ETL. Et donc, on peut, via ces outils-là, faire du chargement de données. Mais avec les API Dynamo, direct, bien sûr, vous pouvez charger vos données et puis faire des put dans Dynamo à la volée. Bon maintenant effectivement si vous avez des gros volumes, c'est pas pratique donc il vaut mieux passer par Data Pipeline, Glue, ils vont vous permettre de faire ça. Ok, alors je vais essayer, on va essayer une dernière fois. Ah, allez on essaie de l'exécuter. Donc on a le tunnel SSH, il est toujours là. Ok, donc on va appeler une API pour décrire le cluster. Et puis on va exécuter notre requête. Et là, c'est toujours une connexion. Vous avez vu, je suis passé vite. C'est toujours une connexion JDBC avec un driver Hive. C'est du SQL à peu près standard. Ici, c'est une requête très simple. Donc en avant. All Lakers. Et pendant qu'il fait ça, on va continuer à répondre aux questions. Alors, en question de Frédéric, est-ce que les données dans DynamoDB sont chiffrées ? Oui, on les chiffre avec KMS, c'est toujours le même fonctionnement. Donc, vous pouvez utiliser une clé KMS pour chiffrer les données qui sont au repos dans Dynamo. Alors je continue à regarder les questions. Alors encore une question de Mohamed. Pour les données de session, comment est-ce qu'on comparerait ElasticCache et Dynamo ? Alors c'est une bonne question. ElasticCache, c'est un service managé qui permet de faire soit du Memcache, soit du Redis. Alors, c'est effectivement du clé-valeur. L'avantage de Dynamo, c'est que l'infrastructure est complètement managée. Là où dans ElasticCache, vous gérez quand même le cluster donc vous devez quand même créer votre cluster, le dimensionner, etc. Donc c'est je dirais avec ElasticCache, on a une vision plutôt un peu comme EMR, un peu comme RDS où on doit quand même choisir le nombre d'instances, la taille d'instances, etc. Donc il y a cette question de sizing qui se pose. Et puis, je pense que dans DynamoDB, il y a quand même cette capacité à requêter, à créer des index, etc., qui n'est pas présente dans ElasticCache. Donc, pour des données qui sont vraiment hyper fines, hyper atomiques, effectivement, des cookies, des trucs comme ça, on pourrait dire qu'on les met dans ElasticCache, on va avoir un stockage et un accès un petit peu plus rapide, un petit peu plus, sans doute un petit peu plus rapide que DynamoDB. Quoique maintenant, avec DynamoDB, il y a quelques mois, on a lancé un service qui s'appelle le DynamoDB Accelerator qui permet de mettre des nœuds de cache devant Dynamo et où finalement on arrive à des latences qui sont en microsecondes, là où la latence typique de Dynamo est plutôt en millisecondes. Donc si on combine DynamoDB, DynamoDB Accelerator, on arrive à des perfs qui sont extrêmement proches de perfs qu'on pourrait avoir sur des caches. Après, ça dépend, si on est très familier de Memcache ou de Redis, on a plutôt envie d'utiliser l'ElasticCache. Si on a une échelle, un volume de données gigantesque, il y a des clients qui ont des centaines de terabytes dans Dynamo. On n'imagine pas mettre des centaines de terabytes dans Memcache ou dans Redis. En tout cas, moi, je ne l'imagine pas. Donc, je pense qu'il y a ça aussi. Il y a le côté échelle. Petite échelle, scalabilité, bien comprise, bien maîtrisée. Pourquoi pas utiliser ElasticCache ? Très, très gros besoin de scalabilité avec des pics très violents, des données peut-être petit peu plus compliquées qu'un simple cookie avec des besoins de requêtage, des besoins d'analytique, etc., des besoins d'index, à ce moment-là plutôt Dynamo. Ok, alors on a réussi à exécuter notre code. Alors ça a pris du temps, c'est pas là pour le coup c'est pas parce que c'est mon bac qui râpe, c'est parce qu'on est sur Hive et que exécuter des requêtes sur Hive, ce n'est pas la chose la plus rapide du monde. Alors on peut le faire bien sûr, mais vous voyez que ça prend du temps. Donc ça prend cette requête là, qui est pourtant assez simple, qui est un simple select. Elle prend quand même quasiment une trentaine de secondes. Pour autant, on arrive à le faire. On se connecte en JDBC, on exécute notre SQL, etc. Donc voilà, on peut évidemment faire ça sur RDS. Mais ce n'est pas forcément la meilleure solution. Alors on va regarder, je crois que je vais... Je vais voir si je peux juste... Je suis vraiment, vraiment, vraiment mal. Non, là, j'ai plus rien. Bon, j'ai plus la main. Ok, allez, on va continuer avec les questions. Puis je vais rebooter tout ça. Alors... Qu'est-ce qu'on a d'autre comme question ? Hugo, s'il y en a d'autres, vas-y, tu peux envoyer. Ah, il y a Jérôme qui est là. Salut Jérôme. Alors, lambda, PHP, je ne sais pas. Mais bon, j'ai envie de dire, il y a des keynotes demain et après-demain. Donc, tous les espoirs sont permis. Allume un cierge. On ne sait jamais. Euh... Alors, Fred repose des questions sur le chiffrement. Une fois qu'on a chiffré les données, le chiffrement KMS est transparent, donc on l'active, et après c'est le SDK qui va gérer le chiffrement et le déchiffrement à la volée. Donc il y a un petit peu de code à rajouter dans l'appli, mais pas grand chose. Donc on peut continuer à fonctionner normalement. Qu'est-ce que j'ai d'autre comme question ? Alors, il y a une question sur le SLA. Il y a une question sur le SLA RDS. Le 99-95, est-ce que c'est sur une seule instance ou est-ce que c'est en multi-AZ ? Ça, c'est une bonne question. De mémoire, je pense que c'est mono-instance, d'autant plus qu'il y a une semaine, on vient d'annoncer sur EC2 que le SLA EC2 passait à 99,99. Je ne sais pas si vous l'avez vue, cette info est super importante. Je m'attends à ce que le SLA RDS soit lui aussi upgradé, on verra. Je ne sais pas si c'est une des annonces qu'on fera ces jours-ci. Mais bien sûr, si vous faites du multi-AZ, là vous montez encore en haute disponibilité. Mais même en single instance, vous pouvez avoir un niveau de disponibilité qui est élevé. Bon, on va s'arrêter là. Je suis vraiment désolé pour les problèmes techniques. Je vais me déconnecter et je vais rebooter tout ça. Et puis j'espère que je n'aurai pas ce genre de souci pour le deuxième. Et puis on essaiera de faire un peu de remise en forme et de remettre les morceaux qui manquent. Voilà, je m'occupe de tout ça et à tout de suite. Merci.