Stratégie de regroupement de connexions à l’aide de PgBouncer dans Azure Database pour PostgreSQL serveur flexible

Cet article fournit des conseils stratégiques pour sélectionner un mécanisme de regroupement de connexions pour vos serveurs flexibles Azure Database pour PostgreSQL.

Présentation

Lorsque vous utilisez un serveur flexible Azure Database pour PostgreSQL, vous créez une connexion à la base de données en établissant un canal de communication entre l’application cliente et le serveur. Ce canal gère les données, exécute des requêtes et lance des transactions. Après avoir établi la connexion, l’application cliente peut envoyer des commandes au serveur et recevoir des réponses. Toutefois, la création d’une connexion pour chaque opération peut entraîner des problèmes de performances pour les applications stratégiques. Chaque fois que vous créez une connexion, Azure Database pour PostgreSQL démarre un nouveau processus à l’aide du processus postmaster, qui consomme plus de ressources.

Pour résoudre ce problème, utilisez le regroupement de connexions pour créer un cache de connexions que Azure Database pour PostgreSQL pouvez réutiliser. Lorsqu’une application ou un client demande une connexion, celle-ci est fournie par le pool de connexions. Une fois la session ou la transaction terminée, la connexion revient au pool à des fins de réutilisation. En réutilisant les connexions, vous réduisez l’utilisation des ressources et améliorez les performances.

Bien que différents outils existent pour le regroupement de connexions, cette section décrit différentes stratégies d’utilisation du regroupement de connexions à l’aide de PgBouncer.

Qu’est-ce que PgBouncer ?

PgBouncer est un pool de connexions efficace conçu pour PostgreSQL. Il réduit le temps de traitement et optimise l’utilisation des ressources lors de la gestion de plusieurs connexions clientes à une ou plusieurs bases de données. PgBouncer offre trois modes de regroupement distincts pour la rotation des connexions :

• Regroupement de sessions : cette méthode attribue une connexion serveur à l’application cliente pendant toute la durée de la connexion du client. Lorsque l’application cliente se déconnecte, PgBouncer retourne rapidement la connexion du serveur au pool. Le regroupement de sessions est le mode par défaut dans open source PgBouncer. Pour plus d’informations, consultez configuration pgBouncer.
• Regroupement de transactions : avec le regroupement de transactions, une connexion serveur est dédiée à l’application cliente pendant une transaction. Une fois la transaction terminée, PgBouncer libère la connexion du serveur, la rendant disponible à nouveau dans le pool. Le regroupement de transactions est le mode par défaut dans le pgBouncer intégré de Azure Database pour PostgreSQL et ne prend pas en charge les transactions préparées.
• Regroupement d’instructions : avec le regroupement d’instructions, une connexion serveur est allouée à l’application cliente pour chaque instruction individuelle. Une fois l’instruction terminée, la connexion du serveur est retournée au pool de connexions. Les transactions à plusieurs instructions ne sont pas prises en charge dans ce mode.

Vous pouvez utiliser PgBouncer dans trois modèles d’utilisation distincts :

• Déploiement avec cohabitation de PgBouncer et de l’application
• Déploiement centralisé et indépendant de l’application de PgBouncer
• Déploiement intégré de pgBouncer et de base de données

Chacun de ces modèles présente ses propres avantages et inconvénients.

Déploiement en colocation de PgBouncer et de l’application

Lorsque vous utilisez cette approche, vous déployez PgBouncer sur le même serveur que celui sur lequel votre application est hébergée. Vous pouvez déployer l’application et PgBouncer sur des machines virtuelles traditionnelles ou dans une architecture basée sur des microservices, comme indiqué ci-dessus :

PgBouncer déployé dans une machine virtuelle d’application

Si votre application s’exécute sur une machine virtuelle Azure, vous pouvez configurer PgBouncer sur la même machine virtuelle. Pour installer et configurer PgBouncer en tant que proxy de regroupement de connexions avec votre serveur flexible Azure Database pour PostgreSQL, consultez Étapes d’installation et de configuration du proxy de regroupement de connexions PgBouncer.

Le déploiement de PgBouncer sur un serveur d’applications peut offrir plusieurs avantages, surtout lorsque vous travaillez avec des bases de données de serveur flexible Azure Database pour PostgreSQL. Voici quelques-uns des principaux avantages et limitations de cette méthode de déploiement :

