alter way Cloud Consulting à l'AWS RE:invent 2018 : Part 3

Publié le
par Aurélien Joga, Alexandre Kervadec, Jérémy Mouton, Kevin Messy, Lionel Daubichon, Igor Aiestaran
dans Amazon Web Services
⭠ Retour à la liste des articles
thumbernail Amazon Web Services


Retrouvez l'ensemble du dossier :

Depuis 2015, première année de présence de l'équipe alter way Cloud Consulting, l'AWS re:Invent n'a cessé de prendre de l'ampleur. La plus grande conférence au monde dans l'univers du Cloud Computing avait réuni 40 000 personnes pour l'édition 2017. Cette année, ce sont un peu plus de 55 000 personnes qui se sont réunies à Las Vegas autour des nouveautés d'Amazon Web Services.

En tant qu'Advanced Partner AWS et experts de pointe sur les technologies Cloud, cet événement est stratégique : c'est l'occasion pour les équipes Amazon Web Services de nous présenter les dernières nouveautés, sorties ou à venir durant les 12 prochains mois.

Nous voilà à la troisième et dernière keynote de ce Re:invent 2018. Comme à l'accoutumé, c'est Werner Vogels qui a été notre orateur pendant 2h. Mais avant le commencement de cette session, nous avons eu un évènement spécial, la finale de Deepracer. Présentée lors de la keynote de Mardi, c'est le championnat d'entrainement (via Machine Learning) des voitures Deepracer. Lors de cette finale, 3 concurrents venant des workshops de présentations se sont affrontés. Vous pouvez retrouver la finale en vidéo sur le compte Youtube AWS. Cette évènement a été présenté par un commentateur de course automobile, Ryan Myrehn.




L'édition 2018 de l'AWS Re:Invent : PART.3

Nouvelle fonctionnalité : Cluster parallèles pour Amazon Redshift

Amazon utilise les données de télémétrie sur l'utilisation de ses services par ses clients. De cette façon, sur les services de bases de données ils peuvent savoir quelless sont les sources de lenteurs pour leurs clients. Werner a déclaré que, lors des 6 derniers mois, les clusters Redshift ont gagné entre 2 et 10x de performances sur certaines actions.

Aussi, concernant Redshift, Amazon s'est aperçu qu'une partie de ses utilisateurs avaient des charges de travail très intenses à certaines périodes de la journée. Afin d'améliorer les temps de réponse à ces requêtes, Amazon peut désormais scaler horizontalement un cluster Redshift lorsque c'est nécessaire. Cela se fait sans action manuelle, et une heure de scaling horizontal est offerte par jour de fonctionnement du cluster de base. Werner a fait remarquer que cela rendait la fonctionnalité gratuite pour 99% des clients concernés.

Nouvelle fonctionnalité pour AWS Lambda : Firecracker

Firecracker est une nouvelle technologie de virtualisation qui se base sur KVM. Ceci va permettre de lancer des microVM sur une infrastructure non-virtualisée. Firecracker implémente différentes fonctionnalités : isolation, sécurité avancée, meilleure utilisation des ressources et pour finir un démarrage des microVMs en 150ms.

Ce projet est open-source et est disponible sur Github.

Nouvelle fonctionnalité pour AWS Lambda : support natif de Ruby



C'est maintenant au tour de Ruby d'être supporté par AWS Lambda et cela nativement.

Nouvelle fonctionnalité pour AWS Lambda : Executables personnalisés pour Lambda

Après l'annonce du support de Ruby dans Lambda, AWS Lambda Custom Runtime est présenté. Cette nouvelle fonctionnalité permet de supporter tous les langages exécutables dans un environnement Linux. Les Lambdas avec Ruby utiliseront cette technologie. Des partenaires ont déjà implémenté le support de C++, Rust, Erlang, PHP et Cobol.

AWS Lambda Custom Runtime est déjà disponible.

Nouvelle fonctionnalité pour AWS Lambda : les layers



Quand on déploie des fonctions Lambda, on finit souvent par ajouter les mêmes dépendances (libs) dans plusieurs Lambdas, ce qui multiplie la duplication de code et complexifie tout le processus. Les layers veulent palier ce problème avec la possibilité de réutiliser ces mêmes dépendances, déployées une seule fois, parmi nos différentes fonctions, à la manière des images Docker formées par des layers.

