View a markdown version of this page

Scénarios d'utilisation courants - Amazon Aurora
Extensibilité des applicationsHaute disponibilitéUtilisation de plusieurs proxys avec une seule cible

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Scénarios d'utilisation courants

Extensibilité des applications

Gestion des connexions dans les applications sans serveur et pilotées par les événements

Les applications sans serveur et axées sur les événements, telles que les API et les services Web soutenus par AWS Lambda, doivent souvent prendre en charge un grand nombre de demandes de clients de courte durée. Ce modèle d'utilisation peut entraîner une perte de connexion du côté de la base de données sans possibilité d'implémenter le regroupement des connexions du côté de l'application. Les performances de la base de données peuvent être dégradées uniquement en raison du nombre de connexions simultanées, ou la base de données peut dépasser sa limite de connexions, ce qui entraîne des erreurs face au client.

Dans ces scénarios, RDS Proxy peut apporter les avantages suivants :

  1. Il décharge le coût d'établissement des connexions de la base de données vers le proxy et permet le regroupement des connexions et le multiplexage afin de traduire un grand nombre de connexions client en un nombre beaucoup plus restreint de connexions à la base de données principale. Cela permet de réduire la surcharge de connexion et la contention des bases de données, en particulier dans les moteurs de base de données tels que PostgreSQL, où le coût d'établissement et de maintenance des connexions est relativement élevé.

  2. Il peut gérer les surtensions de connexion avec plus d'élégance. Par exemple, lorsqu'une base de données dépasse sa limite de connexion, elle renvoie immédiatement une erreur au client. Lorsque le proxy RDS doit emprunter une connexion au pool mais que celui-ci est déjà à pleine capacité, le proxy peut attendre qu'une connexion soit disponible. Cette fonctionnalité peut améliorer l'expérience client en transformant les erreurs graves en une légère augmentation de la latence des requêtes.

  3. Grâce à la taille du pool de connexions configurable, vous pouvez également utiliser le proxy RDS comme mécanisme de régulation ou de délestage. Si le nombre de connexions dépasse les limites que vous spécifiez, le proxy RDS attend qu'une connexion soit disponible dans un délai configurable. Cela peut être utile dans les cas où la base de données gère plusieurs charges de travail et que vous souhaitez limiter la pression qu'une charge de travail spécifique peut créer sur la base de données.

Gestion des connexions dans les applications distribuées basées sur des conteneurs

Une architecture d'application distribuée basée sur des conteneurs peut contenir des centaines, voire des milliers de conteneurs, chacun exécutant une copie du code de l'application. Même si les conteneurs individuels sont capables de regrouper des connexions, ces pools sont spécifiques au conteneur et sont donc très petits. Le nombre de conteneurs multiplié par la taille de chaque mini-pool de conteneurs peut potentiellement dépasser les limites de connexion sur vos bases de données Amazon RDS ou Aurora.

Dans ce cas, la capacité du proxy RDS à effectuer un regroupement de connexions (réutilisation des connexions) et un multiplexage (service à plusieurs clients à l'aide d'une seule connexion principale) est très précieuse. Vous pouvez toujours utiliser le regroupement de connexions au sein de chaque conteneur pour réduire le taux de désabonnement entre les threads de l'application et le proxy RDS, mais le proxy peut aider à ramener le nombre de connexions à la base de données principale à un niveau gérable.

Améliorer l'utilisation des répliques de lecture

Read-heavy les bases de données peuvent nécessiter plusieurs répliques en lecture pour prendre en charge le trafic en lecture seule. Les applications peuvent utiliser leur propre logique pour choisir la réplique à laquelle se connecter ou, le plus souvent, elles peuvent utiliser un mécanisme circulaire tel que DNS-based le point de terminaison du lecteur de cluster Aurora. Cependant, une DNS-based approche peut entraîner une utilisation inégale des répliques en raison de la mise en cache du DNS. Par exemple, les clients peuvent « s'attacher » à une réplique en particulier, ne pas reconnaître les nouvelles répliques ajoutées au cluster ou essayer de se connecter à des répliques qui n'existent plus.

Lorsque vous utilisez un point de terminaison en lecture seule du proxy RDS, le proxy achemine les connexions client entre toutes les répliques disponibles en utilisant la logique des « connexions les moins exceptionnelles ». Le proxy RDS n'équilibre pas la charge du trafic en fonction des indicateurs de base de données tels que l'utilisation du processeur, mais il tente d'égaliser le nombre de connexions client sur chaque réplique, pondéré par la limite de connexion de la base de données. Par exemple, si trois répliques Aurora sont exécutées avec un max_connections paramètre de 500, 500 et 1000 (respectivement), le proxy essaie d'envoyer environ deux fois plus de connexions à la troisième réplique qu'aux deux autres.

