blog reInvent-2019 954x240.png. CB450544124
< < Articles

AWS re:Invent 2019, le bilan par Sébastien Augereau, Architecte chez ekino

17/01/2020

Nous avons, avec Lou, eu la chance de participer à re:Invent 2019, conférence organisée par Amazon Web Services (AWS) qui s’adresse aux développeurs, ingénieurs, administrateurs système, architectes et décideurs techniques de la communauté mondiale du Cloud computing. Cinq jours de conférences et workshops répartis dans 6 grands hôtels de Las Vegas (MGM, Mirage, Venetian, Aria, Bellagio, Encore). Je vous propose de partager avec vous mon top 3 des conférences :

1. Serverless architectural patterns and best practices par Heitor Lessa, Principal Serverless Lead, Well-Architected at AWS

IMG 20191203 134504

En introduction, quelques petits rappels :

Le paramétrage d’une Lambda ne se fait que par un seul critère : la mémoire. Les autres paramètres de performance, que sont cpu et i/o, sont définis proportionnellement à la mémoire allouée. Le coût d'exécution étant un rapport entre la mémoire allouée et le temps d'exécution, avoir beaucoup de mémoire allouée ne veut pas dire forcément que le coût sera plus important, cela peut même parfois être l’inverse. Il existe un outil permettant de faire ce test pour nous : https://github.com/alexcasalboni/aws-lambda-power-tuning

Un certain nombre de patterns sont alors présentés par Heitor Lessa correspondant à des problématiques bien précises. L’orateur agrémente à chaque fois ceux-ci de schémas, et les décline par étape en introduisant des services permettant de répondre aux 5 piliers du Well Architected Framework qui sont :

  • Excellence opérationnelle
  • Sécurité
  • Fiabilité
  • Performance
  • Optimisation des coûts

Ci-dessous, quelques patterns présentés :

  • The comfortable REST : Pattern d’exposition d’API, mêlant API Gateway, Lambda et DynamoDb pour la persistance des données. On découvre par exemple comment créer des métriques CloudWatch personnalisées à travers les logs de sa Lambda (en json) grâce à la nouvelle fonctionnalité sortie en novembre : Embedded Metric Format. Autre fonctionnalité intéressante : il est possible au niveau de l’API Gateway de définir des plans d’usage (dans l’esprit de proposition d’une solution SaaS) associés à une bande passante définie, et pour chacun de ces plans donner une api-key gérée au niveau de l’API Gateway.
  • Call me, “maybe” (principe du WebHook) : Comment résoudre le problème des backend pas aussi scalable que Lambda (exemple de RDS qui peut présenter une limite de concurrence) ? En utilisant Kinesis en tant que buffer, et la nouveauté : il est désormais possible de définir une Lambda Destination, qui en fonction du résultat d'exécution peut rediriger vers une autre Lambda, SNS, SQS, ou EventBridge.

On peut aussi retrouver des idées par ici : https://www.jeremydaly.com/serverless-microservice-patterns-for-aws/.

Quelques outils peuvent être trouvés sur https://github.com/awslabs/aws-lambda-powertools, en Python pour le moment, l’idée est par la suite de fournir cette boîte à outils dans d’autres langages.

Retrouvez la conférence juste ici : https://www.youtube.com/watch?v=9IYpGTS7Jy0&t=

2. Microservices decomposition for SaaS environments par Tod Golding, Principal Cloud Architect, Global SaaS Tech Lead at AWS

IMG 20191206 101937

En introduction, Tod Golding nous donne quelques définitions :

Un micro-service doit être :

  • Autonome
  • Une seule responsabilité
  • Propriétaire et gestionnaire de ses données
  • Testé et versionné séparément
  • Scalable séparément
  • Couplé par contrat
  • Géré par une équipe

Single tenant : les micro-services sont dupliqués par client. Avantages/inconvénients :

  • On sait (à priori) quel est le niveau d’usage de chaque client
  • Pas de bruit de voisinage (le trafic du client A n’impacte pas les performances du client B)
  • Règles de scaling déterministes (on est capable d’analyser le niveau d’utilisation de ce client et de définir des règles de scalabilité en fonction)
  • Limitation de l’impact des problèmes en cas de panne (communément appelé effet de souffle ou “blast radius”)

