Considérations relatives aux applications et à la charge

Multi-tenant et environnements multi-utilisateurs

En termes d'évolutivité et d'amélioration de la gestion des connexions, les avantages de l'utilisation du proxy RDS dépendent de sa capacité à effectuer un regroupement de connexions et, dans une bien plus large mesure, un multiplexage de connexions. Le regroupement des connexions réduit les frais associés à l'ouverture et à la fermeture des connexions. Le multiplexage des connexions permet au proxy de réutiliser une connexion à une base de données principale après une transaction. Pour de plus amples informations, veuillez consulter Concepts et terminologie RDS Proxy.

Lorsqu'une connexion ne peut pas être multiplexée, le proxy adopte un comportement appelé épinglage de connexion. Le pinning est une situation dans laquelle un client est obligé d'utiliser la même connexion proxy sous-jacente pendant toute sa session. La connexion proxy est réservée à ce client et ne peut donc pas être réutilisée par d'autres clients. En d'autres termes, le pinning crée une association 1:1 exclusive entre une connexion client-proxy et une connexion proxy-base de données. Il est important d'éviter l'épinglage dans tous les scénarios où le proxy RDS est principalement utilisé pour des raisons d'évolutivité et d'efficacité. Pour connaître le comportement d’épinglage le plus récent, consultez Contournement de l’épinglage d’un proxy RDS.

En règle générale, les connexions peuvent être multiplexées lorsqu'elles ont un état identique. Les connexions ne peuvent pas être multiplexées lorsqu'elles contiennent des informations d'état personnalisées spécifiques à la session. L'un des aspects qui définissent l'état de session est le nom d'utilisateur de base de données associé à une connexion. Lorsque vous vous connectez au proxy en tant qu' « utilisateur_A », le proxy doit également ouvrir une connexion à la base de données principale en tant qu' « utilisateur_A ». Le proxy peut potentiellement regrouper et réutiliser cette connexion principale pour d'autres clients qui se connectent en tant qu' « utilisateur_A », mais pas pour les clients utilisant un nom d'utilisateur différent.

Ce comportement peut réduire considérablement l'efficacité du regroupement et du multiplexage dans les environnements multi-utilisateurs comportant un grand nombre de comptes de base de données uniques. Cela est particulièrement vrai dans les architectures utilisant la mutualisation au niveau de la base de données ou au niveau du schéma. Si la base de données contient un millier de schémas (un par locataire) et que chaque locataire se connecte à la base de données avec un nom d'utilisateur différent, le pool de connexions est fragmenté en micropools spécifiques à l'utilisateur, ce qui réduit l'efficacité globale.

En outre, certains aspects spécifiques au moteur de base de données peuvent affecter davantage l'efficacité du regroupement et la capacité du proxy à multiplexer les connexions :

1. Dans Amazon RDS et Aurora PostgreSQL, la mutualisation est souvent mise en œuvre en utilisant une base de données par locataire. Cependant, dans PostgreSQL, les connexions sont spécifiques à une base de données : une connexion ouverte avec une base de données ne peut pas accéder aux données d'autres bases de données. Par conséquent, la mutualisation au niveau de la base de données réduit l'efficacité du regroupement et du multiplexage au niveau du proxy. Cette considération s'applique également si la charge de travail utilise la mutualisation au niveau du schéma et si les sessions client utilisent une option personnalisée. search_path Toutefois, si toutes les sessions utilisent le chemin de recherche par défaut et font référence à des tables à l'aide de noms complets (schema_name.table_name), ces sessions peuvent être multiplexées.

2. Dans Amazon RDS et Aurora MySQL, les termes « base de données » et « schéma » sont des synonymes. Multi-tenancy est souvent implémenté en utilisant un schéma par locataire, ce qui dans MySQL équivaut à une base de données par locataire. Les connexions sont ouvertes sur un serveur MySQL dans son ensemble et ne sont pas liées à un schéma. Si l'application utilise la mutualisation au niveau du schéma, le multiplexage des connexions est toujours possible pour les clients utilisant le même nom d'utilisateur de base de données, même si ces connexions doivent accéder aux données dans des schémas différents. Le multiplexage sera plus efficace si la séparation des locataires est effectuée au niveau de l'application au lieu d'utiliser des comptes de base de données différents pour chaque locataire.

Dans les environnements à plusieurs schémas, l'efficacité du multiplexage dépend de la façon dont vous faites référence aux noms de table :

• Pour les clients qui choisissent le schéma actuel à l'aide de variables de session (SET search_path ...dans PostgreSQL et USE schema; dans MySQL) puis utilisent des noms de table non qualifiés dans les requêtes (par exempleSELECT ... FROM table_name), le multiplexage des connexions ne fonctionne qu'entre les clients utilisant le même schéma ou le même chemin de recherche.

• Pour les clients qui ne modifient pas l'état de session pour définir le schéma actuel, mais qui utilisent plutôt des noms de table complets dans les instructions SQL (par exempleSELECT ... FROM schema_name.table_name), le multiplexage n'est pas soumis à des contraintes similaires.

Bases de données desservant plusieurs applications ou piles de logiciels

Comme indiqué dans la section précédente, certaines caractéristiques de l'état de connexion ne provoquent pas d'épinglage, mais réduisent tout de même la capacité du proxy à réutiliser les connexions entre différents clients. Lorsqu'il est utilisé avec des cibles MySQL, le proxy RDS suit un certain nombre d'instructions et de variables de session qui configurent l'état de la session, telles que le jeu de caractères, le fuseau horaire et les paramètres de classement. Lorsqu'un client utilise des instructions ou des variables suivies pour configurer les paramètres de session, la connexion proxy ne peut être réutilisée que pour les autres clients ayant les mêmes valeurs pour ces paramètres.

