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 de connexion pour vos instances Cloud SQL. PostgreSQL crée un processus pour chaque connexion, ce qui entraîne une surcharge de mémoire et de configuration de la connexion. 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 regroupement 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 à grande échelle, en absorbant les pics de connexion soudains et en réutilisant les connexions de base de données existantes.

Poolers de connexions et pools de connexions

Lorsque des applications clientes se connectent à une instance avec le pool de connexions géré 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 poolers de connexions. Un pooler de connexions est un service de 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 pooler de connexions gère les pools de connexions sous la forme d'un groupe de connexions ouvertes et réutilisables au serveur de base de données pour chaque 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 pooler de connexions achemine la requête vers le pool de connexions correspondant :

  • Si une connexion de serveur inactive est disponible dans le pool, le pooler 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 pooler de connexions crée une connexion de serveur dans le pool.
  • Si toutes les connexions au 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 au serveur devienne disponible.
  • Une fois la requête terminée, la connexion au serveur est renvoyée au pool de connexions pour être réutilisée.

Relation entre les poolers et les pools

Un même pooler de connexions peut gérer plusieurs pools de connexions simultanément, avec un pool pour chaque paire unique de base de données et d'utilisateur de base de données qui se connecte via ce pooler.

Si votre instance exécute plusieurs poolers de connexion, chacun d'eux gère indépendamment son propre ensemble de pools de connexion pour les paires de bases de données et d'utilisateurs qui lui sont attribuées.

Les performances et les capacités de scaling du regroupement de connexions géré fonctionnent à plusieurs niveaux :

  • Scaling du cluster de pool de connexions : le nombre de poolers de connexions dans le cluster est automatiquement mis à l'échelle en fonction du nombre de cœurs de processeur virtuel provisionnés pour l'instance (en divisant le nombre de processeurs virtuels par 4, avec un minimum de 1 pooler de connexions). Cela permet de s'assurer que le regroupement de connexions ne devienne pas un goulot d'étranglement. Les connexions client entrantes sont réparties entre les poolers de connexion disponibles. Exemple :

    • Une instance avec deux ou quatre processeurs virtuels exécute un pooler de connexion.
    • Une instance avec 8 processeurs virtuels exécute deux poolers de connexion.
    • Une instance avec 16 processeurs virtuels exécute quatre poolers de connexion.
    • Une instance avec 32 vCPU exécute huit poolers de connexion.
    • Une instance avec 64 processeurs virtuels exécute 16 poolers de connexion.

  • Pooler et scaling du pool : étant donné que les poolers de connexion fonctionnent de manière indépendante, toutes les options de configuration sont appliquées par pooler de connexion plutôt qu'à l'ensemble de l'instance. Les connexions au serveur sont créées à la demande, jusqu'à une limite maximale définie par max_pool_size pour chaque pool géré dans chaque pooler de connexions. Par exemple, si max_pool_size est défini sur 50 sur une instance exécutant deux poolers de connexion (8 processeurs virtuels), chaque pooler de connexion 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. Il est essentiel de dimensionner correctement le pool 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 pool de connexions. Voici quelques-uns des principaux paramètres :

    • max_client_connections : limite le nombre maximal de connexions client autorisées par pooler de connexions (la valeur par défaut est de 5 000 connexions pour chaque pooler 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 au 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 regroupement de connexions géré :

  • Bien que vous puissiez utiliser le regroupement de connexions géré pour toutes les charges de travail transactionnelles, il offre le plus d'avantages en termes de débit et de latence aux applications qui contiennent des connexions de courte durée ou qui entraînent un pic 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 regroupement de connexions géré permet de mettre à l'échelle les connexions lorsque leur nombre est très élevé. Toutefois, pour les applications qui établissent généralement des connexions à longue durée de vie, vous pouvez éviter d'utiliser le regroupement de connexions.
  • Vous pouvez utiliser Identity and Access Management pour sécuriser les connexions à votre instance en fonction du port utilisé par le pool de connexions géré. Pour en savoir plus sur le fonctionnement d'IAM dans Cloud SQL et sur ses limites, consultez Authentification IAM.

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

Conditions requises

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

  • Votre instance doit être une instance Cloud SQL Enterprise Plus.
  • Vous devez être connecté à votre instance en utilisant uniquement une connexion directe ou le 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 être une nouvelle instance avec Private Service Connect activé.
  • Votre instance doit utiliser la nouvelle architecture réseau Cloud SQL.
  • Le regroupement 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 Effectuer la maintenance en libre-service.

Options de mise en commun

Le regroupement de connexions géré vous permet de gérer la façon dont les connexions sont regroupées à l'aide du paramètre pool_mode. Vous pouvez utiliser les options de mise en commun suivantes :

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

Options de configuration avancées

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

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

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

Si le nombre de connexions au serveur est inférieur à min_pool_size, ce paramètre ajoute des connexions au 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 à l'emploi.

La valeur par défaut est de 0 connexions.
max_client_connections Nombre maximal de connexions client autorisées par pooler de connexions lorsque vous utilisez le regroupement de connexions géré. Déterminez cette valeur en fonction de la taille de votre instance et de la taille du pool requises.

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

Définir cette option sur 0 désactive la prise en charge des instructions préparées. 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 0.
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. La valeur par défaut est de 0 secondes.
server_connection_idle_timeout Durée pendant laquelle une connexion au serveur reste inactive avant d'expirer. Cette valeur peut être comprise entre 0 et 2,147,483 secondes. La valeur par défaut est de 600 secondes.
query_wait_timeout Durée pendant laquelle une requête attend une connexion au serveur dans un pool avant d'expirer.

Si vous définissez cette option sur 0, elle est désactivée, ce qui permet la mise en file d'attente indéfinie du client. 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. La valeur par défaut est de 120 secondes.
ignore_startup_parameters Les paramètres que vous souhaitez ignorer et qui ne sont pas suivis par défaut dans les paquets de démarrage du pool de connexions géré.
server_lifetime Durée maximale pendant laquelle une connexion au serveur est inutilisée avant que le regroupement de connexions géré 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 pool de connexions géré avec vos instances Cloud SQL Enterprise Plus, tenez compte des limites suivantes :

  • L'activation du pool 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 d'utiliser au minimum la version 1.24 de Go. Si vous utilisez Go version 1.23 ou antérieure, vous pouvez rencontrer des limitations de performances lorsque vous utilisez le pool de connexions géré.

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

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

  • Si vous utilisez la bibliothèque d'interface de base de données asyncpg pour le pooler Managed Connection Pooling sur les ports 3307 et 6432, vous devez définir max_prepared_statements sur une valeur supérieure à 0 pour activer la prise en charge des instructions préparées dans le pooler Managed Connection Pooling.

  • Si vous utilisez la version 17 de Cloud SQL pour PostgreSQL, 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 l'option Stocker les adresses IP des clients dans Insights sur les requêtes, les adresses IP des clients s'affichent sous la forme local au lieu de l'adresse IP elle-même.

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

Lorsque vous activez le pool de connexions géré, les ports utilisés par les instances Cloud SQL pour diffuser le trafic de 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 au serveur utilisées par le regroupement de connexions géré

La configuration de la base de données max_connections limite le nombre maximal de connexions serveur qu'un pooler dans le pool 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 cas de charge maximale, 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 serveur par processeur pour le regroupement de connexions géré lorsque vous définissez l'indicateur max_connections pour votre base de données. Pour en savoir plus sur l'option max_connections, consultez Connexions simultanées maximales. Pour modifier l'option max_connections pour votre instance, consultez Configurer des options de base de données.

Étapes suivantes