Estrategia de agrupación de conexiones mediante PgBouncer en el servidor flexible de Azure Database for PostgreSQL

En este artículo se proporcionan instrucciones estratégicas para seleccionar un mecanismo de agrupación de conexiones para los servidores flexibles de Azure Database for PostgreSQL.

Introducción

Cuando se usa un servidor flexible Azure Database for PostgreSQL, se crea una conexión a la base de datos estableciendo un canal de comunicación entre la aplicación cliente y el servidor. Este canal administra los datos, ejecuta consultas e inicia transacciones. Después de establecer la conexión, la aplicación cliente puede enviar comandos al servidor y recibir respuestas. Sin embargo, la creación de una nueva conexión para cada operación puede provocar problemas de rendimiento para aplicaciones críticas. Cada vez que se crea una nueva conexión, Azure Database for PostgreSQL inicia un nuevo proceso mediante el proceso de postmaster, que consume más recursos.

Para solucionar este problema, use la agrupación de conexiones para crear una memoria caché de conexiones que Azure Database for PostgreSQL puede reutilizar. Cuando una aplicación o cliente solicita una conexión, procede del grupo de conexiones. Una vez finalizada la sesión o la transacción, la conexión vuelve al grupo para su reutilización. Al reutilizar las conexiones, se reduce el uso de recursos y se mejora el rendimiento.

Aunque existen diferentes herramientas para la agrupación de conexiones, en esta sección se describen diferentes estrategias para usar la agrupación de conexiones mediante PgBouncer.

¿Qué es PgBouncer?

PgBouncer es un agrupador de conexiones eficaz diseñado para PostgreSQL. Reduce el tiempo de procesamiento y optimiza el uso de recursos al administrar varias conexiones de cliente a una o varias bases de datos. PgBouncer ofrece tres modos de agrupación distintos para la rotación de conexiones:

• Agrupación de sesiones: este método asigna una conexión de servidor a la aplicación cliente durante toda la duración de la conexión del cliente. Cuando la aplicación cliente se desconecta, PgBouncer devuelve inmediatamente la conexión del servidor al grupo. La agrupación de sesiones es el modo predeterminado en código abierto PgBouncer. Para obtener más información, consulte Configuración de PgBouncer.
• Agrupación de transacciones: con la agrupación de transacciones, una conexión de servidor se dedica a la aplicación cliente durante una transacción. Una vez completada correctamente la transacción, PgBouncer libera la conexión del servidor, lo que hace que esté disponible de nuevo en el grupo. El modo de agrupación de transacciones es el modo predeterminado del PgBouncer integrado de Azure Database for PostgreSQL y no admite transacciones preparadas.
• Agrupación de instrucciones: en la agrupación de instrucciones, se asigna una conexión de servidor a la aplicación cliente para cada instrucción individual. Una vez completada la instrucción, la conexión al servidor se devuelve al grupo de conexiones. Las transacciones de varias instrucciones no se admiten en este modo.

Puede usar PgBouncer en tres patrones de uso distintos:

• PgBouncer y la implementación de coubicación de aplicaciones
• Implementaciones centralizadas de PgBouncer independientes de la aplicación
• Implementación integrada de PgBouncer y base de datos

Cada uno de estos patrones tiene sus propias ventajas y desventajas.

PgBouncer y la implementación de coubicación de aplicaciones

Cuando se usa este enfoque, se implementa PgBouncer en el mismo servidor donde se hospeda la aplicación. Puede implementar la aplicación y PgBouncer en máquinas virtuales tradicionales o dentro de una arquitectura basada en microservicios, como se resalta:

PgBouncer implementado en la máquina virtual de la aplicación

Si la aplicación se ejecuta en una máquina virtual de Azure, puede configurar PgBouncer en la misma máquina virtual. Para instalar y configurar PgBouncer como proxy de agrupación de conexiones con el servidor flexible de Azure Database for PostgreSQL, consulte Pasos para instalar y configurar el proxy de agrupación de conexiones de PgBouncer.

La implementación de PgBouncer en un servidor de aplicaciones puede proporcionar varias ventajas, especialmente cuando se trabaja con bases de datos de servidor flexibles de Azure Database for PostgreSQL. Algunas de las principales ventajas y limitaciones de este método de implementación son:

Ventajas:

