Réduire de moitié nos dépenses AWS

Il semble souvent que, par défaut, nos dépenses mensuelles AWS n’aillent que dans une seule direction : vers le haut.

Notre stratégie de réduction des coûts AWS a évolué au fil du temps, grâce au travail que nous avons effectué pour nos clients et leurs plateformes cloud, et sur nos propres piles d’applications AWS. Il y a énormément de diable dans les détails. Nous sommes fiers de partager que grâce à ce travail, nous avons réduit de moitié nos factures mensuelles AWS au cours des huit derniers mois. Cela se fait sans compromettre les piles à haute disponibilité que nous avons conçues, ni sacrifier les performances des applications.

Cela a été tout un voyage, avec beaucoup de choses examinées en parallèle. Voici comment nous avons procédé.

Systèmes de fichiers S3

L’une de nos applications courantes hébergées dans le cloud est Moodle SGA (et son cousin, Totara). Généralement, ces applications ont besoin d’un système de fichiers partagé en réseau pour stocker les actifs des fichiers d’application. Nous utilisions un serveur GlusterFSFS redondant triple AZ, chacun ayant un volume EBS dédié stockant une copie complète des données de l’application. Sur les sites plus grands, cela signifiait une empreinte de stockage importante – 3 To x 3 volumes SSD EBS, pour un montant de 1080 USD par mois avec des coûts supplémentaires pour les environnements de non-production et les sauvegardes. Nous avions besoin d’un meilleur moyen.

Nous avons donc développé une implémentation alternative de stockage de fichiers pour Moodle, ce qui signifie que nous avons déplacé la majorité des fichiers de données dans le stockage d’objets S3. Ce code est disponible sous forme de plugin ici https://github.com/catalyst/moodle-tool_objectfs

Les données du site de production ne coûtent désormais que 75 $ par mois au lieu de plus de 1 000 $. Avec certaines autorisations de compartiment S3 intelligentes, il est également possible d’autoriser l’accès des instances d’application hors production au compartiment de production. Cela signifie que nous n’avons pas à dupliquer le stockage de données entre prod et dev, test, uat et staging. Cela signifie des économies de coûts et des commodités opérationnelles considérables.

Bande passante vers S3

Après avoir initialement migré la plupart de notre stockage de fichiers vers S3, nous avons été surpris de constater que nos coûts avaient augmenté et non diminué. Après quelques recherches, nous avons constaté que 27 To de trafic provenant de nos instances EC2 passaient via nos passerelles VPC Nat à 0,059 $ par Go. Cela coûte environ 1500 $ USD! Nous avons résolu ce problème en activant le point de terminaison VPC pour S3, éliminant presque entièrement le trafic de notre passerelle NAT en rendant la voie s3 à zéro. Résultat! Et, un autre exemple de la nature bouclée de l’optimisation des coûts AWS.

Stockage et volumes EBS

AWS a introduit plusieurs nouveaux types de volumes de blocs au cours de la dernière année, y compris le stockage à froid et les volumes à débit optimisé, qui sont tous deux beaucoup moins chers que le stockage soutenu par SSD. En février 2017, Elastic Volumes a été introduit, ce qui nous permet de modifier un type de volume EBS et d’augmenter la taille du volume sans aucun problème.

Cela nous permet de provisionner des volumes plus proches de la taille du contenu sans nécessiter de pré-provisionnement pour une croissance future, car il est si facile de développer des volumes. Il nous permet également de convertir des volumes en types moins chers et plus lents lorsque nous n’avons pas besoin des performances de débit d’E/S du disque.

Il y a encore plusieurs pièges à prendre en compte lorsque vous travaillez avec des volumes Elastic. Après avoir modifié une taille ou un type de volume, aucune autre modification ne peut être effectuée pendant six heures. Les volumes de stockage à froid et de débit optimisé ont une taille minimale de 500 Go et les volumes EBS ne peuvent pas être réduits. De plus, les volumes sc1 et st1 plus lents ont tendance à épuiser les crédits IO Burst. Si cela se produit, les E/S du disque ralentiront considérablement et vous devrez utiliser un type de disque plus rapide. Cela peut être un peu lent à diagnostiquer si vous ne l’avez pas vu auparavant et que vous ne le recherchez pas.

L’examen minutieux de tous nos volumes EBS pour optimiser la taille et le type de chaque volume a permis de réaliser des économies d’environ 250 $ par mois.

Instantanés EBS

Les instantanés de volume AWS sont un outil puissant pour sauvegarder facilement les volumes de production. Cependant, il peut être difficile de calculer tous les coûts à un niveau complètement granulaire et il est très facile de prendre trop d’instantanés. Dans la région de Sydney, nous facturons 0,055 $ par Go/mois pour des blocs de données uniques. Des instantanés plus fréquents d’un volume EBS ne feront pas nécessairement exploser notre facture, car AWS ne facture que les changements de niveau de bloc entre chaque instantané. Cependant, en réalité, nous avons vu beaucoup de stratégies d’instantanés où beaucoup trop de données sont stockées, même en tenant compte du fait que nous ne payons que pour les deltas de bloc.

