Cet article a été co-écrit par plusieurs consultants : Arnaud Col, Simon GUILLOCHON, David Dallago, Tristan MICHE, Edouard CATTEZ, Timothée AUFORT, Imane BENOMAR, Thomas THIRIET et Théo Ponthieu

Notre deuxième journée au AWS re:Invent 2022 s’est achevée. Après la Keynote du matin, nous avons continué nos déplacements entre les différents casinos de Las Vegas pour assister à un maximum de sessions dont les sujets balayent nos différents centres d'intérêts (data, serverless, containerisation, sécurité,...). Maintenant, place à une sélection de conférences qui nous ont marquées.

Keynote du CEO d'AWS

Écrit par Timothée Aufort

Le CEO d’AWS, Adam Selipsky, nous a gâtés avec de nombreuses annonces. J’en ai sélectionné quelques unes parmi les plus intéressantes pour des cas d’usage d’ordre général :

• OpenSearch est désormais disponible en preview avec un mode serverless ;
• GuardDuty supporte dorénavant la détection de menaces au runtime des containers. C’est une super nouvelle car il n'y avait pas encore de service pour répondre à ce besoin ;
• L’arrivée d’un nouveau service autour de la sécurité, Amazon Security Lake. Il permet d'agréger des sources de données multiples pour gérer la sécurité. Les sources peuvent venir à la fois d’autres services AWS comme Security Hub, Athena, OpenSearch, SageMaker; mais aussi venir de partenaires externes comme Cisco Security, Datadog, Splunk, IBM et plein d’autres.

Adam Selipsky CEO de AWS

 Les services Data n’ont pas été en reste cette année :

• L’arrivée de Amazon DataZone. Ce nouveau service pourra être utilisé pour publier de la donnée et la rendre disponible dans un catalogue au travers d’applications web

Le nouveau service AWS : DataZone

• Une intégration Amazon Aurora zero-ETL avec Redshift ;
• Une intégration Redshift avec Apache Spark. Concrètement, on va désormais pouvoir faire du Spark sur Redshift et Redshift Serverless.
• Une nouvelle fonctionnalité sur QuickSight Q prénommée *ML-powered forecasting* qui devrait permettre de faire des prévisions de performance sans impliquer des Data analysts  ou des Data scientists.

Ces nouvelles fonctionnalités vont très certainement pouvoir nous aider à délivrer toujours plus de valeur chez nos clients. Il ne reste plus qu’à les essayer !

Comment Yahoo a optimisé ses in-memory workloads sur AWS

Écrit par Thomas THIRIET

Présenté par Itay Maoz (General Manager In-Memory DB Services AWS), Siva Karuturi (Worldwide Specialist SA In-Memory Databases AWS) et Maulik Shah (Sr. Principal Software Engineer Yahoo)

Ce matin, Yahoo nous a présenté un de leur besoin qui fut un réel challenge et comment ils ont pu trouver une solution acceptable en travaillant étroitement avec AWS.

Leur problématique était de faire correspondre le prix d’une publicité à un instant donné (Ad Auction) avec l’affichage de celle-ci (Ad Impression), autrement dit réaliser une jointure entre 2 sources de données.

Mais ce qui nous a le plus étonné a été les quantités de données allant jusqu’à 800 GiB toutes les 5 minutes pour Ad Auction. Supposons 4h d’historique en mémoire pour être sûr de réaliser la très grande majorité des jointures, il faudrait joindre régulièrement 100GB (Ad Impression) avec 30TB (Ad Auction). Le scan des fichiers sur s3 n’était donc clairement pas envisageable !

Par conséquent, leur première décision fut de travailler avec un modèle clé valeur afin de réaliser les jointures au fur et à mesure et de seulement requêter les données nécessaires.

Ils ont ensuite considéré 3 technologies :

