Réplicas en lecture pour augmenter la capacité de lecture

Les Read Replicas sont des copies de votre instance RDS principale qui reçoivent les mises à jour au moyen d’une réplication asynchrone. Contrairement à l’instance de secours Multi-AZ, les Read Replicas sont accessibles pour les requêtes SELECT, ce qui vous permet de répartir le trafic de lecture et de réduire la charge sur la base de données principale.

Les Read Replicas sont prises en charge pour MySQL, PostgreSQL, MariaDB, Oracle (avec Active Data Guard) et toutes les éditions Aurora. Vous pouvez disposer de jusqu’à 15 Read Replicas pour Aurora MySQL et Aurora PostgreSQL, et de jusqu’à 5 pour RDS MySQL/PostgreSQL standard.

Pour créer une Read Replica, les sauvegardes automatisées doivent être activées sur votre instance source (la période de rétention doit être supérieure à 0). AWS prend un instantané de l’instance principale, le restaure dans une nouvelle instance DB et établit une réplication asynchrone depuis l’instance principale.

Chaque Read Replica possède son propre point de terminaison DNS. Votre application doit être mise à jour afin de diriger les lectures vers les points de terminaison des réplicas. Les gestionnaires de pools de connexions ou les frameworks d’application prenant en charge la séparation lecture/écriture peuvent acheminer automatiquement les requêtes SELECT vers les réplicas.

Comme la réplication est asynchrone, les Read Replicas peuvent avoir un retard de quelques millisecondes à quelques secondes par rapport à l’instance principale, selon le volume d’écritures. C’est ce que l’on appelle le délai de réplication. Vous pouvez le surveiller au moyen de la métrique CloudWatch ReplicaLag.

Les applications doivent être conçues pour tolérer la cohérence éventuelle lors de la lecture depuis les réplicas. Par exemple, après l’insertion d’un enregistrement, une lecture immédiate depuis un réplica peut ne pas encore renvoyer la nouvelle ligne. Pour garantir la cohérence après écriture, il faut acheminer cette lecture précise vers l’instance principale.

RDS permet de créer des Read Replicas dans une Région AWS différente, ce qui favorise la montée en charge mondiale des lectures et la reprise après sinistre. La réplication entre Régions utilise Internet public ou AWS Global Accelerator, et le délai de réplication est supérieur à celui observé au sein d’une même Région en raison de la latence du réseau.

Les réplicas entre Régions sont utiles lorsque vous souhaitez servir les utilisateurs depuis une autre zone géographique, lorsque vous avez besoin d’une copie DR de secours dans une autre Région, prête à être promue, ou lorsque vous voulez décharger la production des requêtes analytiques.

La promotion d’une Read Replica rompt le lien de réplication et la transforme en instance DB principale indépendante et accessible en écriture. Cette opération est utilisée dans les scénarios de reprise après sinistre lorsque l’instance principale d’origine est indisponible, ou lorsque vous souhaitez mettre à niveau le réplica vers une autre version du moteur et l’utiliser comme nouvelle instance principale.

La promotion est irréversible : une fois promue, l’instance ne peut plus être un réplica. Avant de la promouvoir, vérifiez que le réplica est aussi à jour que possible (délai minimal) afin de réduire les pertes de données. Après la promotion, mettez à jour la chaîne de connexion de votre application afin qu’elle pointe vers le nouveau point de terminaison principal.

Lors de l’examen SAA-C03, il est essentiel de distinguer les Read Replicas de Multi-AZ :

• Si le scénario demande une amélioration des performances de lecture ou une montée en charge des lectures → Read Replicas
• Si le scénario demande un basculement automatique ou une haute disponibilité → Multi-AZ
• Si le scénario demande les deux → Multi-AZ sur l’instance principale et Read Replicas

Retenez également que les instances de secours Multi-AZ ne traitent PAS les lectures ; les Read Replicas ne fournissent PAS de basculement automatique (vous devez les promouvoir manuellement pour les réplicas autres qu’Aurora).