• Latencia reducida: Al implementar PgBouncer en la misma máquina virtual de la aplicación, la comunicación entre la aplicación principal y el agrupador de conexiones es eficaz debido a su proximidad. La implementación de PgBouncer en la máquina virtual de la aplicación minimiza la latencia y garantiza interacciones fluidas y rápidas.
• Seguridad mejorada:PgBouncer puede actuar como intermediario seguro entre la aplicación y la base de datos, lo que proporciona una capa adicional de seguridad. Puede aplicar la autenticación y el cifrado, lo que garantiza que solo los clientes autorizados puedan acceder a la base de datos.

En general, la implementación de PgBouncer en un servidor de aplicaciones proporciona un enfoque más eficaz, seguro y escalable para administrar conexiones a bases de datos de servidor flexible de Azure Database for PostgreSQL, lo que mejora el rendimiento y la confiabilidad de la aplicación.

Limitaciones:

• Único punto de error: Si implementa PgBouncer como una sola instancia en el servidor de aplicaciones, se convierte en un único punto de error potencial. Si la instancia de PgBouncer deja de funcionar, puede interrumpir todo el grupo de conexiones de base de datos, lo que provoca un tiempo de inactividad para la aplicación. Para mitigar este único punto de error, configure varias instancias de PgBouncer detrás de un equilibrador de carga para lograr una alta disponibilidad.
• Escalabilidad limitada: la escalabilidad de PgBouncer depende de la capacidad del servidor donde se implementa. Si el servidor de aplicaciones alcanza su límite de conexión, PgBouncer podría convertirse en un cuello de botella, lo que limita la capacidad de escalar la aplicación. Es posible que tenga que distribuir la carga de conexión entre varias instancias de PgBouncer o considerar soluciones alternativas como la agrupación de conexiones en el nivel de aplicación.
• Complejidad de la configuración: la configuración y la optimización de PgBouncer pueden ser complejas, especialmente cuando se tienen en cuenta factores como los límites de conexión, el ajuste de tamaño del grupo y el equilibrio de carga. Los administradores deben ajustar cuidadosamente la configuración de PgBouncer para que coincida con los requisitos de la aplicación y garantizar un rendimiento y estabilidad óptimos.

Pesa estas limitaciones con respecto a las ventajas y evalúe si PgBouncer es la opción adecuada para la configuración específica de la aplicación y la base de datos.

PgBouncer implementado como sidecar de AKS

Puede usar PgBouncer como contenedor sidecar si la aplicación está en contenedores y se ejecuta en Azure Kubernetes Service (AKS), Azure Container Instance (ACI),Azure Container Apps (ACA) o Red Hat OpenShift en Azure (ARO). El patrón sidecar se inspira en el concepto del sidecar acoplado a una motocicleta. Un contenedor auxiliar, conocido como contenedor sidecar, está asociado a una aplicación primaria. Este patrón enriquece la aplicación principal mediante la ampliación de sus funcionalidades y la entrega de soporte complementario.

La implementación de PgBouncer en un sidecar de AKS acopla estrechamente los ciclos de vida de la aplicación y del sidecar y comparte recursos como el nombre de host y la red para hacer un uso eficaz de los recursos. El sidecar de PgBouncer funciona junto con el contenedor de la aplicación dentro del mismo pod en Azure Kubernetes Service (AKS) con una correspondencia 1:1, y actúa como un proxy de agrupación de conexiones para los servidores flexibles de Azure Database for PostgreSQL.

Microsoft publica una imagen del proxy sidecar PgBouncer en el registro de contenedores de Microsoft.

Para más información, consulte esto.

Algunas de las principales ventajas y limitaciones de este método de implementación son:

Ventajas:

• Latencia reducida: al implementar PgBouncer como un sidecar de AKS, la comunicación entre la aplicación principal y el agrupador de conexiones es fluida y eficiente debido a su proximidad. La implementación de PgBouncer en un sidecar de AKS minimiza la latencia y garantiza interacciones fluidas y rápidas.
• Simplificación de la administración y la implementación: el estrecho acoplamiento de PgBouncer con el contenedor de la aplicación simplifica el proceso de administración e implementación. Ambos componentes están estrechamente integrados, por lo que puede administrarlos más fácilmente y coordinarlos sin problemas.
• Alta disponibilidad y resiliencia de la conexión: Si se produce un fallo o un reinicio del contenedor de la aplicación, el contenedor sidecar de PgBouncer lo sigue de cerca, lo que garantiza una alta disponibilidad. Esta configuración garantiza la resistencia de la conexión y mantiene un rendimiento predecible incluso durante las conmutaciones por error, lo que contribuye a un sistema confiable y sólido.