• DynamoDB : serverless, managé, pas de perte de données mais des coûts importants pour leur use case ;
• HBase : Amazon EMR en utilisant HDFS et s3, on-premise pour du batch et streaming, maintenance à réaliser ;
• Amazon ElasticCache : complètement managé, in-memory clé valeur, utilise Redis en cas de streaming, de très bonne performance.
  

En utilisant ElasticCache pour Redis, il leur faut 600 nœuds pour faire rentrer les 30 TB de data. Ce qui fait mal sur la facture, d’autant plus qu’après analyse de leurs données, 95% des jointures étaient réalisées sur une fenêtre d’1 heure (sur les 4 gardées en mémoire). C’est à ce moment là que Yahoo a travaillé en collaboration avec AWS pour être les bêta testeurs d’une solution proposée par ces derniers : le Data Tiering. Cette solution permet de mettre les données les moins souvent accédées sur un SSD. Le coût d’un nœud est un peu plus cher mais a permis à Yahoo de passer de 600 nœuds à 150 et d’observer une économie de 50 %.

Afin de monitorer la part déplacer dans le SSD, plusieurs nouvelles métriques sont disponibles dans CloudWatch.

Enfin, cette solution peut être considérée comme semi-durable car limitée dans le temps (exemple 4h de données). En cas de besoin plus durable, Amazon MemoryDB for Redis peut être une bonne alternative, il s’agit du service avec la plus basse latence pour les databases in-memory sur AWS.

Pour conclure, c’est très rare que nous ayons ces quantités de données à gérer chez nos clients mais le coût de la plus petite instance d’ElasticCache avec Data Tiering n’est pas si excessif (0,781 USD / heure) pour 125 GiB de cache. Il me semble donc intéressant de garder en tête que ce service existe.

Working Backwards from the Customer

Écrit par Arnaud Col

Présenté par Giulia Rossi, Principal Digital Innovation Lead, AWS et John Watson, WW Lead Customer Engagement -- Innovation Programs, Amazon

Working Backwards, c’est la méthode Amazon pour créer de nouveaux services innovants.

J’ai eu l’occasion de participer à un workshop de 2h pour tester cette méthode.

Jeff Bezos, foudateur d'AWS

 On commence par se poser des questions sur notre client :

• Qui est-il, quelles données avons-nous sur lui ?
• Quel est son principal problème ou opportunité ?
• Quelle est la solution et le bénéfice le plus important pour le client ?
• Comment décrit-on la solution et l’expérience client ?
• Comment peut-on tester la solution avec des clients et mesurer le succès ?
  

Le client que j’ai imaginé est CTO d’un groupe de retail Français spécialisé dans le sport qui a besoin d’assurer le scale de son architecture e-commerce afin d’attaquer un nouveau marché.

Son besoin ? Trouver le partenaire qui l’amènera jusqu’au bout.

Ensuite, on génère des idées. Elles doivent être ambitieuses et différentes de ce que l’on connaît déjà. C’est impressionnant de voir le nombre d’idées qu’on arrive à trouver en 8 minutes.

Puis on priorise pour garder La Grande Idée.

Toutes les idées peuvent être tentantes, mais il faut se challenger en équipe pour ne garder que la meilleure. L’idée que j’ai retenue est que nous développions une approche basée sur des business canvas qui permettra de couvrir tous les besoins du client sans aucune zone d’ombre.

J’imagine que c’est ce qui est le plus à même de rassurer le client. Enfin, on prépare un communiqué de presse hypothétique avec une citation client qui présente son expérience avec la solution.

Voici le mien.

Grâce à Ippon Technologies, nous avons doublé notre base clients en un temps record tout en apportant des innovations en continue sur notre portail e-commerce.

Qu’en pensez-vous ?

Delegating access in a multi-account environment with IAM Identity Center

Écrit par Théo Ponthieu

La complexité des permissions et des rôles AWS augmente rapidement lorsque beaucoup de projets et d’équipes se partagent les ressources. AWS fournit les meilleures pratiques et les solutions à implémenter en fonction des besoins des équipes opérationnelles.

