Aller au contenu

Step 2 : RDS

Nous avons vu avec la première étape les instances EC2, leurs volumes EBS ainsi que la partie réseau avec les VPC.

Grâce à ces briques, nous avons pu déployer notre infrastructure applicative et notamment une base de données. Parmi les resources et services que propose AWS, beaucoup sont ce que l'on appelle des services managés. Plutôt que de créer des instances EC2 puis installer et configurer nos services dessus, AWS le fait pour nous de façon optimisée et sécurisée.

Ces services couvrent beaucoup de domaines, serveurs DNS, Kubernetes, Kafka, ActiveMQ, Git, Prometheus, Grafana... Pour les bases de données, AWS dispose de plus de 15 services managées.

Le but de cette étape est de découvrir et utiliser le service AWS fournissant des bases de données relationnelles managées, le service RDS (Relational Database Service).

Concepts

Plutôt que de créer une EC2 pour gérer notre base de donnée, utiliser le service managé AWS RDS, permet de nous décharger de l'installation et mises à jour de l'OS et du moteur DB, de la haute disponibilité/scaling ainsi que des sauvegardes.

RDS supporte un grand nombre de moteurs de bases de données :

  • Db2
  • MariaDB
  • Microsoft SQL Server
  • MySQL
  • Oracle
  • PostgreSQL

AWS a également créé son propre moteur de base de donnée compatible avec MySQL et PostgreSQL nommé Aurora.

Note

On ne peut pas SSH vers les instances. Pourquoi le ferait-on dans tous les cas?

Le service est managé!

Sizing

Comme pour les instances EC2, on choisit le type de l'instance suivant les différentes classes et la taille :

  • General-purpose
  • Memory-optimized
  • Compute-optimized
  • Burstable-performance
  • Optimized Reads

De même avec le stockage:

  • General Purpose SSD
  • Provisioned IOPS SSD
  • Magnetic

Notez que, si activé, RDS permet d'automatiquement augmenter la taille des disques.

Note

Ces choix, comme pour les instances EC2, se font en fonction des besoins, des coûts, des performances...

Patterns de performances

Pour des applications à forte charge, il est parfois possible d'atteindre des limites avec des bases relationnelles, même après avoir optimisé nos requêtes ou avoir "scale verticalement", c'est-à-dire augmenté la taille de l'instance.

Il existe des patterns permettant de palier à cela. Par exemple en utilisant ce que l'on appelle des read replicas. Ce sont des instances sur lesquelles on décharge les lectures de l'instance primaire/active, cela implique un peu de changement applicatif.

RDS permet simplement de créer ces instances de lecture et permet même un autoscaling de celles-ci pour Aurora.

Ces instances de lecture sont éventuellement consistantes via une réplication asynchrone.

Note

Il existe aussi des patterns de cache pour alléger les appels en base de donnée relationnelle. Amazon ElastiCache est le service managé AWS pour avoir des bases de données en mémoires managées type Redis ou Memcached.

Attention cela implique par contre de plus gros changements applicatifs.

HA / DR / Backups

Bien qu'il soit possible de promouvoir une instance "read replica" en une instance autonome, RDS permet d'avoir des clusters/instances tolérants aux pannes de zone via les déploiements multi-AZ.

Ces instances font automatiquement leur bascule, failover, en cas de panne.

RDS permet de faire des sauvegardes automatiques de nos instances et les conserve suivant la période de rétention que l'on configure. Il est également possible de faire des snapshots manuels qui eux n'ont pas d'expiration.

De ces snapshots peuvent ensuite être utilisés pour créer de nouvelles bases de données. Ces restores peuvent même se faire à un instant précis inclus dans la période de rétention automatique, on parle de PITR point-in-time recovery, grace aux logs transactionnels qu'upload RDS vers S3 toutes les 5 minutes.

Sécurité

On attache un Security groups à une instance RDS comme on le ferait avec une EC2.

Les données elle-mêmes peuvent être chiffrées en transit via TLS et au repo avec des clés KMS, un autre service AWS.

RDS fourni automatiquement des logs de la base de données et permet également via des paramétrages d'avoir des audits logs.

RDS propose encore d'autres listes de fonctionnalités que l'on ne développera pas plus ici, blue/green deployments, proxies, notifications...

TP

À vous de jouer

Le but de cette étape est de remplacer l'instance ec2 de base de donnée et son disque par une instance RDS single AZ managée :

  • Copiez votre dossier précédent en un nouveau dossier nommé Step2
  • Utilisez le paramètre database_subnets du module VPC, il créera pour vous le rds subnet group. Notez qu'il faut minimum 2 subnets dans 2 AZ différentes.
  • Remplacez l'instance ec2 de base de données postgres par une ressource terraform aws_db_instance pour créer une instance RDS avec les paramètres suivants
    • Single AZ : multi_az = false
    • 20GiB de stockage gp3
    • db.t4g.micro pour l'instance_class
    • Version 14

Note

Vous pouvez perdre les données actuellement en base, pas besoin de migrer la donnée. Il faudra par contre tout de même redémarrer le backend pour que le modèle de données soit inséré en base par l'application via Liquibase.

Tip

Le module terraform VPC a un paramètre permettant de déclarer automatiquement les aws_db_subnet_group via le paramètre database_subnets. Vous pouvez ensuite récupérer son name via l'ouput associé : module.vpc.database_subnet_group_name

Success

Vous n'avez plus à gérer manuellement l'instance EC2, l'OS, le patching et les sauvegardes de votre base de donnée.

Bonus

Faites un snapshot restore

  • Activez les backups automatiques via backup_retention_period = 2
  • Créez de la donnée erronée ou supprimez-en une fois que les backups sont prêts
  • Faites un restore de votre snapshot et branchez votre application sur le restore