Nous avons trouvé quelques anciens instantanés EBS qui traînaient et qui étaient faciles à éliminer, économisant environ 800 $ par mois. Nous avons vu avec nos clients des scénarios similaires où les instantanés de « sauvegarde » sont oubliés. D’autres économies proviendront de la réduction du volume de données dans les instantanés et du taux de changement de nos instantanés de données.

Instantanés EBS vers S3

Même avec les économies réalisées grâce à l’élimination des anciens instantanés EBS, nous dépensions toujours plus de 2 000 $ par mois en instantanés EBS qui sont des sauvegardes historiques. La plupart des données sur ces instantanés étaient uniques, ce qui a entraîné de faibles économies de coûts grâce aux données partagées. Le prix S3 est inférieur à la moitié du prix d’un instantané EBS par gigaoctet. Ainsi, en utilisant s3-parallel-put https://github.com/mishudark/s3-parallel-put, nous avons pu télécharger le contenu de ces instantanés dans S3. Une fois les instantanés EBS supprimés, nous avons économisé environ 1000 $ par mois lorsque les coûts de stockage S3 accrus sont pris en compte. Nous nous attendons à ce que cela s’améliore avec le temps, car les stratégies de compartiment déplacent lentement les objets vers un stockage basé sur un accès peu fréquent et éventuellement Glacier.

Ceci est un autre exemple de la raison pour laquelle le stockage d’objets est souvent un moyen beaucoup plus rentable d’archiver des données, mais ce n’est pas toujours une simple comparaison lorsque l’on passe de modèles d’instantanés de stockage de blocs au stockage d’objets.

Bande passante multi-VPC

Le trafic de bande passante d’un AWS VPC à un autre à l’aide de l’appairage de VPC entraîne un coût. Pour l’un de nos clusters, un ensemble de nœuds de serveur Web utilisait un montage NFS à partir d’un autre VPC, ce qui entraînait beaucoup de trafic entre VPC. La consolidation de tout dans un seul VPC a complètement éliminé ce trafic. Raison de plus pour engager des ingénieurs réseau cloud expérimentés lors de l’architecture des piles cloud.

Trafic entre les zones de disponibilité

Dans le cadre des exigences d’architecture de haute disponibilité de nos piles d’applications, nous les construisons dans les zones de disponibilité AWS (Az). Le trafic d’une instance EC2 vers une autre instance EC2 dans la même zone de disponibilité est gratuit. Cependant, lorsque ce trafic traverse une zone de disponibilité externe, des frais sont facturés. Lorsque des éléments tels que l’équilibrage de charge des applications ou la réplication constante traversent les zones de disponibilité, un trafic élevé peut être déclenché et les dépenses AWS peuvent augmenter considérablement.

Notre partage de fichiers réseau principal est un volume GlusterFS répliqué avec un nœud dans chaque zone de disponibilité. Ceci est conforme à la politique « Architect for Failure » adoptée par les architectes de solutions AWS. GlusterFS a une option de montage obscure disponible appelée read-subvolume-index. Cette option de montage vous permet d’indiquer à GlusterFS qu’il doit utiliser le nœud local des zones de disponibilité pour les opérations de lecture s’il est disponible. Cette option de montage unique nous a permis d’économiser environ 1 500 $ par mois en trafic réseau qui n’a plus besoin de quitter une zone de disponibilité.

L’option de montage complet dans /etc/fstab est

datanode-1:/sitedata /var/lib/sitedata Glusterfs defaults,_netdev,fetch-attempts=6,backupvolfile-server=datanode-2,xlator-option=*.read-subvolume-index=2 0 0

Ici, le read-subvolume-index doit être différent dans chaque zone de disponibilité pour correspondre au bon serveur GlusterFS.

Instantanés RDS

Au cours des six derniers mois, les coûts de RDS Snapshot ont lentement augmenté à mesure que le nombre et la taille de nos instances RDS augmentent. Les instantanés RDS sont importants car ils font partie de la base de données PITR (Point In Time Recovery) qu’AWS propose.

Pour réduire les coûts ici, nous avons supprimé les instantanés hérités des bases de données mortes depuis longtemps, défini les instances RDS hors production pour stocker les instantanés pendant seulement sept jours au lieu de 31 ou les désactiver complètement.

Les économies de coûts ici étaient minimes, mais chaque bit compte.

Éteindre les choses

AWS et d’autres solutions d’infrastructure cloud nous donnent la flexibilité de lancer une infrastructure à la demande. Leur succès en témoigne. Et c’est un monde meilleur que par le passé, lorsque nous avions un long cycle d’approvisionnement avant de pouvoir déployer quoi que ce soit dans un centre de données.

Au cours de notre croisade d’un mois pour maîtriser les coûts AWS, nous avons identifié les services suivants qui ont pu être désactivés. Mettez n’importe quelle organisation au défi d’examiner de près sa propre infrastructure et de devenir un peu brutale.