Avec Control Tower et IAM Identity Center (SSO), vous pouvez déléguer la gestion des permissions aux utilisateurs tout en gardant le contrôle. C’est une solution dont le but est d’alléger et décentraliser la gestion des permissions au sein d’une grande organisation.

L’idée est de déléguer la gestion des permissions aux équipes elles-mêmes.

Architecture de la délagation des gestion de policies

 
Via cette solution, vous avez un compte principal géré avec AWS Organizations qui délègue la partie gestion des permissions à un sous compte Administrateur.

C’est à l’aide de la nouvelle fonctionnalité  “Délégation d'administration" que vous pouvez déléguer la gestion des policies à des comptes AWS qui sont reconnus comme administrateur délégué (peut-être le chef ou le responsable sécurité d’une équipe). Tous les types de policies sont disponibles. L'administrateur délégué peut ensuite gérer les policies choisies.

Les policies restent sous le contrôle du compte Admin principal qui définit le maximum des privilèges d’une liste de permissions grâce aux permissions boundaries. Ces dernières sont effectives sur tous les comptes, ce qui permet d’avoir un garde-fou pour les administrateurs délégués et les empêche de donner des droits trop importants à leur équipes.

Permissions accordées aux users / rôles en fonction des différentes sources de droits

Avec cette méthode, on évite la problématique de gestion d’un grand nombre de rôles tout en restant sur le principe du “least privilege".

C’est une solution aboutie qui répond au besoin des grandes organisations. Le temps libéré pour les équipes opérationnelles peut être consacré à des tâches qui ont une plus grande valeur ajoutée.

La mise en place de cette solution doit être envisagée assez tôt dans la roadmap opérationnelle. Elle peut remettre entièrement en cause la méthode de gestion des permissions aux ressources AWS au sein d’une entreprise. Cette solution apporte une couche supplémentaire de complexité. Elle est plus particulièrement adaptée pour des entreprises d'une certaine taille.  

Développer des applications event-driven en utilisant Amazon Aurora Serverless v2

Écrit par  Thomas THIRIET

Présenté par Grant McAlister (Sr. Principal Engineer AWS) et Aditya Samant (Sr. Database Specialist Solutions Architect AWS)

Après avoir suivi le workshop d’hier sur le futur de la data analytics en serverless, j’ai continué sur ma lancée aujourd’hui afin de manipuler d’autres architectures serverless. J’ai donc assisté à un workshop sur la v2 d’Aurora MySQL Serverless sortie cette année. L’objectif était de mettre en place en 2h l’architecture ci-dessous et de réaliser des tests de performances afin d’observer la scalabilité de la base de données. Évidemment, une bonne partie des services étaient déjà déployés mais ce fut fun de réaliser les différentes connexions entre eux.

Architecture de la solution event-driven

Le scénario consistait à créer un user et le faire voter sur des questions préalablement insérées dans Aurora. Naturellement avec un user, la base de données tourne sur son minimum qui est 1.5 ACU (Aurora Capacity Unit).

Comment la base va-t-elle réagir en simulant plus de votes ? Pour ce faire, j’ai utilisé l’outil open source artillery et ai observé les résultats ci-dessous :

Graphe de performance de Aurora Serverless

Je fus agréablement surpris de constater à quel point le scaling up fut rapide et linéaire par rapport au ramp up utilisé dans le scénario. Au bout de 2 minutes, j’ai atteint la capacité max configurée (8 ACU) et ai constaté les premiers codes de retour 500. Le graphe permet de constater certaines des nombreuses différences qui existent avec la v1 (voir la documentation AWS sur le sujet).

Pour conclure, j’ai trouvé cette architecture très intéressante. Elle apporte beaucoup de valeur quand l’utilisation de bases de données est très inconsistante. Elle permet de scaler très vite s’il y a un pic d’usage et permet au système de rester up et ne pas prendre trop de retard tout en réduisant les coûts sur des moments faibles en trafic comme par exemple la nuit. Enfin, l’architecture est extrêmement résiliente sur les écritures, si la base de données est inaccessible, les lambdas peuvent être rejouées (jusqu’à 24h) au niveau de Event Bridge (eventbus + rule). En cas d’erreurs persistantes, une dead letter queue peut être configurée.  

