Efficacité à grande échelle : une histoire d'optimisation des coûts AWS

Publié: 2022-07-22

J'ai récemment lancé une plate-forme d'analyse de crypto-monnaie, attendant un petit nombre d'utilisateurs quotidiens. Cependant, lorsque certains YouTubers populaires ont trouvé le site utile et ont publié une critique, le trafic a augmenté si rapidement qu'il a surchargé le serveur et la plate-forme (Scalper.AI) est devenue inaccessible. Mon environnement AWS EC2 d'origine avait besoin d'une assistance supplémentaire. Après avoir envisagé plusieurs solutions, j'ai décidé d'utiliser AWS Elastic Beanstalk pour faire évoluer mon application. Les choses semblaient bien et fonctionnaient bien, mais j'ai été surpris par les coûts dans le tableau de bord de facturation.

Ce n'est pas un problème rare. Une enquête de 2021 a révélé que 82 % des décideurs informatiques et cloud ont rencontré des coûts de cloud inutiles, et 86 % ne pensent pas pouvoir obtenir une vue complète de toutes leurs dépenses cloud. Bien qu'Amazon offre un aperçu détaillé des dépenses supplémentaires dans sa documentation, le modèle de tarification est complexe pour un projet en pleine croissance. Pour faciliter la compréhension, je décomposerai quelques optimisations pertinentes pour réduire vos coûts liés au cloud.

Pourquoi j'ai choisi AWS

L'objectif de Scalper.AI est de collecter des informations sur les paires de crypto-monnaies (les actifs échangés lors de la négociation sur une bourse), d'effectuer des analyses statistiques et de fournir aux commerçants de crypto-monnaies des informations sur l'état du marché. La structure technique de la plateforme se compose de trois parties :

Scripts d'ingestion de données
Un serveur Web
Une base de données

Les scripts d'ingestion collectent des données provenant de différentes sources et les chargent dans la base de données. J'avais de l'expérience avec les services AWS, j'ai donc décidé de déployer ces scripts en configurant des instances EC2. EC2 propose de nombreux types d'instances et vous permet de choisir le processeur, le stockage, le réseau et le système d'exploitation d'une instance.

J'ai choisi Elastic Beanstalk pour les fonctionnalités restantes, car il promettait une gestion fluide des applications. L'équilibreur de charge a correctement réparti la charge entre les instances de mon serveur, tandis que la fonction de mise à l'échelle automatique a géré l'ajout de nouvelles instances pour une charge accrue. Le déploiement des mises à jour est devenu très simple, ne prenant que quelques minutes.

Scalper.AI a fonctionné de manière stable et mes utilisateurs n'ont plus été confrontés à des temps d'arrêt. Bien sûr, je m'attendais à une augmentation des dépenses depuis que j'ai ajouté des services supplémentaires, mais les chiffres étaient beaucoup plus importants que je ne l'avais prévu.

Comment j'aurais pu réduire les coûts du cloud

Avec le recul, il y avait de nombreux domaines de complexité dans l'utilisation des services AWS par mon projet. Nous examinerons les optimisations budgétaires que j'ai découvertes en travaillant avec les fonctionnalités courantes d'AWS EC2 : instances de performances extensibles, transferts de données sortants, adresses IP élastiques et états de terminaison et d'arrêt.

Instances de performances extensibles

Mon premier défi consistait à prendre en charge la consommation d'énergie du processeur pour mon projet en pleine croissance. Les scripts d'ingestion de données de Scalper.AI fournissent aux utilisateurs une analyse des informations en temps réel ; les scripts s'exécutent toutes les quelques secondes et alimentent la plate-forme avec les mises à jour les plus récentes des échanges cryptographiques. Chaque itération de ce processus génère des centaines de tâches asynchrones, de sorte que l'augmentation du trafic du site a nécessité plus de puissance CPU pour réduire le temps de traitement.

L'instance la moins chère proposée par AWS avec quatre vCPU, a1.xlarge, m'aurait coûté environ 75 $ par mois à l'époque. Au lieu de cela, j'ai décidé de répartir la charge entre deux instances t3.micro avec deux vCPU et 1 Go de RAM chacune. Les instances t3.micro offraient suffisamment de vitesse et de mémoire pour le travail dont j'avais besoin à un cinquième du coût de l'a1.xlarge. Néanmoins, ma facture était encore plus importante que ce à quoi je m'attendais à la fin du mois.