Avantages :

• Latence réduite : En déployant PgBouncer sur la même machine virtuelle d’application, la communication entre l’application principale et le pool de connexions est efficace en raison de leur proximité. Le déploiement de PgBouncer dans une machine virtuelle d’application réduit la latence et garantit des interactions lisses et rapides.
• Sécurité améliorée :PgBouncer peut servir d’intermédiaire sécurisé entre l’application et la base de données, offrant ainsi une couche de sécurité supplémentaire. Il peut appliquer l’authentification et le chiffrement, ce qui garantit que seuls les clients autorisés peuvent accéder à la base de données.

Dans l’ensemble, le déploiement de PgBouncer dans un serveur d’applications propose une approche plus efficace, plus sécurisée et plus évolutive de la gestion des connexions aux bases de données de serveur flexible Azure Database pour PostgreSQL. Cela permet d’améliorer les performances et la fiabilité de l’application.

Limitations :

• Point de défaillance unique : Si vous déployez PgBouncer en tant qu’instance unique sur le serveur d’applications, il devient un point de défaillance unique potentiel. En cas de panne de l’instance PgBouncer, l’ensemble du pool de connexions de base de données peut être perturbé et entraîner un temps d’arrêt de l’application. Pour atténuer ce point de défaillance unique, configurez plusieurs instances PgBouncer derrière un équilibreur de charge pour la haute disponibilité.
• Scalabilité limitée : la scalabilité de PgBouncer dépend de la capacité du serveur sur lequel il est déployé. Si le serveur d’applications atteint sa limite de connexion, PgBouncer peut devenir un goulot d’étranglement, ce qui limite la possibilité de mettre à l’échelle l’application. Vous devrez peut-être distribuer la charge de connexion sur plusieurs instances PgBouncer ou envisager d’autres solutions telles que le regroupement de connexions au niveau de l’application.
• Complexité de la configuration : la configuration et l’optimisation de PgBouncer peuvent être complexes, en particulier concernant certains facteurs, tels que les limites de connexion, le dimensionnement du pool et l’équilibrage de charge. Les administrateurs doivent minutieusement ajuster la configuration de PgBouncer pour répondre aux exigences de l’application et garantir des performances et une stabilité optimales.

Pesez ces limitations sur les avantages et évaluez si PgBouncer est le bon choix pour votre application et votre configuration de base de données spécifiques.

Déploiement de PgBouncer en tant que side-car AKS

Vous pouvez utiliser PgBouncer comme conteneur side-car si votre application est conteneurisée et exécutée sur Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) ou Azure Red Hat OpenShift (ARO). Le modèle side-car tire son inspiration du concept d’un side-car qui s’attache à une moto. Un conteneur auxiliaire, appelé conteneur sidecar, est attaché à une application parente. Ce modèle enrichit l’application parente en étendant ses fonctionnalités et en fournissant un support supplémentaire.

Le déploiement de PgBouncer dans un side-car AKS couple étroitement les cycles de vie de l’application et du sidecar et partage des ressources telles que le nom d’hôte et la mise en réseau pour utiliser efficacement les ressources. Le sidecar PgBouncer s’exécute aux côtés du conteneur d’application au sein du même pod dans Azure Kubernetes Service (AKS), selon un mappage 1:1, et sert de proxy de pooling de connexions pour les serveurs flexibles Azure Database pour PostgreSQL.

Microsoft publie une image de proxy sidecar PgBouncer dans le registre de conteneurs Microsoft.

Pour plus d’informations, consultez cette page.

Voici quelques-uns des principaux avantages et limitations de cette méthode de déploiement :

Avantages :

• Latence réduite : déployer PgBouncer en tant que side-car AKS permet d’instaurer une communication fluide et efficace entre l’application principale et l’outil de regroupement de connexions du fait de leur proximité. Le déploiement de PgBouncer en tant que side-car AKS réduit la latence et garantit des interactions fluides et rapides.
• Gestion et déploiement simplifiés : coupler étroitement PgBouncer avec le conteneur d’applications permet de simplifier le processus de gestion et de déploiement. Les deux composants sont étroitement intégrés, ce qui vous permet de les administrer plus facilement et de les coordonner en toute transparence.
• Haute disponibilité et résilience des connexions : Si un conteneur d’applications échoue ou redémarre, le conteneur sidecar PgBouncer suit de près, garantissant une haute disponibilité. Cette configuration assure la résilience des connexions et maintient des performances prévisibles même pendant les basculements, ce qui contribue à un système fiable et robuste.