Vous pouvez utiliser les points de terminaison du lecteur RDS Proxy avec des clusters Aurora ou des déploiements de clusters de Multi-AZ bases de données Amazon RDS avec deux mises en veille lisibles. Les points de terminaison du lecteur proxy ne sont pas pris en charge pour les déploiements d'instances de base de données Amazon RDS avec des répliques de lecture.

Améliorer l'efficacité de la connexion

Lorsque vous introduisez un proxy entre les applications clientes et la base de données, votre objectif est généralement d'améliorer l'efficacité de la gestion des connexions tout en tenant compte du coût de latence d'un saut réseau supplémentaire via le proxy. Une couche intermédiaire supplémentaire peut sembler peu intuitive pour améliorer l'efficacité de la connexion, car toute connexion qui aurait été ouverte directement sur la base de données est désormais ouverte sur le proxy. Les étapes du protocole sont les mêmes dans les deux cas. Par conséquent, si vous consacrez toujours des ressources à des poignées de connexion, l'origine des améliorations d'efficacité n'est peut-être pas évidente.

Le proxy ne rend pas nécessairement les connexions moins coûteuses à établir. Au lieu de cela, il déplace la majeure partie de la charge de gestion des poignées de main de la couche de base de données vers la couche proxy. Lorsque vous payez pour des ressources de base de données, vous souhaitez que ces ressources soient consacrées au travail de base de données et non à des frais supplémentaires. Cela devient particulièrement important lors de l'utilisation de connexions cryptées : bien que le surcoût lié à la transmission de données chiffrées via une connexion existante ne soit pas significatif, le surcoût initial lié à la configuration d'une connexion cryptée est important. Dans les environnements qui génèrent des centaines ou des milliers de connexions par seconde, cet effort supplémentaire peut rapidement s'accumuler. Il se peut que vous ne souhaitiez pas consacrer ce temps processeur à des ressources de base de données (relativement coûteuses) et les décharger sur une couche proxy (relativement peu coûteuse).

En ce qui concerne la latence induite par un saut de réseau supplémentaire, son importance dépend du niveau de « bavardage » de votre application et du nombre d'instructions qu'elle exécute pour chaque « conversation » avec la base de données. Dans RDS Proxy, vous observez généralement une latence accrue dans les faibles millisecondes à un chiffre, mais cela n'aura pas nécessairement d'impact visible sur vos applications. Par exemple :

  • Une charge de travail où les temps d'exécution des requêtes sont de l'ordre de quelques dizaines ou centaines de millisecondes (ou plus) ne remarquera probablement pas la surcharge du proxy, car elle ne représente qu'une petite fraction du temps total des requêtes.

  • Une application qui exécute des requêtes à un chiffre en millisecondes ou inférieures à une milliseconde peut remarquer une différence car le surcoût des requêtes (un saut réseau supplémentaire par requête) est important par rapport au temps d'exécution des requêtes. Cela peut ne pas poser de problème si une session client n'implique qu'une poignée de requêtes, de sorte que la surcharge cumulée reste faible.

Si la latence ajoutée dans votre situation est à la fois perceptible et indésirable, vous devez la comparer aux autres avantages de l'utilisation d'un proxy (regroupement, multiplexage, gestion du basculement).

Haute disponibilité

Multi-AZ les bases de données exécutées sur Amazon RDS et Aurora (à l'exception d'Aurora DSQL) utilisent des mécanismes de basculement pour rétablir la disponibilité en cas de problème avec l'instance de base de données principale. Les failovers sont également utilisés dans le cadre des flux de travail opérationnels, tels que le dimensionnement du calcul pour l'instance principale. Un basculement implique une modification du DNS qui déplace le point de terminaison de base de données principal (read/writecompatible) de l'instance principale précédente vers la nouvelle instance promue. Ce changement de DNS doit être observé et reconnu par les applications clientes, afin que les clients puissent suivre le principal sans délai.

Certaines applications peuvent avoir du mal à reconnaître rapidement les modifications du DNS en raison de la mise en cache du DNS dans le système d'exploitation ou au niveau de l'application. Bien qu'il soit recommandé de résoudre les problèmes de mise en cache du DNS au niveau de l'application, cela n'est pas toujours faisable en raison de la complexité de l'application ou du coût de l'introduction de modifications.

