Le Blog Amazon Web Services

Passer à l’échelle votre instance Amazon RDS verticalement et horizontalement

Amazon RDS est un service managé par AWS qui se charge, entre autres, de gérer pour vous le passage à l’échelle de votre base de données relationnelle au fur et à mesure qu’augmente le trafic de vos applications.

Dans cet article, vous allez apprendre comment passer à l’échelle verticalement et horizontalement vos instances Amazon RDS. Vous pouvez assurer une montée en charge verticale pour votre application quand le nombre croissant de requêtes est globalement équi-réparti entre lecture et écriture. Ou bien vous pouvez passer à l’échelle horizontalement pour vos applications qui ont une prédominance de requêtes en lecture.

Passage à l’échelle vertical

Pour répondre à un niveau plus élevé de sollicitations pour votre base données, vous pouvez augmenter verticalement le nœud principal de votre base de donnée d’un simple clic. Il y a actuellement pas moins de 18 tailles d’instance que vous pouvez choisir pour redimensionner votre base de données RDS que celle-ci utilise un moteur MySQL, PostgreSQL, MariaDB, Oracle ou Microsoft SQL Server.

  • Avant de procéder à l’augmentation, pour les moteurs commerciaux (SQL Server, Oracle), veuillez vérifier que vous disposez bien des licences nécessaires, tout particulièrement si vous apportez vos propres licences de base (BYOL). Une chose importante à garder en tête pour les moteurs de base de données commerciaux, c’est que le contrat de licence limite le nombre de processeurs ou cœurs utilisables,
  • Lors d’un passage à l’échelle de votre base de données, si elle est déployée sur plusieurs zones de disponibilité, Il n’y aura qu’un impact minime sur le service grâce au fait que l’instance secondaire va d’abord être mise à jour avant la bascule de la base sur l’instance mise à jour. En revanche, une instance de base de donnée déployée sur une seule zone de disponibilité sera indisponible durant toute la durée de l’opération de mise à l’échelle,
  • Ainsi, choisissez le moment opportun pour appliquer vos changements selon que vous avez un déploiement sur plusieurs AZ ou une seule AZ. Dans le premier cas, vous pouvez d’appliquer ces changements immédiatement sans impact, dans le second cas, choisissez plutôt une fenêtre de maintenance qui vous aurez définie pour votre instance,
  • Le stockage et le type d’instance sont indépendants. Quand vous augmentez ou diminuez votre instance, la taille du stockage alloué reste la même et n’est en rien affectée par le changement de type d’instance. Vous pouvez modifier votre instance de base de données pour augmenter l’espace de stockage alloué ou augmenter la performance en changeant le type de stockage (par exemple passer de Stockage Générique SSD à Stockage SSD avec niveau de lecture/écriture réservé).

Pour changer le type d’instance, depuis la console Amazon RDS, sélectionnez l’instance de base de donnée à modifier puis cliquer sur le bouton “Modifier”. Ensuite, dans la rubrique “Taille d’instance DB” choisissez l’un des trois types de classe d’instances : standard, mémoire optimisée ou à capacité extensible. Enfin dans la liste correspondante, choisissez la taille d’instance souhaitée.

  • Classe standard (inclut les classes m)
  • Classe à mémoire optimisée (inclut les classes r et x)
  • Classe à capacité extensible (inclut les classes t)

Enfin, choisissez si vous souhaitez appliquer le changement immédiatement ou non. Pour appliquer le changement immédiatement, cocher l’option “Appliquer Immédiatement” tout en bas de la page de modification. Si vous choisissez de ne pas appliquer le changement immédiatement, il sera planifié pour intervenir durant la fenêtre de maintenance que vous avez définie.

Passage à l’échelle horizontal

En complément du passage à l’échelle vertical, vous pouvez augmenter les performances en lecture de votre base de donnée en utilisant des réplicas en lecture pour passer à l’échelle horizontalement. Les moteurs Amazon RDS MySQL, Amazon RDS PostgreSQL et Amazon RDS MariaDB peuvent avoir jusqu’a 5 réplicas en lecture et Amazon Aurora peut comporter jusqu’à 15 réplicas en lecture.

