AWS RDS : quelles sont les différentes bases de données supportées

Avec Amazon RDS, les développeurs ont aujourd’hui accès à plusieurs moteurs de base de données. Si certes les besoins des entreprises sont uniques, elles doivent aussi considérer les licences, les coûts et les capacités d’ouverture.

Il est un  constat : l’offre de services d’AWS est très ramifiée et cela peut être quelque peu perturbant pour les utilisateurs. Le spécialiste du Cloud est une illustration même d’un paradoxe : celui du choix. Les utilisateurs ont accès à un très vaste portefeuille de services, mais sont confrontés à de multiples options ; ce qui crée de la complexité et rend difficile la prise de décision.

Cela est typiquement le cas dans les services de bases de données. AWS dispose à son catalogue 6 services, dont 2 de bases relationnelles, sans parler d’Hadoop EMR, Kinesis Stream, et Amazon S3. Et pour compliquer un peu plus les choses, le service premier de base de données du groupe, Amazon RDS (Relational Database Service) supporte pas moins de 6 moteurs de bases de données. Et chaque option de RDS a des fonctions clé adaptées à différents cas d’usage.

Amazon RDS est un service managé qui peut être configuré et prêt à l’emploi en quelques minutes via la Management Console d’AWS, des APIs REST ou encore en ligne de commandes. AWS propose des configurations par défaut qu’il estime adaptées à chaque moteur de bases de données. Les développeurs ajustent ces paramètres lors de la configuration ; les bases de données peuvent partager leurs paramètres via DB Parameters Groups.

Comme avec les instances EC2, on peut contrôler les capacités de la base en ajustant le nombre de CPU virtuels (jusqu’à 32), la mémoire (jusqu’à 244 Go de RAM) et le type de stockage persistent. Par défaut, les instances Amazon RDS se reposent sur des disques SSD, mais pour augmenter le rendement des transactions, les développeurs peuvent utiliser le provisionnement d’IOPS.

Voici les 6 options proposées par RDS :

  • Amazon Aurora. Il s’agit d’une implémentation personnalisée de la base Open Source MySQL qui, selon AWS, a été conçue pour le Cloud en intégrant le stockage, le réseau, le compute, le système et la base de données dans un unique service. Aurora se dimensionne automatiquement par tranche de 10 Go – et jusqu’à 64 To – pour s’adapter aux usages sans interrompre l’application. La scalabilité des performances est linéaire, selon le besoin de ressources. Pour garantir la haute disponibilité, Aurora opère une réplication automatique dans 3 zones de disponibilité avec deux copies des données dans chacune d’entre elles. Cette redondance permet à Aurora de traiter les données dès que 4 des 6 écritures sont finalisées – au lieu d’attendre la fin de toutes les écritures. Aurora DB peut créer jusqu’à 15 réplications avec très peu de latence.
  • MySQL. Ce service propose une installation brute de l’édition Community de MySQL, avec InnoDB comme moteur de stockage par défaut. Les utilisateurs peuvent configurer les versions 5.5, 5.6 et 5.7 de MySQL. AWS s’est engagé à supporter les versions pendant au moins 3 ans après leur publication sur RDS. A l’inverse d’Aurora, les instances standards de MySQL n’ont pas de capacités d’auto-scaling ni de réplication automatique multi-zones. De plus, les coûts de stockage sont calculés à ce qu’on lui attribue, alors que les utilisateurs Aurora ne paient que pour les ressources consommées par la base. MySQL offre des capacités de dimensionnement plus large et peut être provisionné avec des instances t2.micro, tandis que r3.large est la plus petite instance supportée par Aurora.
  • MariaDB. Cette base de données, fork de MySQL, est disponible sous la forme d’instances dotées des mêmes capacités que le service MySQL, avec le patching automatique et les snapshots de la base. Les instances peuvent se reposer sur des disques magnétiques, SSD, ou sur Elastic Block Stock pour des IOPS plus étendues. Les développeurs peuvent répliquer automatiquement les instances entre les zones de disponibilité, avec un basculement automatique depuis la base primaire.
  • Oracle. Les entreprises peuvent provisioner cette base, soit à la demande ou sur des instances réservées. Comme avec les instances EC2, les bases de données réservées peuvent compenser les coûts avec des remises de 20 à 60% sur l’usage à l’heure, selon les termes de la réservation. Les instances embarquent des licences Oracle, mais les clients peuvent aussi apporter les leurs – à condition de respecter les restrictions d’Oracle en matière de Cloud – et avoir une ristourne de 50% à l’heure.
  • Microsoft SQL Server. Comme avec Oracle, cette option est une instance standard de la base de données de Microsoft. Amazon RDS supporte SQL Server 2008 R2, SQL Server 2012 et 2014 dans leurs éditions Express, Web et Standard, et Enterprise 2008 R2 et 2012. Les clients peuvent réserver des instances ; les entreprises ayant souscrit à la Software Assurance peuvent apporter leurs propres licences pour obtenir des ristournes.
  • PostgreSQL. Ce service propose les mêmes fonctions de management et de patching que les autres bases de données Open Source. PostgreSQL est réputée chez les développeurs pour créer des backends pour le géospatial, l’analyse statistique et le Machine-Learning. Cela permet de migrer le code d’une application vers RDS après peu de modifications.