Al considerar PgBouncer como sidecar de AKS, puede usar estas ventajas para mejorar el rendimiento de la aplicación, optimizar la administración y garantizar la disponibilidad continua del agrupador de conexiones.

Limitaciones:

• Problemas de rendimiento de las conexiones: Las aplicaciones a gran escala que utilizan miles de pods, cada uno de los cuales ejecuta el sidecar PgBouncer, pueden encontrarse con posibles problemas relacionados con el agotamiento de las conexiones a la base de datos. Esta situación puede provocar una degradación del rendimiento e interrupciones del servicio. La implementación de un sidecar de PgBouncer para cada pod aumenta el número de conexiones simultáneas al servidor de bases de datos, lo que puede superar su capacidad. Como resultado, la base de datos podría tener dificultades para controlar el gran volumen de conexiones entrantes, lo que provoca problemas de rendimiento, como un aumento de los tiempos de respuesta o incluso las interrupciones del servicio.
• Implementación compleja: usar el patrón de sidecar introduce un nivel de complejidad en el proceso de implementación, ya que implica ejecutar dos contenedores dentro del mismo pod. Esta complejidad puede complicar potencialmente las actividades de solución de problemas y depuración, lo que requiere un esfuerzo adicional para identificar y resolver problemas.
• Desafíos de escalado: Es posible que el patrón sidecar no sea la opción ideal para las aplicaciones que exigen alta escalabilidad. La inclusión de un contenedor sidecar puede suponer mayores requisitos de recursos, lo que podría limitar el número de pods que se pueden crear y administrar de forma eficaz.

Al considerar este patrón de sidecar, evalúe cuidadosamente las ventajas e inconvenientes entre la complejidad de la implementación y los requisitos de escalabilidad para determinar el enfoque más adecuado para su escenario de aplicación específico.

Aplicación independiente: implementación centralizada de PgBouncer

Cuando se usa este enfoque, se implementa PgBouncer como un servicio centralizado independiente de la aplicación. Puede implementar el servicio PgBouncer en máquinas virtuales tradicionales o en una arquitectura basada en microservicios, como se resalta en las secciones siguientes:

PgBouncer implementado en una máquina virtual Ubuntu detrás de Azure Load Balancer

Configure el proxy de conexión PgBouncer entre la aplicación y la capa de base de datos detrás de un Azure Load Balancer, como se muestra en la siguiente imagen. En este patrón, se implementan varias instancias de PgBouncer detrás de un equilibrador de carga como servicio para mitigar un único punto de error. Este patrón también es adecuado en escenarios en los que la aplicación se ejecuta en un servicio administrado como App de Azure Services o Azure Functions y se conecta al servicio PgBouncer para facilitar la integración con la infraestructura existente.

Para instalar y configurar el proxy de agrupación de conexiones de PgBouncer con servidores flexibles de Azure Database for PostgreSQL, consulte Pasos para instalar y configurar el proxy de agrupación de conexiones de PgBouncer.

Algunas de las principales ventajas y limitaciones de este método de implementación son:

Ventajas:

• Quitar un único punto de error: La conectividad de aplicaciones no se ve afectada por el error de una sola máquina virtual PgBouncer, ya que varias instancias de PgBouncer están detrás de Azure Load Balancer.
• Integración perfecta con Managed Services: si la aplicación se hospeda en una plataforma de servicio administrada, como App de Azure Services o Azure Functions, la implementación de PgBouncer en una máquina virtual permite una integración sencilla con la infraestructura existente.
• Configuración simplificada en una máquina virtual de Azure: si ya está ejecutando la aplicación en una máquina virtual de Azure, la configuración de PgBouncer en la misma máquina virtual es sencilla. La implementación de PgBouncer en la máquina virtual garantiza que PgBouncer se implemente cerca de la aplicación, lo que minimiza la latencia de red y maximiza el rendimiento.
• Configuración no intrusiva: Al implementar PgBouncer en una máquina virtual, puede evitar modificar parámetros en el servidor flexible de Azure Database for PostgreSQL. Esta configuración es útil cuando desea configurar PgBouncer en un servidor flexible Azure Database for PostgreSQL. Por ejemplo, cambiar el parámetro SSLMODE a "obligatorio" en un servidor flexible Azure Database for PostgreSQL podría provocar un error en determinadas aplicaciones que se basan en SSLMODE=FALSE. La implementación de PgBouncer en una máquina virtual independiente le permite mantener la configuración predeterminada del servidor mientras sigue usando las ventajas de PgBouncer.

