Estrategia de agrupación de conexiones para Azure Database for PostgreSQL: servidor flexible mediante PgBouncer

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

Guía estratégica para seleccionar el mecanismo de agrupación de conexiones para el servidor flexible de Azure Database for PostgreSQL.

Introducción

Cuando se usa el servidor flexible de Azure Database for PostgreSQL, el establecimiento de una conexión a la base de datos implica la creación de un canal de comunicación entre la aplicación cliente y el servidor. Este canal es responsable de administrar datos, ejecutar consultas e iniciar transacciones. Una vez establecida 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, el servidor flexible de Azure Database for PostgreSQL genera un nuevo proceso mediante el proceso de postmaster, que consume más recursos.

Para mitigar este problema, la agrupación de conexiones se usa para crear una memoria caché de conexiones que se pueden reutilizar en el servidor flexible de Azure Database for PostgreSQL. Cuando una aplicación o cliente solicita una conexión, se crea a partir del grupo de conexiones. Una vez completada la sesión o transacción, la conexión se devuelve al grupo para su reutilización. Al reutilizar las conexiones, se reduce el uso de recursos y se mejora el rendimiento.

Aunque hay 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, lo que ofrece la ventaja de reducir el tiempo de procesamiento y optimizar el uso de recursos en la administración de varias conexiones de cliente a una o varias bases de datos. PgBouncer incorpora 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. Tras la desconexión de la aplicación cliente, PgBouncer devuelve inmediatamente la conexión del servidor al grupo. El mecanismo de agrupación de sesiones es el modo predeterminado en PgBouncer de código abierto. 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 inteligentemente la conexión del servidor, lo que hace que esté disponible de nuevo en el grupo. La agrupación de transacciones es el modo predeterminado en PgBouncer integrado del servidor flexible 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. Tras la finalización de la instrucción, la conexión del servidor se devuelve inmediatamente al grupo de conexiones. Es importante tener en cuenta que las transacciones de varias instrucciones no se admiten en este modo.

El uso efectivo de PgBouncer se puede clasificar en tres patrones de uso distintos.

• Implementación de PgBouncer y 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.

1. Implementación de PgBouncer y coubicación de aplicaciones

Al usar este enfoque, PgBouncer se implementa en el mismo servidor donde se hospeda la aplicación. La aplicación y PgBouncer se pueden implementar en máquinas virtuales tradicionales o en una arquitectura basada en microservicios, como se resalta:

I. 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, siga las instrucciones proporcionadas en el vínculo siguiente.

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 ventajas y limitaciones clave de este método de implementación son:

Ventajas:

• Latencia reducida: al implementar PgBouncer en la misma máquina virtual de 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 aplicaciones 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 PgBouncer se implementa 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 un único punto de error, puede configurar 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 puede 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.

Es importante ponderar estas limitaciones con respecto a las ventajas y evaluar si PgBouncer es la opción adecuada para la configuración específica de la aplicación y la base de datos.

II. PgBouncer implementado como sidecar de AKS

Es posible 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 de Sidecar se inspira en el concepto de sidecar que se acopla a una motocicleta, donde un contenedor auxiliar, conocido como contenedor sidecar, se vincula a una aplicación principal. Este patrón enriquece la aplicación principal mediante la ampliación de sus funcionalidades y la entrega de soporte complementario.

El patrón de sidecar se usa normalmente con contenedores que se programan como un grupo de contenedores atómicos. La implementación de PgBouncer en un sidecar de AKS acopla estrechamente los ciclos de vida de la aplicación y sidecar y comparte recursos como el nombre de host y las redes para hacer un uso eficaz de los recursos. El sidecar de PgBouncer funciona junto al contenedor de la aplicación dentro del mismo pod en Azure Kubernetes Service (AKS) con asignación 1:1, sirviendo como proxy de agrupación de conexiones para el servidor flexible de Azure Database for PostgreSQL.

