Nous nous retrouvons pour le 2eme article de la série de PostgreSQL en PaaS public, avec cette fois Azure.

Présentation

Azure, bien que assez récent dans sa conquête du cloud (février 2010) a beaucoup étoffé son offre et notamment son offre PaaS BDD avec aujourd’hui près d’une dizaine d’offres dont 3 entièrement dédiées à PostgreSQL (hors offre Arc*) :

• Single server
• Flexible server (toujours en preview lors de cet article)
• Hyperscale (racheté à Citusdata)

Cela montre à quel point Microsoft veut asseoir sa position dans la fourniture d’une offre PaaS PostgreSQL, en effet, l’offre de base ne date que 2017.

La stratégie d’allocation d’instances sur Azure est de simplifier les choix disponibles, ainsi la quantité de mémoire est liée au nombre de CPU.

*Azure Arc permet de créer des infrastructures cloud hybride ou multi cloud

Azure PostgreSQL Single Server

C’est la première offre PaaS PostgreSQL Azure à avoir vu le jour, petite particularité évidente uniquement pour Microsoft, le PaaS ne peut pas être stoppé, redémarré oui mais pas arrêté (à moins de vouloir supprimer celui-ci).

Les versions supportées vont de la 9.5 à la 11 (sachant que la version 13 est sortie le 12/11/2020).

Pour le provisionnement d’instance, on a le choix entre :

• Basic => Idéal pour les petites charges, instances de 1 à 2 CPU, 2Go de RAM / CPU
• General Purpose => de 2 à 64 CPU, 5Go de RAM / CPU
• Memory Optimized => de 2 à 32 CPU, 10Go de RAM / CPU

Stockage

Le stockage allouable va de 5Go à  16To et peut être configuré pour profiter de “l’autogrow” (augmentation automatique du stockage), les IOPS sont liées à la quantité de stockage (3 IOPS/GB, Min 100 IOPS, Max 20,000 IOPS), ce qui implique de devoir “sur-provisionner” pour avoir la quantité d’IOPS voulue.

Azure PostgreSQL Flexible Server

Ce service est en preview mais semble prometteur, en effet, il “comble” certaines lacunes du Single Server notamment le fait de pouvoir arrêter le PaaS sans avoir à le supprimer, ajout du support de la version 12 (support des versions 11 et 12 uniquement).
Flexible Server apporte également certaines “régressions” (qui devraient être comblées à terme), notamment la perte de “l’autogrow”.

Le stockage

Le stockage s’alloue avec un minimum de 32Go et chaque nouvelle augmentation est le double du précédent, ainsi, on a les valeurs suivantes comme stockage disponible :

Azure PostgreSQL Hyperscale (Citus)

Cette version du PaaS reposant sur l’extension de Citus data (racheté par Microsoft en 2019) est surtout dédiée aux gros entrepôts de données, en effet grace à l’extension Citus les données sont “shardées” et les requêtes parallélisables sur de nombreux noeuds.

La mise en place de Citus et donc l’exploitation correcte d’hyperscale demande cependant d’avoir un schéma de données se prêtant correctement car il faut pouvoir partitionner suivant une certaine clef, cependant, ceci étant fait, les accès sont alors transparents (pas d’ajout de code supplémentaire) pour l’application (et/ou les clients).

Performances

Seuls les PaaS Single Server et Flexible Server ont été “Benchés”.

Comme lors de l’article précédent, l’outil benchmarkSQL a été utilisé, les métriques des PaaS ont également été capturées.

Les sources sont disponibles à l’adresse : https://github.com/Capdata/benchmarksql et mises à jour en fonction des avancées, un article a d’ailleurs été écrit montrant comment utiliser benchmarkSQL (https://blog.capdata.fr/index.php/postgresql-benchmarking/)

Les PaaS ont tous la version 11 de PostgreSQL, les options PostgreSQL sont laissées à leurs défauts, les instances de type Basic et Burstable ont été écartées du test car trop limitées en capacités.

A chaque test, on utilise les 2 typologie d’instances (Memory Optimized et General Purpose) et on itère à la fois sur le nombre de CPU (et donc de fait la quantité de RAM) puis sur le stockage alloué (de façon à avoir plus d’IOPS), les résultats sont récapitulés ci-dessous, avec en abscisse l’ID du test composé du type d’instance (General Purpose ou Memory Optimised), du nombre de CPU et de la taille du stockage alloué séparés par “_” et en ordonné le nombre de transactions par minute au 75eme centile  :

 