Cette fonctionnalité est déjà disponible.

Nested Application Serverless Repository



Grâce à SAM et aux CloudFormation Nested Stacks, on peut désormais définir des architectures serverless qui utilisent des applications venant de différentes sources. Cela permet d'éviter la duplication de code et facilite la cohérence ainsi que la conformité aux best practices entre les différentes équipes de développeurs.

Step Functions s'intègre avec AWS Batch, Fargate, DynamoDB, SNS, SQS, Sagemaker



AWS Step Functions s'intègre désormais nativement avec huit nouveaux services, ce qui simplifie la logique applicative nécessaire pour invoquer les différentes actions.

Nouvelle fonctionnalité pour API Gateway : le support des Websockets

Feature très attendue par nombre de développeurs, AWS annonce que API Gateway prend en charge le protocole WebSocket. Grâce aux websockets, le client (application mobile ou navigateur web) peut recevoir des données à l'initiative du backend sans que ce soit forcément en réponse à une requête. Plusieurs nouvelles fonctionnalités sont ainsi possibles, comme les tchats ou l'affichage des données en temps réel, entre autres. Cette annonce ne doit pas nous surprendre étant donné que la même fonctionnalité venait d'être annoncée sur CloudFront, et API Gateway s'appuyant sur ce dernier.

Application Load Balancer supporte AWS Lambda



Jusque là, on pouvait ajouter des instances EC2 ou des adresses IP comme destination dans le Target Group d'un ALB, il manquait la possibilité de diriger le trafic vers une fonction Lambda. Avec cette nouvelle fonctionnalité, les voies d'entrée possibles vers Lambda s'élargissent : API Gateway, SDK, et maintenant les ALB !

Nouveau produit : Amazon Managed Streaming for Kafka



Nous avons eu l'année précédente ActiveMQ managé, c'est au tour de Kafka d'avoir son service managé. Amazon propose désormais un cluster complètement managé et HA pour Kafka en preview publique.

AWS Well-Architected Tool



Afin d'automatiser les contrôles de conformité avec les best practices et le Well-Architected Framework, AWS nous présente ce nouvel outil et nous recommande de l'utiliser systématiquement. La solution permet de prendre connaissance des risques liés à l'infrastructure par rapport aux différents piliers définis dans le framework et précise les améliorations à appliquer.

Revenons maintenant sur les conférences marquantes !


EKS haute performance en production

Dans ce talk, on nous présente les best practice pour avoir un cluster EKS haute performance pour de la production. On commence par définir les composants de Kubernetes et leurs responsable associé :

  • Le control plane (master et Etcd) est de la responsabilité d'AWS avec EKS, qui ne fournit qu'un endpoint à l'utilisateur, à la façon de RDS
  • Les worker nodes sont de la responsabilité totale de l'utilisateur, qui doit gérer l'image (OS, idéalement l'image officielle d'AWS pour EKS) ainsi que les containers sous-jacents.

Optimisations à considérer