Les réplicas en lecture sont synchronisés avec la base de données primaire. Vous pouvez également placer vos réplicas en lecture dans une autre région AWS plus proche de vos utilisateurs pour obtenir de meilleures performances. De plus, vous pouvez utiliser des réplicas en lecture pour accroître le niveau de disponibilité de votre base de donnée par promotion du réplica en lecture en nœud primaire pour accélérer la récupération en cas de sinistre sur un site. Néanmoins les réplicas en lecture ne remplacent pas, pour la haute disponibilité, le déploiement muti zones des disponibilités qui offre une bascule automatique.

Aujourd’hui, les réplicas en lecture d’Amazon RDS supportent l’équilibrage de charge transparent des requêtes ou des connexions. Chaque réplica possède un point de terminaison unique et un nom DNS de sorte qu’une application peut facilement implémenter de l’équilibrage de charge en se connectant au point de terminaison du réplica. Voyons quels sont les options à votre disposition pour permettre aux applications d’utiliser les réplicas en lecture.

Si votre application sait utiliser des pilotes natifs MySQL, il existe des connecteurs MySQL qui vous permettent de séparer les requêtes en lecture seule, des autres requêtes, pour exploiter des points de terminaison des réplicas sans nécessiter de changements important du code de votre application. Par exemple, si vous avez une application en PHP, vous pouvez utiliser le pilote natif MySQL PHP Mysqlnd de réplication et l’extension d’équilibrage de charge.

En complément de l’usage du connecteur MySQL, vous pouvez ajouter un équilibreur de charge entre votre application et les serveurs de base de données. Ce cette manière, vous disposez d’un seul point de terminaison à publier à votre application. Cette approche permet une gestion plus dynamique de l’environnement de base de donnée, en permettant de manière transparente d’ajouter ou de supprimer des réplicas en lecture positionnés derrière l’équilibreur de charge sans devoir constamment mettre à jour la chaîne de caractères définissant la connexion à la base de donnée. Vous pouvez également mettre en place un script personnalisé qui vérifier l’état des connections.

Comme le montre le schéma, vous pouvez utiliser conjointement un équilibreur de charge de niveau 4 transport avec le connecteur MySQL.

Aujourd’hui, l’équilibreur de charge élastique (ELB) ne supporte pas le routage du trafic vers des instances RDS. Cependant dans le cas d’utilisation de AMAZON RDS avec le moteur AMAZON Aurora, l’équilibrage de charge sur les endpoints en lecture est nativement supporté. Pour les autres moteurs, vous pouvez envisager d’autres options comme l’utilisation de HAProxy qui est un logiciel Open-source d’équilibrage de charge très utilisé. Avec cette solution, vous pouvez configurer HAProxy de sorte d’écouter sur un port les requêtes en lecture et sur un autre port les requêtes en écriture.

Vous pouvez aussi utiliser un équilibreur de charge de niveau 7 compatible avec SQL, ce qui permet de transmettre les requêtes selon des règles de routage plus complexe. Ce type d’équilibreur de charge possède des capacités sophistiquées supérieures au connecteur MySQL comme savoir répartir aux mieux les requêtes en lecture/écriture à plusieurs expressions. Cette solution gère le passage à l’échelle de base de données distribuée sans que vous ayez à gérer vous même cette montée en charge au niveau applicatif, de sorte qu’il n’y ait très peu voire même aucune modification à apporter à votre l’application. Pour accomplir cela, il existe plusieurs solutions Open-source (par exemple MaxScale, ProxySQL et MySQL Proxy) et aussi des solutions commerciales dont la plupart se trouvent dans la Marketplace AWS.

Conclusion

En résumé, vous pouvez adapter la configuration de votre base de données Amazon RDS pour passer à l’échelle verticalement ou horizontalement et ainsi répondre à la croissance des requêtes que doit traiter vos applications. Amazon RDS prend à sa charge toute la gestion complexe de l’augmentation des ressources nécessaires à votre base de données, de sorte que vous puissiez vous concentrer sur vos applications métiers.

Article original de Marie Yap et adapté en français par Olivier Rossant, Solutions Architecture dans l’équipe AWS France.