• Premier constat, il y a peu de différences entre les instances de type Memory Optimized et General Purpose
• Deuxième constat, les PaaS de type Flexible Server (azurefs) sont nettement plus performants (en terme de nombre de transactions admissibles / minute) que les PaaS de type Single Server (azuress)
• Dernier constat, sur Flexible Server le stockage alloué limite très peu les IOPS, ie, pour du GP_16 (General purpose 16 CPU), si on compare les performances pour le stockage minimun  (128 Go) au maximun (2 To) on a quasiment autant de transactions par minute, pour preuve la comparaison sur les IOPS des instances lors des benchs (ID correspond à <stockage alloué>_<nombre de cpu>, les types d’instance General Purpose et Memory Optimized ont été agrégées ici et on ne garde que le max de chaque) :

On a donc un réel changement qu’à partir de 1To de stockage provisionné, les IOPS auraient été limitées par le CPU ? Voyons ça ci-dessous :

On a donc une limite sur les petites instances (de 2 et 4 CPU) mais plus rien après.

C’est donc une bonne nouvelle, reste à voir maintenant si cela n’est pas du au fait que le service soit en mode preview car pour rappel, les IOPS max pour 128Go de stockage sont d’uniquement 500 contre près de 4500 ici !!!

 

Comparaison financière

Dans le tableau ci-dessous les tarifs sont donnés de façon indicative uniquement, le but étant de comparer un coût Single Server avec un Flexible Server.

SIZE	SingleServer			FlexibleServer			Diff
	CPU	Storage	Total	CPU	Storage	Total
GP_2_128	119	14	133	116	14	130	-3
MO_2_128	161	14	175	161	14	175	0
GP_4_128	237	14	251	233	14	247	-4
MO_4_128	323	14	337	323	14	337	0
GP_8_128	474	14	488	465	14	479	-9
MO_8_128	646	14	660	646	14	660	0
GP_16_128	949	14	963	931	14	945	-18
MO_16_128	1291	14	1305	1292	14	1306	1
GP_2_256	119	27	146	116	27	143	-3
MO_2_256	161	27	188	161	27	188	0
GP_4_256	237	27	264	233	27	260	-4
MO_4_256	323	27	350	323	27	350	0
GP_8_256	474	27	501	465	27	492	-9
MO_8_256	646	27	673	646	27	673	0
GP_16_256	949	27	976	931	27	958	-18
MO_16_256	1291	27	1318	1292	27	1319	1
GP_2_512	119	55	174	116	55	171	-3
MO_2_512	161	55	216	161	55	216	0
GP_4_512	237	55	292	233	55	288	-4
MO_4_512	323	55	378	323	55	378	0
GP_8_512	474	55	529	465	55	520	-9
MO_8_512	646	55	701	646	55	701	0
GP_16_512	949	55	1004	931	55	986	-18
MO_16_512	1291	55	1346	1292	55	1347	1
GP_2_1024	119	109	228	116	109	225	-3
MO_2_1024	161	109	270	161	109	270	0
GP_4_1024	237	109	346	233	109	342	-4
MO_4_1024	323	109	432	323	109	432	0
GP_8_1024	474	109	583	465	109	574	-9
MO_8_1024	646	109	755	646	109	755	0
GP_16_1024	949	109	1058	931	109	1040	-18
MO_16_1024	1291	109	1400	1292	109	1401	1
GP_2_2048	119	218	337	116	218	334	-3
MO_2_2048	161	218	379	161	218	379	0
GP_4_2048	237	218	455	233	218	451	-4
MO_4_2048	323	218	541	323	218	541	0
GP_8_2048	474	218	692	465	218	683	-9
MO_8_2048	646	218	864	646	218	864	0
GP_16_2048	949	218	1167	931	218	1149	-18
MO_16_2048	1291	218	1509	1292	218	1510	1

Les instances Flexible Server sont donc moins chères, la plus grande différence de tarif allant jusqu’à 18€ pour les instances les plus grosses ce qui représente presque 20% du tarif (je rappelle aussi que contrairement aux Single Server, les instances Flexible Server peuvent être stoppées, suspendant de fait leur coût).

Conclusion

Plus performantes, moins chère, plus de fonctionnalités, les instances Flexible Server sont sans nul doute la prochaine itération des PaaS PostgreSQL sur Azure, reste à savoir si les performances resteront après le passage en General Availability.

Au delà de ce comparatif sur les performances pures, on peut voir à quel point Microsoft investi dans le Cloud et notamment PostgreSQL.

Continuez votre lecture sur le blog :

• PaaS PostgreSQL AWS vs Azure (Capdata team) [AWSAzureNon classéPostgreSQL]
• AWS RDS, Aurora et PostgreSQL (Capdata team) [AWSPostgreSQL]
• Stocker ses bases de données dans un Azure Blob Storage : l’impossible dilemme ? (Vincent Delabre) [AzureSQL Server]
• Comparatif MySQL dans le PaaS, épisode 2 : Azure (David Baffaleuf) [AzureMySQL]
• Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]