Al considerar estas ventajas, la implementación de PgBouncer en una máquina virtual ofrece una solución cómoda y eficaz para mejorar el rendimiento y la compatibilidad de la aplicación que se ejecuta en la infraestructura de Azure.

Limitaciones:

• Sobrecarga de administración: A medida que instala PgBouncer en una máquina virtual, es posible que tenga sobrecarga de administración para administrar varios archivos de configuración. Esta configuración hace que sea difícil hacer frente a las actualizaciones de versiones, las nuevas versiones y las actualizaciones de productos.
• Paridad de características: Si va a migrar de PostgreSQL tradicional a un servidor flexible Azure Database for PostgreSQL y usa PgBouncer, es posible que existan algunas brechas de características. Por ejemplo, la falta de compatibilidad con md5 en Azure Database for PostgreSQL.

PgBouncer centralizado implementado como servicio en AKS

Si está trabajando con implementaciones en contenedores de gran tamaño y altamente escalables en Azure Kubernetes Service (AKS), compuestas por cientos de pods, o en situaciones en las que varias aplicaciones necesitan conectarse a una base de datos compartida, utilice PgBouncer como servicio independiente en lugar de como contenedor sidecar.

Mediante el uso de PgBouncer como servicio independiente, puede administrar y controlar eficazmente la agrupación de conexiones para las aplicaciones a escala más amplia. Este enfoque centraliza la funcionalidad de agrupación de conexiones, lo que permite que varias aplicaciones se conecten al mismo recurso de base de datos, a la vez que se mantiene un rendimiento óptimo y el uso de recursos.

Utilice la imagen del proxy sidecar de PgBouncer publicada en el registro de contenedores de Microsoft para crear e implementar un servicio.

Algunas de las principales ventajas y limitaciones de este método de implementación son:

Ventajas:

• Confiabilidad mejorada: La implementación de PgBouncer como servicio independiente le permite configurarla de forma de alta disponibilidad. Esta configuración mejora la confiabilidad general de la infraestructura de agrupación de conexiones, lo que garantiza la disponibilidad continua incluso en caso de errores o interrupciones.
• Uso óptimo de recursos: Si la aplicación o el servidor de bases de datos tienen recursos limitados, una máquina independiente dedicada a ejecutar el servicio PgBouncer puede ser ventajosa. Al implementar PgBouncer en una máquina con amplios recursos, se garantiza un rendimiento óptimo y se evitan problemas de contención de recursos.
• Administración centralizada de conexiones: cuando la administración centralizada de conexiones de base de datos es un requisito, un servicio PgBouncer independiente proporciona un enfoque más simplificado. Al consolidar las tareas de administración de conexiones en un servicio centralizado, puede supervisar y controlar de forma eficaz conexiones de base de datos en varias aplicaciones, simplificando la administración y garantizando la coherencia.

Al considerar PgBouncer como un servicio independiente dentro de AKS, puede usar estas ventajas para lograr una mejor confiabilidad, eficiencia de los recursos y administración centralizada de conexiones de base de datos.

Limitaciones:

• Mayor latencia de N/W: Al implementar PgBouncer como servicio independiente, tenga en cuenta la posible introducción de más latencia. Esta latencia se produce porque la aplicación y el servicio PgBouncer necesitan pasar conexiones a través de la red. Evalúe los requisitos de latencia de la aplicación y tenga en cuenta las ventajas entre la administración centralizada de conexiones y los posibles problemas de latencia.

Aunque PgBouncer que se ejecuta como un servicio independiente ofrece ventajas como la administración centralizada y la optimización de recursos, evalúe el impacto de la latencia potencial en el rendimiento de la aplicación para asegurarse de que se alinea con sus requisitos específicos.