Multi tenant : les micro-services sont partagés entre tous les clients. Avantages/inconvénients :

  • Ressources partagées
  • Potentiel bruit de voisinage
  • Difficile d’extrapoler sur des patterns d’activités
  • Plus grande sensibilité aux pannes

En tant que fournisseur SaaS on peut faire face à plusieurs profils clients : certains privilégieront la sécurité et donc le cloisonnement (single-tenant) quand d’autres se focaliseront sur la valeur business et le coût (donc le multi-tenant).

Tout n’est pas blanc ni noir, il peut exister des nuances… de gris (toute relation avec un titre de film serait fortuite), on a alors une solution mixte :

  • des microservices transverses en multi-tenant
  • des services plus sensibles en single-tenant

Afin de nous aiguiller, l’orateur nous fait part de quelques bonnes pratiques :

  • Comment gérer les opérations de masse (exemple : import/export de données) qui peuvent être lourdes d’un point de vue charge ? Pour cela il faut gérer ces opérations dans un service dédié et limiter la bande passante sur ce service par tenant.
  • Comment cloisonner d’un point de vue sécurité ces services single-tenant ? Par l’utilisation de rôles IAM.
  • Que faire dans le cas de services utilisant un volume important de données ? Privilégier un modèle de partitionnement par tenant, afin d’éviter des problèmes de performance.
  • Comment gérer les notions de plan et le SLA associé (donc à chaque tenant) ? Le plan Basic pourrait être un micro-service en multi-tenant et dans le cas du plan Business un micro-service dédié pour le tenant
  • Et bien entendu toutes les pratiques DevOps autour de la surveillance/observabilité pour comprendre les profils d’utilisation de ses services, et évaluer l'intérêt ou non de passer un micro-service en single-tenant.

Retrouvez la conférence juste ici : https://www.youtube.com/watch?v=AOfuZN5yo38

3. Best practices for AWS Lambda and Java par Stefano Buliani, Principal, Serverless specialist solutions architect at AWS

Session très intéressante par Stefano Buliani lors de laquelle il analyse en direct la performance d’une Lambda Java, et nous expose les problématiques rencontrées et les solutions apportées. Quelques outils mis en avant lors de cette démo :

  • X-Ray sur Lambda
  • Et bien entendu quand on parle performance, il faut un outil d’injection de charge tel que Gatling

Gatling présente ses résultats sous forme de percentiles (comme beaucoup d’outils de ce genre), ce qu’on peut observer est un p99 constant (99% des requêtes), mais un temps maximum d'exécution très important. Ce phénomène correspond au cold start (temps d’instanciation et d’initialisation de la Lambda avant de pouvoir répondre aux requêtes). Ce “cold start” ne se produit qu’une fois lors d’une exécution régulière, après cela, la Lambda est “chaude” et ne passe plus par cette étape, ce qui explique alors pourquoi le p99 est constant.

Comment faire alors pour réduire ce “cold start” ?

  • Passage du SDK AWS Java en 2.0 et exclusion des dépendances Netty et Apache pour privilégier UrlConnection de AWS
  • Chargement des classes à l’initialisation (via des champs statiques)
  • Fournir toutes les valeurs de configuration connues pour éviter l’auto-discovery
  • Suite à ces 3 changements simples, nous observons une diminution du temps cold start de 47%

Dans l’exemple présenté de Lambda, Guice (framework de DI) est utilisé et la réflexion prend du temps. Quelques solutions sont alors proposées afin de s’en passer :

  • Utilisation de Dagger qui ne se base pas sur le mécanisme de réflexion mais propose des annotations et un annotation-processor.
  • Utilisation de GraalVM, mais comme celui-ci ne gère pas la réflexion, il est alors possible d’utiliser des micro-frameworks qui eux le supportent : par exemple Quarkus et Micronaut (la référence de notre article Micronaut ici). Pour les développeurs Spring pas besoin de tout réécrire car ces micro-frameworks supportent les annotations Spring !

Retrouvez la conférence juste ici : https://www.youtube.com/watch?v=ddg1u5HLwg8

À noter que toutes les sessions sont désormais disponibles sur YouTube.

La suite au prochain épisode...