Afin de comprendre pourquoi, j'ai recherché la documentation d'Amazon et j'ai trouvé la réponse : lorsque l'utilisation du processeur d'une instance tombe en dessous d'une ligne de base définie, elle collecte des crédits, mais lorsque l'instance dépasse l'utilisation de base, elle consomme les crédits précédemment gagnés. S'il n'y a pas de crédits disponibles, l'instance dépense les "crédits excédentaires" fournis par Amazon. Cette capacité à gagner et à dépenser des crédits amène Amazon EC2 à calculer la moyenne de l'utilisation du processeur d'une instance sur 24 heures. Si l'utilisation moyenne dépasse la ligne de base, l'instance est facturée en supplément à un tarif forfaitaire par vCPU-heure.

J'ai surveillé les instances d'ingestion de données pendant plusieurs jours et j'ai constaté que la configuration de mon processeur, qui visait à réduire les coûts, faisait le contraire. La plupart du temps, mon utilisation moyenne du processeur était supérieure à la ligne de base.

Un graphique comporte trois sélections déroulantes choisies en haut de l'écran. Les deux premiers, à gauche, sont "10 février 2022 - 19 février 2022" et "Quotidien", suivis d'un petit "i" encerclé. Le troisième est à droite de l'écran et dit "Ligne" avec un symbole pour un graphique linéaire. Sous les sélections déroulantes, le graphique contient deux graphiques linéaires avec des filtres. En haut, la ligne de filtre indique "Regrouper par : Type d'utilisation" (le filtre sélectionné, sur fond bleu), puis affiche les filtres non sélectionnés : "Service, Compte lié, Région, Type d'instance, Ressource, Catégorie de coût, Balise , Plus", avec "Ressource" grisé et les trois derniers ayant des flèches déroulantes à côté d'eux. Le graphique linéaire du haut a "Coûts ($)" sur l'axe des ordonnées, allant de 0,0 à 2,5. Le graphique linéaire du bas indique « Utilisation (vCPU-Heures) » sur l'axe des y, allant de 0 à 40. Les deux graphiques linéaires partagent des dates étiquetées sur l'axe des x, allant du 10 février au 19 février, et une clé étiquetant leurs lignes violettes : "USE2-CPUCredits:t3". Le graphique linéaire du haut comporte environ huit points connectés de manière linéaire et tend vers le haut au fil du temps : un point autour de (10 février, 0,3 $), un deuxième autour de (11 février, 0,6 $), un troisième autour de (12 février, 0,5 $), un quatrième autour (Feb-14, 2,1 $), un cinquième autour (Feb-15, 2,4 $), un sixième autour (Feb-16, 2,3 $), un septième autour (Feb-18, 2,3 $) et un huitième autour (Feb- 19, 2,6 $). Le graphique de la ligne du bas comporte également environ huit points connectés de manière linéaire et tend vers le haut au fil du temps : un point vers (10 février, 5 heures vCPU), un second vers (11 février, 15 heures vCPU), un troisième vers (février -12, 10 heures vCPU), un quatrième environ (14 février, 40 heures vCPU), un cinquième environ (15 février, 50 heures vCPU), un sixième environ (16 février, 45 heures vCPU) , un septième environ (18 février, 45 heures vCPU) et un huitième environ (19 février, 55 heures vCPU). — Le graphique ci-dessus affiche les augmentations de coûts (graphique du haut) et l'augmentation de l'utilisation du crédit CPU (graphique du bas) pendant une période où l'utilisation du CPU était supérieure à la ligne de base. Le coût en dollars est proportionnel aux crédits excédentaires dépensés, puisque l'instance est facturée par vCPU-heure.

J'avais initialement analysé l'utilisation du processeur pour quelques paires de chiffrement ; la charge était petite, alors je pensais avoir beaucoup d'espace pour la croissance. (J'ai utilisé une seule micro-instance pour l'ingestion de données car moins de paires de chiffrement ne nécessitaient pas autant de puissance CPU.) Cependant, j'ai réalisé les limites de mon analyse d'origine une fois que j'ai décidé de rendre mes informations plus complètes et de prendre en charge l'ingestion de données. pour des centaines de paires de chiffrement, l'analyse des services cloud ne signifie rien si elle n'est pas effectuée à la bonne échelle.

Transferts de données sortants

Un autre résultat de l'expansion de mon site a été l'augmentation des transferts de données depuis mon application en raison d'un petit bogue. Avec un trafic en constante augmentation et plus de temps d'arrêt, j'avais besoin d'ajouter des fonctionnalités pour capter et retenir l'attention des utilisateurs dès que possible. Ma dernière mise à jour était une alerte audio déclenchée lorsque les conditions du marché d'une paire de crypto correspondaient aux paramètres prédéfinis de l'utilisateur. Malheureusement, j'ai fait une erreur dans le code et les fichiers audio ont été chargés dans le navigateur de l'utilisateur des centaines de fois toutes les quelques secondes.