Build with prototypes: be a customer-obsessed developer

Écrit par  Simon Guillochon

Présenté par Sonny Chowdhury (Sr. Manager, Solution  architect @ Amazon), Zubeen  Sahajwani (Sr. Solution  architect @ Amazon) et  Marcel  Mantovani (Solution  architect @ Amazon)

Amazon nous présente le processus d’innovation qui a mené à l’existence du bouton Buy with Prime. en tant que solution destinée aux commerçants souhaitant développer leur activité de vente directe aux consommateurs (DTC). Ainsi, cette nouveauté permet aux utilisateurs d'Amazon de commander directement depuis le site du marchand ayant implémenté le bouton.

Sonny Chowdhury, Manager Solution Architect

En guise de storytelling, les trois architectes nous présentent le déroulé de leur processus d'innovation en partant du moment où l'idée a émergé. Dans un premier temps, ils ont listé les stakeholders et les destinataires de la solution imaginée qui sont au nombre de 3 :

• les marchands implémentent la solution ;
• les clients de ces marchands, les utilisateurs du bouton ;
• les partenaires de ces marchands facilitent l'implémentation.

Une fois que les stakeholders sont définis et avant de partir à la chasse aux informations auprès de ces derniers, il a d'abord fallu définir la problématique à laquelle ils allaient devoir répondre pour arriver à leurs fins. Avec l'expertise d'Amazon dans l'industrie du e-commerce, d'une part, et leur volonté de préserver l'expérience des développeurs du côté des marchands, d'autre part, ils sont arrivés à la conclusion suivante : ils avaient besoin d'apporter aux développeurs des APIs, et ce rapidement. Vient ensuite la récolte des retours clients suite aux interviews menées auprès des stakeholders. Ce feedback a été réparti selon trois aspects : gouvernance, expertise et vision . Gouvernance par les développeurs, expertise et vision apportées par les équipes d'Amazon car si les développeurs côté marchands leur ont remonté une chose, c'est qu'ils veulent être accompagnés dans l'implémentation de la solution proposée. C'est à partir de là, et à partir de là uniquement, que les équipes chargées du projet chez Amazon se sont penchées sur la réalisation d'un premier prototype qui répondrait aux exigences formulées par les développeurs dans leur feedback.

Ce prototype se découpe en deux parties : ce qu'ils ont appelé un accélérateur d'API réalisé en GraphQL et une application blueprint. Si la première partie a permis aux développeurs de rapidement communiquer avec le système d'information d'Amazon, le blueprint - également appelé Proof Of Concept ou PoC - a permis d'accélérer l'implémentation. En effet, son rôle est d'illustrer une application consommant les APIs Buy with Prime mises à disposition par Amazon. Ce blueprint permet ainsi une adoption du produit en 5 étapes par les développeurs :

• Explorer. Installer l'application, la lancer et la parcourir.
• Planifier. Inspecter le code du prototype et définir des estimations plus précises avec une confiance accrue.
• Tester. Modifier l'application selon les scénarios propres aux cas d'usages des développeurs.
• Développer. Implémenter sa propre application via un fork du blueprint par exemple.
• Déployer. Réaliser des déploiements et de l'intégration continue des développements.
  

Ainsi, le retour sur cette expérience se conclut par quelques points clés, à savoir :

• Se concentrer sur la priorisation des besoins clients ;
• Faire de l'amélioration continue en récoltant du feedback ;
• Faire parvenir la voix du client jusqu'à soi grâce au prototype ;
• Construire avec des services managés AWS fournir un modèle sécurisé, fiable et évolutif.

Citation de Kestutis Kazlauskas, CTO, SixAds

