AWS Aurora, quanto mi costi!
I costi di Aurora possono aumentare molto facilmente, se non si presta attenzione ai fattori che contribuiscono alle risorse utilizzate: scopriamo in che modo le query possono influenzare la fattura a fine mese.
Cosa vedrai
Amazon Aurora (spesso abbreviato in Aurora) è un database relazionale proprietario completamente gestito compatibile con MySQL e PostgreSQL.
Come molte soluzioni fully-managed, i costi possono lievitare facilmente ed è bene comprendere quali sono i fattori che influenzano i costi in bolletta.
Tra i vari fattori, c’è lo storage, il tipo di istanza scelta, backup e molto altro, ma oggi parliamo dei costi di I/O.
Cosa sono le richieste di I/O
In Aurora, le richieste di I/O di storage si riferiscono alle operazioni di lettura e scrittura eseguite sul volume di storage sottostante, e quindi sui dati. Queste richieste vengono in genere generate quando i dati vengono recuperati o scritti nel database.
Supponiamo di avere un cluster di database Aurora MySQL con una tabella denominata orders. Quando esegui una query come la seguente:
SELECT * FROM orders WHERE order_id = 1234
Aurora esegue i seguenti passaggi: la query viene analizzata e ottimizzata dall’ottimizzatore di query, e poi verifica se i dati richiesti sono disponibili nel buffer pool (ossia, nella cache).
Il buffer pool
Se i dati non sono in cache, Aurora esegue una richiesta di I/O di lettura per recuperare le pagine di dati richieste dall’utente.
Una volta recuperati i dati, vengono caricati nel buffer pool e i risultati della query vengono restituiti al client.
Amazon Aurora non ha una dimensione prefissata per il buffer pool che si applica a tutti i cluster. Piuttosto, la dimensione effettiva del buffer pool per un cluster Aurora dipende dal tipo di istanza e dalla quantità di memoria allocata al cluster. In particolare, per i cluster che si basano su Aurora MySQL, il buffer pool InnoDB (più o meno equivalente al buffer pool nel tradizionale MySQL) è configurato automaticamente per utilizzare circa il 75% della memoria dell’istanza. Ad esempio, su un’istanza r5.4xlarge con 128 GB di memoria, il buffer pool InnoDB sarebbe di circa 96 GB.
È importante sottolineare che il buffer pool è il componente che in Aurora è progettato per ridurre al minimo le richieste di I/O di storage sfruttando tecniche come la memorizzazione nella cache, lo storage strutturato in log e i modelli di scrittura ottimizzati, così da ridurre anche i costi.
Costi aggiuntivi
Tuttavia, durante le operazioni di lettura e scrittura si verificano comunque richieste di I/O di archiviazione e monitorarle può aiutare a identificare potenziali colli di bottiglia nelle prestazioni o a ottimizzare il carico di lavoro.
Infatti, se i dati richiesti sono disponibili nel buffer pool di Aurora, non ti verranno addebitati i costi di I/O di archiviazione associati a tale query.
Questo perché ti vengono addebitati i costi in base alla quantità di dati trasferiti tra il livello di archiviazione e il motore del database. Questo viene misurato dalle operazioni di I/O eseguite sul volume di archiviazione sottostante.
Quando i dati sono già presenti nel buffer pool, Aurora può fornire un output rispetto alla query direttamente recuperando i dati dalla memoria senza dover accedere al livello di archiviazione. Poiché in questo caso non vengono eseguite operazioni di I/O di archiviazione, non ti vengono addebitati costi di I/O di archiviazione.
Tuttavia, potresti comunque sostenere costi di elaborazione associati alle risorse di CPU e memoria utilizzate per elaborare la query, ma questi costi sono separati dai costi di I/O di archiviazione.
Vale la pena notare che mentre il buffer pool può ridurre significativamente i costi di I/O di archiviazione per i dati a cui si accede di frequente, non elimina completamente la necessità di I/O di archiviazione. Le query che accedono a dati non presenti nel buffer pool o le operazioni che modificano i dati (come INSERT, UPDATE o DELETE) genereranno comunque richieste di I/O di storage e comporteranno costi associati.
