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

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Conseils stratégiques pour choisir le mécanisme de regroupement de connexions du serveur flexible Azure Database pour PostgreSQL.

Introduction

Lors de l’utilisation du serveur flexible Azure Database pour PostgreSQL, l’établissement d’une connexion avec la base de données implique la création d’un canal de communication entre l’application cliente et le serveur. Ce canal est responsable de la gestion des données, de l’exécution des requêtes et de l’initialisation des transactions. Une fois la connexion établie, 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 qu’une connexion est créée, le serveur flexible Azure Database pour PostgreSQL génère un nouveau processus à l’aide du processus d’administrateur, ce qui consomme plus de ressources.

Pour atténuer ce problème, le regroupement de connexions est utilisé pour créer un cache de connexions pouvant être réutilisées dans le serveur flexible Azure Database pour PostgreSQL. Lorsqu’une application ou un client demande une connexion, celle-ci est créée à partir du pool de connexions. Une fois la session ou la transaction terminée, la connexion est retournée au pool pour réutilisation. Réutiliser les connexions permet de réduire l’utilisation des ressources et d’améliorer les performances.

Bien qu’il existe différents outils pour le regroupement de connexions, cette section porte sur les différentes stratégies d’utilisation du regroupement de connexions avec PgBouncer.

Qu’est-ce que PgBouncer ?

PgBouncer est un outil de regroupement de connexions efficace conçu pour PostgreSQL. Il offre l’avantage de réduire les temps de traitement et d’optimiser l’utilisation des ressources dans la gestion de plusieurs connexions clientes à une ou plusieurs bases de données. PgBouncer intègre 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. En cas de déconnexion de l’application cliente, PgBouncer retourne rapidement la connexion serveur au pool. Le mécanisme de regroupement de sessions est le mode par défaut dans PgBouncer open source. Consultez Configuration de 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 intelligemment la connexion au serveur, ce qui la rend à nouveau disponible dans le pool. Le regroupement de transactions est le mode par défaut dans le PgBouncer intégré au serveur flexible Azure Database pour PostgreSQL. Il 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 au serveur est rapidement retournée au pool de connexions. Il convient de noter que les transactions multi-instructions ne sont pas prises en charge dans ce mode.

L’utilisation efficace de PgBouncer se décompose en trois modèles d’utilisation distincts.

• Déploiement de PgBouncer et de la colocalisation d’applications
• Déploiement centralisé et indépendant de l’application de PgBouncer
• Déploiement intégré de PgBouncer et de la base de données

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

1. Déploiement de PgBouncer et de la colocalisation d’applications

Lorsque vous utilisez cette approche, PgBouncer est déployé sur le serveur où votre application est hébergée. L’application et PgBouncer peuvent être déployés sur des machines virtuelles traditionnelles ou dans une architecture basée sur des microservices, tel qu’indiqué ici :

I. Déploiement de PgBouncer 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 le serveur flexible Azure Database pour PostgreSQL, suivez les instructions fournies dans le lien suivant.

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. Les principaux avantages et les principales limites de cette méthode de déploiement comprennent :

Avantages :

• Latence réduite : déployer PgBouncer sur la même machine virtuelle d’application permet d’instaurer une communication efficace entre l’application principale et l’outil de regroupement de connexions du fait de leur proximité. Le déploiement de PgBouncer dans une machine virtuelle d’application réduit la latence et garantit des interactions fluides 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 PgBouncer est déployé en tant qu’instance unique sur le serveur d’applications, il constitue 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, vous pouvez configurer plusieurs instances PgBouncer derrière un équilibreur de charge à des fins de 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 la limite de connexion, PgBouncer peut constituer un goulot d’étranglement, limitant ainsi la possibilité de mettre l’application à l’échelle. Vous devrez peut-être répartir la charge de connexion entre plusieurs instances PgBouncer ou envisager d’autres solutions, comme 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.

Il convient de soupeser ces limitations au regard des avantages et de déterminer si PgBouncer est un choix adapté à votre configuration d’application et de base de données spécifique.

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

Vous pouvez utiliser PgBouncer en tant que conteneur side-car si votre application est conteneurisée et s’exécute sur Azure Kubernetes Service (AKS),Azure Container Instance (ACI),Azure Container Apps (ACA) ou Azure Red Hat OpenShift (ARO). Le modèle side-car s’inspire du concept du side-car traditionnel (sur un motocycle) : un conteneur auxiliaire, appelé conteneur side-car, 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 modèle side-car est généralement utilisé avec des conteneurs planifiés en tant que groupe de conteneurs atomiques. Le déploiement de PgBouncer dans un side-car AKS couple étroitement les cycles de vie de l’application et du side-car. Il partage des ressources telles que le nom d’hôte et la mise en réseau pour utiliser efficacement les ressources. Le side-car PgBouncer fonctionne avec le conteneur d’applications au sein du même pod dans Azure Kubernetes Service (AKS) avec un mappage 1:1. Il agit en tant que proxy de regroupement de connexions pour le serveur flexible Azure Database pour PostgreSQL.