Aurora gère les Read Replicas différemment de RDS standard. Aurora utilise une couche de stockage distribué partagée, de sorte que les réplicas accèdent aux mêmes pages de données sous-jacentes que l’instance principale. Les réplicas Aurora présentent donc un délai de réplication minimal (généralement inférieur à 100 ms) et peuvent chacun traiter du trafic de lecture.

Aurora fournit un point de terminaison de lecture qui répartit la charge des connexions entre toutes les instances répliques disponibles. Votre application se connecte à ce point de terminaison de lecture et Aurora distribue automatiquement les lectures. Si un réplica tombe en panne, il est retiré du pool de lecture sans affecter le point de terminaison.

Dans Aurora, si l’instance principale (d’écriture) tombe en panne, Aurora promouvoit automatiquement l’une des Read Replicas au rôle d’instance principale en environ 30 secondes, soit beaucoup plus rapidement qu’un basculement Multi-AZ RDS standard. Le réplica promu commence immédiatement à accepter les écritures via le point de terminaison d’écriture du cluster.

Aurora prend en charge des niveaux de priorité pour le basculement (0 à 15), afin que vous puissiez contrôler le réplica promu en premier. Attribuez une priorité plus élevée (niveau 0) aux réplicas associés à des classes d’instances plus grandes ou situés dans les AZ privilégiées.

Une architecture type de montée en charge des lectures achemine le trafic via un Application Load Balancer ou la logique de l’application :

• Toutes les opérations d’écriture (INSERT, UPDATE, DELETE) → point de terminaison DB principal
• Toutes les opérations de lecture (SELECT) → points de terminaison des Read Replicas ou point de terminaison de lecture Aurora
• Cache de session et cache de résultats → ElastiCache (réduit davantage les lectures sur les réplicas)

Pour les requêtes analytiques extrêmement lourdes, envisagez de promouvoir un réplica ou d’utiliser la fonctionnalité de requête parallèle d’Aurora afin de déplacer les calculs vers la couche de stockage et d’éviter tout impact sur le cluster de production.

Les principales métriques CloudWatch pour les Read Replicas sont les suivantes :

• ReplicaLag — nombre de secondes de retard par rapport à l’instance principale ; déclenchez une alerte si cette valeur augmente de manière inattendue
• ReadIOPS — vérifie que le stockage du réplica suit la charge des requêtes
• DatabaseConnections — vérifie que le nombre de connexions du réplica n’a pas atteint sa limite
• CPUUtilization — une utilisation élevée du processeur sur le réplica indique qu’une optimisation des requêtes est nécessaire

RDS Performance Insights est disponible sur les Read Replicas et affiche les instructions SQL qui consomment le plus de temps DB, ce qui vous aide à identifier et à optimiser les requêtes de lecture coûteuses.

Cas d’utilisation courants des Read Replicas RDS à l’examen SAA-C03 :

• Rapports et analyses : exécuter de lourdes requêtes SELECT sur un réplica afin de ne pas ralentir les écritures de production
• Distribution géographique : les réplicas entre Régions permettent de servir les utilisateurs d’autres continents avec une latence réduite
• Reprise après sinistre : un réplica entre Régions peut être promu si la Région principale tombe en panne
• Développement et essais : promouvoir un réplica pour créer un environnement de test contenant une copie actuelle des données de production

Les Read Replicas ne remplacent pas les sauvegardes : veillez toujours à gérer séparément les sauvegardes automatisées et les instantanés manuels.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les Read Replicas utilisent une réplication asynchrone pour distribuer le trafic de lecture, que le délai de réplication signifie que les réplicas peuvent être légèrement en retard sur l’instance principale, et que les réplicas Aurora ont un délai minimal et prennent en charge la promotion automatique. Les réplicas entre Régions offrent à la fois une montée en charge mondiale des lectures et une possibilité de DR. Nous allons maintenant étudier la sécurité RDS avec le chiffrement et les groupes de paramètres.