Proxy RDS en production: leçons réelles, limitations et pourquoi nous l’utilisons

Introduction: le vrai problème

Avez-vous déjà exécuté RDS Postgresql en production? Vous avez probablement fait face à des goulots d’étranglement de la limite de connexion, des accidents de l’application pendant les classiques ou des délais d’attente inattendus, souvent aux pires moments possibles. Ce sont des problèmes de production réels où RDS proxy prouve sa valeur en offrant une mise en commun des connexions, une amélioration de la gestion de basculement et une gestion des diplômes sécurisée pour garder vos services résilients et réactifs.

À première vue, RDS Proxy semble être une évidence pour la gestion des connexions. Mais si vous êtes dans un rôle d’ingénierie DevOps ou Platform, vous savez que l’histoire ne s’arrête pas à l’approvisionnement. Ce blog plonge dans les leçons du monde réel en travaillant avec RDS proxy.

Qu’est-ce que RDS proxy?

RDS Proxy est le service géré d’AWS qui gère la mise en commun de la connexion de la base de données, les basculements et l’accès sécurisé et sans renseignements à RDS. Il agit comme un intermédiaire entre votre application et RDS, l’optimisation de l’utilisation des connexions, l’amélioration de la résilience des bascules et l’application des meilleures pratiques de sécurité.

Couler:

Le flux de l’application vers DB via le proxy RDS

Décomposons cela:

1. Poolage de connexion (ce qu’il résout et pourquoi c’est important)
Imaginez votre application comme une foule à haute énergie essayant de se lancer dans un concert et la base de données comme le lieu avec des portes limitées (connexions). Sans contrôle des foules, le chaos s’ensuit. C’est là que le proxy RDS intervient, en tant que videur bien formé qui maintient la ligne en mouvement, évite les tampons et empêche le lieu de s’arrêter.

RDS Proxy maintient un pool de connexions de base de données chaudes et réutilisables que votre application peut emprunter et revenir sur la demande.

• • • Minimise le temps et le coût du processeur pour ouvrir et fermer constamment les connexions.
    • Protége votre instance RDS contre les pointes de la circulation.
    • Empêche les échecs de la «tempête de connexion» pendant les déploiements ou les départs à froid.

Le proxy RDS évolue automatiquement en fonction du nombre de connexions d’application. AWS n’expose pas les boutons directs pour dimensionner le proxy, le proxy ajuste élastiquement son pool de connexion en fonction de la demande. Chaque proxy RDS peut s’ouvrir à environ 1000 connexions (limite souple) par instance RDS cible par défaut.

2. Manipulation de basculement (pourquoi c’est une bouée de sauvetage)
Pendant les basculements RDS planifiés ou imprévus (comme un redémarrage de DB ou un basculement AZ), les applications traditionnelles connectées directement à la base de données subiront des connexions, des délais d’expiration et des accidents potentiels. Avec RDS proxy, votre application se connecte à un point de terminaison proxy stable, pas directement à l’instance DB. Si un basculement se produit:

• • RDS Proxy détecte l’événement de basculement.
  • Il rétablit une connexion avec la nouvelle instance DB dans les coulisses.
  • L’application reste connectée au proxy de manière transparente dans la plupart des cas.

Y a-t-il la latence? Oui, mais minimal. La plupart des reconnexions se terminent dans les 20 à 30 secondes. Au cours de cette fenêtre, les applications peuvent connaître des stands courts, mais beaucoup moins de perturbation que les baisses de connexion complètes.

3. Gestion des diplômes sécurisée
RDS Proxy s’intègre de manière transparente à Secrets Manager ou IAM Authentication, permettant une connectivité de base de données sécurisée sans avoir besoin d’identification HardCode dans la configuration de l’application.

4. TLS Application
Il peut être configuré pour nécessiter un cryptage TLS, assurant une communication cryptée de l’application à la base de données.

5. Pas besoin d’auto-héberger Pgbouner
RDS Proxy offre tous ces avantages sans vous obliger à déployer, configurer et maintenir des outils tiers comme PGBouner.

