Pour ajouter un peu de visibilité à ce comparatif MySQL dans le PaaS, j’ai décidé de faire un récap par thématique et des podiums par solution, avec un argumentaire pour chaque cas. Cet article sera remis à jour avec les infos sur Aurora pour compléter le tableau une fois l’étude publiée.
| Disclaimer : avant de débuter, j’indiquerais que le choix des thèmes et le système de notation n’engage que moi. Je me base sur mon expérience de production sur MySQL, que j’utilise au quotidien depuis plus de 10 ans, de la 4.1 à la 5.7 qui est aujourd’hui notre socle data en production sur AllDB. Si vous avez des commentaires ou si vous n’êtes pas d’accord avec la méthode, vous pouvez vous manifester dans les commentaires en bas de cette page, le dialogue est toujours ouvert 🙂 Egalement pour dire que le monde du cloud est un monde en perpétuel mouvement. Ce qui est annoncé ici peut changer la semaine qui suit. Ce classement dresse un état qui n’est valable que jusqu’à la date de publication de cet article, c’est à dire dans le courant de mai 2019… |
Avant de se lancer, on rappellera les articles de référence pour retrouver tous les détails des tests effectués par plateforme cloud:
– épisode 1 : MySQL sur Google Cloud platform.
– épisode 2 : MySQL et MariaDB sur Microsoft Azure.
– épisode 3 1/2 : MySQL et MariaDB dans Amazon RDS 1/2
– épisode 3 2/2 : MySQL et MariaDB dans Amazon RDS 2/2
Les thématiques
Chaque solution est jugée sur la base d’une thématique. Le but est de dresser un tableau suffisamment exhaustif pour pouvoir estimer justement où se situent ces offres les unes par rapport aux autres… La liste des thématiques est la suivante:
| Couverture technique | Liste des versions et fonctions supportées. Ce thème permet de mesurer la distance en fonctionnalités entre une instance on-premise et une instance dans le PaaS. |
| Tiers et stockage | Variété dans les différents choix de tier et de stockage utilisables. |
| Manageabilité | Souplesse de l’administration (accès aux logs, configuration, connectivité, arrêt, démarrage, etc…) |
| Options de facturation | Variété des choix possibles de facturation. |
| Diagnostics et outillage | Richesse des interfaces de diagnostic et de l’outillage disponible pour l’analyser des incidents et des problèmes de performance. |
| Industrialisation | Mesure des capacités d’automatisation et de la richesse de la grammaire CLI. |
| Disponibilité | Solutions de haute disponibilité proposées. |
| Scalabilité | Solutions de montée en charge sur les tiers, le stockage, les solutions de réplication et le scale-out en lecture seule. |
| Sauvegarde et restauration | Solutions de sauvegarde et flexibilité sur la restauration. |
| Gestion des mises à jour | Encadrement de la maintenance cloud et la mise à jour des versions de la base. |
| Sécurité | Moyens de mise en sécurité du point de vue des données, accès, connexions, sauvegardes, etc… |
| Prix | Evaluation du coût de la solution. |
A noter que je n’ai pas mis de thème ‘Performance’, ce sera certainement l’objet d’un futur post, mais pour noter objectivement la performance il faudrait pouvoir faire un bench, donc, pour l’instant la performance n’entrera pas dans les critères sans preuve à l’appui…
Les critères de notation:
Chaque thématique pour chaque solution sera jugée sur une échelle de 1 à 5 où:
– 1: Inexistant. Le thème n’est tout bonnement pas couvert.
– 2: Faible. La couverture est minimaliste.
– 3: Moyen. Couvre les besoins de base uniquement.
– 4: Optimal. Couvre tous les besoins connus.
– 5: Dépasse les attentes. Présente une plus-value par rapport à l’équivalent on-premise.
Le radar:
Le radar donne la meilleure représentation du bilan par thématique et par solution.
L’avance sur presque tous les domaines prise par Amazon se paye … comptant ! Le prix est ainsi le seul critère pour lequel RDS termine bon dernier. Le détail du pourquoi dans les articles pré-cités, pour la synthèse thématique par thématique, c’est par ici…
Couverture technique
RDS : 5/5. J’ai mis la note maximale à RDS parce qu’il supporte les dernières versions stables de MySQL (8.0.15) et MariaDB (10.3.13), mais aussi la version 5.5 de MySQL pour compatibilité. Aucun autre clouder ne supporte la version 8.0 pour l’instant et aucun autre n’est aussi large dans son choix de version. Quand on migre dans le cloud, c’est important aussi de ne pas avoir à faire une migration de version en plus… Quant aux seules fonctionnalités non supportées on retrouve seulement la réplication semi-synchrone, les tablespaces encryptables ou transpotables et le SET PERSIST dans la version 8.0. J’ai mis 5 aussi car le support de memcached et du plugin d’audit MariaDB dans les option groups est un plus qui n’était pas attendu.
Azure : 3/5. Azure est en seconde position parce qu’il propose MySQL et MariaDB, mais seulement dans les versions 5.6, 5.7 et MariaDB 10.2. Il ne permet toujours pas de créer des fonctions et triggers pour MySQL en raison d’un paramètre non configurable (log_bin_trust_function_creators).
GCP : 2/5. GCP est dernier car il ne propose que MySQL, dans les versions 5.6 et 5.7 pour l’instant, et pas MariaDB. Il ne permet pas d’utiliser Performance_Schema avec tous les tiers et n’autorise pas non plus de faire un CREATE TABLE AS SELECT ou CREATE TEMPORARY TABLE parce que GTID est imposé par défaut.
Tiers et stockage
Globalement les 3 solutions sont équilibrées en termes de tiers disponibles, c’est sur le stockage que la différence se fait.
RDS : 4/5. Sur le stockage, RDS est la seule solution qui propose en plus du provisionnement en Gb un provisionnement en IOPS, (presque) quelle que soit la capacité demandée. Evidemment au prix fort mais la fonctionnalité est là.
Azure : 2/5. C’est le plafond à 6000 IOPS qui pénalise Azure. Comme sur le GP2 d’Amazon, les IOPS sont liés à la capacité à hauteur de 3IOPS/Gb mais il n’y a, contrairement à RDS avec les crédits d’IOPS, aucun levier dans le cas d’Azure, même en stockage Premium.
GCP : 3/5. J’aurais bien mis 3.5 car les caractéristiques du stockage proposé par Google sont quand même bien plus intéressantes que celles d’Azure, avec la capacité à monter beaucoup plus rapidement en IOPS qu’avec les 3IOPS/Gb d’Azure. Elles sont même plus intéressantes que le GP2 de RDS, mais il n’y a pas d’équivalent chez Google de provisionnement en IOPS à ce jour, c’est pourquoi il ne peut pas être au même niveau.
Manageabilité
RDS: 5/5. Encore une fois RDS nous surprend en allant plus loin encore que ce que propose le moteur on-premise en termes de manageabilité.
Déjà la quasi-totalité des commandes qui nécessitent le privilège SUPER sont implémentées via des procédures stockées dédiées. On accède même à des informations qui sont plus du ressort de l’operating system que de la couche applicative de la base, comme la possibilité de décoder le contenu des binlogs par exemple, ou comme on le voit dans la partie diagnostics, accéder aux processus sous-jacents et aux compteurs de l’hôte (uptime, CPU, mémoire, swap, etc…).
L’implémentation du collecteur pour la partie variables de statut est un vrai plus par rapport à l’existant. Tous les paramètres sont modifiables, soit avec des valeurs statiques ou dynamiques (par exemple via la formule DBInstanceClassMemory*3/4 pour innodb_buffer_pool_size) soit des fonctions… Ce qui n’est pas le cas chez les autres clouders.
L’apport des parameter groups et security groups détachés des services PaaS est aussi primordial dans cette catégorie, car il simplifie les déploiements et les restaurations, les PG et SG sont même copiables pour en faire des ‘backups’. Il n’y a guère que le redémarrage au bout de 7 jours d’arrêt qui déçoive un peu mais cela reste gérable et devant le nombre de fonctionnalités en plus par rapports aux concurrents, on ne fera pas la fine bouche.
Azure:3/5. Il y a plus de paramètres de configuration sur Azure que sur GCP, il y a le verrou anti-suppression accidentelle comme sur RDS, par contre le gros point noir c’est l’impossibilité d’arrêter une instance, avec comme seul mode de facturation le pay-as-you-go. Il y aussi le fait qu’une restauration de snapshot oblige à réimplémenter les paramètres, les règles firewalls et les alertes, aspect qui est pris en charge par les parameter groups et security groups chez Amazon. Et enfin autre problème de taille lorsqu’il faudra restaurer une sauvegarde, une ressource ne peut pas être renommée dans Azure. Il faudra donc faire utiliser toujours un alias DNS dans les chaînes de connexion et jamais l’endpoint fourni par Azure.
GCP:3/5. Dans le cas de GCP, la surface de configuration est la plus faible avec seulement 45 paramètres modifiables contre 105 pour Azure et près de 400 sur RDS. Par contre c’est GCP qui est le plus flexible sur les capacités d’arrêt et redémarrage, je l’ai donc mis à égalité avec Azure. Sur RDS, on peut stopper une instance seulement 7 jours, et sur Azure on ne peut rien arrêter du tout… Sur GCP, on peut laisser une instance stoppée sans limitation de temps, on ne paiera que le stockage. Il y a aussi le fait que le stockage ait la capacité d’autoscale, à l’inverse de ses 2 concurrents. Attention toutefois à la facture, c’est un aspect qui peut être positif sur cette thématique et négatif sur la question du prix.
Options de facturation
RDS : 4/5. J’ai mis 4 à RDS car c’est le seul à proposer de la réservation sur 1 an ou 3 ans avec un paiement all upfront ou partial upfront, en plus du pay-as-you-go. RDS est passé à une tarification à la seconde fin mars de cette année, c’est la dernière brique qui manquait pour s’aligner sur les autres, Azure notamment.
Azure: 2/5. Azure ne propose que du pay-as-you-go pour MySQL, même si la notion de réservation commence à arriver pour d’autres bases comme SQL Database. Et en raison de l’impossibilité de stopper une instance sur Azure, je ne met que 2, parce qu’il ne reste que la possibilité de baisser toutes les ressources d’une instance pour limiter sa tarification. Comme évoqué dans l’article de référence, c’est un des gros points noirs d’Azure.
GCP : 3/5. Comme Azure, Google ne propose qu’un système en pay as you go, sans réservation, et reste à une tarification à la minute pour Cloud SQL contrairement à Azure ou RDS. Mais je l’ai mis devant Azure car une instance Cloud SQL est arrêtable, donc le pay-as-you-go a du sens.
Diagnostics et outillage
RDS : 5/5. J’ai mis la note maximale là encore parce que RDS va au delà de ce que permet de faire une instance on-premise. Performance Insights est un premier exemple de cette avance, c’est le seul système proposé qui puisse s’interfacer avec Performance Schema, même si les tiers les plus modestes en sont exclus. Ensuite il y a le bien pratique collecteur GSH pour les variables de statut qui a déjà été mentionné. Enfin Cloudwatch pour la restitution et la gestion des alarmes.
Azure : 3/5. Il y a moins de compteurs disponibles sur Azure, mais tous peuvent être liés à une alerte sur seuil, ce qui reste assez pratique, et c’est ce que l’on attend d’une solution de ce type. Mais il n’y a pas d’outil qui puisse s’interfacer avec Performance Schema alors qu’il est activé par défaut. Quant aux variables de statut, elles sont accessibles mais il faudra construire un système de collecte autour, rien n’est fourni clé en main.
GCP : 2/5. Performance Schema n’est pas disponible dans tous les tiers, et aucun outil n’est proposé pour s’y interfacer. La couche Stackdriver propose une quinzaine de compteurs seulement, donc en termes d’intégration et d’outillage, ça reste la plateforme la plus faible dans ce domaine.
Industrialisation
Les 3 solutions proposent un outil de gestion en ligne de commande pour permettre l’automatisation de certaines tâches comme le déploiement de nouvelles instances, les changements de taille de stockage, de tier, le redémarrage, la configuration, la bascule, le téléchargement des logs, etc…
RDS : 4/5. aws cli est de loin le CLI plus riche en commandes et fonctionnalités. Il y a assez peu de choses que l’on ne peut pas faire en CLI sur AWS en général, ce qui permet de construire des outils de management cloud assez complets: créer un failover replica, créer des read replicas, faire une sauvegarde, la restaurer, créer des alertes, lire les logs, créer des alertes, reconfigurer un paramètre, gérer les règles de firewall, gérer les fenêtres de maintenance, upgrader une instance, lire les évènements attendus comme les opérations de maintenance prévues, changer de tier, de type de stockage… L’équivalent API associé à la puissance de Lambda (runtime serverless) autorise l’automatisation de n’importe quelle tâche récurrente.
Azure : 3/5. az cli est plus réduit en termes de fonctionnalités. Le fait de ne pas pouvoir utiliser la source JSON qui décrit les paramètres d’une instance par exemple, pour pouvoir le recréer suite à une restauration, rend presque impossible l’automatisation de certaines tâches comme la duplication d’environnements.
GCP : 3/5. Mêmes remarques pour GCP. gcloud permet de faire l’essentiel mais ne va pas aussi loin que l’équivalent sur AWS.
Disponibilité
RDS : 4/5. En mode Multi-AZ, l’instance MySQL sera secourue par une instance failover dans une autre zone de disponibilité, synchronisée via un mécanisme de réplication de stockage synchrone. La détection du défaut est gérée par un observer externe, et la bascule de l’endpoint est automatiquement répercutée sur le DNS. Le coût d’ajouter un failover fait monter la facture d’environ 40%, en fonction du tier.
Azure : 2/5. Pas de failover replica sur Azure. Seulement une disponibilité couverte localement dans l’AZ, et au delà des volumes GRS répliqués géographiquement dans une autre région, avec des temps de remontée pouvant aller jusqu’à 12 heures. en fonction de là où l’on souhaite remonter l’instance de secours. C’est le moins bien loti des 3.
GCP : 4/5. Comme pour RDS, il est possible de déployer un failover replica dans une autre zone de disponibilité. Sur GCP, l’instance failover sera maintenue synchronisée via la réplication GTID, c’est donc une approche complètement différente de celle de RDS. Par contre elle sera facturée au même prix que l’instance nominale ce qui fait gonfler la facture de manière considérable.
Scalabilité
Cette thématique montre les possibilité de changer l’échelle de calcul, du stockage, et de répartir la charge en lecture avec des slaves en réplication. Les 3 clouders proposent des solutions assez homogènes.
RDS : 4/5. Changement de tier et de stockage, et même de type de stockage (passer de GP2 à IO1). Et possibilité de créer jusqu’à 5 read replicas pour lisser la charge en lecture seule.
Azure : 4/5. Changement de tier et de stockage, et 5 read replicas comme RDS.
GCP : 4/5. Même chose, pas de limitation donnée sur le nombre de replicas.
Sauvegarde et restauration
Toutes les solutions proposent des backups automatiques et une restauration à un point dans le temps. Dans tous les cas, restaurer une sauvegarde sera fera toujours sur un nouveau service PaaS créé à cette occasion. Donc il y a dans tous les cas le problème de renommage à prendre en considération.
RDS : 4/5. Sur RDS, les sauvegardes automatiques se font sous la forme de snapshots associés à des logs binaires pour la restauration point-in-time. Mais il est possible de créer jusqu’à 50 snapshots manuels maximum par région en plus des snapshots automatiques. Tous les snapshots sont copiables dans d’autres AZ / régions ou partageables avec d’autres comptes Amazon. Tout est gérable depuis aws cli.
Mais ce qui permet à AWS d’être devant ses concurrents, c’est le fait de pouvoir conserver les sauvegardes après avoir supprimé l’instance. Et comme on l’a déjà mentionné dans Manageabilité, lorsque l’on restaure le snapshot d’une instance existante, on peut directement appliquer à la création du nouveau service PaaS le Parameter Group et le Security Group de l’ancien.
Une fenêtre préférentielle de sauvegarde peut être précisée, et RDS conserve jusqu’à 35 jours maximum de sauvegarde en ligne. Et enfin, lorsque l’instance est en Multi-AZ, les backups automatiques se feront sur l’instance de failover pour limiter l’impact en termes de performances sur la production.
Azure : 2/5. Seules les sauvegardes automatiques sont possibles, aucune sauvegarde manuelle. Aucune possibilité de préciser une fenêtre de préférence pour les backups. Les backups peuvent être copiés dans une autre région pour pallier à la perte de la région nominale, mais c’est à peu près tout. Et le seul point par rapport à GCP est la rétention jusqu’à 35 jours.
GCP : 3/5. Des backups automatiques sont effectués et stockés dans 2 régions différentes. Et il est possible d’indiquer une fenêtre de préférence. Les backups ne seront conservés que 7 jours seulement. On ne peut pas backuper sur le failover replica, mais par rapport à Azure, on peut compléter les backups automatiques par des backups manuels.
Gestion des mises à jour
Chez les 3 clouders, la mise à jour des systèmes est pris en charge automatiquement. Ici nous évaluons la souplesse de passage de ces patches, et leur impact sur la disponibilité de l’instance.
RDS : 4/5. Sur RDS, il est possible de définir une fenêtre pour le passage de patches systèmes et les upgrades MySQL mineurs, et dans le cas des upgrades MySQL, il est même possible de les désactiver pour les passer à la main au besoin. Il est aussi possible de changer de version majeure alors que cela n’est pas proposé sur GCP ou Azure. Des logs de maintenance prévue permettent de savoir à l’avance si des opérations sont à prévoir, et on peut aussi choisir de forcer une mise à jour sans attendre la fenêtre de maintenance. Si l’instance est en Multi-AZ, une maintenance provoque une bascule vers l’instance failover de sorte que l’interruption est minimale.
Azure : 2/5. Pas de fenêtre pour la maintenance et les upgrades mineurs MySQL. Pas de migration majeure possible non plus. Comme il n’y a pas de failover replica sur Azure, le passage d’une maintenance implique nécessairement son interruption, à une période qui n’est donc pas prévisible.
GCP : 3/5. Il est possible de préciser une fenêtre de maintenance pour les instances de génération II. On ne peut pas migrer de version majeure.
Prix
On rappelle les éléments de comparaison:
Il n’a pas de secret, la flexibilité et la richesse en fonctionnalités a un coût. Si on se réfère au dernier article sur RDS, on a vu que les 2 solutions vraiment comparables sont GCP et RDS, car dans leur coût final respectif figure un failover replica qui n’existe pas sur Azure. Et à ce jeu-là, Google propose une solution qui certes ne dispose pas de tous les atouts proposés par Amazon, mais qui pourrait bien convenir à des petits et moyens budgets, avec des applicatifs moyennement critiques.
Il faudra cependant bien faire attention aux coût cachés d’une migration dans le PaaS. On a vu dans la thématique de couverture technique que Google est le moins bien placé des trois, ce qui signifie que si vous n’êtes pas dans une version supportée par GCP, il y aura avant tout une première migration à faire on-premise pour amener vos instances en 5.1 ou 5.5 à un bon niveau de compatibilité. Encore plus subtilement, le fait que GCP impose les transactions globales GTID notamment pour le failover replica, impose que l’instance qui migre soit en 5.6.5 minimum car il n’y a pas de support de GTID avant cette version…
RDS : 2/5. La seule thématique où Amazon n’est pas concurrentiel. Si on regarde de près la configuration, celle d’Amazon propose 200Gb à 5000 IOPS provisionnés garantis alors que GCP ne propose que 4500 IOPS maximum. Les deux configurations proposées ne sont donc pas si éloignées que ça, ensuite le choix se fera sur les fonctionnalités. Je pense que pour les déploiements critiques, RDS reste la solution de choix et qu’il faudra simplement y mettre le prix. On rappelle que RDS est la seule solution qui permet de s’engager sur la durée et nous avons montré dans l’article 2/2 sur RDS que sur cette même configuration on arrive à gagner 40% du prix sur 3 ans.
Azure : 3/5. Sur le comparatif effectué dans les articles Azure est moins cher mais le calcul est faussé en raison de l’absence de failover replica. Il ne peut donc pas être mis au dessus de GCP qui propose une solution plus complète et à peine plus onéreuse.
GCP : 4/5. GCP a pour lui cet atout de compétitivité sur le prix de son service. C’est un service qui on l’a vu est plus mature que celui d’Azure parce qu’il en est déjà à sa seconde génération, et que le stockage proposé est aussi le plus intéressant en termes de rapport performances / prix. Et pourtant le failover replica est facturé au prix fort, mais le coût à l’instance reste bien plus faible que sur RDS. Même sur 3 ans avec les 40% de réduction, GCP reste plus attractif avec 60000 euros contre 78000 euros pour RDS. Seul petit bémol, il faudra faire attention aux risques d’explosion de facturation en raison de l’autoscale du stockage.
Sécurité
C’est presque un non-match tant le niveau de sécurisation est comparable sur les 3 solutions. Il n’y en a pas une qui créé une fracture technologique par rapport aux autres. Le niveau est optimal pour les 3 clouders : des certificats sont fournis pour les connexions, le stockage est encryptable pour les données, backups, et les flux réseaux… etc. Ce n’est vraiment pas là où la différence peut se faire…
Classement Final
Sur 12 thématiques à 5 points, sans pondération, on arrive à un classement logique dans lequel RDS domine de la tête et des épaules sans surprise, par sa polyvalence, son orientation production-ready, la richesse des fonctionnalités, disons que ça respire l’expérience. RDS est un service qui a été lancé en 2009 avec MySQL comme premier service PaaS base de donnée, autant dire que ‘précurseur’ est un qualificatif presque faible.
Google Cloud SQL arrive en position de challenger, avec un excellent compromis fonctionnalités / prix, sa force principale. Les performances disque annoncées sont concurrentielles avec les IOPS provisionnés d’Amazon, et on dispose à la fois d’un failover replica pour la reprise sur incident et de read replicas pour le scale-out en lecture. Il y a encore des améliorations à faire comme augmenter la surface de configuration de l’instance (la plus pauvre des 3), ou les interfaces de diagnostics et l’outillage pour l’analyse de performance, peut être sur une troisième génération qui sera compatible avec la version 8.0 ?
Azure arrive en dernière place, on sent bien que pour l’instant les bases open-source ne sont pas encore matures dans le PaaS Microsoft. On en est à une première génération, avec des écueils, et ce n’est pas ce qui constitue la ‘vitrine’ d’Azure en termes de bases de données. Il est possible qu’avec le rachat de Citus Data et l’intégration récente dans Hyperscale, PostgreSQL monte en force beaucoup plus vite dans la ‘culture’ MS que MySQL, l’histoire le dira.
A suivre la mise à jour avec Aurora…
A bientôt !
David.
Continuez votre lecture sur le blog :
- Comparatif MySQL dans le PaaS, épisode 2 : Azure (David Baffaleuf) [AzureMySQL]
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (2/2) (David Baffaleuf) [AWSMySQL]
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]
- Comparatif MySQL dans le PaaS, épisode 1 : Google Cloud SQL (David Baffaleuf) [GCPMySQL]
- PaaS PostgreSQL AWS vs Azure (Capdata team) [AWSAzureNon classéPostgreSQL]