Le speaker nous donne sa liste de recommandations à suivre, à plusieurs niveaux :

  • Optimiser ses images : garder une petite image, utiliser un OS minimaliste (Alpine Linux par exemple) ou carrément pas d'OS du tout (binaire Go avec un lien statique).
  • Optimiser ses pods : combien de containers sidecar y a-t-il dans chaque pod ? Il est possible de mettre beaucoup de sidecars, mais il ne faut pas oublier le coût de ceux-ci en ressources : le minimum de sidecar il y a, plus légers et rapides seront les pods à démarrer.
  • Optimiser les placement de pods : il est important de gérer la répartition des ressources sur un cluster Kubernetes, notamment :
  • En définissant la moyenne basse d'utilisation de ressources pour que l'application puisse tourner et lui attribuer cette quantité de ressources.
  • En définissant une moyenne haute de consommation de ressources et attribuer aux pods des "limits" que le pod ne pourra pas dépasser et ainsi éviter l'overcommit de ressources.
  • Optimiser la densité des pods VS la taille des pods : certaines applications fonctionnent mieux en scale up plutôt qu'en scale out, il faut donc définir une stratégie d'allocation de ressources avec un juste milieu afin de ne pas avoir une énorme quantité de pods par nœud, mais ne pas non plus au contraire avoir un nœud portant un seul pod. L'expérience et la connaissance des besoins de votre application seront la clef de ce compromis.
  • Optimiser le scheduling via les anti-affinités : certaines applications sont plus gourmandes en CPU, par exemple en général les applications de calcul d'itinéraire géographique, il est donc de bonne mesure de dédier des nœuds à ces pods/applications et empêcher tous les autres pods d'être schedulés dessus via des anti-affinités.
  • Optimiser ses nœuds : règle de base, utiliser les dernières générations de type d'instances. Par exemple, un type c5 peut être plus performant et moins cher de 25% qu'une instance de type c4 ! Il faut aussi savoir utiliser les bons types d'instances par rapport à la consommation de ressources qui sera faite sur ces nodes. Par exemple des containers consommant beaucoup de mémoire devront plutôt tourner sur du type "r", et des containers gourmands en CPU seront de préférences placés sur des nœud de type "c".
  • Les performances réseau : avec le plugin AWS VPC CNI, les pods sont rattachés directement à une ENI attachée à l'host, qui limite les différentes couches réseau selon le plugin réseau utilisé. On limite ainsi le temps d'instanciation d'un pod.

Retour d'expérience

Par la suite, nous avons eu un retour d'expérience sur l'optimisation et le scale out d'une base de données déployée sur un cluster Kubernetes suivi par une live démo.


Postgresql best practices

Ce talk présenté par Jim Mlodgenski est un deep dive PostgreSQL sur RDS.

Jim commence par faire un état des lieux des versions de PostgreSQL, la version 10 notamment compatible avec Aurora depuis peu, et la version 11 en preview, mais nous y reviendrons plus tard.

Il recommande ensuite fortement de forcer le chiffrement SSL/TLS lors de connexions (rds.force_ssl 1).
Toujours sur la partie accès à la base PostgreSQL, Jim nous explique la marche à suivre pour utiliser IAM authentication :

  • L'utilisateur doit avoir un nom identique à celui enregistré en base de données
  • Il faut également créer une policy IAM qui permet d'authentifier l'utilisateur.

Un rapide point sur les types de stockage ainsi que les types d'instances RDS supportés par PostgreSQL conclut cette introduction.

Optimisation

L'idée générale à retenir ici est qu'il faut toujours éclater les tables les plus larges pour augmenter les performances.

Performances

Sous PostgreSQL 10 et 11, les performances sont bien plus poussées qu'en version 9.6. Par exemple, sur une query en PostgreSQL 9.6 on passe de 1600 ms à 400 ms sur la version 11, soit environ 74% de gain de performance.

Monitoring

AWS offre un pannel d'outils permettant de monitorer convenablement les bases PostgreSQL. Performance Insight est un excellent outil, une fenêtre ouverte sur ce qu'il se passe dans la base. Autre tips de Jim Mlodgenski, toujours penser à activer pg_stat_statements, cela permet d'avoir toutes les statistiques d'exécution des instructions SQL. Cela va de soi, mais il recommande également de monitorer la RAM, le CPU et l'espace disque, bien sûr CloudWatch offre toutes ces possibilités nativement avec les base RDS.

Conclusion

En résumé, toujours utiliser le multi-AZ, activer les backups automatiques, forcer la terminaison SSL lors d'une connexion aux bases et être exemplaire sur le monitoring.


DynamoDB Deep Dive

What happens under the hood of DynamoDB?

James Sorenson nous présente ici quelques éléments qui composent DynamoDB, et commence par définir les objectifs de ce talk : donner une vision plus détaillée de certains éléments comme le stockage, la sauvegarde ou la gestion des indexes.

Stockage, PutItem & GetItem

Dans un premier temps James nous parle du processus de getitem/putitem. Ce qu'il faut retenir ici, c'est que lors d'un get, Dynamo ne sollicite qu'un storage node (appelé leader), tandis que lors d'un put, du fait de la réplication, Dynamo déploie la données sur trois nœuds de stockage (là ou sont les SSD), en commençant par le leader.

Autre information, DynamoDB utilise Paxos dans la gestion des nœuds de stockage.

Les Tables sur DynamoDB