Considérer PgBouncer comme un side-car AKS vous permet d’exploiter ces avantages pour améliorer les performances de votre application, simplifier la gestion et garantir la disponibilité continue de l’outil de regroupement de connexions.

Limitations :

• Problèmes de performance des connexions : Les applications à grande échelle qui utilisent des milliers de pods, avec un sidecar PgBouncer exécuté dans chacun d’eux, peuvent rencontrer des difficultés liées à l’épuisement des connexions à la base de données. Cette situation peut entraîner une dégradation des performances et des interruptions de service. Le déploiement d’un PgBouncer side-car pour chaque pod augmente le nombre de connexions simultanées au serveur de base de données, qui peuvent dépasser sa capacité. Par conséquent, la base de données peut avoir du mal à gérer le volume élevé de connexions entrantes, ce qui entraîne des problèmes de performances tels que des temps de réponse accrus ou même des pannes de service.
• Déploiement complexe : l’utilisation d’un modèle side-car renforce la complexité du processus de déploiement, car elle implique d’exécuter deux conteneurs dans le même pod. Cette complexité peut compliquer la résolution des problèmes et les activités de débogage, ce qui nécessite un effort supplémentaire pour identifier et résoudre les problèmes.
• Défis de mise à l’échelle : Le modèle side-car peut ne pas être le choix idéal pour les applications qui demandent une scalabilité élevée. L’inclusion d’un conteneur sidecar peut imposer davantage d’exigences en ressources, ce qui peut limiter le nombre de pods que vous pouvez créer et gérer efficacement.

Tout en tenant compte de ce modèle side-car, évaluez soigneusement les compromis entre la complexité du déploiement et les exigences de scalabilité afin de déterminer l’approche la plus appropriée pour votre scénario d’application spécifique.

Indépendant des applications - déploiement centralisé de PgBouncer

Lorsque vous utilisez cette approche, vous déployez PgBouncer en tant que service centralisé indépendant de l’application. Vous pouvez déployer le service PgBouncer sur des machines virtuelles traditionnelles ou dans une architecture basée sur des microservices, comme indiqué dans les sections suivantes :

PgBouncer déployé dans une machine virtuelle Ubuntu derrière Azure Load Balancer

Configurez le proxy de connexion PgBouncer entre l’application et la couche de base de données derrière un Azure Load Balancer, comme illustré dans l’image suivante. Dans ce modèle, vous déployez plusieurs instances PgBouncer derrière un équilibreur de charge en tant que service pour atténuer un point de défaillance unique. Ce modèle convient également aux scénarios dans lesquels l’application s’exécute sur un service managé (comme Azure App Services ou Azure Functions) et se connecte au service PgBouncer pour faciliter l’intégration à votre infrastructure existante.

Pour installer et configurer le proxy de regroupement de connexions PgBouncer avec Azure Database pour PostgreSQL serveurs flexibles, consultez Étapes d’installation et de configuration du proxy de regroupement de connexions PgBouncer.

Voici quelques-uns des principaux avantages et limitations de cette méthode de déploiement :

Avantages :

• Suppression d’un point de défaillance unique : La connectivité des applications n'est pas affectée par l'échec d'une seule machine virtuelle PgBouncer, car plusieurs instances PgBouncer se trouvent derrière Azure Load Balancer.
• Intégration transparente aux services gérés : si l’application est hébergée sur une plateforme de service géré (comme Azure App Services ou Azure Functions), le déploiement de PgBouncer sur une machine virtuelle permet une intégration facile à l’infrastructure existante.
• Installation simplifiée sur une machine virtuelle Azure : si vous exécutez déjà l’application sur une machine virtuelle Azure, la configuration de PgBouncer sur la même machine virtuelle est simple. Le déploiement de PgBouncer dans une machine virtuelle garantit que PgBouncer est déployé à proximité de votre application, ce qui réduit la latence du réseau et optimise les performances.
• Configuration non intrusive : En déployant PgBouncer sur une machine virtuelle, vous pouvez éviter de modifier des paramètres sur votre serveur flexible Azure Database pour PostgreSQL. Cette configuration est utile lorsque vous souhaitez configurer PgBouncer sur un serveur flexible Azure Database pour PostgreSQL. Par exemple, la modification du paramètre SSLMODE sur « obligatoire » sur un serveur flexible Azure Database pour PostgreSQL peut entraîner l’échec de certaines applications qui s’appuient sur SSLMODE=FALSE. Le déploiement de PgBouncer sur une machine virtuelle distincte vous permet de conserver la configuration du serveur par défaut tout en profitant des avantages de PgBouncer.

