Plusieurs articles sur les architectures AWS API Gateway et AWS Lambda pointaient du doigt certains problèmes tout en reconnaissant les nombreux avantages de ces nouvelles stacks.
Nous avons lancé un projet pilote 100% Serverless sur Amazon Web Services afin de nous faire notre propre idée.

L’objectif était le suivant :

• Offrir une API REST de recherche utilisant ElasticSearch comme moteur de recherche
• Scalabilité totale
• Temps de réponse lors des pic à 600 requêtes par seconde :
  • Moyenne < 40ms
  • p50 < 10ms
  • p95 < 90ms
  • p99 < 200ms
• Rester dans des couts comparables à une architecture REST classique
• Temps avant mise en production : 1 mois

Stack recherche :

Un mois plus tard l’architecture déployée est la suivante :

Les API de recherches s’articulent autours d’un cluster elasticsearch managé sur AWS.

• L’indexation est réalisée dans manière incrémentale dès qu’une nouvelle annonce est publiée
• La réindexation est assurée par un workflow Stepfunction
• Enfin l’API de recherche est constituée d’une AWS Lambda dans le VPC, exposée sous forme d’API REST avec AWS API Gateway + un cache cloudfront en frontal.

Le langage utilisé dans les lambdas est le JAVA. La stack est déployée à l’aide de Serverless et de AWS Cloudformation.
Le code n’utilise aucun framework et importe un nombre minimal de librairies externes afin de réduire au maximum la taille du livrable.

Performances :

Deux architectures de cache ont été testées en charge avec l’outil Gatling Frontline.
Dans la première le cache est réalisé par API Gateway. Dans la deuxième c’est Cloudfront qui assure le cache.

Dans les deux cas le TTL du cache est réglé à 5 minutes.

Hits dans le cache :

Les differences de performances se situent au niveau des hits effectués dans le cache :

Les performances du cache sont bien meilleures avec Cloudfront. le temps de réponse pour 75 percentiles est en dessous de 5ms avec Cloufront VS 11ms avec le cache d’API Gateway.

Hits hors cache :

Si l’on s’intéresse aux requêtes qui ne sont pas cachées (recherche avec une géolocalisation ou un prix précis), c’est API Gateway qui tire son épingle du jeu.

Lorsque Cloudfront doit aller chercher l’information sur le service REST on constate un délai moyen ajouté de 30ms par rapport à un accès direct.

Dans notre cas nous avons opté pour Cloudfront pour les raisons suivantes :

• Le taux de cache prévu était de 60 à 70%
  • Le gain sur le cache était de 50% contre une perte pour hors cache de environ 30%
• Le cout global du service était bien inférieur avec Cloudfront (hypothèse de 20 Millions de requêtes journalière à l’API falsifié pour l’article) :
  • Cloudfront : $2,60 par jour
  • API Gateway : $33,5 par jour
• Cloudfront permet de controle le cache plus finement grâce à L’en-tête (header) HTTP Cache-Control , ce qui n’est pas disponible sur le cache d’API Gateway pour lequel la valeur par défaut s’applique à toutes les requêtes (Juillet 2017).

Conclusion :

En production

Cette architecture est en production depuis mi-juillet et fonctionne bien. La mise en ligne a été possible comme prévu en 1 mois mais l’équipe n’en était pas à sa première lambda avec le framework Serverless.
Il s’agit tout de même de la plus grosse API REST Serverless déployé chez Car Boat Média à ce jour.

Les écueils

Nous avons rencontré quelques problèmes lors de ce projet qui se sont révélés non bloquant mais qui font aujourd’hui l’object d’études pour corrections chez AWS.

Déploiement

Le redéploiement actuel de la stack génère un indisponibilité temporaire générant environ 200 appels en erreur sur l’API.

La présence dans le VPC de la lambda crée un nombre important d’ENI (Une ENI par invocation simultanée car notre lambda est configurée avec 1,5GB de mémoire : voir formule), lors d’un redéploiement le remplacement des ENIs existante par de nouvelles est donc important et crée des erreurs et timeout.
Nous avons décidé de sortir la lambda du VPC et je recommanderais en ne jamais mettre de lambdas dans le VPC sauf impératif technique.

Performance

Sous la charge certain appel de lamdba sont long (plusieurs secondes) du fait du cold start des nouvelles lamdba entrant dans le pool de lambda à disposition d’API Gateway. Nous avons ouvert une feature request chez AWS pour l’amélioration de ce point.

Ce problème n’impact que 0.0014% de requête utilisateur.