Le modèle side-car est généralement utilisé avec des conteneurs planifiés en tant que groupe de conteneurs atomiques. Le modèle sidecar lie étroitement les cycles de vie de l’application et du side-car. Il partage des ressources telles que le nom d’hôte et la mise en réseau. Grâce à cette configuration, PgBouncer optimise la gestion des connexions et instaure une communication efficace entre l’application et l’instance de serveur flexible Azure Database pour PostgreSQL.

Microsoft a publié une image de proxy side-car PgBouncer dans le registre de conteneurs Microsoft.

Pour plus d’informations, consultez cette page.

Les principaux avantages et les principales limites de cette méthode de déploiement comprennent :

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 garantit une administration et une coordination fluides.
• Haute disponibilité et résilience de connexion : en cas d’échec ou de redémarrage d’un conteneur d’applications, le conteneur side-car PgBouncer assure un suivi minutieux, garantissant ainsi la 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 performances de connexion : les applications à grande échelle qui utilisent des milliers de pods (chacun exécutant un side-car PgBouncer) peuvent rencontrer des problèmes liés à l’épuisement des connexions de 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 des difficultés à gérer le volume élevé de connexions entrantes. Cela peut entraîner des problèmes de performances, tels qu’une augmentation des temps de réponse, voire des interruptions 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. Cela peut compliquer les activités de résolution des problèmes et de débogage, et nécessiter des efforts supplémentaires pour identifier et résoudre les problèmes.
• Défis de mise à l’échelle : il convient de noter qu’un modèle side-car ne constitue pas forcément un choix idéal pour les applications qui exigent une scalabilité élevée. L’inclusion d’un conteneur side-car peut exiger un nombre supérieur de ressources, et potentiellement limiter le nombre de pods pouvant être créés et gérés efficacement.

Lorsque vous envisagez d’utiliser un modèle side-car, vous devez évaluer avec soins les compromis entre la complexité du déploiement et les exigences de scalabilité afin de déterminer l’approche la plus adaptée à votre scénario d’application.

2. Déploiement centralisé et indépendant de l’application de PgBouncer

Lorsque vous utilisez cette approche, PgBouncer est déployé en tant que service centralisé, indépendamment de l’application. Le service PgBouncer peut être déployé sur des machines virtuelles traditionnelles ou dans une architecture basée sur des microservices, comme indiqué :

I. Déploiement de PgBouncer sur une machine virtuelle Ubuntu derrière Azure Load Balancer

Le proxy de connexion PgBouncer est configuré entre l’application et la couche de base de données derrière un Azure Load Balancer, comme illustré dans l’image. Dans ce modèle, plusieurs instances PgBouncer sont déployées derrière un équilibreur de charge en tant que service permettant d’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.

Consultez le lien d’installation et de configuration du proxy de regroupement de connexions PgBouncer pour le serveur flexible Azure Database pour PostgreSQL.

Les principaux avantages et les principales limites de cette méthode de déploiement comprennent :

Avantages :

• Suppression d’un point de défaillance unique : la connectivité des applications peut ne pas être affectée par l’échec d’une seule machine virtuelle PgBouncer. En effet, il existe plusieurs instances PgBouncer 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 sur une machine virtuelle garantit que PgBouncer est déployé à proximité de l’application. Cela réduit la latence du réseau et optimise les performances.
• Configuration non intrusive : le déploiement de PgBouncer sur une machine virtuelle vous permet de ne pas avoir à modifier les paramètres de serveur sur le serveur flexible Azure Database pour PostgreSQL. C’est utile lorsque vous souhaitez configurer PgBouncer sur une instance de serveur flexible Azure Database pour PostgreSQL. Par exemple, le basculement du paramètre SSLMODE sur « obligatoire » dans le serveur flexible Azure Database pour PostgreSQL peut entraîner l’échec de certaines applications qui dépendent de 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 :PgBouncer étant installé sur une machine virtuelle, vous pouvez rencontrer une surcharge de gestion lorsque vous administrez plusieurs fichiers de configuration. Vous pouvez avoir des difficultés à gérer les mises à niveau de version, les nouvelles versions et les mises à jour produit.
• Parité des fonctionnalités : si vous migrez à partir d’un système PostgreSQL traditionnel vers le serveur flexible Azure Database pour PostgreSQL et que vous utilisez PgBouncer, il peut y avoir certains écarts dans les fonctionnalités. Par exemple, un manque de prise en charge de md5 pour le serveur flexible Azure Database pour PostgreSQL.

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

Si vous utilisez des déploiements conteneurisés de grande taille et hautement évolutifs sur Azure Kubernetes Service (AKS) qui sont composés de centaines de pods, ou lorsque plusieurs applications doivent se connecter à une base de données partagée, vous pouvez utiliser PgBouncer comme service autonome plutôt que comme conteneur side-car.

