Présentation du pool de connexions géré

La mise en pool des connexions gérées 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 utilisation de la mémoire et une surcharge 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, ce surcoût 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 évolutives, en absorbant les pics de connexion soudains et en réutilisant les connexions de base de données existantes.

Regroupements 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 plutôt que 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 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 en tant que groupe de connexions de serveur de base de données réutilisables ouvertes par paire de base de données et d'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 regroupement 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 est atteinte, le client passe à l'état d'attente jusqu'à ce qu'une connexion au serveur soit 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 seul outil de regroupement 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 cet outil.

Si votre instance exécute plusieurs poolers de connexions, chacun d'eux gère indépendamment son propre ensemble de pools de connexions pour les paires de bases de données et d'utilisateurs qui lui sont acheminé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 évolue automatiquement 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 devient pas un goulot d'étranglement. Les connexions client entrantes sont réparties entre les poolers de connexions disponibles. Exemple :

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

  • Mise à l'échelle du pooler et du pool : comme les poolers de connexion fonctionnent indépendamment, toutes les options de configuration sont appliquées par pooler de connexion plutôt que de manière globale sur 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 regroupements de connexions (8 processeurs virtuels), chaque regroupement de connexions peut ouvrir jusqu'à 50 connexions au serveur pour une paire base de données/utilisateur spécifique, ce qui permet d'établir jusqu'à 100 connexions au serveur sur l'instance pour ce pool. Il est essentiel de dimensionner correctement le pool pour garantir les performances : une valeur trop faible peut entraîner des temps d'attente de connexion 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 pooler de connexions. Voici les 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 considérations

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

  • Bien que vous puissiez utiliser le pool de connexions géré pour toutes les charges de travail transactionnelles, il offre les meilleurs avantages en termes de débit et de latence aux applications qui contiennent des connexions de courte durée ou aux applications qui entraînent une augmentation du nombre de connexions.
  • Pour les connexions de longue durée, les performances de connexion avec le 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 faire évoluer les connexions lorsque leur nombre 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 regroupement 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 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 pooling 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 à l'aide d'une connexion directe ou du proxy d'authentification Cloud SQL uniquement.
  • Votre instance doit être configurée pour l'accès aux services privés, utiliser une adresse IP publique ou avoir activé Private Service Connect.
  • 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 une maintenance en libre-service.

Options de pooling

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 pooling 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 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 conserve un état de session. Cela réduit l'efficacité de la mise en commun. Lorsqu'un client se déconnecte, la connexion au serveur est renvoyée au pool de connexions.

Options de configuration avancées

Vous pouvez personnaliser la mise en pool de connexions gérées à 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 connexions. Déterminez cette valeur en fonction de la taille de votre instance et de la taille de votre pool.

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

Si le nombre de connexions au serveur est inférieur à la valeur de 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 à être utilisées.

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 de votre pool.

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

Définir cette option sur 0 désactive la compatibilité avec les instructions préparées. Pour des performances optimales, cette valeur doit dépasser le 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 instructions.
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 une mise en file d'attente indéfinie des clients. 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 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 reste 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 pooling de connexions géré avec vos instances Cloud SQL Enterprise Plus, tenez compte des limites suivantes :

  • L'activation du regroupement 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 ou ultérieure.
  • Si vous utilisez le connecteur de langage Cloud SQL Go, nous vous recommandons d'utiliser au minimum la version 1.24 de Go. Si vous utilisez Go version 1.23 ou une version antérieure, vous risquez de rencontrer des limites de performances lorsque vous utilisez la mise en pool de connexions gérée.

  • 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
    • PRESERVE/DELETE ROW table temporaire
    • LOAD
    • Verrous de conseil au niveau de la session

  • Si vous utilisez la bibliothèque d'interface de base de données asyncpg pour le pooler de regroupement de connexions géré sur les ports 3307 et 6432, vous devez définir max_prepared_statements sur une valeur supérieure à 0 pour activer la compatibilité avec les instructions préparées dans le pooler de regroupement de connexions géré.

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

  • Le suivi des adresses IP clientes n'est pas compatible avec le pooling de connexions géré. Si vous activez l'option Stocker les adresses IP client dans 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 regroupement 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 :

  • Port TCP 5432 : utilisé pour les connexions directes par le serveur de base de données Postgres. Il s'agit du numéro de port par défaut pour la connexion directe à l'aide du client psql.

  • Port TCP 6432 : utilisé pour les connexions directes par le serveur de pooling de connexions géré. Pour vous connecter à l'aide de ce port, spécifiez psql -p 6432 lorsque vous vous connectez directement à l'aide du client psql.

    Vous pouvez utiliser n'importe quelle option d'authentification IAM avec ce port.

  • Port TCP 3307 : utilisé pour les connexions du proxy d'authentification Cloud SQL uniquement par un serveur de pooling de connexions géré. Lorsque vous utilisez le proxy d'authentification Cloud SQL pour vous connecter au pooling de connexions géré, ce numéro de port est configuré avec le client du proxy d'authentification Cloud SQL et ne peut pas être modifié.

    Vous pouvez utiliser n'importe quelle option d'authentification IAM ou l'authentification IAM automatique pour les bases de données avec ce port.

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 au serveur qu'un pooler peut utiliser dans le regroupement de connexions géré. 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 pic de charge, le nombre de connexions pour l'authentification peut devenir très élevé.

Si vous utilisez la valeur max_pool_size par défaut 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 Nombre maximal de connexions simultanées. Pour modifier l'indicateur de base de données max_connections de votre instance, consultez Configurer des indicateurs de base de données.

Étapes suivantes