MySQL dans le cloud - Avantages et inconvénients d'Amazon RDS

Déplacer vos données dans un service de cloud public est une décision importante. Tous les principaux fournisseurs de cloud proposent des services de base de données cloud, Amazon RDS pour MySQL étant probablement le plus populaire.

Dans ce blog, nous allons examiner de près ce que c'est, comment cela fonctionne et comparer ses avantages et ses inconvénients.

RDS (Relational Database Service) est une offre Amazon Web Services. En bref, il s'agit d'une base de données en tant que service, où Amazon déploie et exploite votre base de données. Il prend en charge des tâches telles que la sauvegarde et les correctifs du logiciel de base de données, ainsi que la haute disponibilité. Quelques bases de données sont prises en charge par RDS, nous nous intéressons ici principalement à MySQL - Amazon prend en charge MySQL et MariaDB. Il y a aussi Aurora, qui est le clone de MySQL d'Amazon, amélioré, notamment dans le domaine de la réplication et de la haute disponibilité.

Déployer MySQL via RDS

Examinons le déploiement de MySQL via RDS. Nous avons choisi MySQL, puis on nous présente quelques modèles de déploiement parmi lesquels choisir.

Le choix principal est :voulons-nous avoir une haute disponibilité ou non ? Aurora est également promue.

La boîte de dialogue suivante nous donne quelques options à personnaliser. Vous pouvez choisir l'une des nombreuses versions de MySQL - plusieurs versions 5.5, 5.6 et 5.7 sont disponibles. Instance de base de données - vous pouvez choisir parmi les tailles d'instance typiques disponibles dans une région donnée.

L'option suivante est un choix assez important - voulez-vous utiliser le déploiement multi-AZ ou non ? Tout est question de haute disponibilité. Si vous ne souhaitez pas utiliser le déploiement multi-AZ, une seule instance sera installée. En cas d'échec, un nouveau sera lancé et son volume de données sera remonté dessus. Ce processus prend un certain temps, pendant lequel votre base de données ne sera pas disponible. Bien sûr, vous pouvez minimiser cet impact en utilisant des esclaves et en promouvant l'un d'entre eux, mais ce n'est pas un processus automatisé. Si vous souhaitez disposer d'une haute disponibilité automatisée, vous devez utiliser un déploiement multi-AZ. Ce qui se passera, c'est que deux instances de base de données seront créées. L'un vous est visible. Une deuxième instance, dans une zone de disponibilité distincte, n'est pas visible pour l'utilisateur. Il agira comme un cliché instantané, prêt à prendre en charge le trafic une fois le nœud actif défaillant. Ce n'est toujours pas une solution parfaite car le trafic doit être basculé de l'instance défaillante vers l'instance fantôme. Lors de nos tests, il a fallu environ 45 secondes pour effectuer un basculement mais, évidemment, cela peut dépendre de la taille de l'instance, des performances d'E/S, etc. Mais c'est bien mieux qu'un basculement non automatisé où seuls des esclaves sont impliqués.

Enfin, nous avons des paramètres de stockage - type, taille, PIOPS (le cas échéant) et des paramètres de base de données - identifiant, utilisateur et mot de passe.

À l'étape suivante, quelques options supplémentaires attendent l'entrée de l'utilisateur.

Nous pouvons choisir où l'instance doit être créée :VPC, sous-réseau, doit-il être accessible au public ou non (comme dans - une adresse IP publique doit-elle être attribuée à l'instance RDS), zone de disponibilité et groupe de sécurité VPC. Ensuite, nous avons des options de base de données :premier schéma à créer, port, groupes de paramètres et d'options, si les balises de métadonnées doivent être incluses dans les instantanés ou non, paramètres de chiffrement.

Ensuite, les options de sauvegarde - combien de temps souhaitez-vous conserver vos sauvegardes ? Quand voudriez-vous qu'ils soient pris ? Une configuration similaire est liée aux maintenances - parfois les administrateurs Amazon doivent effectuer une maintenance sur votre instance RDS - cela se produira dans une fenêtre prédéfinie que vous pouvez définir ici. Veuillez noter qu'il n'y a pas d'option pour ne pas choisir au moins 30 minutes pour la fenêtre de maintenance, c'est pourquoi il est vraiment important d'avoir une instance multi-AZ en production. La maintenance peut entraîner le redémarrage du nœud ou un manque de disponibilité pendant un certain temps. Sans multi-AZ, vous devez accepter ce temps d'arrêt. Avec le déploiement multi-AZ, le basculement se produit.

