Concepts et terminologie RDS Proxy - Amazon Relational Database Service

Concepts et terminologie RDS Proxy

Vous pouvez simplifier la gestion des connexions pour vos instances de base de données Amazon RDS et vos clusters de base de données Amazon Aurora à l'aide de RDS Proxy.

RDS Proxy gère le trafic réseau entre l'application cliente et la base de données. Il le fait d'abord de manière active en comprenant le protocole de la base de données. Il ajuste ensuite son comportement en fonction des opérations SQL de votre application et des jeux de résultats de la base de données.

RDS Proxy réduit la charge de mémoire et d'UC pour la gestion des connexions sur votre base de données. La base de données a besoin de moins de mémoire et de ressources de l'UC lorsque les applications ouvrent de nombreuses connexions simultanées. La logique n'est pas non plus nécessaire dans vos applications pour fermer et rouvrir les connexions qui restent inactives pendant longtemps. De même, il faut logique d'application moindre pour rétablir les connexions en cas de problème de base de données.

L'infrastructure de RDS Proxy est hautement disponible et déployée sur plusieurs zones de disponibilité (AZ). Le calcul, la mémoire et le stockage pour RDS Proxy sont indépendants de vos instances de base de données RDS et de vos clusters de base de données Aurora. Cette séparation permet de réduire la surcharge sur vos serveurs de base de données, afin qu'ils puissent dédier leurs ressources à la gestion des charges de travail de base de données. Les ressources de calcul de RDS Proxy sont sans serveur et automatiquement mises à l'échelle en fonction de la charge de travail de votre base de données.

Présentation des concepts RDS Proxy

RDS Proxy gère l'infrastructure pour effectuer le regroupement de connexions et les autres fonctions décrites dans les sections qui suivent. Vous voyez les serveurs proxy qui figurent dans la console RDS sur la page Proxys.

Chaque proxy gère les connexions à une seule instance de base de données RDS ou cluster de base de données Aurora. Le proxy détermine automatiquement l'instance d'enregistreur actuelle pour les instances de base de données RDS multi-AZ et les clusters provisionnés Aurora. Pour les clusters à plusieurs maîtres Aurora, le proxy se connecte à l'une des instances d'enregistreur et utilise les autres instances d'enregistreur comme cibles de secours à chaud.

Les connexions qu'un proxy garde ouvertes et disponibles pour votre application de base de données constituent le groupe de connexions.

Par défaut, RDS Proxy peut réutiliser une connexion après chaque transaction dans votre session. « multiplexage » est le terme utilisé pour cette réutilisation au niveau de la transaction. Lorsque RDS Proxy supprime temporairement une connexion du groupe de connexions pour la réutiliser, cette opération est appelée un emprunt de connexion. lorsque l'opération peut être effectué sans risque, RDS Proxy renvoie cette connexion au groupe de connexions.

Dans certains cas, RDS Proxy ne peut pas s'assurer que la réutilisation d'une connexion à une base de données en dehors de la session en cours peut être effectuée sans risque. Dans ce cas, il maintient la session sur la même connexion jusqu'à la fin. Ce comportement de secours est appelé épinglage.

Un proxy a un point de terminaison par défaut. Vous vous connectez à ce point de terminaison lorsque vous utilisez une instance de base de données RDS ou un cluster de bases de données Aurora, plutôt qu'au point de terminaison en lecture-écriture qui se connecte directement à l'instance ou au cluster. Les points de terminaison à usage spécial d'un cluster Aurora restent disponibles pour vous. Pour les clusters de bases de données Aurora, vous pouvez également créer des points de terminaison supplémentaires en lecture/écriture et en lecture seule. Pour plus d'informations, consultez Présentation des points de terminaison proxy.

Par exemple, vous pouvez toujours vous connecter au point de terminaison du cluster pour les connexions en lecture-écriture sans regroupement de connexions. Vous pouvez toujours vous connecter au point de terminaison du lecteur pour des connexions en lecture seule à charge équilibrée. Vous pouvez toujours vous connecter aux points de terminaison de l'instance pour le diagnostic et le dépannage d'instances de base de données spécifiques au sein d'un cluster Aurora. Si vous utilisez d'autres services AWS tels que AWS Lambda pour vous connecter à des bases de données RDS, vous modifiez leurs paramètres de connexion pour utiliser le point de terminaison proxy. Par exemple, vous indiquez au point de terminaison proxy de permettre aux fonctions de Lambda d'accéder à votre base de données tout en profitant des fonctionnalités de RDS Proxy.