PgBouncer integrado en Azure Database for PostgreSQL

Azure Database for PostgreSQL ofrece PgBouncer como solución integrada de agrupación de conexiones. Puede habilitar este servicio opcional por servidor de base de datos. PgBouncer se ejecuta en la misma máquina virtual que el servidor flexible Azure Database for PostgreSQL. A medida que el número de conexiones aumenta más allá de unos cientos o miles, Azure Database for PostgreSQL podría encontrar limitaciones de recursos. En tales casos, PgBouncer integrado puede proporcionar una ventaja significativa al mejorar la administración de conexiones inactivas y de corta duración en el servidor de bases de datos.

Para obtener información sobre cómo habilitar y configurar la agrupación de conexiones de PgBouncer en Azure Database for PostgreSQL, consulte PgBouncer en Servidor flexible de Azure Database for PostgreSQL.

Algunas de las principales ventajas y limitaciones de este método de implementación son:

Ventajas:

• Configuración de conexión directa: Mediante el uso de PgBouncer integrado en el servidor flexible de Azure Database for PostgreSQL, no necesita una instalación independiente ni una configuración compleja. Puede configurarlo fácilmente directamente desde los parámetros, lo que garantiza una experiencia sin complicaciones.
• Comodidad del servicio administrado: Como servicio administrado, puede disfrutar de las ventajas de otros servicios administrados Azure. Esta ventaja incluye actualizaciones automáticas, lo que elimina la necesidad de mantenimiento manual y garantiza que PgBouncer se mantenga actualizado con las últimas características y revisiones de seguridad.
• Compatibilidad con conexiones públicas y privadas:PgBouncer integrado en el servidor flexible de Azure Database for PostgreSQL proporciona compatibilidad con conexiones públicas y privadas. Esta compatibilidad le permite establecer conexiones seguras a través de redes privadas o conectarse externamente, según sus requisitos específicos.
• Alta disponibilidad (HA): en caso de una conmutación por error, en la que se promueve un servidor en espera al rol principal, PgBouncer se reinicia sin problemas en el modo de espera recién promocionado sin necesidad de realizar ningún cambio en la cadena de conexión de la aplicación. Esta característica garantiza la disponibilidad continua y minimiza la interrupción de la aplicación.
• Rentable: Es rentable, ya que no es necesario pagar por un proceso adicional, como la máquina virtual o los contenedores, aunque tiene algún impacto en la CPU, ya que es otro proceso que se ejecuta en la misma máquina.

Mediante el uso de PgBouncer integrado en un servidor flexible de Azure Database for PostgreSQL, puede disfrutar de la comodidad de la configuración simplificada, la confiabilidad de un servicio administrado, la compatibilidad con varios modos de agrupación y una alta disponibilidad sin problemas durante escenarios de conmutación por error.

Limitaciones:

• No compatible con Burstable:PgBouncer no es compatible actualmente con el nivel de proceso de servidor Burstable. Si cambia el nivel de proceso de Uso general u Optimizado para memoria al nivel Ampliable, perderá la funcionalidad PgBouncer.
• Vuelva a establecer las conexiones tras los reinicios: Cada vez que el servidor se reinicia durante operaciones de escalado, una conmutación por error de alta disponibilidad (HA) o un reinicio, PgBouncer se reinicia junto con la máquina virtual del servidor. Por lo tanto, las conexiones existentes deben volver a establecerse.

En este artículo se describen diferentes formas de implementar PgBouncer. En la tabla siguiente se resume el método de implementación que se va a optar por:

Criterios de selección	PgBouncer en la máquina virtual de la aplicación	PgBouncer en la máquina virtual mediante ALB*	PgBouncer en AKS Sidecar	PgBouncer como servicio	PgBouncer incorporado en Azure Database for PostgreSQL
Administración simplificada
Alta disponibilidad
Aplicaciones en contenedores
Sobrecarga de red y latencia reducidas
Control específico sobre la supervisión y la depuración

Leyenda

Nivel de dificultad	Símbolo
Easy
Media
Difícil

*ALB: Azure Load Balancer.

Contenido relacionado

• PgBouncer en el servidor flexible de Azure Database for PostgreSQL
• Bibliotecas de conexiones