Au vu de ces avantages, le déploiement de PgBouncer sur une machine virtuelle offre une solution pratique et efficace pour améliorer les performances et la compatibilité d’une application exécutée sur l’infrastructure Azure.

Limitations :

• Surcharge de gestion : Lorsque vous installez PgBouncer dans une machine virtuelle, vous pouvez avoir une surcharge de gestion pour gérer plusieurs fichiers de configuration. Cette configuration rend difficile la gestion des mises à niveau de version, des nouvelles versions et des mises à jour de produit.
• Parité des fonctionnalités : Si vous migrez de PostgreSQL traditionnel vers un serveur flexible Azure Database pour PostgreSQL et que vous utilisez PgBouncer, certaines lacunes de fonctionnalités peuvent exister. Par exemple, l’absence de prise en charge de MD5 dans Azure Database pour PostgreSQL.

Déploiement centralisé de PgBouncer en tant que service dans AKS

Si vous travaillez avec des déploiements en conteneur hautement évolutifs et volumineux sur Azure Kubernetes Service (AKS), composés de centaines de pods ou dans des situations où plusieurs applications doivent se connecter à une base de données partagée, utilisez PgBouncer comme service autonome plutôt qu'un conteneur side-car.

En utilisant PgBouncer en tant que service distinct, vous pouvez gérer et gérer efficacement le regroupement de connexions pour vos applications à grande échelle. Cette approche centralise la fonctionnalité de regroupement de connexions, ce qui permet à plusieurs applications de se connecter à la même ressource de base de données tout en conservant des performances optimales et une utilisation optimale des ressources.

Utilisez l’image de proxy sidecar PgBouncer publiée dans le registre de conteneurs Microsoft pour créer et déployer un service.

Voici quelques-uns des principaux avantages et limitations de cette méthode de déploiement :

Avantages :

• Fiabilité améliorée : Le déploiement de PgBouncer en tant que service autonome vous permet de le configurer de manière hautement disponible. Cette configuration améliore la fiabilité globale de l’infrastructure de regroupement de connexions, ce qui garantit une disponibilité continue même en cas de défaillances ou d’interruptions.
• Utilisation optimale des ressources : Si votre application ou le serveur de base de données dispose de ressources limitées, un ordinateur distinct dédié à l’exécution du service PgBouncer peut être avantageux. En déployant PgBouncer sur une machine avec de nombreuses ressources, vous garantissez des performances optimales et empêchez les problèmes de contention des ressources.
• Gestion centralisée des connexions : lorsque la gestion centralisée des connexions aux bases de données est obligatoire, l’utilisation d’un service PgBouncer autonome offre une approche plus rationalisée. Regrouper les tâches de gestion des connexions dans un service centralisé vous permet de surveiller et de contrôler efficacement les connexions aux bases de données sur plusieurs applications. Cela simplifie l’administration et garantit la cohérence.

Choisir d’utiliser PgBouncer comme service autonome dans AKS vous permet d’exploiter ces avantages pour améliorer la fiabilité, l’efficacité des ressources et la gestion centralisée des connexions aux bases de données.

Limitations :

• Latence N/W accrue : Lors du déploiement de PgBouncer en tant que service autonome, envisagez l’introduction potentielle d’une plus grande latence. Cette latence se produit, car l’application et le service PgBouncer doivent passer des connexions sur le réseau. Évaluez les exigences de latence de votre application et prenez en compte les compromis entre la gestion centralisée des connexions et les problèmes de latence potentiels.

Bien que PgBouncer s’exécutant en tant que service autonome offre des avantages tels que la gestion centralisée et l’optimisation des ressources, évaluez l’impact de la latence potentielle sur les performances de votre application pour vous assurer qu’elle s’aligne sur vos exigences spécifiques.