De mon point de vue, le point essentiel à retenir de cette conférence tient dans la considération apportée au besoin exprimé par notre client final. Si, une fois le besoin défini, trouver qui sera notre interlocuteur privilégié pour la mise en place de notre solution, il est important voire essentiel de toujours rester à l'écoute des retours de nos stakeholders tout au long de l'implémentation de notre produit. Bien que tout projet ait besoin d'un business model pour subsister, l'objectif reste principalement d'apporter une solution à un problème. Alors quoi de mieux que d'écouter celui qui rencontre ce problème pour y répondre le mieux possible, par-delà la solution implémentée ? Grâce à l’équipe de Buy with Prime, la marche à suivre a désormais un exemple solide sur lequel s’appuyer.

From serverful to serverless JAVA with AWS Lambda

Écrit par Edouard CATTEZ

Présenté par Maximilian Schellhorn, Solution Architect et  Mark Sailes, Sr. Specialist Solution Architect.

Dans cet atelier, nous avons vu comment découper une application Spring classique, dite serverful, pour la rendre serverless avec l’usage de AWS Lambda. Nous nous sommes particulièrement penchés sur la notion de cold start et warm start. Il s’agissait effectivement de réduire le temps de démarrage de notre application en utilisant plusieurs stratégies différentes et/ou combinées:

• modification de dépendances
• tuning des options JVM
• mise en place d’API Gateway
• …

Pour évaluer le gain de nos différentes approches, nous avons effectué plusieurs benchmark dont voici les résultats :

Les tests ont été effectués avec artillery avec une mémoire allouée de 2048MB par lambda.
Il est intéressant de voir que certaines optimisations sont plus efficaces que d’autres. La compilation native notamment produit des résultats sans équivoque.

L’atelier met en lumière que les choix technologiques et les optimisations d’infrastructures sont importants pour avoir des services qui répondent rapidement. De mon point de vue, ces choix doivent être fait en collaboration avec les développeurs et les opérationnels pour trouver le juste milieu entre optimisation infrastructurelle et efficacité de développement. Certaines de ces décisions structurent le démarrage du projet. De fait, qu’en est-il de la modélisation émergente ? Faut-il articuler le code autour des services du cloud, ou peut-on s’en abstraire totalement ?

ECS: scaling containers from one user to millions

Écrit par Tristan Miche

Présenté par Maish Saidel-Keesing, Senior Developer Advocate, AWS et Abhishek Nautiyal, Sr Product Manager-Technical, Amazon Web Services

AWS ECS est un service managé d’orchestration de conteneurs qui permet de déployer simplement des applications conteneurisées. ECS est naturellement scalable, très intégré à l’ensemble des services AWS et il est même utilisé par AWS pour l'exécution de certains services comme Polly, Lex ou SageMaker.

ECS est le service dont la capacité de scalabilité a le plus augmenté depuis l’an dernier. Il est aujourd’hui possible de lancer 500 tâches par minutes (soit 16 fois plus que l’an dernier si on considère le mode fargate)

Afin d’utiliser au mieux les capacités du service il est recommandé de suivre la démarche suivante:

• Identification des ressources nécessaires  ( CPU, GPU, bande passante réseau, stockage, mémoire) par composants
• Établir des profils de consommation pour les applications ( CPU-bound, Memory-bound,...)
• Déduire des profils les ECs units pour définir les tâches.
• Choix du type de compute ( ECS supporte ec2, EC2/spot, fargate, outpost et même on premise avec ECS anywhere)
  

Pour les applications demandant une forte scalabilité, il convient de garder un œil sur les quotas au niveau Account, Cluster, Services et tâches. On citera en particulier :

• le nombre de target groups ALB
• le nombre de  targets par target groups par région
• le nombre d Elastic IP par région
  

