Confronto Google Cloud SQL e Amazon Aurora

Il primo tentativo di Google di offrire un servizio MySQL As a Service, Cloud SQL, fu lanciato nel 2011 ma era piuttosto deludente in termini di prestazioni e scalabilità. La seconda generazione di Google Cloud SQL, lanciata il 16 agosto scorso, non ha di questi problemi, e anzi offre prestazioni superiori a quelle di Amazon Aurora per alcuni profili di lavoro.

Essenzialmente, Cloud SQL Second Generation è un’implementazione di MySQL 5.7 su un sistema Compute Engine e Persistent Disk di Google. Secondo l’azienda di Mountain View, la seconda generazione offre tempi di esecuzione 7 volte più veloci, una capacità di archiviazione 20 volte superiore e una più alta scalabilità a costi più bassi. Sono inoltre disponibili strumenti di backup automatico che permettono di ripristinare il database in qualsiasi punto nel tempo, e viene offerta una disponibilità del 99,95 percento.

Leggi anche: Amazon sfida MySQL con Aurora

Caratteristiche di Google Cloud SQL Second Generation

Cloud SQL Second Generation è un servizio database completamente gestito, che elimina tutti i passaggi di impostazione e ottimizzazione tipici di un’installazione MySQL locale. Come si può vedere nella figura in basso, quando si configura Cloud SQL è possibile selezionare il tipo di storage, la capacità iniziale, e se di desiderino o meno una replica di failover, backup automatici, logging binario e l’espansione automatica delle dimensioni dello storage.

Creazione di un’istanza con Google Cloud SQL Second Generation

Il database è già ottimizzato per le prestazioni, senza bisogno di pagine e pagine di impostazioni o di trafficare con file di configurazione. Per contrasto, Amazon Aurora permette di configurare l’installazione in ogni singolo dettaglio, ma sono comunque previste delle impostazioni predefinite già ottimizzate.

Interrogata sulle modalità con cui Cloud SQL viene ottimizzato per avere le migliori prestazioni, Google ha risposto che Cloud SQL usa le best practice standard per ottimizzare il livello delle prestazioni, in questo modo.

La configurazione standard è tipica di quel che si può ottenere usando le istanze di Computer Engine. Alcune specifiche sono:

• Opzioni del filesystem Ext4: noatime, discard
• Disk scheduler: impostato su “noop”
• Opzioni MySQL:
o innodb_buffer_pool_size è impostato per il tipo di macchina (quantità di RAM disponibile)
o innodb_flush_method = O_DIRECT
o innodb_flush_neighbor_pages = 0
o innodb_log_file_size = 512 MB

La gestione del database è stata ottimizzata il più possibile laddove abbia un senso.

Backup, repliche, applicazioni di patch e aggiornamenti sono eseguiti automaticamente in base a una programmazione temporale scelta dall’utente, in modo da assicurare una disponibilità superiore al 99,95 percento. Non è possibile ottenere disponibilità superiori (come 99,999) perché patch e aggiornamenti sono assolutamente necessari, ma sono operazioni che avvengono ogni qualche mese durante finestre di manutenzione programmata scelte dal cliente.

Se si vuole clonare un database usando la console, basta solo selezionare un’istanza e selezionare Create clone dal menu Actions. Creare una replica o una copia di failover è altrettanto facile, e come la creazione di un clone non interferisce sulle prestazioni. È anche possibile eseguire queste azioni dalla linea di comando di gcloud o in modo programmatico attraverso le REST API.

È pratica comune restringere l’accesso ai database MySQL solo a indirizzi IP specifici, ma questo può essere un problema per sviluppatori che agiscono da remoto con indirizzi IP dinamici.

Cloud SQL Second Generation include in meccanismo di proxy che elimina questo problema senza compromettere la sicurezza. Il proxy uitilizza OAuth e un suo proprio tunnel sicuro.

Se si sono abilitati i backup e il logging binario, è possibile utilizzare dei punti di ripristino per recuperare il database SQL nello stato che aveva immediatamente prima di uno specifico evento, come per esempio un drop table indesiderato. I punti di ripristino usano la funzionalità clone di Cloud SQL.

Leggi anche: Il confronto definitivo tra i cloud di Amazon, Google e Microsoft

Scalabilità di Google Cloud SQL

Le opzioni hardware per Cloud SQL Second Generation vanno da 1 CPU virtuale e 614 MB di memoria Ram fino a 16 CPU virtuali e 104 GB di Ram, come mostrato nell’immagine qui sotto.

In ciascun raggruppamento (macchine standard e high end) si possono scegliere CPU e memoria insieme, e non separatamente. Se si vogliono fare dei test, è possibile attivare una macchina Cloud SQL db-f1-micro tra le macchine Shared-core (una vCPU e 614 MB, nessuna SLA) per pochi centesimi all’ora (oltre a eventuali costi di storage e transito di rete).

Le diverse combinazioni di risorse hardware con cui è possibile equipaggiare un’istanza Cloud SQL.

Se la tabella maggiore è molto grande, ma il carico previsto è relativamente leggero, si può probabilmente trovare una macchina ottimale nel gruppo high-memory.

Se viceversa le dimensioni della tabella sono ridotte o il carico è relativamente alto, è meglio considerare le macchine del gruppo standard. La regola di base è cominciare con la macchina più piccola possibile, ma che abbia Ram sufficiente a contenere la tabella più grande del database.

