La galaxie des coûts du cloud

La galaxie des coûts du cloud

Cet article est la première partie de notre série sur les coûts du cloud. Elle s’intéresse aux coûts des machines ; la seconde partie étudie le coût humain de la gestion de l'infrastructure web.

Qui s’est déjà servi d’un fournisseur de cloud (aws, gcp, azure, …) sait que leur système de tarification ressemble de près à une hydre aux mille têtes. Ajoutons à cela des données rares sur les fréquences des pannes et complétons par des coûts humains (temps passé par les développeurs, compétences à maintenir à jour…) souvent oubliés : on a rarement une bonne vision des coûts engendrés par une infrastructure web, encore plus rarement du juste prix auquel on devrait payer celle-ci.

Aussi, pour éclairer la constellation des coûts du cloud, cet article a décidé de cerner au plus près les différents pôles de dépense liés à une infrastructure web, d’identifier leur prix, les gains qu’ils apportent ; enfin de comprendre comment optimiser son usage du cloud.

À cette fin, pour rendre nos descriptifs plus précis et concrets, nous suivrons en fil rouge une application utilisant la stack MEAN : inspiré d’un cas réel, nous considérons un site de vente en ligne observant 100 000 personnes de passage par mois, ayant 20 000 clients par mois et générant 10 euros par client.

Ce premier article s’intéresse au coût des machines ; un second étudiera les coûts humains de gestion de l’infrastructure web.

TL; DR

Selon l’architecture de l’infrastructure et selon les choix des technologies cloud employées, à performance équivalente, les dépenses liées aux machines peuvent varier de 1 à 4.

En fil rouge

Dans notre exemple fil rouge, notre application utilise la stack MEAN : Angular, Node.js et mongoDb.  Ainsi, la charge de notre application se résume par :

  • 100 000 utilisateurs par mois, 20 000 clients, 200 000 de CA
  • en temps normal, 1 CPU, 2 Go RAM
  • aux moments les plus critiques : 10 CPU, 20 Go RAM
  • base de données avec 200 kO par utilisateur et inférieure à long terme à 2 Go.

Prix des instances Node.js

Commençons par regarder le coût des machines servant à faire tourner le back de notre application, notre serveur en Node.js

Comparaison entre différents fournisseurs de cloud

Afin d’harmoniser les tarifs, nous nous basons sur le coût d’une instance à un CPU, 4 Go RAM. Lorsque le fournisseur de cloud ne dispose pas d’instance de ce type, nous prenons l’instance supérieure en capacité la plus proche et divisons son tarif par le nombre de CPU pour se ramener à une capacité comparable.

Pour la région, nous utilisons chaque fois la région la plus proche de Paris.

Prix d’une instance Node.js (un CPU ; 4 Go RAM) à la demande selon les différents clouds au 24/04/22 — région France ou UE

Prix d’une instance Node.js (un CPU ; 4 Go RAM) à la demande selon les différents clouds au 24/04/22 — région France ou UE

Entre azure et ovh, un écart de 35% existe. AWS se situe au milieu.

À la webcapsule, nous utilisons AWS. En effet, ce cloud est compétitif au niveau des prix et propose de nombreuses innovations qui facilitent les performances et la gestion des infrastructures web.

Comparaison entre différents services AWS

null

Prix pour 1 CPU, 4Go de RAM au sein d’aws au 24/04/22

On remarque une grande disparité des prix au sein du cloud aws, allant du simple au triple. Le passage en serverless (technologie aws Fargate) peut s’accompagner d’un surcoût important si l’on n’y prend garde. Ainsi, à application et capacité identique, le prix final dépend du choix de la technologie AWS employée.

Les instances SPOT sont peu chères, mais elles sont complexes à bien utiliser.

Quelle est alors la bonne offre à utiliser au sein d’AWS ?

Comparaison entre deux architectures

 →Stratégie du monolithe Cette stratégie a parfois existé. Elle nous sert surtout de référence conceptuelle pour un usage a minima des technologies cloud, bien qu’en pratique elle soit peu employée. Elle consiste à lancer une instance une fois pour toutes et à ne quasi plus s’en préoccuper par la suite.

On peut surcalibrer cette machine afin d’avoir l’esprit serein ou bien la calibrer au plus juste des besoins afin de payer le moins possible.

On remarque que, sur AWS, les instances burstables se mettent naturellement à l’échelle quant au CPU. Le facteur de dimensionnement principal est alors ici la mémoire. Au vu du pic attendu, on peut opter :

  • pour une machine t4gx.2large : 8 CPU, 32 Go RAM, en acceptant certains problèmes de performances au moment des pics. Coût mensuel : 122 €/mois
  • pour une machine m5.4xlarge : 16 CPU, 64 Go RAM, en surdimensionnant. Coût mensuel : 283 €/mois

→Stratégie clustering On décide de virtualiser l’application via docker et d’ainsi pouvoir mettre en place des plans de montée en charge. On utilise les technologies serverless. On considère, pour le calcul des coûts, que la somme sur un mois de CPU dépensé est de deux. (1 présent en permanence, et jusqu’à 10 CPU au moment des pics de charge => 2 en moyenne)

Là encore, deux manières de faire sont possibles :

  • la plus rapide est d’utiliser aws Fargate — on ne gère aucun serveur. Coût mensuel : ~ 100 €/mois
  • la plus optimisée est d’utiliser aws ECS par dessus des instances EC2 réservées et des instances spot Coût mensuel : ~ 20 €/mois
null

Coût du back selon la stratégie employée au 24/04/22

Prix de la base de données