Par conséquent, certains comportements des applications et des pilotes peuvent réduire votre capacité à réutiliser les connexions au sein du proxy. Par exemple, vous pouvez autoriser différentes applications à se connecter à la base de données en utilisant le même nom d'utilisateur, en supposant que le proxy puisse réutiliser et multiplexer les connexions entre ces applications. Toutefois, si une application démarre les connexions avec le fuseau horaire A (SET time_zone = ?) et qu'une autre utilise le fuseau horaire B, les connexions sont réutilisables au sein d'une application, mais pas entre applications. Cela entraîne une fragmentation du pool de connexions, ce qui nuit à l'efficacité du regroupement et du multiplexage.

Pour de plus amples informations, veuillez consulter Ce que le proxy RDS suit pour les bases de données RDS for MariaDB et RDS for MySQL. Le suivi de l'état de session n'est actuellement pas pris en charge pour les cibles de base de données autres que MySQL.

Consultez Directives de configuration les directives de configuration et les meilleures pratiques relatives à la gestion de l'état des sessions afin d'éviter le blocage des connexions.

Utilisation du regroupement au niveau de l'application et de pilotes avancés avec RDS Proxy

Le proxy RDS permet d'améliorer l'évolutivité et l'efficacité des connexions dans les situations où l'application elle-même n'utilise pas le regroupement de connexions. Dans le même temps, de nombreux moteurs et frameworks incluent des fonctionnalités de mise en commun. Vous utilisez peut-être également des wrappers ou des pilotes avancés qui implémentent certaines fonctionnalités du proxy au niveau du pilote.

L'utilisation du regroupement au niveau de l'application et d'autres améliorations de la gestion des connexions n'est pas intrinsèquement incompatible avec l'utilisation du proxy RDS et n'annule pas ses avantages. Par exemple, vous utilisez peut-être le regroupement de connexions dans les conteneurs de votre application, mais le nombre de conteneurs est suffisamment important pour que les limites de connexion à la base de données ne soient toujours pas atteintes sans utiliser de proxy. Lorsque vous utilisez le proxy RDS avec des pools au niveau de l'application et d'autres fonctionnalités liées à la connexion, examinez et comprenez les raisons pour lesquelles des fonctionnalités avancées de gestion des connexions existent au niveau de l'application. Décidez lesquelles de ces fonctionnalités méritent d'être conservées (ou sont inoffensives) et lesquelles peuvent se chevaucher ou interférer avec le comportement du proxy. Par exemple :

1. La mise en commun des fonctionnalités intégrées aux pilotes et aux frameworks peut être utile même si elles semblent se chevaucher avec la fonctionnalité du proxy RDS. Si un pool au niveau de l'application améliore l'efficacité de la connexion locale en plus des avantages fournis par le proxy, vous pouvez le conserver.

2. Les fonctionnalités liées à la gestion du basculement peuvent interférer avec la logique du proxy RDS ou augmenter la complexité globale de la pile sans apporter d'avantages. Par exemple, si votre application suit activement la topologie de vos clusters Aurora pour éviter les retards de DNS-related basculement, elle n'a plus besoin de le faire avec RDS Proxy. Le maintien de cette logique de suivi topologique peut entraîner des comportements indésirables, tels que le contournement du proxy par les threads d'application et la connexion directe à des instances de base de données individuelles. Dans ce scénario, vous pouvez désactiver la logique de suivi au niveau de l'application et laisser RDS Proxy abstraire la topologie du cluster pour vous.

3. Les bibliothèques de regroupement de connexions peuvent utiliser des fonctionnalités de gestion d'état qui semblent bénéfiques en théorie, mais qui interfèrent avec le comportement du proxy. Les bibliothèques PostgreSQL appellent la requête pour réinitialiser l'état de connexion entre DISCARD ALL les emprunts, par exemple. Il peut sembler que la réinitialisation des connexions devrait faciliter le regroupement et le multiplexage, mais elle interfère avec la gestion interne de l'état des sessions d'Amazon RDS Proxy. Lors de l'utilisationDISCARD, le proxy épingle votre connexion client lors de la libération, ce qui réduit l'efficacité du multiplexage.

Pour tous les composants de gestion des connexions au niveau de l'application que vous conservez, assurez-vous que leur configuration n'interfère pas avec la logique de gestion des connexions utilisée par Amazon RDS Proxy. Par exemple :

• Alignez le dimensionnement du pool sur toutes les couches de la pile. Si les pools au niveau de l'application sont surdimensionnés (ou si votre pool de proxy est sous-dimensionné), l'application peut essayer d'ouvrir des connexions que le proxy n'est pas configuré pour gérer. Ces connexions peuvent au mieux connaître des retards et des erreurs de rejet au pire.

• Alignez les paramètres de délai d'expiration pour réduire le taux de désabonnement et éviter toute confusion quant au comportement de connexion. Si le pool d'applications maintient les connexions actives pendant 300 secondes, mais que le proxy est configuré pour fermer les connexions au bout de 60 secondes, l'application verra des fermetures de connexion prématurées au lieu du comportement attendu.

Certaines de ces décisions architecturales et de ces choix de configuration peuvent nécessiter des tests et des expérimentations. Il n'est pas toujours possible de prévoir exactement le comportement des applications dans un environnement comportant plusieurs niveaux de gestion des connexions et de mise en pool.

Reportez-vous à Directives de configuration pour les directives de configuration courantes.