L'impact a été énorme. Mon bogue a généré des téléchargements audio à partir de mes serveurs Web, provoquant des transferts de données sortants supplémentaires. Une infime erreur dans mon code a entraîné une facture presque cinq fois plus importante que les précédentes. (Ce n'était pas la seule conséquence : le bogue pouvait provoquer une fuite de mémoire dans l'ordinateur de l'utilisateur, de sorte que de nombreux utilisateurs ont cessé de revenir.)

Un graphique similaire au précédent mais avec la première liste déroulante indiquant « 6 janvier 2022 - 15 janvier 2022 », les « Coûts ($) » du graphique supérieur allant de 0 à 30, et le graphique inférieur ayant « Utilisation (Go)" sur l'axe des y, allant de 0 à 300. Les deux graphiques linéaires partagent des dates étiquetées sur l'axe des x, allant de Jan-06 à Jan-15, et une clé étiquetant leurs lignes violettes : "USE2- DataTransfer-Out-Octets." Le graphique linéaire du haut comporte environ huit points connectés de manière linéaire et tend vers le haut au fil du temps : un point autour de (Jan-06, 2 $), un deuxième autour de (Jan-08, 4 $), un troisième autour de (Jan-09, 7 $), un quatrième autour (Jan-10, 6 $), un cinquième autour (Jan-12, 15 $), un sixième autour (Jan-13, 25 $), un septième autour (Jan-14, 24 $) et un huitième autour (Jan- 15, 29 $). Le graphique de la ligne du bas comporte également environ huit points connectés de manière linéaire et tend vers le haut au fil du temps : un point autour de (Jan-06, 10 Go), un deuxième autour de (Jan-08, 50 Go), un troisième autour de (Jan-09, 80 Go), un quatrième environ (10 janvier, 70 Go), un cinquième environ (12 janvier, 160 Go), un sixième environ (13 janvier, 270 Go), un septième environ (14 janvier, 260 Go) , et un huitième environ (15 janvier, 320 Go). — Le graphique ci-dessus affiche les augmentations de coûts (graphique du haut) et l'augmentation des transferts de données sortantes (graphique du bas). Étant donné que les transferts de données sortants sont facturés au Go, le coût en dollars est proportionnel à l'utilisation des données sortantes.

Les coûts de transfert de données peuvent représenter jusqu'à 30 % des hausses de prix AWS. Le transfert entrant EC2 est gratuit, mais les frais de transfert sortant sont facturés par Go (0,09 $ par Go lorsque j'ai construit Scalper.AI). Comme je l'ai appris à la dure, il est important d'être prudent avec le code affectant les données sortantes ; réduire les téléchargements ou le chargement de fichiers dans la mesure du possible (ou surveiller attentivement ces domaines) vous protégera des frais plus élevés. Ces centimes s'accumulent rapidement puisque les frais de transfert de données d'EC2 vers Internet dépendent de la charge de travail et des tarifs spécifiques à la région AWS. Une dernière mise en garde inconnue de nombreux nouveaux clients AWS : le transfert de données devient plus coûteux entre différents emplacements. Cependant, l'utilisation d'adresses IP privées peut éviter des coûts de transfert de données supplémentaires entre différentes zones de disponibilité d'une même région.

Adresses IP élastiques

Même lorsque vous utilisez des adresses publiques telles que les adresses IP élastiques (EIP), il est possible de réduire vos coûts EC2. Les EIP sont des adresses IPv4 statiques utilisées pour le cloud computing dynamique. La partie "élastique" signifie que vous pouvez attribuer une EIP à n'importe quelle instance EC2 et l'utiliser jusqu'à ce que vous choisissiez de vous arrêter. Ces adresses vous permettent d'échanger de manière transparente des instances non saines avec des instances saines en remappant l'adresse sur une autre instance de votre compte. Vous pouvez également utiliser les EIP pour spécifier un enregistrement DNS pour un domaine afin qu'il pointe vers une instance EC2.

AWS ne fournit que cinq EIP par compte et par région, ce qui en fait une ressource limitée et coûteuse avec une utilisation inefficace. AWS facture un faible taux horaire pour chaque EIP supplémentaire et facture un supplément si vous remappez un EIP plus de 100 fois par mois ; rester sous ces limites réduira les coûts.

