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 stockagegp3
db.t4g.micro
pour l'instance_class- Version
14
- Single AZ :
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