Este patrón de sidecar se usa normalmente con contenedores que se programan como un grupo de contenedores atómicos. El patrón de sidecar enlaza fuertemente los ciclos de vida de la aplicación y sidecar y tiene recursos compartidos, como el nombre de host y las redes. Con esta configuración, PgBouncer optimiza la administración de conexiones y facilita una comunicación eficaz entre la aplicación y la instancia de servidor flexible de Azure Database for PostgreSQL.

Microsoft ha publicado una imagen de proxy de sidecar de PgBouncer en el registro de contenedor de Microsoft.

Consulte esto para más información.

Algunas de las ventajas y limitaciones clave 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, lo que permite una administración más sencilla y una coordinación fluida.
• Alta disponibilidad y resistencia de la conexión: si un contenedor de aplicación falla o se reinicia, el contenedor sidecar de PgBouncer le sigue de cerca, asegurando 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 la conexión: las aplicaciones a gran escala que usan miles de pods, cada uno ejecutando sidecar de PgBouncer, pueden encontrarse con problemas potenciales relacionados con el agotamiento de la conexión 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 puede tener dificultades para controlar el gran volumen de conexiones entrantes, puede provocar problemas de rendimiento, como un aumento de los tiempos de respuesta o incluso 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. Esto 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 escalabilidad: es importante tener en cuenta que el patrón de sidecar puede no ser la opción ideal para las aplicaciones que exigen una alta escalabilidad. La inclusión de un contenedor sidecar puede imponer más 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, es fundamental evaluar cuidadosamente las ventajas 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.

2. Aplicación independiente: implementación centralizada de PgBouncer

Al usar este enfoque, PgBouncer se implementa como un servicio centralizado, independientemente de la aplicación. El servicio PgBouncer se puede implementar en máquinas virtuales tradicionales o en una arquitectura basada en microservicios como se resalta:

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

El proxy de conexión de PgBouncer se configura entre la capa de aplicación y de base de datos detrás de Azure Load Balancer como se muestra en la 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 Azure App Services o Azure Functions y se conecta al servicio PgBouncer para facilitar la integración con la infraestructura existente.

Consulte el vínculo para instalar y configurar el proxy de agrupación de conexiones de PgBouncer con el servidor flexible de Azure Database for PostgreSQL.

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

Ventajas:

• Quitar un único punto de error: es posible que la conectividad de la aplicación no se vea afectada por el error de una sola máquina virtual de PgBouncer, ya que hay varias instancias de PgBouncer 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 Azure App 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 los parámetros del servidor en el servidor flexible de Azure Database for PostgreSQL. Esto resulta útil cuando desea configurar PgBouncer en una instancia de servidor flexible de Azure Database for PostgreSQL. Por ejemplo, cambiar el parámetro SSLMODE a "obligatorio" en un servidor flexible de 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 PgBouncer está instalado en la máquina virtual, puede haber sobrecarga de administración para administrar varios archivos de configuración. Esto dificulta la administración de actualizaciones de versiones, nuevas versiones y actualizaciones de productos.
• Paridad de características: si va a migrar de PostgreSQL tradicional a un servidor flexible de Azure Database for PostgreSQL y usa PgBouncer, es posible que haya algunas lagunas en las características. Por ejemplo, la falta de compatibilidad con md5 en el servidor flexible de Azure Database for PostgreSQL.

II. PgBouncer centralizado implementado como servicio en AKS

Si está trabajando con implementaciones en contenedores y altamente escalables en Azure Kubernetes Service (AKS), que constan de cientos de pods o en situaciones en las que varias aplicaciones necesitan conectarse a una base de datos compartida, PgBouncer se puede emplear como un servicio independiente en lugar de un contenedor sidecar.

Al usar PgBouncer como un servicio independiente, puede administrar y controlar eficazmente el agrupamiento de conexiones para sus aplicaciones a mayor escala. Este enfoque permite centralizar 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 y un uso óptimo de los recursos.

La imagen de proxy sidecar de PgBouncer publicada en el registro de contenedor de Microsoft se puede usar para crear e implementar un servicio.

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

Ventajas:

• Confiabilidad mejorada: la implementación de PgBouncer como servicio independiente permite la configuración de una manera de alta disponibilidad. Esto mejora la confiabilidad general de la infraestructura de agrupación de conexiones, lo que garantiza la disponibilidad continua incluso frente a errores o interrupciones.
• Uso óptimo de recursos: si la aplicación o el servidor de bases de datos tienen recursos limitados, optar por una máquina independiente dedicada a ejecutar el servicio PgBouncer puede ser ventajosa. Al implementar PgBouncer en una máquina con recursos amplios, puede garantizar un rendimiento óptimo y evitar 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 un servicio independiente, es importante tener en cuenta la posible introducción de más latencia. Esto se debe a la necesidad de que las conexiones se pasen entre la aplicación y el servicio de PgBouncer a través de la red. Es crucial evaluar los requisitos de latencia de su aplicación y considerar las ventajas y desventajas entre la administración centralizada de las conexiones y los posibles problemas de latencia.

Aunque PgBouncer funcionando como un servicio independiente ofrece ventajas como la administración centralizada y la optimización de recursos, es importante evaluar el impacto de la latencia potencial en el rendimiento de su aplicación para asegurarse de que se ajusta a sus requisitos específicos.

3. PgBouncer integrado en el servidor flexible de Azure Database for PostgreSQL

El servidor flexible de Azure Database for PostgreSQL ofrece PgBouncer como una solución de agrupación de conexiones integrada. Esto se ofrece como un servicio opcional que se puede habilitar en cada servidor de base de datos. PgBouncer se ejecuta en la misma máquina virtual que la instancia de servidor flexible de Azure Database for PostgreSQL. A medida que el número de conexiones aumenta más allá de unos cientos o miles, el servidor flexible de Azure Database for PostgreSQL puede 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.

Consulte el vínculo para habilitar y configurar la agrupación de conexiones de PgBouncer en el servidor flexible de Azure Database for PostgreSQL.

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

Ventajas:

• Configuración sin problemas: con PgBouncer integrado en el servidor flexible de Azure Database for PostgreSQL, no es necesario realizar una instalación independiente ni una configuración compleja. Se puede configurar fácilmente directamente desde los parámetros del servidor, lo que garantiza una experiencia sin complicaciones.
• Conveniencia del servicio administrado: como servicio administrado, los usuarios pueden disfrutar de las ventajas de otros servicios administrados de Azure. Esto incluye actualizaciones automáticas, lo que elimina la necesidad de mantenimiento manual y garantiza que PgBouncer permanezca actualizado con las últimas características y revisiones de seguridad.
• Compatibilidad con conexiones públicas y privadas: el PgBouncer integrado en el servidor flexible de Azure Database for PostgreSQL proporciona compatibilidad con conexiones públicas y privadas. Esto permite a los usuarios establecer conexiones seguras a través de redes privadas o conectarse externamente, en función de 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. Esto garantiza la disponibilidad continua y minimiza la interrupción de la aplicación.
• Coste eficiente: es rentable, ya que los usuarios no necesitan 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.

Con PgBouncer incorporado en el servidor flexible de Azure Database for PostgreSQL, los usuarios pueden disfrutar de la comodidad de una configuración simplificada, la fiabilidad de un servicio administrado, la compatibilidad con varios modos de agrupación y una alta disponibilidad sin fisuras durante los escenarios de conmutación por error.

Limitaciones:

• No compatible con Ampliable: PgBouncer no se admite actualmente con el nivel de proceso de servidor Ampliable. Si cambia el nivel de proceso de De uso general u Optimizado para memoria al nivel Ampliable, perderá la funcionalidad de PgBouncer.
• Reestablecer conexiones tras reinicios: cada vez que se reinicia el servidor durante las operaciones de escalado, conmutación por error de alta disponibilidad o reinicio, PgBouncer también se reinicia junto con la máquina virtual del servidor. Por lo tanto, las conexiones existentes deben volver a establecerse.

Hemos analizado diferentes formas de implementar PgBouncer y la tabla resume qué método de implementación optar para:

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 integrado en el servidor flexible de 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
Fácil
Media
Difícil

*ALB: Azure Load Balancer.