J'ai récemment décidé d'expérimenter l'API sur notre site Web CardGames.io et d'essayer le framework Serverless . Au cours des dernières années, c'est devenu un sujet brûlant dans le monde de la technologie, et j'ai tergiversé, je voulais garder mes compétences techniques à jour et essayer quelque chose de nouveau. Par conséquent, j'ai décidé de passer plusieurs heures à étudier sans serveur et de voir s'il y avait un sens à un tel placement d'API.

Configuration actuelle

CardGames.io fonctionne sur AWS. Toutes les pages html, CSS, JavaScript et images sont stockées dans S3. Nous avons une API C # hébergée sur Elastic Beanstalk, elle fonctionne sur des serveurs Linux exécutant .NET Core avec Docker. Enfin, nous utilisons CloudFront CDN avant la statique sur S3 et API. Vous trouverez ci-dessous le score EC2 pour août 2019. Nous avons plusieurs autres instances, mais les API fonctionnent sur m1.small (oui, t2.small fonctionne probablement mieux) avec un équilibrage de charge classique. Si vous résumez le surligné en rouge, alors 164,21 $ par mois sortent, pas mal. J'ai même inclus EBS là-bas, parce que je ne sais pas comment briser ces dépenses, nous avons plusieurs projets sur EC2.


Compte AWS pour Elastic Beanstalk

Nous avons deux environnements avec 1 à 3 instances chacun: actif et inactif, car le déploiement de .NET Core dans Docker sur AWS prend plusieurs minutes, nous le faisons donc dans un environnement inactif, puis basculons les enregistrements CNAME sur celui récemment déployé. Un déploiement lent était l'une des raisons pour lesquelles je voulais essayer quelque chose de nouveau. Nous avons plusieurs serveurs avec des applications node.js sur Beanstalk - et ils sont déployés en quelques secondes. Je voulais que ce soit la même chose pour l'API.

Passer à Serverless

J'ai étudié un très bon tutoriel d' hébergement d'API Web ASP.NET avec le framework Serverless et j'ai constaté que vous n'avez besoin que d'ajouter un fichier de configuration simple, une dépendance et une petite classe de démarrage à un projet d'API existant. Le déploiement a pris environ vingt secondes, bien mieux que dans Beanstalk. Je pense que grâce à la prise en charge intégrée de .NET Core dans Lambda (cependant, seulement 2.2), tandis que dans Beanstalk, il n'est pris en charge que si vous utilisez un docker indépendant. Dans tous les cas, j'étais heureux sans penser aux groupes de mise à l'échelle automatique, aux instances max et autres.

Test de performance

Sans serveur sur AWS est Lambda, qui héberge vraiment vos fonctionnalités, et l'API Front Gateway, qui vous permet d'ajouter des éléments tels que les limites de vitesse, les clés d'API, etc. J'ai hébergé les fonctionnalités Lambda dans la région us-west-2, où se trouvent les serveurs Beanstalk. J'ai ensuite configuré l'instance CloudFront pour acheminer les demandes de l'un de nos jeux vers la nouvelle configuration sans serveur, et l'autre vers l'ancienne configuration Beanstalk. Il a ensuite lancé un test simple sur deux URL: l'une sans serveur, l'autre Beanstalk. Les deux URL ont invoqué la même API, stockant le même événement dans la base de données. J'ai exécuté 100 requêtes pour chacune, voici les résultats:


Comparaison des performances

Dans plusieurs exécutions, la configuration sans serveur était 15% plus lente (si je l'ai fait, je l'ai exécutée depuis l'Islande, d'où le grand ping). La vitesse a été une déception, mais elle est restée assez élevée - je me suis rendu compte qu'il y avait des frais généraux sur le devant de la passerelle API devant notre API: il y a trop de fonctions, même si nous ne les utilisons pas. Donc, triste, mais pas critique!

Les prix

Honnêtement, au début, je ne pensais pas aux prix. Je viens de décider que payer pour une utilisation réelle serait probablement moins cher que de payer pour des instances 24/7. Par conséquent, il a permis à la nouvelle installation sans serveur de fonctionner pendant plusieurs jours, puis a commencé à vérifier les comptes. Oups! La facture de Lambda + API Gateway a déjà dépassé la centaine de dollars! Au début, j'ai commencé à jouer avec Lambda, en allouant moins de mémoire pour la sauvegarder, mais quand j'ai bien regardé ce qui se passait, il est devenu évident que le problème était avec la passerelle. Voici les tarifs API Gateway:


Tarifs API de passerelle

Notre API accepte environ 10 millions de demandes par jour. Cela représente environ 35 $ par passerelle uniquement chaque jour . De plus, Lambda coûte environ 10 $ par jour, bien que cela puisse être réduit en allouant moins de mémoire. Ensemble, cela représente environ 45 $ par jour, soit 1350 $ par mois , contre 164 $ par mois sur Elastic Beanstalk. Huit fois plus cher ! J'aime les nouvelles technologies et un déploiement rapide, mais je ne vais pas payer 1200 $ de plus par mois pour cela. Retour à Beanstalk!

Conclusion

Probablement, j'aurais dû me familiariser avec les prix à l'avance et faire des calculs mathématiques! Mais bien sûr, alors je devrais faire un vrai travail et ne pas acquérir de précieuses compétences techniques! Je suis sûr que dans certaines situations, les API Gateway et Lambda sont meilleures que Elastic Beanstalk. Ce n'est tout simplement pas notre cas. Peut-être que si vous utilisez des clés API, des limites de vitesse et d'autres fonctions de passerelle API, il est logique de payer 3,50 $ par million de demandes. Nous ferions mieux de mettre un équilibreur de charge normal devant Lambda. Pour autant que je sache, ce n'est pas possible; une API de passerelle est requise pour l'accès http à Lambda.

Mais même si nous venions de payer Lambda, à 10 $ par jour, cela aurait rapporté 300 $ par mois au lieu de 164 $. Nous avons de nombreuses requêtes, mais chaque requête fait très peu: en gros, un appel DB par requête. Peut-être que les requêtes plus lourdes qui utilisent plus de temps de calcul conviennent mieux à Lambda, où vous payez pour 100 ms de temps de calcul. Voici un rapport pour une demande. Comme vous pouvez le voir, nous utilisons 3,50 ms de temps de calcul, mais la facture est fixée à 100 ms, ce n'est pas un arrondi faible.


Rapport Lambda pour une demande

Enfin, je ne critique absolument pas les API Gateway, Lambda ou Serverless. Juste pour montrer que pour certaines charges de travail, ils sont beaucoup plus chers que l'ancien ennuyeux EC2 et Elastic Beanstalk. Sur ce que nous resterons. Il est également probable qu'il existe un moyen bien meilleur ou plus efficace de configurer le système, je ne suis en aucun cas un expert AWS, donc si vous voyez des erreurs flagrantes, assurez-vous de l'indiquer dans les commentaires.