PgBouncer intégré dans Azure Database pour PostgreSQL

Azure Database pour PostgreSQL offre PgBouncer comme solution de regroupement de connexions intégrée. Vous pouvez activer ce service facultatif par serveur de base de données. PgBouncer s’exécute sur la même machine virtuelle que le serveur flexible Azure Database pour PostgreSQL. À mesure que le nombre de connexions augmente au-delà de quelques centaines ou milliers, Azure Database pour PostgreSQL peut rencontrer des limitations de ressources. Dans ce cas, le déploiement intégré de PgBouncer peut fournir un avantage significatif, car il améliore la gestion des connexions inactives et de courte durée sur le serveur de base de données.

Pour savoir comment activer et configurer le regroupement de connexions PgBouncer dans Azure Database pour PostgreSQL, consultez PgBouncer dans Azure Database pour PostgreSQL serveur flexible.

Voici quelques-uns des principaux avantages et limitations de cette méthode de déploiement :

Avantages :

• Configuration transparente : En utilisant le PgBouncer intégré dans votre serveur flexible Azure Database pour PostgreSQL, vous n'avez pas besoin d'une installation distincte ou d'une configuration complexe. Vous pouvez facilement le configurer directement à partir des paramètres, ce qui garantit une expérience sans soucis.
• Commodité du service géré : En tant que service géré, vous pouvez profiter des avantages d’autres services gérés Azure. Cet avantage inclut les mises à jour automatiques, éliminant la nécessité d’une maintenance manuelle et garantissant que PgBouncer reste à jour avec les dernières fonctionnalités et correctifs de sécurité.
• Prise en charge des connexions publiques et privées : Le pgBouncer intégré dans votre serveur flexible Azure Database pour PostgreSQL fournit la prise en charge des connexions publiques et privées. Cette prise en charge vous permet d’établir des connexions sécurisées sur des réseaux privés ou de se connecter en externe, en fonction de vos besoins spécifiques.
• Haute disponibilité (HA) : en cas de basculement (lorsqu’un serveur de secours est promu au rôle principal), PgBouncer redémarre en toute fluidité sur le serveur de secours qui vient d’être promu, sans avoir à modifier la chaîne de connexion de l’application. Cette fonctionnalité garantit la disponibilité continue et réduit la perturbation de l’application.
• Économique : Il est économique, car vous n’avez pas besoin de payer pour un calcul supplémentaire comme la machine virtuelle ou les conteneurs, bien qu’il ait un impact sur le processeur, car il s’agit d’un autre processus s’exécutant sur la même machine.

En utilisant le PgBouncer intégré dans un serveur flexible Azure Database pour PostgreSQL, vous pouvez profiter de la commodité de la configuration simplifiée, de la fiabilité d’un service managé, de la prise en charge des différents modes de regroupement et de la haute disponibilité transparente pendant les scénarios de basculement.

Limitations :

• Non pris en charge avec Burstable :PgBouncer n’est actuellement pas pris en charge avec le niveau de calcul du serveur Burstable. Si vous remplacez le niveau de calcul « Usage général » ou « Mémoire optimisée » par « Burstable », vous perdez la capacité PgBouncer.
• Rétablissez les connexions après redémarrage : Chaque fois que le serveur redémarre pendant les opérations de mise à l’échelle, le basculement haute disponibilité ou un redémarrage, le pgBouncer redémarre avec la machine virtuelle du serveur. Par conséquent, les connexions existantes doivent être rétablies.

Cet article décrit différentes façons d’implémenter PgBouncer. Le tableau suivant résume la méthode de déploiement à choisir :

Critères de sélection	PgBouncer sur une machine virtuelle d’application	PgBouncer sur une machine virtuelle avec ALB*	PgBouncer sur un side-car AKS	PgBouncer en tant que service	Azure Database pour PostgreSQL avec PgBouncer intégré
Gestion simplifiée
Haute disponibilité
Applications conteneurisées
Charge et latence de réseau réduites
Contrôle granulaire précis pour la surveillance et le débogage

Légende

Niveau de difficulté	Symbole
Easy
Moyen
Difficile

* ALB : Azure Load Balancer.

Contenu connexe

• PgBouncer dans Azure Database pour PostgreSQL - Serveur flexible
• Bibliothèques de connexion