Toutes les offres de RDS ont des modèles de licences différents, que ce soit pour les bases propriétaires et Open Source.  AWS tient à jour une grille tarifaire  pour l’ensemble des services proposés.

Quelles options RDS choisir

Le choix du bon moteur RDS repose grandement sur les besoins de l’application. Par exemple, les entreprises qui s’appuient déjà sur Oracle ou SQL Server pour leurs systèmes patrimoniaux  préféreront certainement utiliser les mêmes plateformes sur AWS. En revanche, les développeurs, qui créent de nouvelles applications, natives pour le Cloud, devront quant à eux opter pour une base Open Source – à moins d’avoir des exigences auxquelles ces bases ne répondent pas.

Aurora peut être un bon choix, car ce service propose un champ fonctionnel étendu, comme la haute disponibilité, la redondance multi-zones et des fonctions d’auto-scaling ; ce qui élimine les coûts liés au sur-provisioning. Les petites bases de données sont l’exception : elles n’ont pas besoin des mêmes capacités qu’une instance r3.large – la plus petite option pour Aurora. Les développeurs qui doivent s’adosser à d’anciennes versions de MySQL peuvent aussi considérer cette option.

La taille des instances détermine leur coût. Les développeurs travaillant sur des applications qui ne nécessitent pas de grandes instances trouveront cela surdimensionné.  Les applications qui fonctionnent sous Aurora ne sont pas « enfermées », car le service s’appuie sur MySQL et peut donc être migré vers d’autres moteurs MySQL.

Les bases de données Open Source ont su combler le fossé fonctionnel qui existait avec les bases traditionnelles. Selon Gartner, en 2018, 70% de toutes les nouvelles applications seront motorisées par une base de données Open Source et la moitié des utilisateurs de bases relationnelles commerciales passeront à l’Open Source. D’ici là, le marché des bases devrait se consolider, pense le cabinet. Les acteurs qui tirent le marché devraient opérer à des rachats et faire converger leurs outils avec des technologies alternatives, comme NoSQL, le In-Memory et le Big Data, dans une unique plateforme.

Dans ce contexte, AWS ainsi que d’autres acteurs du Cloud mènent la danse en proposant des services de bases de données centralisés et managés, et connectés via des APIs. Les nombreuses fonctions ainsi que la capacité à gérer les performances permettent aux développeurs de sélectionner la bonne technologie pour une tâche donnée. 

Traduit et adapté par la rédaction

Dernière mise à jour de cet article : octobre 2016

Approfondir

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close