Enfin, nous avons des paramètres liés à la surveillance supplémentaire - voulons-nous l'activer ou non ?

Gérer RDS

Dans ce chapitre, nous examinerons de plus près comment gérer MySQL RDS. Nous ne passerons pas en revue toutes les options disponibles, mais nous aimerions mettre en évidence certaines des fonctionnalités mises à disposition par Amazon.

Instantanés

MySQL RDS utilise des volumes EBS comme stockage, il peut donc utiliser des instantanés EBS à des fins différentes. Sauvegardes, esclaves - tous basés sur des instantanés. Vous pouvez créer des instantanés manuellement ou ils peuvent être pris automatiquement, en cas de besoin. Il est important de garder à l'esprit que les instantanés EBS, en général (pas seulement sur les instances RDS), ajoutent une surcharge aux opérations d'E/S. Si vous souhaitez prendre un instantané, attendez-vous à ce que vos performances d'E/S chutent. À moins que vous n'utilisiez un déploiement multi-AZ, c'est-à-dire. Dans ce cas, l'instance "fantôme" sera utilisée comme source d'instantanés et aucun impact ne sera visible sur l'instance de production.

Sauvegardes

Les sauvegardes sont basées sur des instantanés. Comme mentionné ci-dessus, vous pouvez définir votre planification de sauvegarde et votre rétention lorsque vous créez une nouvelle instance. Bien sûr, vous pouvez modifier ces paramètres par la suite, via l'option "modifier l'instance".

À tout moment, vous pouvez restaurer un instantané - vous devez accéder à la section des instantanés, choisir l'instantané que vous souhaitez restaurer, et une boîte de dialogue similaire à celle que vous avez vue lorsque vous avez créé une nouvelle instance s'affichera. Ce n'est pas une surprise car vous ne pouvez restaurer un instantané que dans une nouvelle instance - il n'y a aucun moyen de le restaurer sur l'une des instances RDS existantes. Cela peut surprendre, mais même dans un environnement cloud, il peut être judicieux de réutiliser le matériel (et les instances que vous possédez déjà). Dans un environnement partagé, les performances d'une seule instance virtuelle peuvent différer - vous préférerez peut-être vous en tenir au profil de performances que vous connaissez déjà. Malheureusement, ce n'est pas possible dans RDS.

Une autre option dans RDS est la récupération ponctuelle - une fonctionnalité très importante, une exigence pour toute personne qui doit prendre soin de ses données. Ici, les choses sont plus complexes et moins brillantes. Pour commencer, il est important de garder à l'esprit que MySQL RDS cache les journaux binaires à l'utilisateur. Vous pouvez modifier quelques paramètres et répertorier les binlogs créés, mais vous n'y avez pas directement accès - pour effectuer n'importe quelle opération, y compris les utiliser pour la récupération, vous ne pouvez utiliser que l'interface utilisateur ou la CLI. Cela limite vos options à ce qu'Amazon vous permet de faire, et cela vous permet de restaurer votre sauvegarde jusqu'à la dernière "heure de restauration" qui se trouve être calculée dans un intervalle de 5 minutes. Ainsi, si vos données ont été supprimées à 9h33, vous ne pouvez les restaurer que jusqu'à l'état à 9h30. La restauration ponctuelle fonctionne de la même manière que la restauration d'instantanés :une nouvelle instance est créée.

Évolutivité, réplication