Au-delà de l’atteinte des quotas on peut également faire face à de l’API throttling ( dépassement du nombre de requêtes à l’API AWS pour une période donnée). Afin de pouvoir analyser et prévenir en cas de throttling, il est fortement recommandé de collecter les événements de type THROTTLED dans cloudtrail vers cloudwatch logs pour analyse de l’origine et d'implémenter un mécanisme de retry (par exemple en déclenchant de façon temporisée une lambda)

Enfin voici une liste d’optimisation permettant d'améliorer les performances d’une applications fortement sollicitée sous ECS:

• Permettre une adaptation rapide du nombre de tâches en fonction de la charge
• Réduire l'intervalle de temps entre deux tests de vie
• Réduire le nombre de test de vie nécessaire pour considérer le composant comme ready
• Réduire la durée de dé-enregistrement d’une tâche en cas scale down
• Améliorer le temps d'arrêt de l’application sur SIGTERM et réduire le STOP_TIMEOUT
• Utiliser le cache pour les images
• En EC2, paramétrer ECS_image_pull_behavior à “once” ou “preferred cache”
• En fargate, réduire au maximum la taille des images, placer la registry dans la même region et éventuellement augmenter le CPU de la tâche pour réduire le temps d’extraction de l’image.
• Network mode: le mode bridge est un peu plus performant au niveau provisionning  mais offre moins de flexibilité que le mode AWS vpc (une ENI par tâche)
• Utiliser la stratégie de placement binpack pour maximiser la densité des tâches par instance

ECS est donc à considérer au même titre qu'EKS lors du choix d’un orchestrateur de conteneur et en particulier pour une application ayant d'un fort besoin de scalabilité, celle-ci sera en effet plus simple à mettre en place tout en ayant une capacité d’analyse et d’optimisation des performances.

AWS Lambda SnapStart: Fast cold starts for your java functions

Écrit par Damien Rollet et Edouard CATTEZ

Présenté par Mark Sailes

Mark Sailes sur scène

SnapStart est une nouvelle option de configuration de la lambda, qui n’est pas activée par défaut. Cette option permet de prendre un snapshot de notre application, notamment après que celle-ci ait été initialisée. De fait, chaque nouvelle instance est démarrée à partir du snapshot. Les gains de performance sont extraordinaires puisque l’on peut désormais démarrer une application JAVA d’un claquement de doigts. Fini les cold starts !

Toutefois, l’environnement de départ étant désormais le même pour toutes les instances, il faut être vigilant sur certains points.

Connexions réseaux

L’établissement de la connexion avec la base de données lors de la phase d’init a pour conséquence de mettre en mémoire cette connexion et donc de l’intégrer au snapshot. Toutefois, après un certain temps, cette connexion peut ne plus exister. Démarrer une instance avec une connexion expirée ne sera pas un problème grâce au système retry de la plupart des mécanismes de connexion. En revanche, il faudra penser à mettre à jour le snapshot pour éviter que le problème ne persiste pour toute nouvelle instance postérieure à l’expiration de la connexion.

Données éphémères

On peut penser notamment aux secrets. Les secrets sont chargés en mémoire et permettent à l’application de se connecter à d’autres acteurs (la base de données par exemple). En mettant ces données éphémères dans le snapshot, on s’expose à un problème particulier : la rotation des secrets. Effectivement, si un secret est corrompu ou bien qu’il arrive en fin de vie, il est nécessaire d’en générer un nouveau. Il en sera de même pour le snapshot dans cette situation.

Uniqueness

AWS a testé quelques fonctions liées notamment à l’aléatoire et donc à la cryptographie:

• OpenSSL
• /dev/random
• /dev/urandom
• java.security.SecureRandom

Ils sont tous snapshot-compatibles. Toute autre méthode non testée par AWS est à la charge de l’équipe de développement.

Voici les résultats obtenus sur une application de test en ajoutant la nouvelle fonctionnalité :

Résultats des optimisations du temps de lancement