Chaque proxy contient un groupe cible. Ce groupe cible incarne l'instance de base de données RDS ou le cluster de base de données Aurora auquel le proxy peut se connecter. Pour un cluster Aurora, le groupe cible est associé par défaut à toutes les instances de base de données de ce cluster. Le proxy peut ainsi se connecter à l'instance de base de données Aurora promue comme instance de rédacteur dans le cluster. L'instance de base de données RDS associée à un proxy ou le cluster de base de données Aurora et ses instances sont appelés les cibles de ce proxy. Pour des raisons pratiques, lorsque vous créez un proxy via la console, RDS Proxy crée également le groupe cible correspondant et enregistre automatiquement les cibles associées.

Une famille de moteurs est un ensemble associé de moteurs de base de données qui utilisent le même protocole de base de données. Vous choisissez la famille de moteurs pour chaque proxy que vous créez.

Regroupement de connexions

Chaque proxy effectue le regroupement de connexions pour l'instance de rédacteur de sa base de données Aurora ou RDS associée. Le regroupement de connexions est une optimisation qui réduit la surcharge associée à l'ouverture et à la fermeture des connexions, tout en maintenant plusieurs connexions ouvertes simultanément. Cette surcharge inclut la mémoire nécessaire pour gérer chaque nouvelle connexion. Cette opération implique également une surcharge de l'UC pour fermer chaque connexion et en ouvrir une nouvelle : liaison Transport Layer Security/Secure Sockets Layer (TLS/SSL), authentification, négociation, etc. Le regroupement de connexions simplifie la logique de votre application. Vous n'avez pas besoin d'écrire de code d'application pour minimiser le nombre de connexions ouvertes simultanées.

Chaque proxy effectue également le multiplexage de connexion, également connu sous le nom de réutilisation de connexion. Grâce au multiplexage, RDS Proxy exécute toutes les opérations d'une transaction à l'aide d'une connexion de base de données sous-jacente, avant d'utiliser une connexion différente pour la transaction suivante. Si vous ouvrez de nombreuses connexions simultanées au proxy, celui-ci conserve un plus petit nombre de connexions ouvertes à l'instance ou au cluster de base de données. Cela permet de réduire davantage la surcharge de mémoire pour les connexions sur le serveur de base de données. Cette technique réduit également le risque que des erreurs liées au « nombre de connexions trop élevé » se produisent.

Sécurité RDS Proxy

RDS Proxy utilise les mécanismes de sécurité RDS existants tels que TLS/SSL et AWS Identity and Access Management (IAM). Pour obtenir des informations générales sur ces fonctionnalités de sécurité, reportez-vous à la section Sécurité dans Amazon RDS. Si vous n'êtes pas familier avec la façon dont RDS et Aurora utilisent l'authentification, l'autorisation et d'autres domaines de sécurité, commencez par découvrir la façon dont RDS et Aurora utilisent ces domaines.

RDS Proxy peut agir comme une couche de sécurité supplémentaire entre les applications clientes et la base de données sous-jacente. Vous pouvez par exemple vous connecter au proxy à l'aide de la version 1.2 de TLS, même si l'instance de base de données sous-jacente prend uniquement en charge les versions 1.0 ou 1.1 de TLS. Vous pouvez vous connecter au proxy à l'aide d'un rôle IAM, même si le proxy se connecte à la base de données à l'aide de la méthode native d'authentification par nom d'utilisateur et mot de passe. Grâce à cette technique, vous pouvez appliquer de fortes exigences d'authentification pour les applications de base de données sans avoir à fournir un effort de migration coûteux pour les instances de base de données elles-mêmes.

