Présentation du pool de connexions géré

Le pooling de connexions géré vous permet de faire évoluer vos charges de travail en optimisant l'utilisation des ressources et la latence des connexions pour vos instances Cloud SQL. PostgreSQL crée un processus pour chaque connexion, ce qui entraîne une utilisation de la mémoire et une surcharge de configuration des connexions. Dans les architectures qui établissent fréquemment de nombreuses connexions de courte durée, telles que les microservices ou les applications sans serveur exécutées sur Cloud Run, cette surcharge peut affecter les performances et l'évolutivité de la base de données.

Lorsque le pooling de connexions géré est activé, les clients se connectent à un cluster de pool de connexions intermédiaire au lieu de se connecter directement au serveur de base de données. Cette attribution dynamique améliore les performances, en particulier pour les connexions mises à l'échelle, en absorbant les pics de connexion soudains et en réutilisant les connexions de base de données existantes.

Regroupeurs de connexions et pools de connexions

Lorsque des applications clientes se connectent à une instance pour laquelle le pooling de connexions géré est activé, elles se connectent à un cluster de pool de connexions intermédiaire au lieu de se connecter directement au serveur de base de données. Le cluster de pool de connexions se compose d'un ou de plusieurs regroupeurs de connexions. Un regroupeur de connexions est un service proxy de base de données qui gère et achemine les connexions de base de données entre les applications clientes et le serveur de base de données.

Un regroupeur de connexions gère les pools de connexions en tant que groupe de connexions de serveur de base de données réutilisables ouvertes par paire base de données/utilisateur.

Lorsqu'une application cliente authentifiée se connecte à une base de données en tant qu'utilisateur spécifique, le regroupeur de connexions achemine la requête vers le pool de connexions correspondant :

  • Si une connexion de serveur inactive est disponible dans le pool, le regroupeur de connexions l'attribue à la requête du client.
  • Si aucune connexion de serveur inactive n'est disponible et que la limite du pool (max_pool_size) n'a pas été atteinte, le regroupeur de connexions crée une connexion de serveur dans le pool.
  • Si toutes les connexions de serveur du pool sont utilisées et que la limite du pool a été atteinte, le client passe à un état d'attente jusqu'à ce qu'une connexion de serveur devienne disponible.
  • Une fois la requête terminée, la connexion de serveur revient au pool de connexions pour être réutilisée.

Relation entre les regroupeurs et les pools

Un seul regroupeur de connexions peut gérer plusieurs pools de connexions simultanément, avec un pool pour chaque paire base de données/utilisateur unique qui se connecte via ce regroupeur.

Si votre instance exécute plusieurs regroupeurs de connexions, chacun d'eux gère indépendamment son propre ensemble de pools de connexions pour les paires base de données/utilisateur qui lui sont acheminées.

Les performances et les capacités de mise à l'échelle du pooling de connexions géré fonctionnent à plusieurs niveaux :

  • Mise à l'échelle du cluster de pool de connexions : le nombre de regroupeurs de connexions dans le cluster est automatiquement mis à l'échelle en fonction du nombre de cœurs de vCPU provisionnés pour l'instance (en divisant le nombre de vCPU par 4, avec un minimum d'un regroupeur de connexions). Cela garantit que le pooling de connexions ne devient pas un goulot d'étranglement. Les connexions client entrantes sont distribuées entre les regroupeurs de connexions disponibles. Exemple :

    • Une instance avec 2 ou 4 vCPU exécute 1 regroupeur de connexions.
    • Une instance avec 8 vCPU exécute 2 regroupeurs de connexions.
    • Une instance avec 16 vCPU exécute 4 regroupeurs de connexions.
    • Une instance avec 32 vCPU exécute 8 regroupeurs de connexions.
    • Une instance avec 64 vCPU exécute 16 regroupeurs de connexions.

  • Mise à l'échelle des regroupeurs et des pools : comme les regroupeurs de connexions fonctionnent indépendamment, toutes les options de configuration sont appliquées par regroupeur de connexions plutôt que globalement sur l'instance. Les connexions de serveur sont créées à la demande jusqu'à une limite maximale définie par max_pool_size pour chaque pool géré dans chaque regroupeur de connexions. Par exemple, si max_pool_size est défini sur 50 sur une instance exécutant 2 regroupeurs de connexions (8 vCPU), chaque regroupeur de connexions peut ouvrir jusqu'à 50 connexions de serveur pour une paire base de données/utilisateur spécifique, ce qui permet un total de 100 connexions de serveur sur l'instance pour ce pool. Un dimensionnement précis du pool est essentiel pour les performances : si vous définissez une valeur trop faible, les temps d'attente de connexion peuvent être plus longs, tandis qu'une valeur trop élevée peut gaspiller les ressources du serveur de base de données.

  • Configurations de connexion client : les limites de connexion client et le comportement de délai avant expiration sont également configurés par regroupeur de connexions. Les principaux paramètres sont les suivants :

    • max_client_connections: limite le nombre maximal de connexions client autorisées par regroupeur de connexions (la valeur par défaut est de 5 000 connexions pour chaque regroupeur de connexions).
    • client_connection_idle_timeout: contrôle la durée pendant laquelle une connexion client peut rester inactive avant d'expirer.
    • query_wait_timeout: contrôle la durée pendant laquelle une requête attend une connexion de serveur disponible dans le pool avant d'expirer.

