Article co-écrit avec Hicham Yahiaoui (Cloud Architect @Stack-Labs) et Yoann Metenier (Cloud Architect @Stack-Labs)
Keynote
La GenAI c’est génIAl
L'AWS Summit Paris 2024 s’est déroulée au palais des congrès. Le lieu était plus que nécessaire au vu du nombre de personnes présentes à cet évènement. Dès notre arrivée, et après avoir récupéré nos cartes d’accès, nous nous sommes installés dans le grand amphithéâtre afin d’assister à la Keynote d’ouverture.
Julien Groues (General Manager - Europe South, AWS) a effectué quelques présentations sur AWS en début de keynote pour ensuite laisser la main à Mai-Lan Tomsen-Bukovec (VP of Technology, AWS) qui est venu pour discuter des nouveautés 2024 AWS : la GenAI.
Tout au long de cette keynote de 1h30 plusieurs intervenants sont montés sur scène afin de présenter leurs besoins et utilisations de la GenAI sur AWS. Cependant, une annonce surprise a été effectuée en début de session : AWS x Mistal AI.
En effet le premier intervenant sur scène n’est autre que Arthur Mensch CEO de Mistral AI. Il est venu pour confirmer son partenariat avec AWS permettant aux utilisateurs de disposer de Mistral AI dans AWS Bedrock pour la région Europe ! Les versions disponibles sont : Mistral Large, Mistral 7B et Mistral 8x7B.
A la suite de cette annonce forte excitante, les intervenants suivants sont venu présenter leurs utilisation du cloud AWS pour dynamiser leur activité et enrichir l'expérience de leurs clients:
- Fabien Mangeant (Chief Data and AI Officer, Air Liquide)
- Thomas Wolf (Co-Founder, Hugging Face)
- Raphaëlle Deflesselle (CTO, Groupe TF1)
- Tom Brown (Co-Founder, Anthropic)
A la fin de la keynote, nous avons poursuivi notre périple AWS en participant à quelques conférences parmi les 175 disponibles et en discutant sur les stands des partenaires afin de découvrir des projets et utilisations de diverses solutions sur AWS. Nous avons choisi de vous présenter dans la suite de cet article 3 conférences auxquelles nous avons assisté.
Multi-régions Zéro latence avec Kubernetes, Couchbase & Qovery
Laurent Doguin (Developer Advocate Couchbase) et Romaric Philogène (CEO Qovery) nous ont fait le plaisir d’effectuer une présentation de l’intégration entre Couchbase et Qovery permettant de réduire et stabiliser une connexion BDD – Kubernetes dans un environnement multi-région sur AWS.
Un peu de contexte
Le temps d’attente de réponse d’une application peut provoquer une lassitude des utilisateurs d’autant plus à notre époque où nous sommes habitués à des services qui répondent rapidement. Nos interlocuteurs nous présentent les résultats d’une étude AWS qui dit :
- 100 ms de latence sur la page amazon.com = 1% de baisse des ventes
- De manière générale :
- 2 secondes de chargement pour un site internet = 9% des utilisateurs abandonneront la navigation,
- 5 secondes de chargement pour un site internet = 38% des utilisateurs,
- 3 secondes de chargement via smartphone = 53% des utilisateurs
Le problème posé
Dans une architecture multi-région comment puis-je faire pour disposer d’un temps de lecture/écriture acceptable pour n’importe quel client indépendamment de sa localisation géographique ?
Nous pouvons représenter ce problème avec le schéma suivant :
Nous pouvons voir que dans cette situation les client aux Etats-Unis et en Asie dispose d’un temps de lecture et écriture nettement supérieur à ceux en Europe. Comme expliqué dans notre contexte, ce délai supplémentaire peut provoquer de la frustration et donc amener à une perte d’utilisateurs sur ces régions.
A la suite de cette mise en contexte, Laurent et Romaric ont proposé une solution de base souvent utilisée, appelée « active/passive ». Cette méthode consiste à déployer plusieurs instances d’application dans les différentes régions et d’utiliser des read réplicas pour les base de données (schéma ci-dessous).
Via cette solution nous constatons une nette amélioration concernant la lecture du contenu en base. Si la lecture représente la plus grande partie des actions réalisées par les clients, alors cette solution est viable. Mais quid de la situation où l'écriture est aussi un aspect important pour les clients ? Dans ce cas la solution basique devient non valide car nous disposons toujours d’un temps d’écriture très élevé pour les deux régions éloignées.
Plusieurs solutions se présentent alors :
- Retravailler le modèle de données pour séparer les régions entre-elles et que chacune repose sur sa propre base de données (beaucoup de travail à faire et peut-être pas possible en fonction du modèle de données)
- Utiliser un schéma plus horizontale avec la possibilité d’écrire/lire les données de chaque base de données correspondant à sa région et gérer un système de réplication de données (complexe à mettre en œuvre et gestion des conflits sur les données à gérer soi-même)
- Utiliser la solution « active/active » proposé par Couchbase et Qovery afin de permettre à la fois de disposer de bases de données par région et synchronisées entre elles de manière efficace via Couchbase, mais également de disposer du gestionnaire de déploiement serverless des ressources et plateformes centralisé, Qovery, connecté aux instances Couchbase
Les présentateurs ont conclu leur conférence par la présentation de la solution (vous l’aurez deviné) N°3 : l’utilisation de Couchbase (Capella) et Qovery (schéma ci-dessous). Dans cette dernière, les utilisateurs de n’importe quelle région disposent tous du même temps de lecture et écriture sur l’application tout en bénéficiant d’une synchronisation des données avec latence faible complètement gérée par Couchbase.
A noter également que la solution proposée par Couchbase permet de disposer des données de manière active/active tout en gérant l’aspect conformité de ces dernières (via l’utilisation de filtres) vis à vis des lois en vigueurs dans les régions et pays de déploiements.
En conclusion
Couchbase x Qovery est un couple prometteur. En effet, la solution exige un coût supplémentaire par rapport à une solution gérée par le client lui-même. Cependant, aujourd’hui de nombreux clients souhaitent réduire l’aspect maintenance et opérabilité de leurs infrastructures sur le Cloud.
Avec des interfaces claires et faciles d’utilisation (qui changent grandement de l’interface console AWS) la solution proposée peut être une alternative intéressante pour des clients avec un besoin spécifique et rapide avec une infrastructure simple.
Vous pouvez retrouver une démo ici : https://www.youtube.com/watch?v=nza3ldlPI7w
Optimisez les coûts et la mise à l'échelle d'EKS avec Karpenter
Imane Zeroual (AWS), Sebastien Allamand (AWS) et Martinho Moreira (Voodoo) nous présente le projet Karpenter, sa mise en place dans un cluster EKS et un retour d'expérience sur les bénéfices apportés par cette solution.
Maximiser l'Efficacité des Clusters Kubernetes avec Karpenter
Kubernetes s'est imposé comme l'une des solutions les plus populaires pour la gestion des applications conteneurisées à grande échelle. Cependant, malgré ses avantages indéniables, Kubernetes peut présenter des défis en matière de gestion des ressources et d'optimisation des clusters. C'est là que Karpenter entre en jeu.
Qu'est-ce que Karpenter ?
Karpenter est un projet open-source développé par AWS qui vise à optimiser les clusters Kubernetes en automatisant le dimensionnement des nœuds. Son objectif principal est de garantir que les ressources sont utilisées de manière efficace tout en maintenant les performances et la disponibilité des applications.
Comment fonctionne Karpenter ?
Karpenter s’installe dans le cluster Kubernetes en tant qu’opérateur et va remplacer le mécanisme d’autoscaling d’AWS pour provisionner les nœuds.
Karpenter analyse les demandes de ressources des pods et les regroupe en fonction de leurs caractéristiques. En utilisant ces informations, il peut déterminer la meilleure façon de répartir les charges de travail sur les nœuds disponibles, et ainsi réduire le nombre de nœuds nécessaires.
Par exemple, il peut regrouper plusieurs pods légers sur un seul nœud pour libérer des ressources sur d'autres nœuds et ainsi les supprimer du cluster.
Karpenter peut également s'intégrer avec des services cloud tels qu'AWS Spot Instances ou des instances de type Graviton, ce qui permet d'optimiser les coûts tout en maintenant les performances des applications.
Afin de paramétrer et utiliser au mieux Karpenter, Sébastien Allamand nous présente ensuite quelques outils et méthodes tels que les détections de Drift du dataplane ou l’analyse approfondie de la perturbation des nœuds.
Retour d'expérience
Pour finir cette session, Martinho Moreira de chez Voodoo nous fait un retour d'expérience sur leur mise en place de Karpenter, l’architecture et les points de vigilance qu’ils en ont retiré.
Les slides parlent d’eux même :
En conclusion
Cette conférence fut très intéressante pour une découverte de cet outil de plus en plus utilisé dans le cadre d’optimisations FinOps.
La présentation a été accompagnée d’une démo qui nous a permis de rendre concret certains use cases, et de constater en live le fonctionnement de l’outil et les optimisations réalisées par Karpenter.
La 2ème partie de la conférence a bien complété ce talk avec un retour d'expérience concret de la part de Voodoo. Ils ont ainsi pu nous partager factuellement les retombées en termes de bénéfice de l’outil, les étapes de migration et les pièges à éviter lors de la mise en place de Karpenter.
Accelerate Gen AI with Amazon Bedrock and Snowflake:
Nadir Djadi de Snowflake a présenté une approche accélérée de l'intelligence artificielle générative en utilisant Amazon Bedrock et Snowflake.
Après une brève introduction sur le rôle de Snowflake, il a présenté une vue d'ensemble de la plateforme en mettant en avant trois points clés : L'IA accessible au quotidien sans expertise, le déploiement rapide d'applications avec personnalisation, la sécurité et la gouvernance des données garanties.
Ensuite, nous avons exploré certaines fonctionnalités offertes par Snowflake avant de nous concentrer sur la partie Amazon Bedrock. Cette dernière offre une intégration transparente des modèles fondamentaux (FMs) de divers fournisseurs pour des applications d'intelligence artificielle générative évolutive, avec des options de personnalisation privées.
Nous avons ensuite passé en revue les FM disponibles sur Amazon Bedrock, en notant que Mistral n'a pas été inclus dans la liste puisqu'il a été annoncé le jour même.
Enfin, il a conclu en montrant comment Snowflake peut interagir avec Amazon Bedrock via Snowpark External Access, qui repose sur des identifiants temporaires de AWS Security Token Service (STS) pour authentifier et accéder aux endpoint des modèles Amazon Bedrock.
En conclusion, je trouve la solution présentée par Nadir Djadi très intéressante, surtout pour son aspect permettant une utilisation rapide de l'IA sans nécessiter une expertise préalable. Cela me donne vraiment envie d'expérimenter Amazon Bedrock dans mes projets futurs.
Alors l’AWS Summit Paris c’est génIAl?
Cette année encore AWS nous gratifie d’un show à la taille de son investissement en France. En effet, l’acteur n°1 du cloud public a réussi à nous faire sentir à l’étroit sur les 3 étages du Palais des congrès de Paris. Nous avons pu profiter un maximum, même si pour certaines conférences il était difficile d’avoir une place.
Cette année s’annonce très intéressante sur le secteur de la GenAI. AWS compte bien rattraper son retard sur les aspects data et IA, en consacrant une attention particulière dans l’accompagnement de ses partenaires et clients voulant explorer ces solutions.
Nous resterons bien sûr à l’écoute des nouveautés qu’AWS pourraient annoncer dans les mois à venir, et nous n'hésiterons pas à vous les partager sur notre blog.
Top comments (0)