Vous stockez les informations d'identification de base de données utilisées par RDS Proxy dans AWS Secrets Manager. Chaque utilisateur de base de données pour l'instance de base de données RDS ou le cluster de base de données Aurora auquel un proxy accède doit avoir un secret correspondant dans Secrets Manager. Vous pouvez également configurer l'authentification IAM pour les utilisateurs de RDS Proxy. Vous pouvez ainsi appliquer l'authentification IAM pour l'accès à la base de données, même si les bases de données utilisent l'authentification native par mot de passe. Nous vous recommandons d'utiliser ces fonctions de sécurité au lieu d'intégrer les informations d'identification de base de données dans votre code d'application.

Utilisation de TLS/SSL avec RDS Proxy

Vous pouvez vous connecter à RDS Proxy à l'aide du protocole TLS/SSL.

Note

RDS Proxy utilise des certificats de l'AWS Certificate Manager (ACM). Si vous utilisez RDS Proxy, lorsque vous effectuez la rotation de votre certificat TLS/SSL, vous n'avez pas besoin de mettre à jour les applications qui utilisent des connexions RDS Proxy.

Afin d'appliquer TLS pour toutes les connexions entre le proxy et votre base de données, vous pouvez spécifier un paramètre Exiger la sécurité de la couche de transport lorsque vous créez ou modifiez un proxy.

RDS Proxy permet également de garantir que votre session utilise TLS/SSL entre votre client et le point de terminaison RDS Proxy. Pour que RDS Proxy procède ainsi, spécifiez l'exigence côté client. Les variables de session SSL ne sont pas définies pour les connexions SSL à une base de données utilisant RDS Proxy.

  • Pour RDS for MySQL et Aurora MySQL, spécifiez l'exigence côté client avec le paramètre --ssl-mode lorsque vous exécutez la commande mysql.

  • Pour Amazon RDS PostgreSQL et Aurora PostgreSQL, spécifiez sslmode=require comme partie de la chaîne conninfo lorsque vous exécutez la commande psql.

RDS Proxy prend en charge le protocole TLS versions 1.0, 1.1 et 1.2. Vous pouvez vous connecter au proxy à l'aide d'une version de TLS supérieure à celle utilisée dans la base de données sous-jacente.

Par défaut, les programmes client établissent une connexion chiffrée avec RDS Proxy. L'option --ssl-mode fournit davantage de contrôle. Du côté client, RDS Proxy prend en charge tous les modes SSL.

Pour le client, les modes SSL sont les suivants :

PREFERRED

SSL est le premier choix, mais n'est pas obligatoire.

DISABLED

Aucun mode SSL n'est autorisé.

REQUIRED

SSL est obligatoire.

VERIFY_CA

SSL est obligatoire et une vérification de l'autorité de certification (CA) est effectuée.

VERIFY_IDENTITY

SSL est obligatoire et une vérification de l'autorité de certification (CA) et de son nom d'hôte est effectuée.

Note

Vous pouvez utiliser le mode SSL VERIFY_IDENTITY lors de la connexion au point de terminaison proxy par défaut. Vous ne pouvez pas utiliser ce mode SSL lorsque vous vous connectez aux points de terminaison proxy que vous créez.

Lorsque vous utilisez un client avec --ssl-mode VERIFY_CA ou VERIFY_IDENTITY, spécifiez l'option --ssl-ca pointant vers une autorité de certification au format .pem. Pour le fichier .pem à utiliser, téléchargez tous les PEM de la CA racine depuis Amazon Trust Services et placez-les dans un seul fichier .pem.

RDS Proxy utilise des certificats à caractères génériques, qui s'appliquent à un domaine et à ses sous-domaines. Si vous utilisez le client mysql pour vous connecter avec le mode SSL VERIFY_IDENTITY, vous devez actuellement exécuter la commande mysql compatible avec MySQL 8.0.

Basculement

Le basculement est une fonction de haute disponibilité qui remplace une instance de base de données par une autre lorsque l'instance d'origine est indisponible. Un problème lié à une instance de base de données peut entraîner un basculement. Celui-ci peut également faire partie de procédures de maintenance normales, lors d'une mise à niveau de la base de données par exemple. Cette opération s'applique aux instances de base de données RDS dans une configuration multi-AZ et aux clusters de base de données Aurora dotés d'une ou plusieurs instances de lecteur en plus de l'instance de rédacteur.