Cas d'utilisation et points à prendre en compte

Tenez compte des points suivants lorsque vous utilisez le pooling de connexions géré :

  • Bien que vous puissiez utiliser le pooling de connexions géré pour toutes les charges de travail transactionnelles, il offre le meilleur débit et la meilleure latence aux applications qui contiennent des connexions de courte durée ou qui entraînent une augmentation du nombre de connexions.
  • Pour les connexions de longue durée, les performances de connexion à l'aide du pooling de connexions géré peuvent être légèrement inférieures à celles d'une connexion directe. Dans ce cas, le pooling de connexions géré fournit une mise à l'échelle des connexions lorsque le nombre de connexions est très élevé. Toutefois, pour les applications qui établissent généralement des connexions de longue durée, vous pouvez éviter d'utiliser le pooling de connexions.
  • Vous pouvez utiliser Identity and Access Management pour sécuriser les connexions à votre instance en fonction du port utilisé par le pooling de connexions géré. Pour en savoir plus sur le fonctionnement d'IAM dans Cloud SQL et ses limites, consultez la page Authentification IAM.

Pour en savoir plus sur l'activation du pooling de connexions géré, consultez la page Configurer le pooling de connexions géré.

Conditions requises

Pour utiliser le pooling de connexions géré, votre instance doit répondre aux exigences suivantes :

  • Votre instance doit être une instance Cloud SQL Enterprise Plus.
  • Vous ne devez être connecté à votre instance qu'à l'aide d'une connexion directe ou du proxy d'authentification Cloud SQL.
  • Votre instance doit être configurée pour l'accès aux services privés, utiliser une adresse IP publique ou avoir Private Service Connect activé.
  • Votre instance doit utiliser la nouvelle architecture réseau Cloud SQL.
  • Le pooling de connexions géré nécessite un numéro de version de maintenance minimal de POSTGRES_$version.R20250727.00_14. Pour en savoir plus sur la maintenance en libre-service, consultez la page Effectuer une maintenance en libre-service.

Options de pooling

Le pooling de connexions géré vous permet de gérer le regroupement des connexions à l'aide du paramètre pool_mode. Vous pouvez utiliser les options de pooling suivantes :

  • transaction (par défaut) : regroupe les connexions au niveau de la transaction. Les connexions sont renvoyées au pool une fois chaque transaction terminée. Cloud SQL recommande d'utiliser le mode de pooling transaction pour les connexions de courte durée.
  • session : regroupe les connexions au niveau de la session. Chaque session utilise une connexion de serveur dédiée qui maintient un état de session. Cela réduit l'efficacité du pooling. Lorsqu'un client se déconnecte, la connexion de serveur revient au pool de connexions.

Options de configuration avancées

Vous pouvez personnaliser le pooling de connexions géré à l’aide des options de configuration suivantes.

Nom de la configuration Description
max_pool_size Nombre maximal de connexions de serveur autorisées pour une paire base de données/utilisateur dans chaque pool de connexions. Cette configuration est appliquée par regroupeur de connexions. Déterminez cette valeur en fonction de la taille de votre instance et des exigences de taille du pool.

La valeur par défaut est de 50 connexions par paire base de données/utilisateur pour chaque regroupeur de connexions.
min_pool_size Nombre minimal de connexions de serveur disponibles à tout moment dans chaque pool de connexions. Cette configuration est appliquée par regroupeur de connexions. Déterminez cette valeur en fonction de la taille de votre instance et des exigences de taille du pool.

Si le nombre de connexions de serveur est inférieur à min_pool_size, ce paramètre ajoute d’autres connexions de serveur au pool. Cela permet de gérer les augmentations soudaines de la charge de la base de données après des périodes d'inactivité et de s'assurer que les connexions sont disponibles et prêtes à être utilisées.

La valeur par défaut est de 0 connexion.
max_client_connections Nombre maximal de connexions client autorisées par regroupeur de connexions lors de l'utilisation du pooling de connexions géré. Déterminez cette valeur en fonction de la taille de votre instance et des exigences de taille du pool.

La valeur par défaut est de 5,000 connexions pour chaque regroupeur de connexions.
max_prepared_statements Nombre maximal d'instructions préparées nommées au niveau du protocole compatibles par regroupeur de connexions en transaction mode de pooling. Déterminez cette valeur en fonction de la taille de votre instance et des exigences de taille du pool.

