Guide approfondi
Simulateur de coût de montée en charge d'une base de données et d'IOPS : quand la base gérée coûte plus que le revenu par utilisateur
Analyse sectorielle pour décideurs
Une base de données gérée est la partie d'une architecture que l'on veut le plus oublier, et qui vous le rend bien à l'arrivée de la facture. Tout commence par une petite instance et un petit disque. Puis les utilisateurs augmentent, les fonctionnalités ajoutent des requêtes, les tables se remplissent d'historique, et l'offre qui était bon marché devient la plus grosse ligne de la facture. Contrairement aux serveurs web, les bases de données ne montent pas en charge en ajoutant des machines identiques bon marché. Elles passent à des instances plus grandes, ajoutent du débit provisionné et copient tout vers des réplicas, et chacune de ces étapes multiplie le coût.
La structure du problème est que le coût monte par paliers tandis que le chiffre d'affaires croît en douceur. Les tailles d'instance doublent : de deux à quatre, huit puis seize vCPU, avec un prix qui double à peu près à chaque fois. Le stockage et les IOPS sont facturés séparément et les réplicas multiplient le tout. Le revenu par utilisateur ne double pas quand votre instance double. Une entreprise confortablement rentable avec 30 000 utilisateurs peut constater que la taille supérieure annule le gain des 10 000 utilisateurs suivants.
Le modèle en dominos suit la chaîne. Les utilisateurs et les IOPS pour mille utilisateurs fixent la demande de pointe sur la couche de stockage. Les besoins de calcul décident de la taille de l'instance, qui détermine à son tour la facture avec les réplicas, le stockage et le débit provisionné. La facture devient une part du chiffre d'affaires, ce qui décide finalement du bénéfice. Une requête mal indexée peut changer la première case d'un facteur trois sans aucune variation du nombre d'utilisateurs, et c'est pourquoi l'optimisation des requêtes est souvent le moyen le moins cher de faire baisser toutes les cases suivantes.
L'iceberg sépare l'instance que tout le monde voit des extras qui rendent la facture plus élevée que prévu. Les postes visibles sont l'instance principale et le stockage. Sous la ligne de flottaison se trouvent les réplicas, qui répètent le calcul et le stockage, les IOPS provisionnés au-delà de la base qu'un disque inclut, les sauvegardes conservées des semaines et le trafic qui réplique les données entre zones. Chacun est facturé sous une rubrique différente, et il est donc facile de les sous-estimer lors de la planification. Utilisez le simulateur pour tester le comportement de votre propre architecture à mesure que les utilisateurs augmentent, et le point où la base de données cesse d'être abordable.
Formules et méthodologie
Le modèle porte sur un seul mois. La demande d'IOPS de pointe est le nombre de milliers d'utilisateurs multiplié par les IOPS par millier et par un facteur de pointe de 2,5. Le calcul nécessaire est de 0,0005 vCPU par utilisateur, arrondi à une taille d'instance en puissance de deux avec un minimum de deux. Chaque réplica répète l'instance principale, le stockage et les IOPS provisionnés. Les IOPS provisionnés sont facturés au-delà d'une base de 3 000. Le stockage, les sauvegardes et la réplication entre zones s'ajoutent au total, et les autres coûts représentent 40 % du chiffre d'affaires.
- IOPS de pointe
- I = utilisateurs ÷ 1000 × IOPS pour 1000 × 2,5
- Les opérations par seconde que la couche de stockage doit soutenir en pointe.
- Taille de l'instance
- V = 2^plafond(log₂(max(2, utilisateurs × 0,0005)))
- Les vCPU de l'instance principale, qui existent en tailles en puissance de deux.
- Facture de la base de données
- F = (1 + réplicas) × (V × prix + coût des IOPS + stockage) + sauvegardes + entre zones
- Le calcul, le débit et le stockage répétés sur chaque nœud, plus les sauvegardes et la réplication.
- IOPS provisionnés
- max(0, I − 3000) × 0,10 $ par nœud
- Le débit au-delà de ce que le disque inclut, facturé sur chaque nœud.
- Bénéfice net
- Net = chiffre d'affaires × (1 − 40 %) − F
- Le résultat mensuel. Le point de rupture est celui où il atteint zéro.
Élasticité en cascade
Les réplicas et les IOPS par utilisateur sont les variables les plus élastiques, puisque chacun se multiplie sur tous les nœuds. Le revenu par utilisateur fait varier toute la marge. Les utilisateurs modifient le résultat à la fois par le chiffre d'affaires et par le passage à une instance plus grande : la croissance n'est donc pas un gain gratuit.
Trois études de cas concrètes
Démarrage en autofinancement
Un petit produit sur une base de données minimale
Un jeune produit compte trois mille utilisateurs, un seul réplica et peu de données par utilisateur. Le revenu par utilisateur est élevé et l'instance est à la taille minimale. Ce scénario montre que la base de données est négligeable au début et comment un revenu par utilisateur élevé laisse de la marge pour grandir.
Croissance d'une entreprise de taille intermédiaire
Une grande base d'utilisateurs avec des requêtes efficaces
Un produit de trois cent mille utilisateurs maintient de faibles IOPS par utilisateur grâce à l'indexation et au cache, et exploite deux réplicas. La facture est importante en valeur absolue mais représente une part modeste du chiffre d'affaires. Ce scénario montre l'échelle qui fonctionne quand les requêtes sont optimisées.
Crise de type cygne noir
Des requêtes lourdes et trop de réplicas
Un produit à grande base d'utilisateurs et faible revenu par utilisateur exécute des requêtes non indexées, cinq réplicas et beaucoup de données stockées par utilisateur. Les IOPS provisionnés et les réplicas multiplient chaque coût. Ce scénario montre la facture de la base de données dépassant le chiffre d'affaires et le levier qui redresse le mois.
Matrice des repères sectoriels
| Indicateur | Zone de danger | Moyenne du secteur | Élite : les 10 % meilleurs |
|---|---|---|---|
| Coût de la base de données en part du chiffre d'affaires | Plus de 35 % | 8–15 % | Moins de 6 % |
| Coût de la base de données par utilisateur actif et par mois | Plus de 0,25 $ | 0,05–0,12 $ | Moins de 0,04 $ |
| Réplicas pour un SaaS typique | Plus de 3 sans besoin de lecture avéré | 1–2 | 1 instance de secours plus des réplicas de lecture ciblés |
| Part des IOPS provisionnés réellement utilisée en pointe | Moins de 30 % | 50–70 % | 70–85 % |
| Conservation des sauvegardes | Des mois d'instantanés complets | 7–14 jours | Conservation par paliers avec archivage |
Variables et leviers
Utilisateurs actifs
Les utilisateurs qui génèrent de la charge sur la base de données au cours d'un mois typique.
Levier: Ne supposez pas que plus d'utilisateurs signifie toujours une meilleure marge ; vérifiez que le revenu par utilisateur couvre encore la taille d'instance suivante.
Revenu par utilisateur et par mois
Revenu mensuel moyen que vous tirez d'un utilisateur actif.
Levier: Augmentez le revenu par utilisateur grâce à des paliers de prix, car le coût de base de données par utilisateur croît avec l'usage et le stockage.
IOPS pertinents en pointe pour 1 000 utilisateurs
Opérations de lecture et d'écriture par seconde générées en moyenne par chaque millier d'utilisateurs. La conception des requêtes et l'indexation influencent surtout ce chiffre.
Levier: Ajoutez les index manquants, mettez en cache les lectures fréquentes et regroupez les écritures ; réduire les IOPS évite souvent à la fois des disques plus gros et des instances plus grandes.
Prix par vCPU et par mois
Ce que facture votre base de données gérée par vCPU et par mois pour la classe d'instance que vous utilisez.
Levier: Comparez les familles d'instances et engagez-vous sur de la capacité réservée dès que votre charge est prévisible.
Réplicas de lecture et instances de secours
Copies supplémentaires de la base de données pour la lecture ou le basculement. Chacune répète le coût de calcul, de stockage et d'IOPS.
Levier: Remettez en question chaque réplica : gardez une instance de secours pour le basculement et n'ajoutez des réplicas de lecture que lorsque les lectures l'exigent vraiment.
Données stockées par utilisateur (Go)
Gigaoctets moyens de stockage de base de données que chaque utilisateur ajoute, index compris.
Levier: Archivez les anciennes lignes vers un stockage moins cher, fixez des limites de conservation et compressez les grosses colonnes.
Comment utiliser ce simulateur
- 1Partez du préréglage réaliste ou saisissez vos utilisateurs, le revenu par utilisateur et les détails de votre instance actuelle.
- 2Lisez les cinq cases de l'effet domino pour voir si la demande d'IOPS ou la taille de l'instance passe au rouge en premier.
- 3Appuyez sur « Trouver mon point de rupture » pour voir la charge ou le nombre de réplicas qui annule le bénéfice.
- 4Comparez la configuration actuelle avec le plan d'optimisation sur le graphique de 24 mois.
- 5Examinez chaque trimestre les requêtes lentes et les réplicas inutilisés, avant le prochain palier d'instance.
Erreurs à éviter
- Supposer que le coût de la base de données croît proportionnellement aux utilisateurs, alors qu'il croît par paliers et se multiplie avec les réplicas.
- Provisionner des IOPS bien au-delà de ce qu'utilise la charge, parce que le réglage a été copié d'un système plus grand.
- Conserver des réplicas de lecture qu'aucune requête n'utilise, en payant deux ou trois fois le calcul et le stockage.
- Agrandir l'instance avant d'examiner les requêtes lentes et les index manquants qui ont créé la charge.
Questions fréquentes
Que sont les IOPS et pourquoi sont-ils facturés ?
IOPS désigne les opérations d'entrée et de sortie par seconde : le nombre de lectures et d'écritures effectuées par la couche de stockage. Certains niveaux de stockage incluent une base et facturent le débit provisionné au-delà. Vérifiez les règles actuelles de votre fournisseur.
Quand dois-je ajouter un réplica de lecture ?
Quand les lectures dominent nettement et que l'instance principale est le goulot d'étranglement, ou quand vous avez besoin de latence géographique ou de basculement. Ajouter des réplicas par habitude multiplie toute la facture.
Pourquoi le coût fait-il des sauts à certains nombres d'utilisateurs ?
Les instances existent en tailles fixes : franchir un seuil vous fait passer à la taille suivante, au prix à peu près doublé. Le modèle utilise des tailles en puissance de deux pour montrer ces sauts.
Une instance plus grande vaut-elle mieux que davantage de réplicas ?
Pour les écritures, une instance principale plus grande est la réponse habituelle. Pour les lectures, les réplicas ou le cache aident. Le bon mélange dépend de la charge de travail : mesurez avant de monter en charge.
Comment trouver le nombre d'utilisateurs où la base de données devient inabordable ?
Appuyez sur « Trouver mon point de rupture ». L'outil pousse chaque variable vers son extrémité la plus défavorable et indique la valeur à laquelle le bénéfice mensuel atteint zéro.
Quelle est la précision de cet outil ?
C'est un modèle pédagogique aux prix illustratifs, et non un devis ou un conseil d'ingénierie. Remplacez les constantes par les prix actuels de votre fournisseur et votre charge mesurée.
Il s'agit d'un modèle de planification à visée pédagogique, fondé sur des hypothèses explicites. Il ne constitue ni un conseil financier, ni un conseil fiscal, ni un conseil juridique. Remplacez les données par vos propres chiffres et faites valider les décisions importantes par un professionnel qualifié.