MySQL RDS permet le scale-out en ajoutant de nouveaux esclaves. Lorsqu'un esclave est créé, un instantané du maître est pris et il est utilisé pour créer un nouvel hôte. Cette partie fonctionne plutôt bien. Malheureusement, vous ne pouvez pas créer de topologie de réplication plus complexe comme celle impliquant des maîtres intermédiaires. Vous n'êtes pas en mesure de créer une configuration maître - maître, ce qui laisse toute haute disponibilité entre les mains d'Amazon (et les déploiements multi-AZ). D'après ce que nous pouvons dire, il n'y a aucun moyen d'activer GTID (pas que vous puissiez en bénéficier car vous n'avez aucun contrôle sur la réplication, pas de CHANGE MASTER dans RDS), uniquement des positions de journal binlog à l'ancienne. /P>

L'absence de GTID rend impossible l'utilisation de la réplication multithread - alors qu'il est possible de définir un certain nombre de travailleurs à l'aide de groupes de paramètres RDS, sans GTID, cela est inutilisable. Le principal problème est qu'il n'y a aucun moyen de localiser une seule position de journal binaire en cas de plantage - certains travailleurs pourraient avoir été en retard, d'autres pourraient être plus avancés. Si vous utilisez le dernier événement appliqué, vous perdrez des données qui ne sont pas encore appliquées par ces travailleurs "en retard". Si vous utilisez l'événement le plus ancien, vous vous retrouverez très probablement avec des erreurs de "clé en double" causées par les événements appliqués par les travailleurs les plus avancés. Bien sûr, il existe un moyen de résoudre ce problème, mais ce n'est pas trivial et cela prend du temps - certainement pas quelque chose que vous pourriez facilement automatiser.

Les utilisateurs créés sur MySQL RDS n'ont pas le privilège SUPER, donc les opérations, qui sont simples dans MySQL autonome, ne sont pas triviales dans RDS. Amazon a décidé d'utiliser des procédures stockées pour permettre à l'utilisateur d'effectuer certaines de ces opérations. D'après ce que nous pouvons dire, un certain nombre de problèmes potentiels sont couverts bien que cela n'ait pas toujours été le cas - nous nous souvenons quand vous ne pouviez pas passer au prochain journal binaire sur le maître. Un plantage du maître + une corruption du binlog pourraient rendre tous les esclaves brisés ; il existe maintenant une procédure pour cela :rds_next_master_log .

Un esclave peut être manuellement promu maître. Cela vous permettrait de créer une sorte de HA au-dessus du mécanisme multi-AZ (ou de le contourner), mais cela a été rendu inutile par le fait que vous ne pouvez pas réasservir aucun des esclaves existants au nouveau maître. N'oubliez pas que vous n'avez aucun contrôle sur la réplication. Cela rend tout l'exercice futile - à moins que votre maître ne puisse gérer tout votre trafic. Après avoir promu un nouveau maître, vous ne pouvez pas le basculer car il n'a pas d'esclaves pour gérer votre charge. La création de nouveaux esclaves prendra du temps, car les instantanés EBS doivent d'abord être créés, ce qui peut prendre des heures. Ensuite, vous devez réchauffer l'infrastructure avant de pouvoir la charger.

Absence de privilège SUPER

Comme nous l'avons indiqué précédemment, RDS n'accorde pas aux utilisateurs le privilège SUPER et cela devient ennuyeux pour quelqu'un qui a l'habitude de l'avoir sur MySQL. Tenez pour acquis que, dans les premières semaines, vous apprendrez à quelle fréquence il est nécessaire de faire des choses que vous faites assez fréquemment - comme tuer des requêtes ou utiliser le schéma de performance. Dans RDS, vous devrez vous en tenir à une liste prédéfinie de procédures stockées et les utiliser au lieu de faire les choses directement. Vous pouvez tous les lister en utilisant la requête suivante :

SELECT specific_name FROM information_schema.routines;

Comme pour la réplication, un certain nombre de tâches sont couvertes, mais si vous vous retrouvez dans une situation qui n'est pas encore couverte, alors vous n'avez pas de chance.

Interopérabilité et configurations de cloud hybride

C'est un autre domaine où RDS manque de flexibilité. Supposons que vous souhaitiez créer une configuration mixte cloud/sur site - vous disposez d'une infrastructure RDS et que vous souhaitez créer quelques esclaves sur site. Le principal problème auquel vous serez confronté est qu'il n'y a aucun moyen de déplacer des données hors de RDS, sauf pour effectuer un vidage logique. Vous pouvez prendre des instantanés de données RDS, mais vous n'y avez pas accès et vous ne pouvez pas les éloigner d'AWS. Vous n'avez pas non plus d'accès physique à l'instance pour utiliser xtrabackup, rsync ou même cp. La seule option pour vous est d'utiliser mysqldump, mydumper ou des outils similaires. Cela ajoute de la complexité (le jeu de caractères et les paramètres de classement peuvent causer des problèmes) et prend du temps (il faut beaucoup de temps pour vider et charger les données à l'aide d'outils de sauvegarde logique).

Il est possible de configurer la réplication entre RDS et une instance externe (dans les deux sens, donc la migration des données vers RDS est également possible), mais cela peut être un processus très long.

D'autre part, si vous souhaitez rester dans un environnement RDS et étendre votre infrastructure à travers l'Atlantique ou de la côte est à la côte ouest des États-Unis, RDS vous permet de le faire - vous pouvez facilement choisir une région lorsque vous créez un nouvel esclave.

Malheureusement, si vous souhaitez déplacer votre maître d'une région à l'autre, cela n'est pratiquement pas possible sans temps d'arrêt - à moins que votre nœud unique ne puisse gérer tout votre trafic.

Sécurité

Bien que MySQL RDS soit un service géré, tous les aspects liés à la sécurité ne sont pas pris en charge par les ingénieurs d'Amazon. Amazon l'appelle "Modèle de responsabilité partagée". En bref, Amazon s'occupe de la sécurité du réseau et de la couche de stockage (afin que les données soient transférées de manière sécurisée), du système d'exploitation (correctifs, correctifs de sécurité). D'autre part, l'utilisateur doit s'occuper du reste du modèle de sécurité. Assurez-vous que le trafic vers et depuis l'instance RDS est limité au sein du VPC, assurez-vous que l'authentification au niveau de la base de données est effectuée correctement (pas de comptes d'utilisateur MySQL sans mot de passe), vérifiez que la sécurité de l'API est assurée (les AMI sont définies correctement et avec un minimum de privilèges requis). L'utilisateur doit également prendre soin des paramètres du pare-feu (groupes de sécurité) pour minimiser l'exposition du RDS et du VPC dans lequel il se trouve aux réseaux externes. Il est également de la responsabilité de l'utilisateur de mettre en œuvre le chiffrement des données au repos, soit au niveau de l'application, soit au niveau de la base de données, en créant d'abord une instance RDS chiffrée.