La connexion via un proxy rend votre application plus résistante aux basculements de base de données. Lorsque l'instance de base de données d'origine est indisponible, RDS Proxy se connecte à la base de données de secours sans supprimer les connexions d'application inactives. Cela permet d'accélérer et de simplifier le processus de basculement. Par conséquent, le basculement est plus rapide et interrompt moins longtemps votre application par rapport à un problème de redémarrage ou de base de données classique.

Sans RDS Proxy, un basculement provoque une brève interruption de service. Pendant la panne, vous ne pouvez pas effectuer d'opérations d'écriture sur cette base de données. Toutes les connexions de base de données existantes sont interrompues et votre application doit les rouvrir. La base de données est ouverte à de nouvelles connexions et opérations d'écriture lorsqu'une instance de base de données en lecture seule est promue pour remplacer celle qui n'est pas disponible.

Pendant les basculements de base de données, RDS Proxy continue d'accepter les connexions à la même adresse IP et redirige automatiquement les connexions vers la nouvelle instance de base de données principale. Les clients qui se connectent via RDS Proxy ne sont pas sujets aux éléments suivants :

  • Délais de propagation du système de noms de domaine (DNS) lors du basculement.

  • Mise en cache DNS locale.

  • Délai d'expiration de connexion.

  • Incertitude concernant l'instance de base de données qui est le rédacteur en cours.

  • Attente d'une réponse à la requête d'un ancien rédacteur devenu indisponible sans fermer les connexions.

Pour les applications qui conservent leur propre regroupement de connexions, passer par RDS Proxy implique que la plupart des connexions restent actives pendant des basculements ou d'autres interruptions. Seules les connexions qui se trouvent au milieu d'une transaction ou d'une instruction SQL sont annulées. RDS Proxy accepte immédiatement les nouvelles connexions. Lorsque le rédacteur de base de données n'est pas disponible, RDS Proxy place les demandes entrantes dans la file d'attente.

Pour les applications qui ne conservent pas leurs propres regroupements de connexions, RDS Proxy offre des taux de connexion plus rapides et davantage de connexions ouvertes. Il permet de réduire la surcharge coûteuse des reconnexions fréquentes à la base de données. Il effectue cette opération en réutilisant les connexions de base de données maintenues dans le regroupement de connexions de RDS Proxy. Cette approche est particulièrement importante pour les connexions TLS, où les coûts d'installation sont importants.

Transactions

Toutes les instructions d'une seule transaction utilisent toujours la même connexion à la base de données sous-jacente. La connexion devient disponible pour une session différente lorsque la transaction se termine. Voici les conséquences de l'utilisation de la transaction en tant qu'unité de granularité :

  • La réutilisation de la connexion peut se produire après chaque instruction individuelle lorsque le paramètre RDS for MySQL ou Aurora MySQL autocommit est activé.

  • Inversement, lorsque le paramètre autocommit est désactivé, la première instruction que vous émettez dans une session lance une nouvelle transaction. Par conséquent, si vous saisissez une séquence SELECT, INSERT, UPDATE ainsi que d'autres instructions en langage de manipulation de données (DML), la réutilisation de la connexion ne se produit que lorsque vous émettez COMMIT, ROLLBACK ou que vous mettez fin à la transaction.

  • La saisie d'une instruction en langage de définition de données (DDL) entraîne la fin de la transaction une fois l'instruction terminée.

RDS Proxy détecte lorsqu'une transaction se termine par le protocole réseau utilisé par l'application cliente de base de données. La détection des transactions ne repose pas sur des mots-clés tels que COMMIT ou ROLLBACK apparaissant dans le texte de l'instruction SQL.

Dans certains cas, RDS Proxy peut détecter une demande de base de données qui rend impossible le déplacement de votre session vers une autre connexion. Dans ce cas, il désactive le multiplexage pour cette connexion pendant le reste de votre session. La même règle s'applique si RDS Proxy ne peut pas s'assurer de la praticité du multiplexage pour la session. Cette opération est appelée épinglage. Pour savoir comment détecter et réduire l'épinglage, consultez Contournement de l'épinglage.