0

Azure et PostgreSQL en PaaS

twitterlinkedinmail

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 :

32

64

128

256

512

1024

2048

4096

8192

16384

Les IOPS sont ici aussi liées au stockage (mais également au CPU) :

Storage size

32

64

128

256

512

1024

2048

4096

8192

16384

IOPS_MAX

120

240

500

1100

2300

5000

7500

7500

16000

18000

Attention, contrairement au Single Server le PaaS nécessite un arrêt pour upgrader le stockage.

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 :

twitterlinkedinmail

Nicolas MARTIN

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.