La base de données doit être disponible en permanence. Il faut aussi en gérer les backups. Les solutions de gestion les plus efficaces sont donc les bases de données autogérées. Nous mentionnons cependant pour notre base de données fil-rouge, ce que coûterait une instance ec2 comme un point de comparaison.

null

Coût de différents services de base de données au 24/04/22

La tarification de mongoDb est relativement moins chère quoique comparable au service auto-géré par AWS. On remarque un écart important entre l’instance ec2 et le prix du cluster de base de données. En effet, d’une part, le dimensionnement d’un cluster impose comme point d’entrée des capacités supérieures à celle que nous utiliserions. D’autre part, une instance autogérant une base de données est facturée environ deux fois plus chère par AWS.

Prix des autres éléments d’infrastructure

  • pour la stratégie de clustering, il nous faut prévoir une application load balancer. Celle-ci est facturée : 20 €/ mois pour l’application load balancer
  • le front angular est stocké sur s3 et délivré via un CDN : 1 €/mois pour le front
  • on peut considérer l’utilisation d’un pare-feu applicatif (WAF) : 29 €/mois

Dans la suite de nos discussions, comme la pratique du WAF est peu répandue, nous ne l’intégrons pas dans les coûts mentionnés.

Enfin, notons que Flexera rapporte, dans son état du cloud annuel, que 33% des dépenses du cloud seraient perdues en éléments inutiles : machines oubliées, configurations surdimensionnées, modifications multiples…

Somme des coûts directs

Ainsi, selon la stratégie employée, en affectant à chacune l’ensemble des éléments nécessaires, on obtient :

null

Coût des éléments d’infrastructure selon la stratégie choisie

Cependant, à ces dépenses directes, il faut ajouter les coûts liés aux pannes potentielles des machines et aux interruptions de service que chaque stratégie engendre.

Fréquence et coût des pannes de service

Les statistiques sont rares sur le nombre de pannes des machines ou des datacenters dans le cloud. En effet, ces technologies sont encore relativement récentes et les données semblent soigneusement gardées par les fournisseurs de cloud. On peut cependant recouper différentes sources d’informations et s’essayer à des analyses pour en estimer la fréquence et le coût.

Coût d’une interruption de service

Le chiffre d’affaires moyen sur notre application est de 268 €/h. Nous considérons donc que la perte liée à une heure d’interruption de service est de 268 €/h.

Ce montant demeure inexact en deux sens opposés. En premier lieu, il ne tient pas compte des pertes d’image et de confiance que l’interruption génère auprès des utilisateurs et qui se traduisent ensuite en des pertes financières. En second lieu, il néglige le report des utilisateurs sur des horaires différents, qui diminue le coût de l’interruption.

Durée de vie d’une machine isolée

Le niveau de disponibilité garanti par aws pour une instance ec2 isolée sur un mois est de 90%. Si l’on se fie à différents retours d’expérience, le taux d’indisponibilité d’une machine en temps normal est d’environ 1% par mois. Cela donne une durée de vie d’un serveur de 8 ans. À ce taux normal, il faut inclure tous les événements rares qui peuvent rendre une région indisponible — incendie, bugs… En considérant qu’un événement se produirait une fois par 20 ans, on peut donc estimer qu’un serveur isolé restera en vie environ 5 ans.

En outre, dans une architecture avec une machine isolée, il faut une bonne journée (mise à jour à faire, backup à retrouver) pour pouvoir rétablir le service.

Ainsi, on obtient le coût d’interruption suivant :

  • coût de l’interruption de service : 6432 €
  • coût de la panne amorti sur 5 ans : 107 €/mois

On peut considérer que ce coût s‘applique de manière équivalente pour toute architecture avec un single point of failure.

Indisponibilité d’une région AWS

Ici, les données sur le nombre d’incidents sont encore plus rares. Aws s’engage sur des niveaux de disponibilité. Cependant, ceux-ci nous éclairent finalement peu sur la disponibilité réelle. En effet, par exemple, pour un service comme le load balancer, aws s’applique des pénalités dès 5 minutes d’indisponibilité. On pourrait donc croire que ces pénalités contraignent l’entreprise. Cependant, les dédommagements sont seulement de 10% du coût mensuel du service si l’interruption du service dure moins de 8h. Cela revient à un dédommagement de 2€ pour une indisponibilité de l’ensemble de l’infrastructure de plusieurs heures. AWS s’engage finalement très peu.

Or, des incidents peuvent exposer une région entière et avoir lieu tous les de 2 ans environ. Ces incidents durent quelques heures. Il est en outre difficile pour quelques heures de migrer l’application sur une autre région. Enfin, les services reviennent sans intervention humaine à la normale une fois l’incident résolu.

On peut donc considérer que, pour une stratégie en cluster, le coût lié aux interruptions est d’environ : 22 €/mois, 20 €/mois avec dédommagement d’aws.

null

Coût d’une interruption de service selon l’architecture

Synthèse des coûts liés aux machines

En prenant en compte l’ensemble des coûts liés aux différentes architectures d’infrastructure web, on obtient les coûts suivants.

null

Coût complet des machines selon la stratégie d’accès au cloud

Cependant, à ces dépenses directes, il faut ajouter les coûts liés aux pannes potentielles des machines et aux interruptions de service que chaque stratégie engendre.

Nous avons donc chiffré l’ensemble des dépenses liées aux machines. Cependant, le coût total de la gestion ne s’arrête pas là.

Il faut en effet être en mesure de modifier l’application, de gérer l’infrastructure et ses mises à jour. Il nous reste donc à prendre en compte les coûts humains de la gestion de l’infrastructure, ce que nous ferons dans un prochain article.