Anche dimensioni e prestazioni dello storage si possono controllare solo congiuntamente, scegliendo tra dischi meccanici o SSD. Nel caso dei dischi meccanici il consiglio è di scegliere il taglio minimo necessario e consentire l’aumento automatico in base all’uso. L’aumento delle dimensioni del disco non comporta alcun downtime, quindi non ci sono controindicazioni.

Per le prestazioni di storage migliori, è bene scegliere gli SSD e allocare più spazio di quanto si ritiene di aver bisogno.

È possibile scalare il tipo di macchina in ogni momento, ma questo comporterà un’interruzione del servizio. Quando viene modificato il tipo di macchina, il database viene spento, il volume di storage viene spostato su un’altra macchina virtuale, e l’istanza che è stata migrata viene riavviata. Questo processo impiega dai tre ai cinque minuti. Per confronto, nella mia esperienza, il riavvio di una macchina Amazon Aurora avviene in poco più di 5 minuti.

Le prestazioni di Google Cloud SQL

Di seguito mostreremo alcuni semplici benchmark transazionali condotti da Google, ma è bene ricordare che le prestazioni effettive dipendono molto dai profili di carico specifici dell’applicazione coinvolta. Google ha usato Sysbench, così come ha fatto Amazon per i test di Aurora. Una grande differenza è data dal fatto che Amazon ha usato l’istanza più grande possibile, con 32 CPU virtuali e 244 GB di memoria, e ha usato quattro macchine client per saturare il carico del database e avere i valori più alti possibili di transazioni. La macchina più grande di Google ha 16 vCPU e 104 GB di Ram, e ha scelto quindi istanze di Amazon RDS MySQL e Aurora di dimensioni equivalenti per il confronto.

Google ha scelto una tabella quasi cinque volte più grande della Ram disponibile, in modo che i dati non potessero essere tenuti per intero in memoria, e quindi i valori di benchmark riflettono anche le prestazioni dello storage. Come dicevamo prima però, conviene invece fare in modo che la memoria possa contenere per intero il database per avere il massimo delle prestazioni.

Il primo grafico qui sotto mostra il rapporto tra transazioni e il numero di thread concorrenti di Sysbench per Amazon RDS MySQL, Amazon Aurora e Google Cloud SQL Second Generation. Ciascun ciclo di thread è stato eseguito per 30 minuti. Durante otto differenti esecuzioni, si può notare che il picco di transazioni con Cloud SQL si raggiunge all’inizio, e poi il valore cala, mentre il numero di transazioni su Aurora è più costante, ma più basso. Con 32 thread concorrenti, le prestazioni di Cloud SQL e Aurora cominciano più o meno uguali, ma Cloud SQL si assesta su un punto più basso.

Cloud SQL raggiunge un maggior numero di transazioni fino a 16 thread concorrenti dei client.

Si potrebbe pensare che questo sia un cattivo risultato per Google, ma non lo è. Per comprendere perché, bisogna dare un’occhiata alla latenza.

Nel mondo reale, le applicazioni – e in particolare i siti web aperti al pubblico – impongono limiti alla latenza del database, in modo da rendere più responsiva l’applicazione. Se si guarda alla latenza nei casi di utilizzo di più thread, si nota che con Amazon RDS MySQL questa comincia ad aumentare dopo i 16 thread, mentre Aurora e Cloud SQL bisogna arrivare a 128 thread per vedere valori simili.

Valori così alti possono andare bene se si sta semplicemente eseguendo interrogazioni per un report in batch su una replica o uno snapshot, ma se avete un sito web che deve rispondere velocemente ai clienti, è necessario operare nella regione della bassa latenza, basso carico. In queste condizioni, Google Cloud SQL Second Generation ha prestazioni migliori di Amazon Aurora.

Cloud SQL e le alternative

L’altro grande numero da tenere in considerazione quando si sceglie un servizio database è il costo. Da questo punto di vista, il prezzo di Google Cloud SQL Second Generation e Amazon Aurora è più o meno lo stesso. I valori più alti di transazioni al secondo farebbero propendere per Google Cloud SQL per applicazioni che richiedono una minore latenza, ma questo non è il caso di tutte le applicazioni.

Ricordiamo però che Aurora può scalare molto più di Google Cloud SQL (quasi il doppio di CPU e memoria). Se pensate di avete bisogno di raggiungere quei livelli di prestazioni che con Google non si possono ottenere se non aggiungendo repliche in lettura e forse anche lo sharding (per le transazioni in scrittura), Aurora potrebbe essere una scelta migliore. È comunque probabile che Google aumenti le dimensioni massime delle macchine nel breve futuro.

Come terzo punto, è bene ricordare che i database funzionano bene se sono “vicini” all’applicazione che li utilizza. Se le vostre app sono già sui cloud di Google e Amazon, non ha molto senso piazzare il database in un cloud diverso. Di più, è bene che applicazione e database risiedano nella stessa zona di disponibilità.

Infine, ripetiamo un’altra volta la cosa più importante: i benchmark non sono la vostra applicazione, e i risultati potrebbero non somigliare nemmeno a quelli che il vostro tool esprime. Prima di fare una scelta definitiva, fate dei test su entrambe le piattaforme. Fintanto che si rimane nella fase di test, spostare tutto da un cloud all’altro è relativamente facile. Quando si è già entrati in produzione, le cose si possono complicare parecchio.