Le chiffrement au niveau de la base de données peut être activé uniquement lors de la création de l'instance, vous ne pouvez pas chiffrer une base de données existante déjà en cours d'exécution.

Limites RDS

Si vous envisagez d'utiliser RDS ou si vous l'utilisez déjà, vous devez connaître les limitations associées à MySQL RDS.

Absence de privilège SUPER peut être, comme nous l'avons mentionné, très ennuyeux. Bien que les procédures stockées prennent en charge un certain nombre d'opérations, il s'agit d'une courbe d'apprentissage car vous devez apprendre à faire les choses d'une manière différente. L'absence de privilège SUPER peut également créer des problèmes lors de l'utilisation d'outils de surveillance et de tendance externes - certains outils peuvent encore nécessiter ce privilège pour certaines parties de leurs fonctionnalités.

Le manque d'accès direct au répertoire de données et aux journaux MySQL rend plus difficile l'exécution d'actions qui les implique. Il arrive de temps en temps qu'un administrateur de base de données ait besoin d'analyser des journaux binaires ou une erreur de queue, une requête lente ou un journal général. Bien qu'il soit possible d'accéder à ces journaux sur RDS, c'est plus fastidieux que de faire tout ce dont vous avez besoin en vous connectant au shell sur l'hôte MySQL. Les télécharger localement prend également un certain temps et ajoute une latence supplémentaire à tout ce que vous faites.

