Le coût de l’Infrastructure devient un driver de l’architecture
Le design de l’architecture ainsi que le choix des services Cloud utilisés ont un impact direct sur les coûts. Ainsi, une architecture correcte sur le plan technique peut s’avérer être très impactante sur le plan financier.
Trois modèles de coûts peuvent être obtenus en fonction de l’architecture utilisée :
- Modèle 1: Les coûts croissent par palier. C’est le modèle obtenue traditionnellement avec l’usage de services IaaS basés sur des VM et du stockage,
- Modèle 2: les coûts croissent linéairement avec le trafic et restent très limités lorsque le trafic est faible,
- Modèle 3 : Les coûts croissent exponentiellement avec le trafic. L’architecture n’est pas adaptée au besoin.
Modèle 1 : Architectures traditionnelles basées sur des services IaaS
L’architecture est basée sur l’usage de service IaaS et donc de VM et de stockage. Il est donc nécessaire de déployer un certain nombre de VM et de stockage pour supporter le trafic nominal entrainant un coût d’infrastructure incompressible même en cas de très faible trafic.
Lorsque le trafic augmente, il est nécessaire au-delà d’un certain seuil d’augmenter le nombre de VM et la quantité de stockage faisant grimper les coûts par palier.
L’infrastructure déployée doit toujours être en surcapacité par rapport au trafic réel afin de supporter les pic de charge entraînant un surcoût.
Prenons l’exemple classique d’une plateforme e-commerce permettant de :
- Présenter son catalogue en ligne
- Effectuer des commandes
- Envoyer des emails pour la confirmation de la commande et le suivi de la livraison
- Suivre les commandes effectuées
Cette plateforme devra fonctionner 7/7j 24/24h, être hautement disponible, scalable et doit pouvoir évoluer facilement pour supporter une forte augmentation du trafic
Dans ce modèle, l’architecture de cette plateforme utilisera les ressources suivantes :
- 2 serveurs Web pour servir les pages Web du portail
- 2 API Gateway permettant d’exposer les API des services de la plateformes
- 2 serveurs pour le déploiement des services
- Une base de données SQL (Par exemple Postgre SQL) redondée en mode Actif / Passif
- 2 serveurs pour le déploiement d’un gestionnaire de file de message utilisé pour stocker les demandes d’envoi de mails
- 2 serveurs pour déployer les services de traitement de ces messages
- 2 serveurs de mail
Les hypothèses de volumétrie utilisées pour le calcul des coûts d’infrastructure sont données en annexe.
Tous les composants sont doublés afin d’assurer la haute disponibilité
Le coût de cette infrastructure déployée en Irlande sur AWS (Tarif au 01/01/2021 avec des VM réservées sur 1 an C5 Large 2 vCPU et 4 Go de RAM et R5XLarge 4 vCPU, 32 Go de RAM pour la base de données) est de :
- 1142 $ par mois avec des serveur Linux et une base de données Open Source Postgre-SQL
- 2917 $ par mois avec des serveurs Windows et une base de données SQL-Server
On peut noter que l’utilisation de serveurs Windows et d’une base de données SQL-Server entraîne une très forte augmentation des coûts par rapport à l’utilisation d’un OS et d’une base de données Open Source PostgreSQL sur Linux en raison du coût des licences qui vient s’ajouter aux coûts d’infrastructure.
Modèle 2 : Architectures Cloud native basées sur des services PaaS
L’usage des services PaaS avec une tarification basée sur le volume ou le nombre de transactions permet d’obtenir un coût qui croit linéairement avec le trafic. Le coût étant directement proportionnel au trafic, celui-ci reste très limité lorsque le trafic est faible. Ceci est intéressant lors du démarrage d’un nouveau système pour lequel la charge va croître lentement et particulièrement pour des structures ayant des budgets limités tel qu’une startup par exemple.
Dans ce modèle, l’architecture de notre plateforme e-commerce déployée sur AWS utilisera les services suivants :
- Des Buckets S3 utilisés comme serveurs Web pour le déploiement des pages Web statiques, des images et des scripts JavaScripts du portail
- Une API Gateway
- Des fonctions Serverless Lambda pour l’implémentation des services
- Une base de données NoSQL managée : DynamoDB
- Un gestionnaire de file de message managé Simple Queue Service (SQS)
- Des fonctions Serverless Lambda pour la lecture des messages
- Le service de mail Simple Email Service (SES) pour l’envoi de mails
Tous les services utilisés sont managés, hautement disponible et fortement scalable.
Avec les mêmes hypothèses de volumétrie que précédemment, le coût de cette infrastructure déployée en Irlande sur AWS (Tarif au 01/01/2021) est de :
Modèle 3 : Architectures inadaptées au besoin entrainant une croissance exponentielle des coûts avec le trafic
L’architecture retenue va s’avérer avoir un coût exponentiel à partir d’un certain seuil de trafic. Ce problème ne va pas apparaitre immédiatement mais uniquement lorsque le trafic va croitre fortement. En effet ce genre de comportement est en général constaté avec de très fortes charges comme on peut l’avoir avec une plateforme internet ayant un spectre international : Une plateforme d’e-commerce ou une plateforme de jeu en ligne par exemple.
Dans ce cas, l’architecture doit rapidement être revue afin d’éviter des impacts financiers trop importants.
Ce genre de comportement pourrait être observé en utilisant une base de données relationnelle telle que PostgreSQL ou SQL-Server pour le stockage des données d’une plateforme e-commerce ou d’une plateforme de jeu en ligne ayant plusieurs millions d’utilisateurs et des centaines de milliers d’utilisateurs simultanés. En effet l’infrastructure nécessaire pour obtenir des temps de réponses acceptables est dans ce cas exponentielle à partir d’un certain niveau de trafic.
Dans ce cas, précis, l’usage d’une base de données relationnelle classique est fortement déconseillé et il convient d’utiliser plutôt des bases NoSQL permettant de supporter un très fort trafic à des coûts beaucoup plus faibles.
Le retour d’expérience présenté en 2014 à la conférence AWS reinvent sur l’implémentation du Jeu en ligne des Simpsons est de ce point de vue très intéressant
En conclusion, on peut voir au travers cet exemple classique que les coûts d’infrastructure peuvent varier très fortement selon l’architecture utilisée et que d’une manière générale, l’usage des services PaaS managés et en particulier des services ServerLess permettent de diminuer fortement les coûts et surtout d’éviter la facturation d’une infrastructure en surcapacité.
Annexe :
Hypothèses de volumétrie utilisées pour le calcul des coûts d’infrastructure :
- Ressources statiques du site Web incluant les images des articles du catalogue : 30 Go
- Nombre de clients par jour : 10 000 clients
- Volumétrie des données métier : 50 Go
- Nombre d’email envoyés par jour : 30 000 mails
- Sauvegarde des données métier chaque jour : Conservation d’un historique glissant de 7 jours. Sauvegarde Hebdomadaire : Conservation 12 semaines. Sauvegarde mensuelle : Conservation 12 mois
- Volume de données sortantes par mois : 2 To