AWS met également à disposition un outil pour scanner votre code afin de vérifier sa compatibilité avec le SnapStart et identifier les antipatterns (https://github.com/aws/aws-lambda-snapstart-java-rules).

Dernier point à noter, l’ajout de deux nouveaux hooks permettant une exécution juste avant la réalisation du snapshot ou juste après son utilisation afin notamment de gérer vos données uniques.

En conclusion, AWS Lambda SnapStart ouvre un nouveau champ des possibles. Avec les snapshots, nous pouvons dors et déjà imaginer que des interfaçages Spring rendront la vie du développeur toujours plus simple. On peut effectivement s’attendre à ce que l’usage de Snapstart soit intégrée dans une nouvelle dépendance et qu’une nouvelle annotation permettra de qualifier les beans éligibles pour le snapshot.

En attendant, AWS va continuer d’étoffer son workshop sur les lambdas Java en proposant des exercices sur Lambda SnapStart. Il ne reste donc plus qu’à jouer avec !

Putting cost optimization into practice

Workshop animé par : Rovan Omar - Amazon Web Services (AWS), Principal et Jang Whan Han - Amazon Web Services (AWS) Well-Architected Geo SA \

Écrit par David Dallago

reInvent  AWS  FinOps

Pour cette deuxième journée d’AWS, je participe à un workshop finops adressant les sujets suivants:

• Comment collecter les données de cost et usage ?
• Comment configurer des dashboards de monitoring cost et usage ?
• Comment analyser les cost reports ?
  

Cinq best practices sont abordées pour entrer dans le sujet:

• Choisir un modèle de consommation: être capable de scaler à la demande, planifier en fonction de l’utilisation des environnements …
• Analyser et identifier les coûts: être capable d’avoir un ROI
• Stopper les dépenses à faible valeur ajoutée : toutes les opérations de maintenance adressées par AWS
• Mesurer la valeur générée d’un point de vue métier
• Avoir le contrôle des coûts d’utilisation des services
  

Nous mettons donc en oeuvre l’architecture suivante:

Architecture de la solution

Les fichiers AWS CUR sont configurables depuis la console de facturation et sont exportés dans des buckets S3. Un crawler va ensuite créer ou mettre à jour les tables du catalogue de data AWS Glue. Avec l’intégration AWS Glue, nous allons pouvoir exécuter des requêtes SQL sur ces données financières via Amazon Athena (serverless). Enfin, Amazon QuickSight va s’intégrer avec Amazon Athena et va nous permettre de créer le dashboard suivant :

Dashboard Quicksight de visualisation des résultats

Ces trois widgets permettent de suivre:

• Le coût généré par compte AWS
• Le coût généré par type d’instance
• Le coût généré par service
  

Ce workshop permet la mise en œuvre rapide d’un outillage au service du finops. Il s’appuie uniquement sur des services managés et permet de créer d’autres dashboards simplement.

C’est un exemple simple qui montre l'intérêt de la mise en place de ce type de reporting dès les premiers déploiements sur le cloud afin de maîtriser les coûts puis de les optimiser.

Comment exécuter des workloads Spark serverless avec AWS analytics ?

Écrit par Imane BENOMAR

Aujourd’hui je vous propose une revue des services permettant d’exécuter un workload Apache Spark en mode serverless sur AWS sans se soucier de la gestion de l’infrastructure sous-jacente. AWS offre deux options pour exécuter un cluster Spark en mode serverless, Spark sur Amazon EMR Serverless et Spark sur AWS Glue. Voici un comparatif accompagné de quelques cas d’usages :

Une démonstration nous a permis d'apprécier la rapidité de mise en place des deux solutions avec toutefois un peu plus de configuration pour l’option EMR.

Cette session montre rapidement l'intérêt et les différentes possibilités de l’approche serverless pour exécuter sur AWS des workloads Spark et cela donne fortement envie d'en faire ou d’en refaire. Et vous, quelle solution allez-vous choisir ?

PS : Pour découvrir notre récapitulatif de la 3ème journée de ce re:Invent 2022, dirigez-vous ici.