Introduction

Cet article fait partie d’une suite d’articles venant à découvrir les services PaaS BDD PostgreSQL que fournissent les principaux acteurs acteurs du cloud.

Le scénario de test sera toujours le même, un bench de type TPC-C sera lancé à l’aide d’une version benchmarksql revue pour intégrer la connexion SSL et la capture de traces SGBD (sources disponibles ici : https://github.com/Capdata/benchmarksql), chaque bench :

• Durera 20 minutes
• Base de données avec 200 entrepôts (Cf norme TPC-C)
• Sera lancé avec 50 clients à partir d’une VM créée dans la même zone que le PaaS

Le but est de mesurer pour des configurations particulières le nombre de transactions par minutes, les valeurs seront ensuite agrégées et extrait le 90e centile du nombre de transactions totales par minutes (tpm / min) et du nombre de commandes par minutes (nopm / min, c’est la valeur de référence pour les benchmark de type TPC-C).

AWS

Présentation

AWS fournit un accès à PostgreSQL en service managé au travers de 2 offres :

• RDS PostgreSQL
• RDS Aurora

RDS PostgreSQL est disponible en versions 9.5.2 à 12.4 ,quant à Aurora il offre une compatibilité de 9.6.8 à 11.8

Un peu d’historique

2009 : Mise en service de RDS
2013 : Support de PostgreSQL dans RDS
2014 : Mise en service de Aurora (support Mysql uniquement)
2017 : Support de PostgreSQL par aurora
2019 : Aurora PostgreSQL logical replication
2019 : Aurora Serverless disponible pour PostgreSQL (nombre de régions disponibles encore assez limité aujourd’hui)
2020 : Babelfish* en preview sur Aurora pour PostgreSQL

*Babelfish (annoncé en décembre 2020) est un projet sous licence apache v2 (ouverture des sources prévue pour le premier trimestre de 2021) qui ajoute un endpoint à PostreSQL rendant transparente pour les application la conversion SQL Server / PostgreSQL et ce sans à avoir à changer quoi que ce soit côté applicatif.

AWS RDS

RDS pour Relational Database Service est le service de Base de données Relationnelle géré par AWS, offre un large choix de moteurs SGBD propriétaire (SQLServer, Oracle, Mysql, Aurora) ou libres (MariaDB, PostgreSQL).

En plus de profiter de tous les services inhérents à tous les composants AWS, celui-ci comprend le stockage, la gestion des sauvegarde et des montées de versions mineures automatiques (si validé).

Pour une description détaillée de RDS je vous renvoie à l’excellent article de David Baffaleuf : https://blog.capdata.fr/index.php/comparatif-mysql-dans-le-paas-episode-3-amazon-rds-2-2/

RDS Aurora

Aurora est le moteur SGBD RDS développé par AWS, offrant une compatibilité avec soit PostgreSQL soit MySQL (choix défini lors de la création).
Aurora, en plus de promettre un gain en performances promet également une durabilité accrue des données ; en effet, les données sont regroupées par block de 10Gb et présentées par 6 storage nodes différents répartis de façon uniforme sur 3 Zones de disponibilités (AZ) différentes (on a donc 2 storages nodes par AZ ) le stockage s’agrandit de façon autonome par block de 10Gb jusqu’à atteindre la limite (contrainte par le système) de 64To (limite qui augmente régulièrement).

L’historique des modifications du service est disponible ici : https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/WhatsNew.html

Aurora un moteur SGBD-R à part

Aurora et le stockage

Aurora se distingue des PaaS RDS classique par son stockage et l’optimisation SGBD qui a été faite pour en tirer plein parti.

En effet, la façon dont est conçu le stockage sur Aurora est très particulier, comme expliqué ci-dessus, le stockage est alloué et protégé par block de 10Gb :

De plus, ce stockage est régulièrement backupé sur S3 :

(ci-dessus, chaque carré vert correspond à 1 storage node et chaque bloc de couleur à un “protection group” (ensemble de données) de 10Gb

Pour éviter les latences sur le stockage le moteur n’attend pas l’acquittement de tous les storage nodes mais considère la donnée comme écrite si au moins 4 des 6 storage nodes l’ont validée, ainsi même avec la perte d’une AZ (ou de 2 storage nodes d’AZ différentes) le service est toujours rendu.

De plus des modifications ont étés apportées au sein même des SGBD (Mysql et PostgreSQL) de façon à ce que les données échangées (entre les instances de BDD et les storage nodes) soient réduites au strict minimum (les logs de transaction).

Pour plus d’informations :

Performances

Comme expliqué en introduction, l’outil benchmarkSQL sera utilisé (légèrement modifié pour supporter le SSL et capturer des métriques complémentaires), seront en plus capturé en fin de chaque bench les métriques des PaaS.

Les sources sont disponibles à l’adresse : https://github.com/Capdata/benchmarksql

Les PaaS ont tous la version 11 de PostgreSQL, les options PostgreSQL sont laissées à leurs défauts et leur configuration est la suivante :

aws_aurora : Aurora en compatibilité PostgreSQL
aws_rds : Stockage de type gp2 et taille allouée 2To (IOPS liées à la taille du stockage : 3 IOPS/Go max 16k IOPS), IOPS :   6k IOPS
aws_rds_pio_10k : Stockage de type IO provisionnés, 10k IOPS max
aws_rds_pio_30k : Stockage de type IO provisionnés, 30k IOPS max

Partant de là, la seule variable à être ajustée a été la capacité / classe d’instance EC2 (CPU et mémoire) de l’instance :

(Il n’y a pas de valeurs pour aurora pour les classes db.m5.* car ces classes ne sont pas disponibles sur aurora).

Tarification des instances

CPU / MEM

Les tarif donnés ici sont sur la Zone Paris pour une seule instance en dollar US (données au 04/12/2020 et donnés ici à unique titre de comparaison).

La différence de tarif entre les 2 Types de PaaS (RDS Classique et Aurora) n’est pas énorme (du moins en ce qui concerne le coût de l’instance).

Stockage

Il y a donc de présenté 3 classes de stockage différentes :

GP2:
Stockage à usage général (SSD) 0,133 USD par Go/mois
Cependant, les opérations d’IO consommées ne vous sont pas facturées.

IO Provisionnées :
Tarif de stockage 0,145 USD par Go/mois
Tarif d’IOPS provisionnés 0,116 USD par IOPS/mois
Cependant, les opérations d’IO consommées ne vous sont pas facturées.

Aurora :
Taux de stockage 0,11 USD par Go et par mois
Taux d’E/S 0,22 USD par tranche d’un million de demandes
Le stockage utilisé par votre base de données Amazon Aurora est facturé par tranches de Go/mois. Les IO consommées sont, quant à elles, facturées par tranches de millions de requêtes

La grosse différence entre Aurora et les autres types de stockage est donc le fait que les IO sont facturées en plus du stockage, c’est donc un élément à prendre en charge lors du choix Aurora vs RDS Classique.

Explications :

Pour un stockage de 20Go et une moyenne de 1000 IO/s en lecture et 1000 IO/s en écriture (ce qui est assez faible).

Aurora :

– Cout du stockage seul 20 Go x 0.11 USD = 2.20 USD
– 1000 Reads/Second + 1000 Writes/Second = 2000 Number of I/Os per second
– 2000 IO/s x 730 h x 60 min x 60 s = 5 256 000 000  IO / mois
– 5 256 000000 x 0.00000022 USD = 1156,30 USD (coût des IOs)
– 2,20 USD + 1156,30 USD = 1 158,30 USD

Coût final mensuel : 1 158,30 USD

RDS Classique GP2 :

– Cout du stockage seul 20 Go x 0,133 USD = 2,66 USD

Coût final mensuel : 2,66 USD

Remarque : Les performances d’IO pour ce stockage sont de 3 IOPS pour chaque Go, avec un minimum de 100 IOPS.
Par exemple, les performances de base pour un volume de 100 Gio sont de 300 IOPS.

Pour le cas présenté ci-dessus, le stockage alloué (pour des raisons de performances) été de 2048Go (ce qui représente une grosse sur allocation mais nécessaire pour atteindre un niveau d’IOPS raisonnable).

RDS Classique Provision IOPS  :
Provision de 10 000 IOPS

– 20 Go  x 0,145 USD = 2,90 USD (Stockage seul)
– 10 000 IOPS x 0,116 USD = 1 160,00 USD (Coût des IO)
– 2,90 USD + 1 160,00 USD = 1 162,90 USD

Coût final mensuel : 1 162,90 USD 

RDS Classique Provision IOPS  :
Provision de 30 000 IOPS

– 20 Go  x 0,145 USD = 2,90 USD (Stockage seul)
– 30 000 IOPS x 0,116 USD = 3 480,00 USD (Coût des IO)
– 2,90 USD + 3 480,00 USD = 1 162,90 USD

Coût final mensuel : 3 482,90 USD 

Comparatif de coûts stockage

Conclusion

Il est clair qu’Aurora est plus performant que RDS Classique et peut revenir moins cher que de l’IO provisionné, cependant, il faut bien toujours garder à l’esprit que sur Aurora chaque IO a un prix, de plus ce moteur, bien que pleinement compatible avec PostgreSQL (ou MySQL) reste un moteur propriétaire.

Une assez bonne surprise est également ressortie de ce benchmark, les trés bonnes performances de RDS avec un stockage GP2 (attention, ici il n’y a aucune garantie sur les IO).

Continuez votre lecture sur le blog :

• PaaS PostgreSQL AWS vs Azure (Capdata team) [AWSAzureNon classéPostgreSQL]
• Azure et PostgreSQL en PaaS (Capdata team) [AzurePostgreSQL]
• Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]
• Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (2/2) (David Baffaleuf) [AWSMySQL]
• MySQL dans le PaaS : le radar de notation des solutions (David Baffaleuf) [AWSAzureGCPMySQL]