Slashing AWS Bills avec Graviton: un guide sur le terrain des tranchées

Si vous avez déjà réussi AWS à grande échelle, vous connaissez l’histoire. Les coûts n’explosent pas du jour au lendemain; Ils vous faufilent sur vous. Le projet de loi a l’air bien au début, mais une fois de plus, les équipes commencent à faire tourner les charges de travail, l’élément de ligne pour EC2 commence à grimper plus rapidement que quiconque prévu. La finance demande des réponses, les ingénieurs haussent les épaules et vous commencez à vous rendre compte que ce n’est pas une erreur flagrante, mais d’innombrables petites inefficacités se cachent à travers la flotte.

Nous avons rencontré ce problème exact il y a quelques années. Au moment où nous l’avons remarqué, le «saignement régulier» était déjà devenu significatif. Nous ne faisons rien d’inhabituel – exécutant les microservices en cours d’exécution, certaines bases de données, un mélange d’environnements Dev / Test. Mais les échelles d’inefficacité et les factures de nuage ne pardonnent pas.

C’est là que nous avons commencé à regarder AWS Gravity.

Processeurs AWS Graviton: spécialement conçu pour les charges de travail cloud.

Pourquoi Graviton existe même

La plupart d’entre nous ont grandi en exécutant des charges de travail sur des puces Intel ou AMD. Ces processeurs ont été conçus pour servir un large univers de machines – liptops, ordinateurs de bureau, serveurs et même plates-formes de jeu. AWS, cependant, a pris un chemin différent. Ils ont construit Graviton à un seul but: les charges de travail des nuages.

Et parce qu’AWS possède à la fois le matériel et le cloud sur lequel il fonctionne, ils peuvent régler les deux ensemble d’une manière qu’Intel et AMD ne peuvent tout simplement pas. Cette intégration serrée apparaît en coût et en performance, mais pas toujours de manière évidente.

La partie importante: il ne s’agit pas seulement du taux horaire inférieur sur la page de tarification. La question est de savoir si vos charges de travail fonctionnent mieux, si l’écosystème a rattrapé et si votre équipe est prête pour le changement opérationnel.

Ce que nous avons trouvé dans la pratique

Lorsque nous avons comparé Graviton à nos flottes Intel et AMD, nous avons divisé les choses en quatre domaines – le coût, les performances, la compatibilité et les opérations. Ce n’était pas un exercice de feuille de calcul soigné; C’était plus comme peler des couches arrière pendant les expériences.

En fin de compte

Graviton surpasse constamment x86 en termes de performance entre les régions

À Mumbai (AP-South-1), nous avons vu certains des nombres les plus spectaculaires, ce qui a fait des économies à 50% lors du passage de EC2 basé sur Intel. Dans d’autres régions, les économies étaient plus petites mais toujours entre 20 et 25%. Même en comparant AMD, Graviton a généralement pris de l’avant d’environ 20%.

Sur la performance

Les charges de travail multi-thread aimaient Graviton. Quelques-uns de nos emplois de traitement par lots ont en fait offert 40% de meilleurs prix / performances par rapport à la famille C5 d’Intel. Mais les charges de travail à un seul thread ont raconté une autre histoire – celles-ci fonctionnaient toujours plus vite sur x86, en particulier les puces AMD avec des vitesses d’horloge élevées.

Sur les bases de données

C’était le plus surprenant. L’exécution de RDS sur Graviton n’a pas seulement réduit les coûts – c’est amélioré le débit. Nous avons mesuré environ 30% de requêtes de plus par seconde et nettement meilleur coût par requête.

Les différences cachées

Il existe des bizarreries architecturales qui méritent d’être comprises avant de sauter. Par exemple, Graviton n’utilise pas d’hyperthreading – chacun des cartes VCPU en un seul noyau physique. Cela peut ressembler à une note de bas de page technique, mais cela rend les performances plus prévisibles.

Avec Graviton4, AWS a également introduit la mémoire DDR5 et une bande passante de réseau plus élevée. Cette combinaison s’est beaucoup mieux mise à l’échelle pour nos API à fort trafic que les puces plus anciennes. Et lorsque nous avons examiné la consommation d’énergie, Graviton3 a utilisé environ 60% de puissance en moins que les machines x86 équivalentes. Ce n’est pas seulement une victoire de facturation – c’est aussi une plus petite empreinte carbone.

Les leçons de migration que nous avons apprises

Le point de départ le plus simple était les conteneurs. Nous avions déjà des constructions Docker, donc passer à des constructions multi-archs était indolore. Quelque chose comme:

docker buildx build --platform=linux/arm64,linux/amd64 -t myapp:latest --push

De là, nous les avons déployés progressivement en mélangeant Graviton et x86 nœuds dans le même groupe de mise à l’échelle automatique. Cela nous a donné des tests de charge réels sans parier la ferme.

Bases de données

Les bases de données, en revanche, avaient besoin de plus de soins. Nous avons lancé des répliques de lecture sur Graviton, pointé du trafic de production réel vers eux et regardé de près. Ce n’est qu’après des semaines de test que nous les avons promenés auprès des primaires. Le gain en valait la peine – 27% de meilleurs prix / performances et près d’un troisième débit supplémentaire.

Lambda

Lambda était encore plus facile. Le passage des temps d’exécution à ARM64 a pris des minutes, et les avantages se manifestent rapidement: des démarrages à froid plus courts, des invocations moins chères et environ 34% de meilleurs prix.

Où ça marche, où il ne le fait pas

Il est tentant de déclarer «Graviton partout!» Mais la réalité est plus nuancée.

Nous avons vu les plus grandes victoires dans les conteneurs, les microservices, les API et les emplois par lots. Les environnements Dev / Test étaient également des candidats parfaits – risque tout à fait, facile à échanger, économies immédiates.

Mais certaines charges de travail sont restées sur x86. Applications héritées avec anciennes dépendances, services à thread unique qui ont besoin d’une vitesse d’horloge brute ou de bibliothèques qui ne jouent tout simplement pas bien avec le bras – ils étaient plus de douleur que de gain.

La leçon: ne retournez pas toute la flotte du jour au lendemain. Choisissez des charges de travail sûres, migrez, mesurez, renforcez la confiance, puis développez.

Emballage

Graviton n’est pas seulement un autre type d’instance – il est AWS montrant ce qui se passe lorsque vous concevez des puces spécifiquement pour le cloud. Bien effectués, les migrations peuvent réduire les coûts de 20 à 50%, souvent avec de meilleures performances en prime.

. Mais après avoir exécuté des comparaisons côte à côte en production, les calculs sont devenus impossibles à ignorer. L’infrastructure est devenue plus maigre, les factures ont chuté et même nos chiffres de durabilité étaient meilleurs.

Si vous cherchez un levier pour plier la courbe de coût AWS sans refonte architecturale massive, Graviton pourrait être l’outil le plus pointu que vous n’avez pas encore utilisé.

Vous avez trouvé cela utile? PARTAGEZ-LE