Guida di approfondimento
Simulatore di scalabilità di database e IOPS: quando il costo del database gestito supera il ricavo per utente
Analisi direzionale del settore
Un database gestito è la parte dell'infrastruttura che le persone vorrebbero dimenticare, e che le dimentica a sua volta quando arriva la fattura. Si parte da una piccola istanza e un piccolo disco. Poi gli utenti crescono, le funzioni aggiungono query, le tabelle si riempiono di storico, e il piano che era economico diventa la voce più grande della fattura. A differenza dei server web, i database non scalano aggiungendo macchine identiche e a basso costo. Scalano passando a istanze più grandi, aggiungendo capacità di throughput allocata e copiando tutto sulle repliche, e ognuno di questi passi moltiplica il costo.
La struttura del problema è che il costo sale a gradini mentre i ricavi crescono in modo continuo. Le dimensioni delle istanze raddoppiano: da due a quattro a otto a sedici vCPU, con il prezzo che raddoppia all'incirca a ogni passo. L'archiviazione e gli IOPS vengono fatturati separatamente e le repliche moltiplicano ciascuna di queste voci. Il ricavo per utente non raddoppia quando raddoppia la vostra istanza. Un'attività comodamente redditizia con 30.000 utenti può scoprire che la dimensione successiva annulla il guadagno dei 10.000 utenti seguenti.
Il modello a domino segue la catena. Gli utenti e gli IOPS ogni mille utenti fissano la richiesta di picco sul livello di archiviazione. I requisiti di calcolo decidono la dimensione dell'istanza, che a sua volta determina la fattura insieme a repliche, archiviazione e throughput allocato. La fattura diventa una quota dei ricavi, che infine decide l'utile. Una query mal indicizzata può cambiare la prima casella di un fattore tre senza alcuna variazione di utenti, ed è per questo che l'ottimizzazione delle query è spesso il modo più economico per abbassare tutte le caselle successive.
L'iceberg separa l'istanza che tutti vedono dagli extra che rendono la fattura più grande del previsto. Sono visibili l'istanza primaria e l'archiviazione. Sotto la linea di galleggiamento ci sono le repliche, che ripetono calcolo e archiviazione, gli IOPS allocati oltre la base che un disco include, i backup conservati per settimane e il traffico che replica i dati fra le zone. Ognuna è fatturata sotto una voce diversa, quindi è facile sottostimarle in fase di pianificazione. Usate il simulatore per provare come si comporta la vostra architettura al crescere degli utenti e dove il database smette di essere sostenibile.
Schema delle formule e della metodologia
Il modello è un solo mese. La richiesta di IOPS di picco è gli utenti ogni mille per gli IOPS ogni mille per un fattore di picco di 2,5. Il calcolo necessario è 0,0005 vCPU per utente, arrotondato per eccesso a una dimensione di istanza in potenze di due con un minimo di due. Ogni replica ripete istanza primaria, archiviazione e IOPS allocati. Gli IOPS allocati sono fatturati oltre una base di 3.000. Archiviazione, backup e replica fra zone si aggiungono al totale, e gli altri costi sono il 40% dei ricavi.
- IOPS di picco
- I = utenti ÷ 1000 × IOPS ogni 1000 × 2,5
- Operazioni al secondo che il livello di archiviazione deve sostenere nel picco.
- Dimensione dell'istanza
- V = 2^ceil(log₂(max(2, utenti × 0,0005)))
- vCPU sull'istanza primaria, che vengono in dimensioni a potenze di due.
- Fattura del database
- D = (1 + repliche) × (V × prezzo + costo IOPS + archiviazione) + backup + fra zone
- Calcolo, throughput e archiviazione ripetuti su ogni nodo, più backup e replica.
- IOPS allocati
- max(0, I − 3000) × $0,10 per nodo
- Throughput oltre ciò che il disco include, fatturato su ogni nodo.
- Utile netto
- Netto = ricavi × (1 − 40%) − D
- Il risultato mensile. Il punto di rottura è dove arriva a zero.
Elasticità a cascata
Repliche e IOPS per utente sono gli input più elastici, perché ciascuno si moltiplica su ogni nodo. Il ricavo per utente scala l'intero margine. Gli utenti cambiano il risultato sia con i ricavi sia passando a un'istanza più grande, quindi la crescita non è una vittoria gratuita.
Tre casi di studio reali
Avvio con risorse proprie
Un piccolo prodotto su un database minimo
Un giovane prodotto ha tremila utenti, una sola replica e pochi dati per utente. Il ricavo per utente è alto e l'istanza è della dimensione minima. Caricando il caso si vede che il database è trascurabile all'inizio e come un alto ricavo per utente lasci spazio per crescere.
Crescita nel mercato intermedio
Una grande base di utenti con query efficienti
Un prodotto con trecentomila utenti mantiene bassi gli IOPS per utente con indicizzazione e cache e gestisce due repliche. La fattura è grande in termini assoluti ma è una quota modesta dei ricavi. Caricando il caso si vede la scala funzionare quando le query sono ottimizzate.
Crisi da cigno nero
Query pesanti e troppe repliche
Un prodotto con una grande base di utenti e un basso ricavo per utente esegue query senza indici, cinque repliche e molti dati archiviati per utente. IOPS allocati e repliche moltiplicano ogni costo. Caricando il caso si vede la fattura del database superare i ricavi e quale leva risana il mese.
Matrice dei parametri di riferimento del settore
| Indicatore | Zona di pericolo | Media del settore | Eccellenza (primo 10%) |
|---|---|---|---|
| Costo del database in percentuale dei ricavi | Sopra il 35% | 8–15% | Sotto il 6% |
| Costo del database per utente attivo al mese | Sopra $0,25 | $0,05–0,12 | Sotto $0,04 |
| Repliche per un tipico SaaS | Più di 3 senza una chiara esigenza di lettura | 1–2 | 1 di riserva più repliche in lettura mirate |
| Quota di IOPS allocati effettivamente usata nel picco | Sotto il 30% | 50–70% | 70–85% |
| Conservazione dei backup | Mesi di snapshot completi | 7–14 giorni | Conservazione a livelli con archivio |
Variabili e leve
Utenti attivi
Utenti che generano carico sul database in un mese tipico.
Leva: Non date per scontato che più utenti significhino sempre un margine migliore: verificate che il ricavo per utente copra ancora la dimensione di istanza successiva.
Ricavo per utente al mese
Ricavo mensile medio che ottenete da un utente attivo.
Leva: Aumentate il ricavo per utente con livelli di prezzo, perché il costo del database per utente cresce con l'uso e l'archiviazione.
IOPS rilevanti nel picco ogni 1.000 utenti
Operazioni medie di lettura e scrittura al secondo generate da ogni migliaio di utenti. Progettazione delle query e indicizzazione incidono di più su questo valore.
Leva: Aggiungete gli indici mancanti, mettete in cache le letture frequenti e raggruppate le scritture: ridurre gli IOPS spesso evita sia dischi più grandi sia istanze più grandi.
Prezzo per vCPU al mese
Quanto il vostro database gestito addebita per vCPU al mese per la classe di istanza che usate.
Leva: Confrontate le famiglie di istanze e impegnatevi su capacità riservata una volta che il carico è prevedibile.
Repliche in lettura e di riserva
Copie aggiuntive del database per le letture o per il failover. Ognuna ripete il costo di calcolo, archiviazione e IOPS.
Leva: Mettete in discussione ogni replica: tenete una riserva per il failover e aggiungete repliche in lettura solo quando le letture ne hanno davvero bisogno.
Dati archiviati per utente (GB)
Gigabyte medi di archiviazione del database che ogni utente aggiunge, indici compresi.
Leva: Archiviate le righe vecchie su storage più economico, fissate limiti di conservazione e comprimete le colonne voluminose.
Come usare questo simulatore
- 1Partite dalla configurazione realistica o inserite utenti, ricavo per utente e dettagli dell'istanza attuale.
- 2Leggete le cinque caselle del domino per vedere se diventano rossi per primi la richiesta di IOPS o la dimensione dell'istanza.
- 3Premete Trova il mio punto di rottura per vedere il carico o il numero di repliche che azzera l'utile.
- 4Confrontate la configurazione attuale con il piano di ottimizzazione nel grafico di 24 mesi.
- 5Esaminate ogni trimestre le query lente e le repliche inutilizzate, prima del prossimo salto di istanza.
Errori da evitare
- Dare per scontato che il costo del database cresca in proporzione agli utenti, quando cresce a gradini e si moltiplica con le repliche.
- Allocare IOPS ben oltre ciò che il carico usa, perché l'impostazione è stata copiata da un sistema più grande.
- Tenere repliche in lettura che nessuna query usa, pagando calcolo e archiviazione due o tre volte.
- Ingrandire l'istanza prima di guardare le query lente e gli indici mancanti che hanno creato il carico.
Domande frequenti
Che cosa sono gli IOPS e perché vengono fatturati?
IOPS significa operazioni di input e output al secondo: quante letture e scritture compie il livello di archiviazione. Alcuni livelli di archiviazione includono una base e fatturano il throughput allocato oltre di essa. Controllate le regole aggiornate del vostro fornitore.
Quando devo aggiungere una replica in lettura?
Quando le letture dominano chiaramente e l'istanza primaria è il collo di bottiglia, oppure quando servono latenza geografica o failover. Aggiungere repliche per abitudine moltiplica l'intera fattura.
Perché il costo salta a certi numeri di utenti?
Le istanze hanno dimensioni fisse, quindi superare una soglia vi porta alla dimensione successiva con un prezzo all'incirca doppio. Il modello usa dimensioni a potenze di due per mostrare questi salti.
Un'istanza più grande è meglio di più repliche?
Per le scritture la risposta abituale è una istanza primaria più grande. Per le letture aiutano repliche o cache. La combinazione giusta dipende dal carico, quindi misurate prima di scalare.
Come trovo il numero di utenti al quale il database diventa insostenibile?
Premete Trova il mio punto di rottura. Lo strumento sposta ogni input verso il suo estremo peggiore e riporta il valore al quale l'utile mensile arriva a zero.
Quanto è accurato?
È un modello didattico con prezzi indicativi, non un preventivo tecnico né una consulenza. Sostituite le costanti con i prezzi attuali del vostro fornitore e con il carico che avete misurato.
Questo è un modello di pianificazione a scopo didattico, con ipotesi dichiarate. Non costituisce consulenza finanziaria, fiscale o legale. Sostituite i dati con le vostre cifre e verificate le decisioni importanti con un professionista qualificato.