Utiliser PgBouncer comme un service distinct vous permet de gérer efficacement le regroupement de connexions pour vos applications à plus grande échelle. Cette approche permet de centraliser la fonctionnalité de regroupement de connexions. Cela permet à plusieurs applications de se connecter à la même ressource de base de données tout en conservant des performances et une utilisation optimales des ressources.

L’image de proxy side-car PgBouncer publiée dans le registre de conteneurs Microsoft peut être utilisée pour créer et déployer un service.

Les principaux avantages et les principales limites de cette méthode de déploiement comprennent :

Avantages :

• Fiabilité améliorée : le déploiement de PgBouncer en tant que service autonome permet une configuration hautement disponible. Cela améliore la fiabilité globale de l’infrastructure de regroupement de connexions et garantit une disponibilité continue, même en cas de défaillance ou d’interruption.
• Utilisation optimale des ressources : si votre application ou le serveur de base de données dispose de ressources limitées, il peut être avantageux d’opter pour une machine distincte dédiée à l’exécution du service PgBouncer. Déployer PgBouncer sur une machine disposant de ressources suffisantes vous permet de garantir des performances optimales et d’éviter les problèmes de contention de 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 un 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 réseau accrue : lors vous déployez PgBouncer en tant que service autonome, il convient de tenir compte de l’introduction potentielle d’une plus grande latence. Cela est dû à la nécessité de passer des connexions entre l’application et le service PgBouncer sur le réseau. Il est essentiel d’évaluer les exigences de latence de votre application et de tenir compte des compromis entre la gestion centralisée des connexions et les problèmes de latence potentiels.

Bien que PgBouncer en tant que service autonome offre certains avantages (comme la gestion centralisée et l’optimisation des ressources), il convient d’évaluer l’impact d’une telle latence sur les performances de votre application pour vous assurer qu’elle répond à vos besoins spécifiques.

3. PgBouncer intégré dans le serveur flexible Azure Database pour PostgreSQL

Azure Database pour PostgreSQL – Serveur flexible offre PgBouncer comme solution de regroupement de connexions intégrée. Il s’agit d’un service facultatif qui peut être activé par serveur de base de données. PgBouncer s’exécute dans la même machine virtuelle que l’instance de serveur flexible Azure Database pour PostgreSQL. À mesure que le nombre de connexions dépasse plusieurs centaines (voire milliers), il se peut que le serveur flexible Azure Database pour PostgreSQL rencontre 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.

Consultez le lien pour activer et configurer le regroupement de connexions PgBouncer dans le serveur flexible Azure Database pour PostgreSQL.

Les principaux avantages et les principales limites de cette méthode de déploiement comprennent :

Avantages :

• Configuration homogène : grâce au PgBouncer intégré dans le serveur flexible Azure Database pour PostgreSQL, il n’est pas nécessaire d’effectuer une installation distincte ou une configuration complexe. Il peut être facilement configuré directement à partir des paramètres du serveur, ce qui garantit une expérience sans tracas.
• Avantages du service géré : grâce au service géré, les utilisateurs peuvent profiter des avantages d’autres services gérés Azure. Cela inclut les mises à jour automatiques, la fin des maintenances manuelles et la garantie que PgBouncer reste à jour avec les dernières fonctionnalités et les derniers correctifs de sécurité.
• Prise en charge de connexions privées et publiques : le PgBouncer intégré dans le serveur flexible Azure Database pour PostgreSQL prend en charge les connexions publiques et privées. Cette fonctionnalité permet aux utilisateurs d’établir des connexions sécurisées sur des réseaux privés ou de se connecter en externe, en fonction de leurs besoins précis.
• 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 capacité garantit une disponibilité continue et réduit les interruptions dans l’application.
• Économique : les utilisateurs n’ont pas besoin de payer un calcul supplémentaire comme une machine virtuelle ou des conteneurs. Il a cependant un certain impact sur le processeur, car il s’agit d’un autre processus qui s’exécute sur la même machine.

Grâce au PgBouncer intégré au serveur flexible Azure Database pour PostgreSQL, les utilisateurs peuvent profiter de la commodité d’une configuration simplifiée, de la fiabilité d’un service géré, de la prise en charge de différents modes de regroupement et d’une haute disponibilité homogène pendant les scénarios de basculement.

Limitations :

• Incompatibilité avec Burstable : PgBouncer n’est actuellement pas pris en charge avec le niveau de calcul de 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.
• Reconnexion après démarrage : à chaque redémarrage du serveur lors des opérations de mise à l’échelle, du basculement haute disponibilité ou du redémarrage, PgBouncer est également redémarré avec la machine virtuelle du serveur. Par conséquent, les connexions existantes doivent être rétablies.

Nous venons d’aborder les différentes façons d’implémenter PgBouncer. Ce tableau revient sur le choix de la méthode de déploiement :

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	PgBouncer intégré dans le serveur flexible Azure Database pour PostgreSQL
Gestion simplifiée
HA
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
Facile
Moyenne
Difficile

* ALB : Azure Load Balancer.