Définir cette option sur 0 désactive la prise en charge des instructions préparées support. Pour des performances optimales, cette valeur doit être supérieure au nombre d'instructions préparées couramment utilisées dans votre base de données. Un nombre élevé d'instructions préparées dans le pooling de connexions géré peut entraîner une augmentation de l'utilisation de la mémoire.

La valeur par défaut est de 0 instruction.
client_connection_idle_timeout Durée pendant laquelle une connexion client reste inactive avant d'expirer. Cette valeur peut être comprise entre 0 et 2,147,483 secondes, et la valeur par défaut est de 0 seconde.
server_connection_idle_timeout Durée pendant laquelle une connexion de serveur reste inactive avant d'expirer. Cette valeur peut être comprise entre 0 et 2,147,483 secondes, et la valeur par défaut est de 600 secondes.
query_wait_timeout Durée pendant laquelle une requête attend une connexion de serveur dans un pool avant qu'elle n'expire.

Définir cette option sur 0 la désactive, ce qui permet une mise en file d'attente client indéfinie. L'activation de cette option empêche les serveurs qui ne répondent pas de bloquer les connexions.

Cette valeur peut être comprise entre 0 et 2,147,483 secondes, et la valeur par défaut est de 120 secondes.
ignore_startup_parameters Paramètres que vous souhaitez ignorer et qui ne sont pas suivis par défaut dans les paquets de démarrage du pooling de connexions géré.
server_lifetime Durée maximale pendant laquelle une connexion de serveur est inutilisée avant que Managed Connection Pooling ne la ferme. Si la valeur est définie sur 0 secondes, la connexion est immédiatement fermée après utilisation.

La valeur par défaut est de 3600 secondes.

Limites

Lorsque vous utilisez le pooling de connexions géré avec vos instances Cloud SQL Enterprise Plus, tenez compte des limites suivantes :

  • L'activation du pooling de connexions géré sur une instance existante entraîne le redémarrage de la base de données.
  • Le pooling de connexions géré ne peut être utilisé qu'avec le proxy d'authentification Cloud SQL version 2.15.2 et ultérieure.
  • Si vous utilisez le connecteur de langage Go Cloud SQL, nous vous recommandons une version Go minimale de 1.24. Si vous utilisez la version 1.23 ou une version antérieure de Go, vous pouvez rencontrer des limites de performances lorsque vous utilisez le pooling de connexions géré.

  • Si vous utilisez le pooling de connexions géré en mode de pooling transaction, les fonctionnalités SQL suivantes ne sont pas compatibles :

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • Tables temporaires PRESERVE/DELETE ROW
    • LOAD
    • Verrous consultatifs au niveau de la session

  • Si vous utilisez la bibliothèque d'interface de base de données asyncpg pour le regroupeur de pooling de connexions géré sur les ports 3307 et 6432, vous devez mettre à jour la max_prepared_statements avec une valeur supérieure à 0 pour activer la prise en charge des instructions préparées dans le regroupeur de pooling de connexions géré.

  • Si vous utilisez Cloud SQL pour PostgreSQL version 17, l'option sslnegotiation=direct n'est pas compatible.

  • Le suivi des adresses IP des clients n'est pas compatible avec le pooling de connexions géré. Si vous activez Stocker les adresses IP client dans les Insights sur les requêtes, les adresses IP client s'affichent sous la forme local au lieu de l'adresse IP elle-même.

Ports utilisés par le pooling de connexions géré

Lorsque vous activez le pooling de connexions géré, les ports utilisés par les instances Cloud SQL pour diffuser le trafic de la base de données changent. Vous pouvez utiliser Identity and Access Management pour sécuriser les connexions en fonction du port.

Les ports utilisés par le pooling de connexions géré et leurs options IAM disponibles sont les suivants :

Connexions de serveur utilisées par le pooling de connexions géré

La configuration de base de données max_connections limite le nombre maximal de connexions de serveur qu'un regroupeur dans le pooling de connexions géré peut utiliser. Cloud SQL recommande d'ajuster cette valeur en fonction des exigences de charge de travail de votre instance et de la taille de l'instance de base de données. En période de forte charge, le nombre de connexions pour l'authentification peut devenir très élevé.

Si vous utilisez la valeur par défaut max_pool_size de 50 connexions par pool, nous vous recommandons de réserver au moins 15 connexions de serveur par processeur pour le pooling de connexions géré lorsque vous définissez l'option max_connections pour votre base de données. Pour en savoir plus sur l'option max_connections, consultez la section Nombre maximal de connexions simultanées. Pour modifier l'indicateur de base de données max_connections de votre instance, consultez la page Configurer des indicateurs de base de données.

Étape suivante