Les tables DynamoDB, qui utilisent un système de clé/valeur, se voient attribuer une valeur de hash, celui-ci permet de trier les données en interne.

Les noeuds de stockage en détails

Ici, un peu plus de détails sur le stockage de DynamoDB. Les noeuds de stockage DynamoDB sont composés d'un "B-tree" et de logs de réplication. Le "B-tree" regroupe les interactions, les queries et les scans, tandis que les logs de réplication contiennent toutes les mutations ayant eu lieu sur un base.

La santé des nœuds de stockage est assurée par l'outil "auto admin", qui s'occupe notamment de réparer, si cela est nécessaire les partitions. James nous explique que "Auto Admin" est un véritable DBA pour DynamoDB, car "un être humain ne peut pas gérer un système qui scale autant que DynamoDB".

Modification des indexes secondaires

Lorsqu'une modification a lieu sur un index secondaire, c'est le "log propagator", autre élément de DynamoDB qui se charge de mettre à jour un index depuis la table principale.

A chaque problème sa solution

James nous explique ici que DynamoDB fournit une solution de provisionning par charge de travail, le burst pour des des workload très aléatoires, "l'adaptive capacity dans le cadre du stockage, ou encore l'auto scaling. Ce qu'il faut retenir ici c'est que de nouvelles améliorations sont à venir.

Les sauvegardes

Lors d'une sauvegarde ce sont les logs de réplication qui sont uploadés sur s3 ainsi qu'un snapshot du b-tree, les deux éléments qui composent en réalité le nœud de stockage.


Infrastructure as Code: AWS Best Practices

La session, assurée par Leah Riverts et Alex Wood, se concentre essentiellement sur le CDK, le nouveau kit de développement CloudFormation haut niveau, disponible en preview. Ce nouvel outil, assez impressionnant, permet de générer automatiquement des centaines de lignes de templates CloudFormation à partir de seulement quelques douzaines de lignes de TypeScript ou JavaScript.

Basée sur une philosophie de type “opinionated expressiveness” qu’on n’osera pas traduire : essentiellement, le kit va présupposer certaines caractéristiques de notre infrastructure sauf avis contraire comme par exemple :

  • La création de tous les rôles IAM avec les bonne policies
  • L’affectation des instances EC2 ou des services ECS à des subnets privés, les Load Balancers aux subnets publiques

Pour résumer, CDK simplifie énormément les templates CloudFormation tout en automatisant l’application des best practices. L’outil est open source et disponible sur GitHub. Toujours en preview, on est encouragés à jouer avec et à l’améliorer, mais il faudra être prudent et attendre un peu avant de l’utiliser en production.


Introduction to Version 3 of the AWS SDK for JavaScript (TypeScript)

Le SDK JavaScript fait peau neuve et Christopher Radek, un des développeurs du projet, profite du re:Invent pour nous montrer les nouveautés :

  • Toutes les méthodes retournent maintenant des promesses. Auparavant, il fallait ajouter .promise() à la fin de chaque appel pour avoir le même effet. On abandonne donc définitivement le modèle historique des callbacks.
  • Le langage TypeScript est préféré, même si JavaScript reste disponible. L’utilisation de TypeScript, fortement typé, diminue la probabilité d’erreur et facilite une assistance automatique très pratique dans l’éditeur (VScode lors de la demo).
  • Le SDK a été complètement modularisé : chaque service représente désormais un package npm séparé, ce qui permet d’obtenir un package final beaucoup plus petit. On peut même aller plus loin et importer seulement la méthode dont on a besoin.
  • La configuration globale disparaît au profit d’une configuration qui doit être passée pour chaque client déclaré. C’est une conséquence importante de la séparation en modules.
  • Autre conséquence de la modularisation : la partie du SDK qui permet de signer des requêtes API est maintenant beaucoup plus facile à importer séparément. Très pratique pour ceux qui doivent signer, par exemple, des requêtes API Gateway avec authentification IAM.
  • Des couches middleware peuvent être ajoutées très facilement pour personnaliser au maximum les appels du SDK.

L’utilisation de la v3 est globalement très similaire à la v2, et cela facilite énormément les migrations. Pensez bien à enlever tous vos .promise() ! Le projet est disponible sur GitHub, open source, et en phase de "developer preview".

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way