Planification de l’emplacement où utiliser le proxy RDS

Il est judicieux d’associer à un proxy tout cluster de bases de données qui rencontre des erreurs liées à un « nombre de connexions trop élevé ». Cela se caractérise souvent par une valeur élevée de la ConnectionAttempts CloudWatch métrique. Le proxy permet aux applications d’ouvrir de nombreuses connexions client, tandis que le proxy gère un plus petit nombre de connexions à long terme au cluster de bases de données.

Pour les clusters d' de base de données qui utilisent des classes d' AWS instance plus petites, telles que T2 ou T3, l'utilisation d'un proxy peut permettre d'éviter certaines out-of-memory conditions. Il peut également contribuer à réduire la surcharge de l’UC lors de l’établissement des connexions. Ces conditions peuvent se produire lorsque vous faites face à un grand nombre de connexions.

Vous pouvez surveiller certaines CloudWatch métriques Amazon pour déterminer si un cluster d' de base de données approche certains types de limites. Ces limites concernent le nombre de connexions et la mémoire associées à la gestion des connexions. Vous pouvez également surveiller certaines CloudWatch mesures pour déterminer si un cluster d' de base de données gère de nombreuses connexions de courte durée. L’ouverture et la fermeture de telles connexions peuvent entraîner une surcharge de performances sur votre base de données. Pour en savoir plus sur les métriques à surveiller, consultez Surveillance des métriques RDS Proxy avec Amazon CloudWatch.

AWS Lambda les fonctions peuvent également être de bons candidats pour l'utilisation d'un proxy. Ces fonctions réalisent fréquemment des connexions de base de données courtes qui bénéficient du regroupement de connexions offert par le proxy RDS. Vous pouvez profiter de toute authentification IAM dont vous disposez déjà pour les fonctions Lambda, plutôt que de gérer les informations d’identification de base de données dans votre code d’application Lambda.

Les applications qui ouvrent et ferment généralement un grand nombre de connexions à des bases de données et qui ne disposent pas de mécanismes intégrés de regroupement des connexions sont de bons candidats pour l’utilisation d’un proxy.

Il est souvent judicieux d’utiliser les applications qui maintiennent un grand nombre de connexions ouvertes pendant de longues périodes avec un proxy. Les applications dans des secteurs tels que le logiciel en tant que service (SaaS) ou le e-commerce réduisent souvent la latence pour les demandes de base de données en laissant les connexions ouvertes. Avec le proxy RDS, une application peut garder davantage de connexions ouvertes que lorsqu’elle se connecte directement au cluster de bases de données.

Vous n'avez peut-être pas adopté l'authentification IAM et Secrets Manager en raison de la complexité de la configuration de cette authentification pour tous les clusters d' de base de données. Le proxy peut appliquer les politiques d’authentification relatives aux connexions client pour des applications spécifiques. Vous pouvez profiter de toute authentification IAM dont vous disposez déjà pour les fonctions Lambda, plutôt que de gérer les informations d’identification de base de données dans votre code d’application Lambda.

Le proxy RDS peut aider à rendre les applications plus résilientes et plus transparentes face aux pannes de bases de données. Le proxy RDS contourne les caches du système de nom de domaine (DNS) afin de réduire les temps de basculement jusqu’à 66 % pour les bases de données Aurora Multi-AZ. Le proxy RDS achemine automatiquement le trafic vers une nouvelle instance de base de données tout en préservant les connexions aux applications. Cela rend les basculements plus transparents pour les applications.