Manque de contrôle sur la topologie de réplication, haute disponibilité uniquement dans les déploiements multi-AZ. Étant donné que vous n'avez aucun contrôle sur la réplication, vous ne pouvez implémenter aucun type de mécanisme de haute disponibilité dans votre couche de base de données. Peu importe que vous ayez plusieurs esclaves, vous ne pouvez pas en utiliser certains comme candidats maîtres car même si vous promouvez un esclave en maître, il n'y a aucun moyen de réasservir les esclaves restants sur ce nouveau maître. Cela oblige les utilisateurs à utiliser des déploiements multi-AZ et à augmenter les coûts (l'instance "fantôme" n'est pas gratuite, l'utilisateur doit payer).

Disponibilité réduite grâce à des temps d'arrêt planifiés. Lors du déploiement d'une instance RDS, vous êtes obligé de choisir une fenêtre horaire hebdomadaire de 30 minutes pendant laquelle les opérations de maintenance peuvent être exécutées sur votre instance RDS. D'une part, cela est compréhensible car RDS est une base de données en tant que service, de sorte que les mises à niveau matérielles et logicielles de vos instances RDS sont gérées par les ingénieurs AWS. D'un autre côté, cela réduit votre disponibilité car vous ne pouvez pas empêcher votre base de données principale de tomber en panne pendant la durée de la période de maintenance. Encore une fois, dans ce cas, l'utilisation de la configuration multi-AZ augmente la disponibilité car les modifications se produisent d'abord sur l'instance fantôme, puis le basculement est exécuté. Le basculement lui-même, cependant, n'est pas transparent, donc, d'une manière ou d'une autre, vous perdez le temps de disponibilité. Cela vous oblige à concevoir votre application en gardant à l'esprit les défaillances inattendues du maître MySQL. Non pas qu'il s'agisse d'un mauvais modèle de conception - les bases de données peuvent planter à tout moment et votre application doit être conçue de manière à pouvoir résister même au scénario le plus désastreux. C'est juste qu'avec RDS, vous avez des options limitées pour une haute disponibilité.

Options réduites pour la mise en œuvre de la haute disponibilité. Compte tenu du manque de flexibilité dans la gestion de la topologie de réplication, la seule méthode de haute disponibilité réalisable est le déploiement multi-AZ. Cette méthode est bonne mais il existe des outils de réplication MySQL qui minimiseraient encore plus les temps d'arrêt. Par exemple, MHA ou ClusterControl, lorsqu'ils sont utilisés en relation avec ProxySQL, peuvent fournir (sous certaines conditions, comme le manque de transactions de longue durée) un processus de basculement transparent pour l'application. Lorsque vous êtes sur RDS, vous ne pourrez pas utiliser cette méthode.

Perspectives réduites sur les performances de votre base de données. Bien que vous puissiez obtenir des métriques de MySQL lui-même, il ne suffit parfois pas d'avoir une vue complète de 10 000 pieds de la situation. À un moment donné, la majorité des utilisateurs devront faire face à des problèmes vraiment étranges causés par un matériel défectueux ou une infrastructure défectueuse - paquets réseau perdus, connexions interrompues brusquement ou utilisation élevée du processeur de manière inattendue. Lorsque vous avez accès à votre hôte MySQL, vous pouvez tirer parti de nombreux outils qui vous aident à diagnostiquer l'état d'un serveur Linux. Lorsque vous utilisez RDS, vous êtes limité aux métriques disponibles dans Cloudwatch, l'outil de surveillance et de tendance d'Amazon. Tout diagnostic plus détaillé nécessite de contacter le support et de lui demander de vérifier et de résoudre le problème. Cela peut être rapide, mais cela peut aussi être un processus très long avec beaucoup de communications par e-mail.

Verrouillage du fournisseur causé par un processus complexe et chronophage d'extraction des données du RDS MySQL. RDS n'autorise pas l'accès au répertoire de données MySQL, il n'y a donc aucun moyen d'utiliser des outils standard de l'industrie comme xtrabackup pour déplacer des données de manière binaire. En revanche, le RDS sous le capot est un MySQL maintenu par Amazon, il est difficile de dire s'il est compatible à 100% avec l'amont ou non. RDS n'est disponible que sur AWS, vous ne pourrez donc pas effectuer une configuration hybride.

Résumé

MySQL RDS a à la fois des forces et des faiblesses. C'est un très bon outil pour ceux qui souhaitent se concentrer sur l'application sans avoir à se soucier de l'exploitation de la base de données. Vous déployez une base de données et commencez à émettre des requêtes. Pas besoin de créer des scripts de sauvegarde ou de configurer une solution de surveillance, car c'est déjà fait par les ingénieurs d'AWS - tout ce que vous avez à faire est de l'utiliser.

Il y a aussi un côté sombre du RDS MySQL. Manque d'options pour créer des configurations plus complexes et une mise à l'échelle en dehors de l'ajout de plus d'esclaves. Manque de prise en charge pour une meilleure haute disponibilité que ce qui est proposé dans les déploiements multi-AZ. Accès fastidieux aux journaux MySQL. Absence d'accès direct au répertoire de données MySQL et absence de prise en charge des sauvegardes physiques, ce qui rend difficile le déplacement des données hors de l'instance RDS.

Pour résumer, RDS peut fonctionner correctement pour vous si vous appréciez la facilité d'utilisation plutôt que le contrôle détaillé de la base de données. Vous devez garder à l'esprit qu'à un moment donné dans le futur, vous pourriez devenir trop grand pour MySQL RDS. On ne parle pas forcément ici uniquement de performances. Il s'agit davantage des besoins de votre organisation pour une topologie de réplication plus complexe ou d'un besoin d'avoir une meilleure compréhension des opérations de base de données pour traiter rapidement les différents problèmes qui surviennent de temps à autre. Dans ce cas, si votre ensemble de données a déjà augmenté en taille, il peut être difficile de sortir du RDS. Avant de prendre la décision de transférer vos données dans RDS, les responsables de l'information doivent tenir compte des exigences et des contraintes de leur organisation dans des domaines spécifiques.

Dans les prochains articles de blog, nous vous montrerons comment extraire vos données du RDS dans un emplacement séparé. Nous aborderons à la fois la migration vers EC2 et vers l'infrastructure sur site.