Qu’est-ce qu’un pgbouncer? Un Pooler de connexion léger, souvent utilisé avec PostgreSQL pour gérer efficacement les connexions de la base de données. Il nous oblige à exécuter et à gérer le service, à gérer la mise à l’échelle, à gérer les scripts de basculement et à configurer la sécurité. D’un autre côté, le proxy RDS, étant un service géré, élimine toute cette au-dessus. Vous obtenez des avantages similaires sans le mal de tête de l’exécution de Pgbouncer vous-même.

Pourquoi cela peut-il changer la donne?

• Environnements élastiques, ECS ou Lambda, profitez le plus; Ils engendrent des connexions imprévisibles.
• Isolation de basculement: Lorsque l’instance RDS redémarre ou modifie les AZ, le proxy RDS cache cette turbulence de votre application.
• Meilleure sécurité: avec l’utilisation de jetons IAM ou de Secrets Manager.
• Les groupes de sécurité peuvent être resserrés pour bloquer l’accès DB direct.
• Il gère des milliers de connexions ECS simultanées plus gracieusement que les connexions RDS directes.

Lorsque RDS proxy n’est peut-être pas le meilleur choix…

Oui, il a des inconvénients
Bien que RDS proxy apporte de nombreux avantages, il est important de comprendre où il pourrait échouer. Voici quelques limites que l’on devrait garder à l’esprit:

• Ajoute de la latence: Étant donné que les demandes de la base de données passent par le proxy, il introduit un léger retard. Pour les applications qui nécessitent une latence ultra-faible ou une réactivité en temps réel, ce houblon supplémentaire pourrait être un inconvénient.
• Pas idéal pour les connexions à longue durée de vie: Si votre application maintient des connexions à la base de données à longue durée de données ou utilise déjà un regroupement de connexions efficace du côté client, RDS Proxy pourrait ne pas fournir beaucoup de valeur supplémentaire.
• Le débogage peut être plus complexe: Étant donné que le proxy se situe entre votre application et la base de données, le diagnostic de défaillances de connexion ou les goulots d’étranglement des performances peut être plus délicat.
• Limitations de compatibilité que vous devez connaître:
  • Aurora Serverless V2 n’est pas pris en charge: AWS confirme officiellement que RDS Proxy ne prend pas actuellement en charge Aurora Serverless V2.
  • Protocole PostgreSQL version 3.0 ou plus récent uniquement: RDS Proxy nécessite la version 3.0 du protocole moderne de PostgreSQL (introduit dans PostgreSQL 7.4+). Les bases de données utilisant des versions de protocole plus anciennes ne fonctionneront pas avec le proxy.
  • MySQL Limitations: Pour MySQL, RDS Proxy prend en charge la plupart des fonctionnalités standard mais ne prend pas en charge certaines options de message de démarrage avancées.
• Accès VPC uniquement: Les points de terminaison proxy RDS sont accessibles uniquement à partir du même VPC ou des réseaux connectés (comme VPC Peering ou VPN).

Surveillance dans le proxy RDS

Le proxy RDS peut être surveillé à l’aide d’Amazon CloudWatch. CloudWatch recueille et traite les données brutes des proxies en mesures lisibles et à temps proche. RDS Proxy expose les métriques CloudWatch comme:

• Connexions de données
• ClientConnections
• Activeconnections
• Connexionborrowtimeouts

Ceux-ci sont essentiels au réglage et à l’alerte pour les scénarios de rafale, les délais d’attente d’inactivité et l’efficacité de réutilisation de la connexion. Pour plus de détails, peut lire – Surveillance des métriques proxy RDS avec Amazon CloudWatch

Informations et mises à jour plus détaillées sur le proxy RDS

Pour les informations les plus précises et les plus à jour sur les fonctionnalités, les limitations et les configurations prises en charge RDS, je recommande fortement de vérifier la dernière documentation AWS. Vous trouverez ci-dessous les documents «bons à lire» si vous prévoyez d’adopter ou utilisent déjà RDS proxy:

