DEV Community

Cover image for La valeur du serverless : un exemple concret
Paul SANTUS
Paul SANTUS

Posted on

La valeur du serverless : un exemple concret

J'entends souvent dire que les services managés, en particulier les services serverless, sont coûteux. Je voulais donc vous raconter cette histoire vécue.

Avant de le faire, permettez-moi de vous rappeler que les fournisseurs de cloud proposent très souvent de nombreuses options pour exécuter une charge de travail. Un mantra d'AWS est « nous préférons ET plutôt que OU ». Prenons l'exemple des files d'attente (queues) :

  • Vous pouvez configurer des instances EC2 et exécuter Rabbit MQ par-dessus celles-ci.
  • Vous pouvez également faire la même chose avec des conteneurs sur ECS/EKS. Plus de système d'exploitation à gérer.
  • Vous pouvez également utiliser AWS MQ pour RabbitMQ. Plus de logiciel à gérer.
  • Vous pouvez également utiliser AWS SQS. Plus de frais horaires, et pas de planification de capacité !

Revenons maintenant à mon histoire. Un de mes clients avait besoin d'un système de cache pour conserver les données de sessions, afin que tous les conteneurs de son application partagent le contexte utilisateur.

Comme nous ne voulons pas gérer de serveurs, AWS Elasticache pour Redis était la solution évidente. Mais comme mon client avait besoin de très peu de mémoire cache (moins de 50 Mo), nous avons utilisé des instances cache.t4g.micro. Une seule instance en développement, un petit cluster de 2 instances en pré-production et en production.

Pendant quelques mois, tout s'est bien passé. Notre système a fonctionné sans problème. Cependant, un jour, 6 heures après une mise en production, le système a planté. De fait, un site d'e-commerce ne fonctionne pas bien sans cache de sessions.

Ce qui s'est passé, c'est que la version nouvellement mise en production a ajouté juste un tout petit peu de charge sur le cache, ce qui a conduit à un débit réseau plus élevé. Les instances T4 ont un débit de base et une réserve de débit pour les pics de charge, mais si votre application consomme plus que la base pendant une longue période, la réserve se vide et l'instance devient presque injoignable. (Ce mécanisme est bien connu sur le processeur des T4, moins sur la couche réseau)

Le débit réseau aux alentours de la mise en production

Cela a pris un peu de temps pour diagnostiquer et rendre au système sa pleine capacité opérationnelle. Ce qui implique :

  • une perte de CA pour mon client, et un impact sur la réputation.
  • du temps de ses salariés + de son consultant préféré pour diagnostiquer, restaurer puis faire évoluer le système.

Tout cela parce qu'il était considéré comme trop coûteux d'utiliser la version Serverless, car son stockage minimum de 1 Go signifiait que le coût serait d'au moins... ~106 $/mois.

Quand c'est arrivé, AWS avait publié quelques mois avant Elasticache pour Valkey (un fork de Redis, qui a annoncé sa sortie du monde open-source) qui a un stockage minimum inférieur (100 Mo) et coûte 30% de moins. Nous avons donc fini par déplacer tous les environnements sur cette solution.

Avec la version sans serveur d'Elasticache, nous n'avons plus à nous soucier que de la quantité de mémoire cache que nous utilisons et du nombre de requêtes que nous effectuons. Et ceci uniquement d'un point de vue FinOps, pas pour des considérations de fiabilité. AWS a supprimé toute la charge de surveillance des métriques du serveur, telles que le processeur, le débit, les IOPS, etc.

Quelques points à emporter de la lecture de cet article :

  1. À moins que vous n'ayez une équipe d'exploitation dont la tâche consiste exclusivement à surveiller les serveurs, utilisez le serverless.
  2. Considérez le coût total de possession (TCO), et pas seulement le coût du service, lorsque vous prenez ces décisions d'architecture. (Le stockage est bon marché, le calcul l'est moins, mais le temps humain est à tous égards la ressource la plus coûteuse dont vous disposez).
  3. Le compromis est presque toujours en faveur du serverless, à moins que vous n'ayez un débit/une charge très élevés sur votre service. Dans ce cas seulement, il peut être intéressant de déployer et de surveiller les serveurs.
  4. Surveillez en permanence les nouveautés d'AWS, car AWS offre régulièrement de nouvelles options qui devraient vous amener à reconsidérer les décisions d'architecture passées (enregistrez les éléments de justification de ces décisions, afin que vous puissiez les reconsidérer avec moins d'efforts)
  5. Chaque fois que vous utilisez des instances T4, surveillez non seulement les crédits CPU, mais aussi les métriques "network allowance" !
  6. Surveillez vos systèmes autour des mises en production (j'y reviendrai bientôt).

J'espère que cet article vous évitera quelques incidents de production !

Heroku

This site is built on Heroku

Join the ranks of developers at Salesforce, Airbase, DEV, and more who deploy their mission critical applications on Heroku. Sign up today and launch your first app!

Get Started

Top comments (0)

Heroku

Build apps, not infrastructure.

Dealing with servers, hardware, and infrastructure can take up your valuable time. Discover the benefits of Heroku, the PaaS of choice for developers since 2007.

Visit Site

👋 Kindness is contagious

Explore a sea of insights with this enlightening post, highly esteemed within the nurturing DEV Community. Coders of all stripes are invited to participate and contribute to our shared knowledge.

Expressing gratitude with a simple "thank you" can make a big impact. Leave your thanks in the comments!

On DEV, exchanging ideas smooths our way and strengthens our community bonds. Found this useful? A quick note of thanks to the author can mean a lot.

Okay