Comment réduire les coûts d'infrastructure de paiement de 30 %

Les coûts d'infrastructure cloud pour les systèmes de paiement ont une propriété constante : ils croissent plus vite que le volume de transactions. L'écart n'est pas causé par des décisions architecturales coûteuses mais par l'accumulation de petites inefficacités que personne n'a le temps d'auditer pendant une période de croissance rapide.

Un audit de coûts structuré du calcul, du stockage, du transfert de données et de la configuration des services révèle généralement 25 à 40 % d'économies sans aucune réduction de la fiabilité ou des performances. Voici comment en réaliser un.

Commencer par le redimensionnement du calcul

La plus grande catégorie de surcoût est celle des instances de calcul fonctionnant à 10-30 % d'utilisation CPU moyenne. Ce sont des instances qui ont été provisionnées pour une charge de pointe qui ne s'est jamais matérialisée ou qui s'est produite une fois, et l'instance n'a jamais été redimensionnée ensuite.

Extrayez les données d'utilisation pour chaque instance sur une période de 30 jours. Identifiez les instances où le CPU p95 est inférieur à 40 % et la mémoire p95 inférieure à 50 %. Ce sont des candidates au rétrécissement. Pour les services sans état, évaluez également si la mise à l'échelle horizontale avec de plus petites instances vous donne une meilleure utilisation que quelques grandes.

Couverture réservée et engagements d'utilisation

La tarification à la demande est significativement plus chère que la tarification réservée ou avec engagement d'utilisation pour les charges de travail stables. La plupart des plateformes de paiement ont une base stable de trafic - les transactions qui tournent 24h/24 indépendamment des campagnes ou des pics saisonniers - qui devrait être couverte par des réservations.

Une cible raisonnable : 60-70 % de votre calcul de base couvert par des réservations d'un an, avec une capacité à la demande pour le reste. Les Compute Savings Plans (AWS) ou les Committed Use Discounts (GCP) sont généralement plus flexibles que les réservations d'instances spécifiques et plus faciles à gérer à mesure que les types d'instances évoluent.

Voir aussi : L'observabilité pour les systèmes critiques de transaction

Les coûts de transfert de données sont invisibles jusqu'à ce qu'ils ne le soient plus

Le transfert de données entre zones de disponibilité, entre régions et vers Internet est facturé au gigaoctet et s'accumule rapidement dans les systèmes qui déplacent des données financières entre services. La plupart des équipes ne suivent pas les coûts de transfert de données séparément.

Auditez les postes de coût de transfert de données dans votre facture cloud. Recherchez des schémas de trafic inter-AZ qui pourraient être réduits en colocalisant des services, une réplication inter-régions plus importante que nécessaire, et des charges utiles de réponse API qui incluent plus de données que les clients n'en utilisent réellement.

Hiérarchisation du stockage

Les données de transaction de paiement ont un schéma d'accès naturel : les transactions récentes sont fréquemment consultées, les transactions plus anciennes sont occasionnellement consultées, et les données archivées sont consultées pour les audits et les demandes réglementaires. Stocker toutes les données dans le même niveau de stockage chaud revient à payer des prix premium pour des données rarement consultées.

Implémentez des politiques de cycle de vie qui déplacent les données de transaction de plus de 90 jours vers un stockage standard, et les données de plus d'un an vers un stockage d'archive. Assurez-vous que vos systèmes de piste d'audit et de reporting peuvent toujours accéder aux données archivées - ils devraient lire depuis l'archive plutôt que de nécessiter une migration vers le stockage chaud.

Services sous-utilisés

Les systèmes qui ont grandi rapidement accumulent des services qui ont été provisionnés pour un usage qui n'existe plus - un environnement de test de charge qui a tourné une fois, un service de feature flag pour une fonctionnalité lancée il y a un an, un réplica de base de données pour un pipeline de reporting reconstruit sur un data warehouse.

Un audit d'inventaire des services est mécanique mais précieux. Pour chaque service en fonctionnement, identifiez : qu'est-ce que c'est, qu'est-ce qu'il sert, quand a-t-il été accédé pour la dernière fois, qui en est propriétaire. Les services sans propriétaire et sans trafic récent sont des candidats au décommissionnement.

Voir aussi : Quand réarchitecturer ou stabiliser une plateforme de paiement

Le chiffre des 30 %

Dans les engagements d'optimisation d'infrastructure que nous avons menés, les résultats typiques sont :

• Redimensionnement du calcul : réduction de 12-18 %
• Couverture des instances réservées : réduction de 8-12 %
• Optimisation du transfert de données : réduction de 4-8 %
• Hiérarchisation du stockage et nettoyage des services : réduction de 4-6 %

Le total est additif car ce sont des catégories indépendantes. Une réduction de 30 % sur un système dépensant 500 000 $/an en infrastructure représente 150 000 $/an - avec une période de retour sur investissement de l'engagement mesurée en semaines, pas en mois.

---

Si vos coûts d'infrastructure croissent plus vite que votre volume de transactions, un audit des coûts d'infrastructure identifiera exactement où se trouve le surcoût et ce qu'il faut faire.

Notre service d'optimisation de l'infrastructure combine l'audit des coûts avec un travail d'ingénierie pratique pour mettre en œuvre les économies - dimensionnement, capacité réservée et élimination du gaspillage architectural qui s'accumule mois après mois.