Dans ce scénario, le proxy RDS constitue un moyen efficace d'éviter les retards liés au DNS-related basculement. Les read/write points de terminaison et les points de terminaison en lecture seule facultatifs fournis par RDS Proxy sont « stables » dans le sens où les adresses IP sous-jacentes à ces points de terminaison ne changent pas lorsque les instances de base de données échangent leurs rôles. RDS Proxy suit en permanence la topologie de la base de données principale et soustrait les modifications des rôles d'instance aux clients.

Il existe d'autres moyens de gérer les problèmes de mise en cache du DNS, par exemple en utilisant des pilotes avancés directement capables de détecter la topologie de la base de données sans recourir au DNS. Cependant, il peut être plus facile de déployer un seul proxy devant la base de données au lieu d'introduire des modifications de code et de nouveaux pilotes au niveau de l'application.

Lire la disponibilité

En plus d'améliorer l'expérience client lors des basculements de bases de données, RDS Proxy contribue également à la disponibilité des applications en cas de problèmes de réplication en lecture. Il le fait de deux manières :

  1. Si une réplique en lecture devient indisponible, mais que d'autres répliques sont disponibles dans le cluster, le proxy peut acheminer de nouvelles connexions vers les répliques disponibles. Les clients n'ont pas à s'inquiéter des délais de propagation du DNS ou de la mise en cache du DNS.

  2. Pour une connexion client existante qui est multiplexée, le proxy peut envoyer les requêtes suivantes à partir de cette connexion vers une autre réplique disponible. Dans ce cas, le client ne remarquera peut-être même pas qu'une réplique principale a rencontré un problème. Lorsque vous utilisez cette technique, RDS Proxy garantit que la nouvelle réplique n'est pas en retard par rapport à la précédente en termes de délai de réplication. Ainsi, les requêtes suivantes envoyées par le client ne verront pas de données qui pourraient être considérées comme périmées.

Utilisation de plusieurs proxys avec une seule cible

Il est recommandé d'utiliser un proxy RDS par cible de base de données, telle qu'une instance Amazon RDS ou un cluster Aurora. Cela fonctionne bien dans la plupart des scénarios, simplifie la configuration et rend l'expérience client plus prévisible. En comparaison, l'utilisation de plusieurs proxys vous oblige à aligner soigneusement la configuration sur tous les proxys afin d'éviter tout comportement inattendu. Par exemple, vous devez vous assurer que la taille combinée de tous les pools de proxys ne dépasse pas les limites de connexion de la base de données cible unique.

Vous pourriez toujours envisager d'utiliser plusieurs proxys dans certaines situations. Les sections suivantes présentent les scénarios les plus courants et décrivent les avantages et les inconvénients d'un proxy unique par rapport à une approche multiproxy.

Disponibilité du proxy

L'infrastructure du proxy RDS est hautement disponible et déployée sur plusieurs zones de disponibilité (AZ) dès sa conception. La capacité du proxy est répartie sur de nombreux nœuds avec surveillance continue de l'état de santé, et elle est automatiquement ajustée en fonction de la taille de l'instance provisionnée ou des paramètres ACU maximaux Serverless v2 de votre base de données. Grâce à la Multi-AZ conception distribuée du proxy, vous n'avez pas besoin d'exécuter plusieurs proxys devant vos clusters Amazon RDS ou Aurora dans un souci de haute disponibilité.

En fait, l'utilisation de plusieurs proxys devant une seule base de données cible signifie que la pile d'applications est désormais chargée de détecter les problèmes et d'y réagir au lieu de s'appuyer sur les mécanismes robustes intégrés au proxy. Par conséquent, l'utilisation de plusieurs proxys pour des raisons de haute disponibilité est fortement déconseillée, car elle est susceptible d'introduire plus de problèmes qu'elle ne peut en résoudre.

Gestion de plusieurs groupes de clients

Chaque proxy fournit un read/write point de terminaison et (éventuellement) des points de terminaison supplémentaires read/write ou en lecture seule. Lorsqu'un seul proxy est utilisé pour gérer plusieurs groupes de clients ou plusieurs charges de travail, ces charges de travail peuvent potentiellement interférer. Par exemple, une charge de travail peut monopoliser le pool de connexions au point qu'il ne reste plus assez de connexions libres pour gérer les autres charges de travail. L'utilisation de proxys distincts pour isoler les charges de travail peut s'avérer une solution intéressante, mais vous pouvez d'abord envisager d'autres options :

  • La base de données elle-même peut fournir des alternatives plus simples à l'exécution de plusieurs proxys. Par exemple, si le problème est dû au fait que certains utilisateurs monopolisent le pool, vous pouvez utiliser le système d'autorisation de la base de données pour limiter le nombre de connexions simultanées que ces utilisateurs sont autorisés à ouvrir.

  • De même, les délais d'expiration des requêtes et des délais d'inactivité au niveau de la base de données peuvent résoudre les problèmes liés aux connexions orphelines ou aux requêtes inutilisées.

  • Si le problème est dû à la durée de la requête ou de la transaction ou à la consommation de ressources par requête plutôt qu'au nombre de connexions simultanées, l'utilisation de proxys supplémentaires ne sera pas utile car le proxy n'impose aucune limite au poids des requêtes ou des transactions. Si le problème ne peut pas être résolu à la source, vous pouvez utiliser le planificateur d'événements de la base de données pour exécuter du code qui détecte et met fin à l'activité des clients en fonction de conditions arbitraires au lieu de déplacer ces clients problématiques vers un proxy distinct.