Real Project Story: High CPU, Spiks Wild et proxy à la rescousse

Nous exécutions un microservice nommé API XYZ sur Amazon ECS (EC2). L’API XYZ sert de magasin API et de données central, modélisant le domaine de paris XYZ, permettant à plusieurs équipes d’accéder et de travailler avec les données de paris. C’est un service à fort trafic, en particulier pendant les heures de paris ou les promotions de paris.

Au fil du temps, il y avait des pointes de processeur imprévisibles sur notre API DB XYZ (instance PostgreSQL RDS). Ces pics poussaient occasionnellement l’utilisation du processeur près de 100%, conduisant à une dégradation des performances, à des temps de réponse plus lents et même à l’instabilité au niveau de la tâche dans les EC.

Phase 1: diagnostiquer le problème
Nous avons retracé les pointes à des éclats soudains de connexions et de modèles de requête inefficaces. Étant donné que les tâches ECS-EC2 peuvent tourner ou évoluer rapidement, chaque conteneur établissant plusieurs nouvelles connexions DB a amplifié le problème. La base de données n’a pas été en mesure de gérer efficacement ces rafales.

Phase 2: atténuation en plusieurs étapes
Pour résoudre le problème, nous avons mis en œuvre ce qui suit:

• • • Requête et optimisation du code: Nous avons examiné et optimisé plusieurs requêtes inefficaces, ajouté des index manquants et réglé la logique dans le service pour réduire la charge dans la base de données.
    • Read accrue des répliques (nœuds de lecteur): En plus de la configuration existante, augmentez le nombre de répliques de lecture de 1, se terminant avec une configuration à 3 nœuds: 1 primaire (lecture-écriture) et 2 répliques en lecture seule. Le service utilisait déjà la logique d’équilibrage de charge pour diviser le trafic de lecture au niveau de l’application.
    • Présentation du proxy RDS: RDS Proxy a permis aux services ECS de réutiliser les connexions regroupées plutôt que d’ouvrir de nouvelles.

Après avoir mis en œuvre toutes les solutions ci-dessus:

• • L’utilisation du processeur a fortement chuté.
  • La stabilité du service ECS s’est améliorée.
  • Les limites de connexion DB n’ont plus été violées.
  • La latence pendant les événements de mise à l’échelle a été considérablement réduite.

Phase 3: Rollbacks et leçons
Après avoir vu un comportement stable pendant quelques semaines, nous avons supposé qu’en raison de la requête et de l’optimisation du code, nous avons décidé de simplifier la configuration:

• • • Nous avons supprimé la réplique de lecture supplémentaire (retour à 1 lecteur + 1 écrivain).
    • Nous avons supprimé le proxy RDS, l’optimisation de la requête en pensant seule serait suffisante.

En quelques jours, les mêmes pointes de CPU sont revenus. Les tâches ECS ont de nouveau commencé à vivre l’instabilité. Il est devenu évident que Le proxy RDS faisait le travail lourd en absorbant les surtensions de connexion. Nous avons rapidement rétabli le proxy RDS. Les niveaux de CPU se sont immédiatement stabilisés.

Nous nous sommes finalement installés sur une architecture stable:

• • Un nœud RDS en lecture
  • Une réplique de lecture
  • RDS proxy activé

Le vrai point à retenir: la mise en commun de la connexion via Le proxy RDS était essentiel pour garantir que le processeur RDS est resté sous contrôleen particulier avec une configuration ECS évolutive où les montées de connexion sont difficiles à prévoir.

CONCLUSION

Le proxy RDS n’est pas une solution miracle, mais c’est un outil puissant. Utilisez-le lorsque l’environnement de votre application est élastique, vos bascules affectent la disponibilité ou souhaitent sécuriser davantage la connexion.

Il s’agit de savoir quand permettre, ce que toutes choses recherchent et quand reculer. Le proxy RDS peut apporter des améliorations de fiabilité et de sécurité importantes aux charges de travail RDS PostgreSQL.

Restez pragmatique. Restez curieux.