Terminer et arrêter les états

AWS propose deux options pour gérer l'état des instances EC2 en cours d'exécution : résilier ou arrêter. La résiliation arrêtera l'instance et la machine virtuelle provisionnée pour celle-ci ne sera plus disponible. Tous les volumes Elastic Block Store (EBS) attachés seront détachés et supprimés, et toutes les données stockées localement dans l'instance seront perdues. Vous ne serez plus facturé pour l'instance.

L'arrêt d'une instance est similaire, avec une petite différence. Les volumes EBS attachés ne sont pas supprimés, leurs données sont donc conservées et vous pouvez redémarrer l'instance à tout moment. Dans les deux cas, Amazon ne facture plus l'utilisation de l'instance, mais si vous optez pour l'arrêt au lieu de résilier, les volumes EBS généreront un coût tant qu'ils existent. AWS recommande d'arrêter une instance uniquement si vous prévoyez de la réactiver prochainement.

Mais il existe une fonctionnalité qui peut augmenter votre facture AWS à la fin du mois même si vous avez résilié une instance au lieu de l'arrêter : les instantanés EBS. Il s'agit de sauvegardes incrémentielles de vos volumes EBS stockés dans le service de stockage simple d'Amazon (S3). Chaque instantané contient les informations dont vous avez besoin pour créer un nouveau volume EBS avec vos données précédentes. Si vous résiliez une instance, ses volumes EBS associés seront automatiquement supprimés, mais ses instantanés resteront. Comme S3 est facturé en fonction du volume de données stockées, je vous recommande de supprimer ces instantanés si vous ne les utilisez pas sous peu. AWS offre la possibilité de surveiller l'activité de stockage par volume à l'aide du service CloudWatch :

Une fois connecté à la console AWS, dans le menu Services en haut à gauche, recherchez et ouvrez le service CloudWatch.
Sur le côté gauche de la page, sous le menu déroulant Métriques , cliquez sur Toutes les métriques .
La page affiche une liste de services avec des métriques disponibles, notamment EBS, EC2, S3, etc. Cliquez sur EBS puis sur Métriques par volume . (Remarque : l'option EBS ne sera visible que si des volumes EBS sont configurés sur votre compte.)
Cliquez sur l'onglet Requête . Dans la vue Éditeur , copiez et collez la commande SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId , puis cliquez sur Exécuter . (Remarque : CloudWatch utilise un dialecte SQL avec une syntaxe unique.)

Une vue d'ensemble de la configuration de surveillance CloudWatch décrite ci-dessus (affichée avec des données vides et aucune métrique sélectionnée). Si vous avez des instances EBS, EC2 ou S3 existantes sur votre compte, celles-ci s'afficheront en tant qu'options de métrique et rempliront votre graphique CloudWatch.

CloudWatch offre une variété de formats de visualisation pour analyser l'activité de stockage, tels que des graphiques circulaires, des lignes, des barres, des graphiques en aires empilées et des nombres. L'utilisation de CloudWatch pour identifier les volumes et instantanés EBS inactifs est une étape facile vers l'optimisation des coûts du cloud.

De l'argent supplémentaire dans votre poche

Bien que les outils AWS tels que CloudWatch offrent des solutions décentes pour la surveillance des coûts du cloud, diverses plates-formes externes s'intègrent à AWS pour une analyse plus complète. Par exemple, les plates-formes de gestion du cloud telles que CloudHealth de VMWare affichent une ventilation détaillée des principaux domaines de dépenses pouvant être utilisés pour l'analyse des tendances, la détection des anomalies et la surveillance des coûts et des performances. Je vous recommande également de configurer une alarme de facturation CloudWatch pour détecter toute augmentation des frais avant qu'ils ne deviennent excessifs.

Amazon fournit de nombreux excellents services cloud qui peuvent vous aider à déléguer les travaux de maintenance des serveurs, des bases de données et du matériel à l'équipe AWS. Bien que les coûts de la plate-forme cloud puissent facilement augmenter en raison de bogues ou d'erreurs des utilisateurs, les outils de surveillance AWS fournissent aux développeurs les connaissances nécessaires pour se défendre contre des dépenses supplémentaires.

Avec ces optimisations de coûts à l'esprit, vous êtes prêt à lancer votre projet et à économiser des centaines de dollars dans le processus.

En tant que partenaire conseil avancé du réseau de partenaires Amazon (APN), Toptal offre aux entreprises un accès à des experts certifiés AWS, à la demande, partout dans le monde.