Si vous décidez d'utiliser plusieurs proxys devant la même cible, assurez-vous que la taille totale de tous les pools de connexions ne dépasse pas les capacités de la base de données cible. Par exemple, la somme de MaxConnectionsPercent tous les proxys doit être inférieure à 100, sinon les proxys peuvent essayer d'ouvrir plus de connexions que ce que la base de données est configurée pour gérer.

Chaque proxy est facturé séparément, et le taux de facturation dépend de la taille des ressources de base de données sous-jacentes et non de l'activité de la charge de travail. Tenez compte du coût d'exécution de plusieurs proxys par rapport au coût de mise en œuvre de solutions alternatives, le cas échéant.

Contrôle indépendant des pools de lecture et d'écriture

Chaque proxy fournit un read/write point de terminaison et (éventuellement) des points de terminaison supplémentaires read/write ou en lecture seule, mais les limites et les délais d'expiration sont configurés pour l'ensemble de la cible du proxy et non individuellement pour chaque point de terminaison du proxy.

Par exemple, un cluster Aurora peut traiter un grand volume de requêtes en lecture seule à l'aide de plusieurs répliques en lecture et du point de terminaison du lecteur du proxy, mais vous souhaitez limiter le nombre de read/write connexions afin de réduire la pression sur les ressources sur le rédacteur unique. Comme le MaxConnectionsPercent paramètre est défini pour l'ensemble de la cible du proxy (cluster), vous ne pouvez pas limiter le nombre de connexions au point de read/write terminaison sans affecter également les limites du point de terminaison en lecture seule.

Il existe plusieurs manières de relever ce défi :

Vous pouvez lancer des répliques de lecture supplémentaires dans le cluster et réduire proportionnellement les paramètres du MaxConnectionsPercent proxy. Cela permet de préserver la taille totale du pool de connexions en lecture seule tout en réduisant le nombre maximum de connexions autorisées sur le graveur. Cependant, cela augmente également le coût du cluster et devient de moins en moins efficace au fur et à mesure que le nombre de répliques augmente.

Vous pouvez utiliser des groupes de paramètres au niveau de l'instance pour configurer les limites de connexion à la base de données (comme dans max_connections Aurora MySQL ou PostgreSQL) pour les répliques en lecture indépendamment du rédacteur. Cependant, vous devez éviter d'utiliser une configuration asymétrique des paramètres, car les répliques peuvent être promues en tant que rédacteur lors d'un basculement, de sorte que la différenciation initiale des paramètres ne sera pas permanente. Vous pourriez envisager de modifier les paramètres de priorité de basculement au niveau de l'instance afin d'influencer les répliques sélectionnées pour la promotion lors des basculements, et de vous en servir comme mécanisme d'exclusion du basculement souple pour rendre la configuration asymétrique plus prévisible. Cependant, les priorités de basculement ne sont que des indications et ne constituent pas une garantie ferme du comportement du basculement. Multi-instance les configurations avec des paramètres asymétriques sont donc déconseillées car elles nécessitent une surveillance continue et peuvent produire un comportement inattendu en cas de basculement sur une instance que vous ne préférez pas.

Dans ce scénario, l'utilisation de plusieurs proxys peut être le moyen le plus propre de gérer séparément les pools de lecture et d'écriture. Vous pouvez créer deux proxys pour la base de données cible unique, puis configurer les applications pour qu'elles utilisent le point de terminaison du rédacteur depuis le premier proxy et le point de terminaison en lecture seule depuis le second proxy. Un proxy gère uniquement les charges de travail d'écriture, l'autre les charges de travail de lecture uniquement, et le MaxConnectionsPercent (ainsi que d'autres paramètres) peut être configuré indépendamment pour chaque proxy. Cette solution implique un coût supplémentaire pour exécuter le deuxième proxy, mais elle est plus simple et plus prévisible que les alternatives précédentes.