Confronto istanze cloud

La stessa configurazione su tre cloud, e perché non è lo stesso affare

Scegliere un'istanza di database di solito comincia da una configurazione — tante vCPU, tanta memoria — e finisce sul nome più economico sopra quella soglia nell'elenco del provider. Questo strumento fa quella ricerca contemporaneamente su AWS RDS, Google Cloud SQL e Azure Flexible Server, e aggiunge il numero che quegli elenchi omettono: quante connessioni ciascuno ti lascerà davvero aprire.

Come funziona

• Prende un minimo di vCPU e un minimo di memoria e trova, per ciascun cloud, l'istanza più piccola che soddisfa entrambi.
• Mostra accanto due opzioni più grandi, così vedi cosa costa in risorse il gradino successivo.
• Riporta il limite di connessioni di ogni istanza accanto alla sua configurazione, calcolato con la regola di quel provider.
• Contrassegna esplicitamente la corrispondenza più piccola, perché la prima riga della tabella di un provider raramente è quella che vuoi.

corrispondenza più piccola = minimo tra le istanze dove
    vcpu >= tuo_minimo  E  memoria >= tuo_minimo
  ordinate per vcpu, poi per memoria

le connessioni derivano dalla regola pubblicata da ogni
provider, non da uno standard comune di settore

Esempio pratico

Un servizio che richiede almeno 8 vCPU e 32 GiB, confrontato sui tre cloud.

1. AWS: db.m5.2xlarge — 8 vCPU, 32 GiB, circa 3.324 connessioni
2. Azure: B8ms — 8 vCPU, 32 GiB, 3.437 connessioni
3. Google Cloud SQL: db-custom-8-53248 — 8 vCPU, 52 GiB, 600 connessioni
4. le configurazioni quasi coincidono su due cloud; i limiti di connessione non coincidono affatto

AWS e Azure approdano a hardware praticamente identico con tetti di connessione praticamente identici. Cloud SQL ti dà 20 GiB di memoria in più e circa un quinto delle connessioni. Se il tuo servizio pesa in connessioni e non in memoria, la decisione è tutta lì.

Come leggere il risultato

• Cloud SQL accetta forme macchina personalizzate arbitrarie, quindi la corrispondenza più piccola mostrata per Google è la più piccola in questo catalogo, non la più piccola esistente. Lì è disponibile una forma da esattamente 8 vCPU e 32 GiB; la colonna lo segnala, e la cifra Google va letta come un campione.
• La corrispondenza più piccola a volte è di tipo burstable, e burstable non equivale. La serie B di Azure e la classe t di AWS accumulano crediti CPU a riposo e limitano quando i crediti finiscono: accettabile per un database di sviluppo o uno strumento interno a picchi, scadente per qualsiasi carico di fondo costante.
• I conteggi di vCPU non sono confrontabili tra cloud senza cautela. Le istanze AWS Graviton contano core fisici mentre le classi x86 contano hyperthread, quindi 8 vCPU Graviton e 8 vCPU x86 non sono la stessa potenza. Confronta con fiducia dentro un cloud, solo a grandi linee tra cloud.
• Qui si confrontano configurazione e tetto di connessioni, non il prezzo. Capacità riservata, sconti per uso impegnato e piani di risparmio spostano il costo reale di molte volte, e lo spostano in modo diverso su ogni cloud: un confronto di configurazioni avvia una decisione, non la chiude.
• Per la maggior parte dei database la memoria conta più delle vCPU, perché determina sia la cache che tiene le query lontane dal disco sia, su AWS e Azure, il tetto di connessioni stesso. Se non sai quale soglia alzare, alza la memoria.

Domande frequenti

Perché Google mostra più memoria di quanta ne ho chiesta?

Perché il catalogo qui campiona le forme Cloud SQL comuni invece di enumerarle tutte, e la forma campionata più vicina sopra la tua soglia può eccedere. Cloud SQL supporta forme personalizzate, quindi di solito puoi richiedere esattamente la memoria che vuoi: leggi la colonna Google come indicativa.

La corrispondenza più piccola è sempre la scelta giusta?

È la cosa più economica che supera la tua soglia, il che è giusto solo se la soglia è giusta. Fissa la soglia sull'uso misurato più margine per la crescita e per il failover, non sul picco attuale: un'istanza dimensionata esattamente sul picco di oggi non ha spazio per quello di domani.

Perché i limiti di connessione differiscono tanto a parità di memoria?

Perché li fissano regole diverse con intenzioni diverse. AWS e Azure ricavano il limite dalla memoria e finiscono nello stesso intervallo. Google lo fissa per fasce di memoria su valori molto più bassi, presumendo che i carichi con molte connessioni usino un pooler. Nessuna delle tre sbaglia; vengono applicate in modo diverso, ed è questo a riguardarti.