Bonnes pratiques Big Data sur le cloud AWS

Transcript

Bonjour, bienvenue pour une nouvelle après-midi de Webinar AWS. Aujourd'hui, nous allons parler de Big Data. Exceptionnellement, nous enregistrons ces Webinars à l'avance car je suis en déplacement à la date initialement prévue. Mais n'hésitez pas à poser vos questions pendant le déroulé du webinar. Je ferai le maximum pour me connecter pendant la session et répondre à vos questions dans le chat. Au programme de cet après-midi, nous commencerons par une présentation générale des services Big Data disponibles sur AWS. Puis, dans le deuxième webinar, nous ferons une Big Data Battle. Nous comparerons les performances de plusieurs services en direct sur le même dataset. Ne ratez pas cette deuxième session. Mais commençons donc par l'introduction et par le panorama du Big Data et des services disponibles sur AWS. Nous allons commencer rapidement par rappeler les problèmes qui sont spécifiques au Big Data, que vous connaissez certainement déjà. Nous parlerons de quelques principes d'architecture. Nous verrons comment essayer de poser un cadre relativement simple sur le Big Data que nous utiliserons tout au long de cette présentation. Bien sûr, nous parlerons beaucoup des différentes technologies et des différents services qui sont disponibles sur AWS. Je vous montrerai une architecture de référence et quelques schémas d'architecture, quelques patterns que vous pourrez réutiliser dans vos propres plateformes. La big data, on peut en donner de nombreuses définitions. Il y en a une qui est devenue célèbre, celle des 3V. Ce qui caractérise le big data, c'est le volume, la quantité de données qui ne cessent d'augmenter chaque jour. La vélocité des données, c'est-à-dire la rapidité avec laquelle cette donnée s'accueille. De plus en plus de flux de données sont des flux temps réel et non plus des flux batch ou des flux périodiques, et donc ça pose un tout un tas de problèmes. Enfin, le troisième V qui est la variété, qui définit la grande quantité de formats différents sous lesquels la data peut vous arriver, structurée, non structurée, textes, binaires, etc. Ces trois V sont la définition, on va dire communément acceptée du Big Data. Lors de l'émergence du Big Data au milieu des années 2000, on était plutôt sur des traitements batch, sur du traitement tous les jours ou quelques fois par jour, d'une quantité de données plutôt non structurées, des logs web, des choses comme ça. Progressivement, on est passé à des traitements de flux de plus en plus temps réel, avec un travail en continu sur la data et non plus quelques fois par jour. Maintenant, on a ajouté des notions de machine learning pour non seulement agréger la donnée, la traiter, mais aussi en tirer des conséquences et des prédictions, le plus souvent en temps réel. Bien sûr, au fil du temps, les services cloud ont évolué de la même façon. Au début du cloud, on s'appuyait plutôt sur des machines virtuelles, puis progressivement sur des services managés, et depuis un an ou deux, le serverless est en train de prendre un essor important. On voit finalement que, autant pour la partie big data pure que pour son socle infrastructure, les choses n'ont cessé d'évoluer depuis des années. Et bien sûr, tout ça nous a amené à utiliser, que ce soit dans le cloud ou ailleurs, une quantité invraisemblable d'outils et de services. L'écosystème Hadoop s'est enrichi au fil des années de nombreux ajouts, et d'autres projets en dehors de l'écosystème Hadoop ont fait leur apparition. De manière symétrique, au sein du cloud AWS, on a vu apparaître un grand nombre de services liés à l'analytique de manière générale et de plus en plus spécialisée pour le Big Data, le machine learning. Aujourd'hui, tout ça crée évidemment de la complexité et suscite tout un tas de questions chez les développeurs et chez les utilisateurs. Et c'est à ces questions que nous allons essayer de répondre aujourd'hui. Les challenges du Big Data sont liés à ce que je viens de dire. On est passé d'une situation où Hadoop a émergé en 2006 à aujourd'hui, dix ans après, des dizaines d'outils différents et une complexité importante. La première question que tout le monde se pose, c'est bon, est-ce qu'il y a une architecture de référence ? Est-ce qu'il y a une façon acceptée, un peu standard de faire les choses ou pas ? La deuxième question, c'est de se dire, parmi tous ces outils, lesquels dois-je utiliser et lesquels sont les plus adaptés à mon application et à mon business ? En supposant qu'on ait réussi à répondre à cette question, se pose ensuite la question de comment les mettre en place, comment les déployer, comment les monitorer, comment les opérer, etc. Il y a aussi cette question souvent occultée : le Big Data n'est pas une fin en soi. Le Big Data doit être piloté par une réflexion d'entreprise, une réflexion sur l'utilisation des données à des fins business et pas juste pour se faire plaisir. Faire du Big Data pour faire du Big Data n'a pas beaucoup d'intérêt. Faire du Big Data pour améliorer une expérience utilisateur, l'efficacité de l'entreprise, c'est ça qu'on doit viser. Il ne faut jamais perdre de vue la question à laquelle on essaie de répondre. Les grands principes d'architecture qui vont nous guider pendant cette présentation sont les suivants. Le premier, et c'est sans doute le plus important, c'est de construire des systèmes découplés, de bien séparer les différentes étapes d'un projet Big Data. De la collecte de la donnée à son stockage, à son traitement, parfois à nouveau à son stockage sous une forme agrégée, puis ensuite son analyse, son exploration pour obtenir les réponses que l'on recherchait. Cette notion de découper et de découpler les systèmes est extrêmement importante et c'est ça qui va nous permettre de réduire la complexité. Le deuxième point important, c'est d'utiliser le bon outil pour la tâche qu'on essaie d'accomplir. Vous allez voir, il y a plein de cas particuliers, plein de cas très différents, plein d'outils très différents. En aucun cas, il n'est possible d'avoir un seul outil pour répondre à tous ces besoins. C'est une erreur sans doute assez grave que vous feriez en adoptant cette posture. Le troisième point important, c'est de réduire la complexité et de se concentrer sur le projet lui-même et pas sur la plomberie. Les services AWS, les services managés AWS, ont leur importance puisqu'ils vont prendre en charge la scalabilité, la disponibilité, la sécurité, etc. Ils vont vous décharger des tâches d'infrastructure à faible valeur ajoutée et vous permettre de vous concentrer sur la résolution du problème, sur la réponse à la question. Une autre bonne pratique est de travailler sur des données immutables, c'est-à-dire de garder votre donnée brute à un endroit central, de ne pas la modifier. Ainsi, vous pourrez la transformer de manière répétée dans des formats différents, l'agréger dans des dimensions différentes, surtout conserver la donnée brute et à partir de là construire des vues ou des transformations avec les différents outils qu'on va voir aujourd'hui. Le dernier point qui a son importance est de faire attention aux coûts. Le Big Data ne veut pas dire forcément des coûts très importants. C'est aussi souvent une erreur qu'on voit malheureusement. Les gens pensent que les projets Big Data sont extrêmement coûteux parce qu'ils nécessitent beaucoup de techno, beaucoup d'infra, etc. Et ce n'est pas forcément le cas. Si vous respectez bien les principes dont je viens de parler et que vous utilisez l'élasticité du cloud, vous pouvez arriver à des coûts qui sont parfaitement raisonnables et maîtrisés. L'approche qu'on va avoir aujourd'hui est vraiment une approche très simple : « j'ai des données et je veux utiliser ces données. » En fait, j'ai même des questions que je me pose sur ces données et je veux répondre à ces questions. Pour cela, il va falloir que je collecte la donnée, que je la stocke, que je l'analyse, que je la consomme ou que je la visualise. Il est très probable que je doive passer à travers plusieurs cycles d'analyse et de stockage de données intermédiaires pour trouver la réponse. Les paramètres importants de ce pipeline qui vont dicter les choix de techno sont la latence que vous pouvez accepter entre l'analyse et la réponse. Est-ce que vous pouvez attendre une heure, une journée ? Ou est-ce qu'au contraire, il faut que ce traitement soit le plus temps réel possible ? Quel est le débit ? Quel est le volume de données que vous faites entrer dans le pipeline ? Est-ce qu'on parle de quelques kilo-octets par minute ? Est-ce qu'on parle de mégaoctets, de gigaoctets ? Est-ce qu'on parle de dizaines de téraoctets par jour ? Les solutions à mettre en place ne seront pas les mêmes, évidemment. Et puis, une fois de plus, le coût. Quel est le coût que vous êtes prêt à associer à ce projet ? Nous allons étudier ces différentes phases du pipeline. Nous allons commencer, évidemment, par la phase de collecte. La phase de collecte, c'est la phase que vous maîtrisez le moins, c'est celle qu'on peut probablement même vous imposer puisque les données que vous allez collecter vont certainement provenir en grande partie du monde extérieur. Elles vont provenir des applicatifs de vos clients ou des terminaux mobiles de vos clients, de fournisseurs de données, de partenaires. Les données vous arrivent dans un format qui est leur format natif, et il faut que vous vous adaptiez. La première catégorie de données que vous pouvez être amené à collecter sont des données de type transactionnel, donc des données structurées, bien définies, qui seront souvent des données venant de bases de données. La deuxième catégorie sont des données au format fichier, donc là ça peut être des fichiers log, des logs web, des logs d'application, des documents que vous êtes amenés à indexer et dans lesquels vous allez faire des recherches. Et puis la troisième catégorie sont des événements. Ça peut être aussi bien des messages que des flux, en particulier si vous travaillez dans le monde de l'IoT, où là vous pouvez être amené à gérer un très grand nombre de flux, chacun ayant sans doute un très faible débit. Mais évidemment, les petits ruisseaux font les grandes rivières et au final ça peut être un volume de données extrêmement important. Vous devez avoir un ensemble de technologies qui vont vous permettre de collecter ces différents types de données. Un paramètre vraiment important dont on parlera de manière répétée, c'est ce qu'on appelle la température des données. La température des données est un paramètre qui va être associé à l'usage que vous allez en faire. Prenons les données chaudes. Les données chaudes sont des données sur lesquelles vous voulez une latence très faible, c'est-à-dire que vous voulez pouvoir y accéder en millisecondes avec un nombre de requêtes par seconde très important. Ce sont vraiment les données critiques, temps réel de votre application. La plupart du temps, on parle de volumes relativement faibles et de tailles unitaires relativement faibles, mais par contre, on veut pouvoir y accéder à un débit très soutenu et avec une latence extrêmement faible. Les données tièdes, appelons-les comme ça, seront intermédiaires. Ce sont des données dont vous avez besoin en quelques secondes, qui sont des données plus pérennes, que vous allez vouloir garder plus longtemps, qui seront des données de travail de vos applications. Là, on sera plutôt dans les bases de données ou dans les logs. Et puis les données froides, qui seront la plus grosse quantité, en tout cas la plus grosse partie quantitativement, où là on trouvera toutes les archives, tous les logs historiques, toutes les données empilées depuis des mois voire des années. On peut avoir des quantités énormes de données. On veut évidemment les garder très longtemps, c'est la mémoire de l'entreprise, la mémoire des applications, mais au jour le jour, on s'en sert finalement assez peu, on les requête assez peu, et lorsqu'on le fait, on est prêt à attendre un petit peu pour y avoir accès. Voilà les trois grandes catégories. Évidemment, il y a tout le spectre entre ces extrêmes. Mais vous verrez que ce paramètre de température de données est vraiment important. Une fois que vous avez collecté les données, il s'agit maintenant de les stocker. Nous allons reprendre les catégories dont on parlait tout à l'heure. Commençons par les données les plus chaudes, qui vont provenir le plus souvent d'applications web ou mobile, qui seront des données de cache vraiment des données que vous allez stocker en mémoire. Ce sont vraiment les données les plus chaudes de votre application, vous voulez la latence la plus faible, le débit le plus élevé, et donc vous ne pouvez pas envisager de les stocker sur disque. Juste en dessous, on aura les données en base de données, donc les données transactionnelles, où là aussi, on veut un nombre de garanties de requêtes par seconde. On veut une bonne durabilité. On a des données plutôt structurées et on s'orientera vers des bases de données SQL ou NoSQL. Ensuite, continuons pour les données de type log, généralement on les indexera et fera des recherches, donc on s'orientera vers un back-end qui aura cette capacité. Pour les fichiers, les vrais fichiers à proprement parler, les logs web, les logs applicatifs, etc., on s'orientera vers un stockage de type file system ou stockage d'objets. Pour les messages, sans surprise, on s'orientera vers les files de messages, on verra lesquels sont disponibles. Et puis pour les flux, où là vraiment on parle d'un très grand nombre de flux, avec une granularité très faible et un côté temps réel très important, on restera sur des files de messages mais vraiment spécialisés sur le traitement de flux. Nous allons rentrer dans les détails. Commençons par les flux, par les messages. Pour les messages, il existe un service qui est disponible depuis longtemps qui s'appelle SQS, qui est l'un des plus vieux services d'AWS, Simple Queue Service, un service managé pour les files de messages, et qui répond bien à des problématiques d'application traditionnelles qui ont besoin de s'échanger des messages. Avec un nombre de messages par seconde raisonnable, des tailles de messages raisonnables, un nombre d'acteurs communiquants raisonnable. On est dans le passage de messages entre applications. Pour ce qui est des flux, où là on pourrait parler de millions de devices, de millions de capteurs IoT qui s'échangent des milliards de messages par jour, peut-être des messages de quelques octets mais en très grande quantité, SQS n'est pas vraiment adapté, il faut aller vers d'autres technologies. Il y a un produit open source qui s'appelle Kafka qui répond bien à ce besoin. AWS propose un service qui s'appelle Kinesis, qui est un service managé qui est équivalent à Kafka, donc qui va gérer des files de messages, qui va persister les messages, etc., et qui est extrêmement scalable. On a une abstraction de plus haut niveau sur Kinesis qui s'appelle Firehose, qui permet de manière assez simple de déplacer des données entre des services AWS avec moins de flexibilité et moins de complexité que Kinesis Streams, mais intéressant dans des cas un peu plus simples. Et puis bien sûr, on a toujours DynamoDB, qui est le service managé NoSQL d'AWS, et qui permet de stocker des données de type clé-valeurs, sur lesquelles on peut activer des streams, afin de déclencher, par exemple, une fonction lambda à chaque mise à jour, ou au bout de n mises à jour dans une table DynamoDB. Cela peut être un mécanisme intermédiaire pour stocker des données clé-valeurs de manière pérenne dans Dynamo, tout en ayant des traitements temps réels déclenchés par les streams DynamoDB. L'avantage d'avoir des streams, c'est de dire qu'on peut avoir un immense nombre de producteurs de données, auxquels correspond un grand nombre de consommateurs. Il faut pouvoir avoir un mécanisme qui est capable d'accepter une volumétrie très importante en entrée, un grand nombre de clients, tout en garantissant que les messages ne soient pas perdus et ne soient consommés qu'une fois. C'est un des avantages de Kinesis, qui découple complètement les producteurs et les consommateurs. Les producteurs écrivent le message dans le flux et reprennent la main automatiquement, ils font autre chose. Les consommateurs de l'autre côté lisent les messages à leur rythme, à leur vitesse, ils peuvent lire dans plusieurs flux différents, c'est flexible, l'ordre des messages est préservé, on peut avoir de la consommation en parallèle sur les différents flux, et puis on a des flux persistants puisque Kinesis peut garder les messages jusqu'à 14 jours. Même si tous les consommateurs s'arrêtent de travailler, on a la garantie qu'on ne perd pas les messages. SQS, c'est un cas plus simple. SQS peut avoir plusieurs producteurs. Il y a aussi une persistance des messages. Mais l'ordre des messages par défaut n'est pas garanti, et on ne peut pas faire de consommation en parallèle sur SQS. Donc c'est un seul consommateur à la fois qui va lire dans une file. Depuis peu, on a introduit une file FIFO qui permet de garantir l'ordre des messages, mais c'est vraiment un feature qui est encore tout récent. Certes, on ne peut pas faire de consommation parallèle, mais on peut avoir du déclenchement en parallèle de clients sur une file SNS. Donc on peut déclencher plusieurs lambdas, on peut faire plusieurs choses comme ça. Néanmoins, c'est quand même un schéma qui est moins flexible, qui est sans doute moins scalable aussi que Kinesis. Pour résumer, pour des problématiques d'application traditionnelles, d'échanges de messages traditionnels, SQS est très simple et convient parfaitement bien. Dès qu'on parle de flux temps réel avec un très grand nombre de producteurs, de consommateurs et un grand besoin de parallélisme, il vaut mieux utiliser Kinesis. Voilà un petit résumé des capacités de chaque système. Rassurez-vous, je ne vais pas tout lire, j'ai déjà détaillé certaines des différences entre ces systèmes. Vous lirez tout ça à tête reposée, et n'hésitez pas à me poser vos questions si vous en avez. Pour les messages et les flux, remontons d'un cran, parlons des fichiers. Je dirais que c'est sans doute le cas le plus simple où évidemment on va stocker tout ça dans S3. Pourquoi S3 est-il adapté au Big Data ? On pourrait en parler longtemps, mais la disponibilité et la durabilité de S3 sont très bonnes. On peut en confiance y stocker toutes ces données et les retrouver lorsqu'on en a besoin. Il n'y a aucune limite de stockage sur S3. Vous pouvez stocker des centaines de pétaoctets si vous en avez besoin. C'est du stockage sans limite, donc c'est bien adapté pour de grandes quantités de données. Et puis, on en parlera tout à l'heure, S3 peut servir de point de stockage et de point de lecture pour les différents back-ends d'analyse d'AWS, que ce soit EMR, Redshift, etc. C'est vraiment le point stockage central à partir duquel les back-ends vont venir lire les données, les travailler, etc. Voilà, vous connaissez tous S3, vous l'utilisez tous, et c'est vraiment l'option la plus évidente pour stocker toutes vos données. Se pose quand même la question de quid d'HDFS là-dedans. HDFS est le file system d'Hadoop, c'est le file system qui sera disponible sur vos clusters EMR. Donc, qu'est-ce qu'on fait ? Qu'est-ce qu'on stocke dans S3 ? Qu'est-ce qu'on laisse sur HDFS ? Mon opinion est de laisser tout dans S3. Et puis, lorsque pour des raisons de performance, vous avez envie d'avoir les données localement présentes sur votre cluster, vous pouvez les charger très facilement avec les connecteurs qui sont disponibles dans EMR. Travailler localement, faire travailler vos nœuds localement sur le cluster, le dataset, et puis ensuite faire de la place, mais il ne faut surtout pas rajouter des nœuds dans le cluster EMR uniquement parce que vous avez besoin de stockage. C'est dommage, c'est coûteux, et il faut vraiment avoir le minimum de choses dans HDFS, ce dont vous avez besoin à l'instant T, et ce qui est dans S3 et auquel vous accédez finalement très peu, n'hésitez pas à l'envoyer dans Glacier, qui est le service d'archivage, qui vous permet là aussi d'archiver l'immense quantité de données et de les récupérer en 3 ou 4 heures. Inutile de garder dans S3 des choses qui servent peut-être une fois par an, voire encore moins. Continuons à explorer les services de stockage. Parlons maintenant de la recherche, des bases de données et des caches. Dans ce cas-là, il faut vraiment sauter à la tête que une seule solution ne conviendra pas à tout. Malheureusement, je crois encore des gens qui pensent qu'on peut répondre à tout ça avec un seul back-end. Malheureusement, la réalité est tout autre. Il faut vraiment ne pas chercher à faire rentrer ce type de données, en particulier dans une base de données relationnelle. On peut faire du clé-valeur dans une base de données relationnelle, mais ce n'est pas la meilleure solution, ça ne scalera pas, c'est coûteux, vous allez payer le coût de la transaction systématiquement, alors que vous n'en avez sûrement pas besoin, etc. S'il vous plaît, ayez l'esprit critique et ne tombez pas dans le schéma du couteau suisse universel qui est séduisant, amusant, qui paraît peut-être plus simple au début et puis ensuite qui vous décevra parce qu'en fait, il sait rien vraiment faire de très bien. Il faut vraiment avoir une palette d'outils et spécialiser chacun sur un cas d'utilisation. Pour ce qui est des données en mémoire, les données les plus chaudes, les données brûlantes, celles que vous voulez accéder en moins d'une milliseconde, à peut-être des centaines de milliers d'appels par seconde, là vous devez absolument vous orienter vers le service ElastiCache, qui est un cache managé qui supporte Redis. Ces caches vous permettent de faire du clustering, du backup, du resizing et qui vous déchargent de la complexité de gérer ces clusters. Ensuite, pour des données semi-structurées ou structurées, vous pouvez choisir parmi des technos NoSQL ou SQL. Là aussi, bien sûr, vous pouvez choisir entre des services AWS, des services managés ou des bases de données compliquées que vous installez dans EC2, si vous voulez faire du Cassandra ou du MongoDB, vous pouvez tout à fait le faire dans EC2. Maintenant, il est peut-être plus simple d'utiliser DynamoDB qui est managé. Et voilà, la même remarque s'applique aux bases de données SQL ou RDS, qui vraiment vous simplifie beaucoup la vie. Et puis pour les recherches, les données que vous voulez indexer, dans lesquelles vous voulez faire des recherches, il y a un service Elasticsearch Managé qui vous permet en quelques clics de construire un cluster Elasticsearch et de ne pas vous en occuper outre mesure. Donc, ElastiCache, Dynamo, RDS, Elasticsearch, ce sont vraiment les quatre services managés qui vont grandement vous simplifier la vie. Bien sûr, il y a d'autres options. Si vous voulez faire du Cassandra, du Mongo ou autre chose, il n'y a pas de problème. Vous pouvez le faire dans EC2. Soyez juste bien conscient du coût tout court et du coût opérationnel qui va être associé à ce choix d'architecture. Ça fait beaucoup de choses. Et qu'est-ce qu'on choisit ? Qu'est-ce qui va nous guider plutôt vers Dynamo ou plutôt vers RDS ou plutôt vers ElastiCache ? Les quatre grands paramètres, c'est la structure des données. Est-ce qu'elles ont un schéma fixe ? Est-ce que c'est du clé-valeur ? Est-ce que c'est entre deux ? Comment je vais y accéder ? Est-ce que je fais des requêtes ? Est-ce que je fais du clé-valeur ? Est-ce que j'ai besoin de les transformer ? Quelle est la température de ces données, bien sûr ? Est-ce qu'elles sont chaudes, brûlantes, glacées ? Et puis, quel est le coût que vous voulez associer à ce stockage ? Quelques exemples. Caricaturaux, parfois la réalité est plus compliquée. Mais bien sûr, si vous faites du clé-valeur, on est plutôt là où, on l'a dit, on est dans le monde du cache, en mémoire ou dans le NoSQL. Si on veut faire des grosses jointures, si on a un besoin impératif de transaction et si on a besoin de développer en SQL, bien sûr on va plutôt aller vers des bases de données relationnelles. Si on a besoin de faire des recherches, du facetting, des choses comme ça, naturellement on va s'orienter vers du search, Elasticsearch. La structure des données est importante, la façon dont on accède aux données est importante, et généralement le choix apparaît assez rapidement, mais il faut quand même se poser la question. Voilà une façon de représenter les choses. En abscisse, vous avez la température des données, et en ordonnée, vous avez la structure des données. Donc prenons les cas extrêmes. Si vous avez des données très très froides auxquelles vous avez besoin d'accéder moins d'une fois par an, un glacier est la bonne solution. Si vous avez des données tièdes, très structurées, géographiques, une base de données SQL est sans doute une bonne solution. Si vous avez des données tièdes mais très peu structurées, des fichiers, des logs, etc., S3 est sans doute une bonne solution générale. Et puis si vous avez des données brûlantes, peu structurées ou sans aucune structure, clé-valeurs pures, bien sûr il faut aller sur du in-memory. Si vous êtes un peu au milieu de tout ça, la recherche est toujours la solution un peu intermédiaire entre les fichiers et les bases de données. Vous voyez, il y a tout un tas de paramètres. Il faut vraiment faire cette analyse à chaque fois pour chaque application, se poser les bonnes questions. Quelle est la latence ? Quel est le volume ? Quelles sont les requêtes ? Quel est le coût, etc. Bien regarder les différents services et faire le bon choix. On voit que finalement, il y a assez peu de recoupements. Parfois, effectivement, entre le SQL et les fichiers, on peut hésiter, mais bon, affinez bien votre analyse et la bonne réponse devrait apparaître. Voilà un récapitulatif des différents services, des différents data stores qui sont disponibles. Lisez tout ça à tête reposée, choisissez celui qui colle le plus à votre application. Sachant que ces choix-là, ils ne vous engagent pas pour 10 ans, vous pouvez tout à fait commencer avec RDS, un chemin un peu balisé, médian, bien connu, etc., et puis si vous vous rendez compte que la volumétrie de votre application augmente et que le taux de requête augmente et que le scaling d'une base de données relationnelle n'est peut-être pas une bonne idée, vous pouvez vous poser la question de bouger vers DynamoDB, voire vers ElastiCache. Tout ça ce n'est pas des silos, ce sont des points de départ sur la base des différents paramètres de votre application, et puis ensuite vous verrez comment les choses évoluent, et il n'est pas si compliqué ensuite de passer d'un système à l'autre, voire même d'en utiliser plusieurs pour différents systèmes. Prenons un exemple, comparons le coût de l'utilisation de S3 et le coût d'utilisation de DynamoDB. Voilà un petit projet qui a besoin d'un grand nombre de petits fichiers, peut-être jusqu'à 1 milliard de fichiers, avec une taille totale de données d'environ 1,5 téra, par mois. Donc voilà quelques paramètres : 300 écritures par seconde, une taille moyenne d'objet de 2 kilo-octets, donc à peu près 1,5 téra par mois, et puis environ 700, un peu moins de 800 millions d'objets à stocker tous les mois. Donc on vous propose, vous le connaissez peut-être déjà, si ce n'est pas le cas, ce sera l'occasion de le découvrir, une calculette qui vous permet d'estimer les coûts, qui vous donne des ordres d'idées du coût d'une solution. On peut le faire, donc la demande, double simulation avec Dynamo sur la base des paramètres qu'on a définis avec Dynamo et avec S3. Et donc on voit ici que sur la base de ces paramètres, 300 écritures par seconde, 2K de taille d'objet, 1,5 téra par mois et environ 800 millions d'objets, on arrive à un coût de DynamoDB d'environ 644 dollars par rapport à un coût S3 de 3 900 et quelques dollars. Vous voyez, j'entends souvent « Ah, DynamoDB c'est cher, on met tout dans S3 ». Bon, ça dépend. Vous m'entendez souvent dire « ça dépend ». Mais voilà, c'est fait, une fois de plus. Il faut vraiment regarder à chaque fois et estimer à chaque fois le coût potentiel. Là, vous voyez qu'il n'y a pas photo. Même si votre nombre d'écritures par seconde est faux à 20% près, c'est quand même DynamoDB qui est l'option la plus économique. Vous voyez que ça peut varier sauvagement parce que si on prend un deuxième scénario où on reste toujours à 300 écritures par seconde mais où cette fois la taille des objets est plus de 2K, c'est 32K, eh bien, vous voyez que cette fois, dans le scénario 2, c'est clairement S3 qui est beaucoup plus intéressant cette fois. Donc vous voyez, c'est ce que je disais tout à l'heure, une application qui démarrait avec une volumétrie faible, des détails d'objets faibles et qui démarrait sur Dynamo parce que vous avez fait ce calcul initialement, deviendrait finalement très coûteuse lorsque la taille des objets se mettrait à augmenter. Il est important vraiment au fil du temps de monitorer aussi le coût des services et de ne pas hésiter à refaire ces simulations. Là, vous voyez que l'économie est très significative. On parle de 5000$ par mois, ce n'est pas négligeable. Donc pensez régulièrement à estimer le coût et à regarder s'il n'y a pas un back-end qui, étant donné l'évolution de votre appli, est plus adapté. Continuons avec la phase d'analyse. Plusieurs façons d'analyser les données. La première, la plus ancienne, le mode batch, le calcul, l'analyse périodique de données, tous les quelques jours, toutes les semaines ou tous les mois, les fameux rapports mensuels, les rapports de vente, etc. On s'éloigne un peu d'Hadoop et on utilise plutôt des services conçus pour être plus interactifs, comme Athena ou Redshift, qui donnent des réponses plus rapides. La troisième façon est la communication en temps réel, où on est dans la communication entre systèmes, entre machines, et on veut la latence la plus faible possible. On utilise alors des services comme SQS, Kinesis, et on vise des traitements à l'échelle, potentiellement en milliers ou dizaines de milliers de messages par seconde, avec des analyses en temps réel, par exemple avec Spark Streaming ou Kinesis Analytics. En fonction de l'usage, que ce soit un processus automatisé qui tourne une fois par mois, le travail quotidien d'un analyste ou de la communication entre systèmes, il est important de choisir le niveau de sophistication approprié. Pour le machine learning, on veut faire des prédictions en temps réel ou en quelques minutes, sur la base des données traitées. Amazon Machine Learning ou SparkML sont des options. Il existe plusieurs solutions de streaming, comme Spark Streaming, Kinesis Analytics, et des fonctions Lambda déclenchées par des écritures dans DynamoDB ou des messages SQS. L'objectif est de recevoir, stocker et analyser les flux en temps réel, plutôt que de stocker tout et analyser plus tard. Il y a beaucoup de choix, de langages et de paramètres, et il est important de bien regarder tout cela pour choisir la meilleure solution pour votre application. Pour les outils d'analyse, on a un écosystème double : Hadoop et Hive pour des temps de réponse plus lents, et Presto, Spark, Athena, et Redshift pour des temps de réponse plus rapides. Athena permet de faire des requêtes sur des données stockées dans S3 sans gérer d'infrastructure, tandis que Redshift offre des capacités de BI sur un cluster dédié, rapide et scalable. Il y a aussi des possibilités pour le streaming en temps réel dans Spark ou l'interrogation par un analyste via Athena ou Redshift. Il est important de tester les différents systèmes et de choisir celui qui convient le mieux. C'est pour cela que nous ferons un benchmark plus tard. Nous n'avons pas parlé d'ETL. De nombreux utilisateurs ont des ETL dans leurs plateformes. Nous avons des partenariats avec des ETL majeurs comme Matillion, disponibles sur la marketplace AWS. Vous pouvez les déployer, tester et prototyper à très faible coût. Au dernier re:Invent, nous avons annoncé un service ETL appelé GLU, en preview, qui va compléter l'écosystème data AWS. La dernière étape du pipeline est la consommation. Elle peut prendre des formes très différentes. Les applications peuvent interroger Redshift ou Amazon Machine Learning via des API. Les utilisateurs humains peuvent faire de l'exploration, de la visualisation, et de l'analyse avec des outils comme QuickSight, Kibana, Tableau, Looker, et MicroStrategy, disponibles sur la marketplace. L'objectif est d'être compatible avec le maximum d'outils pour ne pas changer votre façon de travailler et profiter de l'élasticité des services AWS. Pour la partie R&D, vous pouvez utiliser des outils comme Jupyter ou Zeppelin pour connecter EMR et lancer des analyses et de la data science. Tout cela fonctionne très bien. En résumé, bien que le nombre de services soit important, ils peuvent être organisés en différentes étapes et spécialisés en fonction de la structure et de la température des données. Avec des paramètres d'entrée clairs, les choix apparaissent rapidement. Le chemin à travers ces étapes se dessine facilement si vous connaissez la latence, le format des données, et comment elles seront accédées. Des patterns fréquents chez nos clients incluent le découplage des services pour une meilleure scalabilité et simplicité, et la consommation en parallèle des données via Kinesis pour des analyses en temps réel, des réactions immédiates via Lambda, et des applications personnalisées. En fonction de la rapidité des réponses souhaitées, des systèmes comme Spark Streaming, Lambda, Redshift, Athena, et Hive se positionnent différemment. Pour le traitement temps réel, des données peuvent arriver dans Kinesis, être pré-agrégées avec Kinesis Analytics, puis envoyées dans EMR pour du streaming avec Spark, stockées dans S3, et traitées par Lambda ou des applications Kinesis. Un autre exemple est un chemin rapide pour le traitement interactif, où les données arrivent dans Kinesis, sont stockées dans S3, puis analysées par Redshift, Athena, Presto, ou Spark. Un chemin plus lent peut traiter l'ensemble des données pour des résultats plus détaillés. Les points importants sont de construire des systèmes découplés avec le meilleur outil pour chaque étape, de s'appuyer sur les services managés AWS pour la scalabilité, la haute disponibilité, et la sécurité, d'utiliser un format de données immutable archivé dans S3, et de ne pas modifier les données brutes. Le coût peut être simulé avec la calculatrice AWS, et il est important de refaire les simulations régulièrement. Merci de m'avoir écouté. J'espère que je serai connecté sur la plateforme du webinar pour répondre à vos questions. On se retrouve dans quelques minutes pour le deuxième webinar, où nous entrerons dans les détails et ferons un benchmark sur Athena, Redshift Spectrum, Hive, et Spark. Merci beaucoup. À tout à l'heure.