• 1x instance EC2 t2.medium dans une région que nous n’utilisons généralement pas, une relique des tests de charge des siècles passés
• 2 instances RDS m4.large non utilisées au cours des mois que nous avons créés à des fins de test
• 2x nœuds de cache élastique qui pourraient être consolidés dans un nœud existant
• 1x point final de recherche élastique qui n’a jamais indexé un seul document
• Plusieurs centaines de Go de volumes EBS inutilisés, quelque part un groupe de mise à l’échelle automatique n’a pas mis fin aux volumes EBS lors de l’arrêt
• 4 ELB inutilisés qui ne recevaient aucun trafic et le DNS ne leur était plus pointé
• 1 point de terminaison VPN qui n’était plus connecté
• 1x groupe de test de mise à l’échelle automatique avec 2x machines t2.micro qui n’est plus nécessaire.

Individuellement, aucun de ces articles n’était particulièrement gros ou cher, mais une fois assemblés, ils s’additionnent tous.

Connection directe

Étant donné qu’une grande partie du trafic de notre compte AWS se fait vers notre bureau, une connexion Direct Connect pourrait potentiellement nous faire économiser plusieurs centaines de dollars par mois. Le trafic de connexion directe est 1/3 du prix du trafic sortant régulier, la surcharge devant trouver un FAI avec une offre de connexion directe et payer pour le port de connexion directe lui-même. Nous avons fait le calcul, et les économies potentielles ne sont pas assez importantes pour justifier le temps passé, mais cela vaut la peine de s’y intéresser.

ICE

Ice est un outil open source de Netflix. Il permet des visualisations et un examen faciles de votre facturation AWS détaillée, et vous permet d’explorer les modèles de dépenses au quotidien. Il utilise les rapports de facturation détaillés AWS qui sont téléchargés dans un compartiment S3. Il existe un certain nombre d’autres offres en tant que service telles que CloudCheckr et AWS Trusted Advisor. Mais rappelez-vous, ces outils ne font que vous aider à décider quoi faire, ils ne le font pas pour vous !

 

Utiliser des instances réservées

La dernière possibilité d’économies, une fois que toute notre infrastructure est d’une capacité appropriée, a été d’investir dans des instances réservées. Cela signifie que nous nous engageons sur une certaine utilisation d’AWS et que nous bénéficions d’une remise pour cela. Les coûts d’utilisation d’EC2 ne représentent que 25 % de notre facture, le reste provenant du stockage, du trafic et d’autres services AWS. Néanmoins, une réduction de 30% sur le prix est la bienvenue.

Une chose que nous avons remarquée lorsque nous travaillons avec nos clients pour réduire leurs factures AWS via l’achat d’instances réservées, c’est qu’ils peuvent avoir des difficultés à comprendre le modèle, et ils peuvent hésiter à s’engager dans des dépenses importantes pour un achat important d’instances réservées. . Croyez-le ou non, les ingénieurs Sysadmins et DevOps ne sont pas des comptables. Et il y a toujours un élément de risque lorsqu’on s’engage sur une taille de service AWS particulière.

Nous avons découvert que la réduction des dépenses AWS n’est souvent pas l’affaire d’une seule personne. Nous agissons tous en tant que propriétaires de l’entreprise et toute réduction de nos dépenses AWS est bonne pour nos bénéfices.

Google Cloud vient de lancer une région en Australie, et nous pensons que le modèle d’économie de Google est bien meilleur. Si vous exécutez une instance de calcul Google pendant un mois entier, vous réalisez une économie de 30 %. Aucune planification à long terme requise et aucun risque qu’une réservation à long terme ne soit inutilisée en cas de modification des besoins.

Nous avons constaté que la réservation d’instances pour le cache EC2, RDS et Elastic entraînait initialement des frais uniques plus élevés, mais au cours des prochains mois, cela devrait nous permettre d’économiser plusieurs milliers de dollars.

Conclusion

La chose la plus importante dans la gestion de vos dépenses AWS est de faire attention. Demandez aux personnes bien informées dans une salle d’examiner le total des dépenses. Ce sera difficile les premières fois, mais vous identifierez presque certainement des économies potentielles.

Il n’y a pas de solution miracle pour résoudre tous vos problèmes de coûts AWS. Il s’agira très probablement d’une combinaison de vigilance et d’une politique d’utilisation AWS pragmatique. De plus, ne négligez pas la valeur de l’engagement d’un partenaire AWS pour examiner l’utilisation de votre infrastructure.

Il y a sans aucun doute plus de stratégies que celles mentionnées dans ce blog, et nous examinerons d’autres choses que nous pouvons faire pour réduire davantage notre facture au fil du temps.

J’espère que cela vous sera utile là-bas.

Alex Lawn est l’un des membres fondateurs de Team Cloud, l’initiative de conseil dédiée au cloud de Catalyst.