Escenarios de uso comunes

Escalabilidad de aplicaciones

Gestión de conexiones en aplicaciones basadas en eventos y sin servidor

Las aplicaciones basadas en eventos y sin servidor, como, por ejemplo, las API y los servicios web respaldados por AWS Lambda, suelen ser compatibles con un gran número de solicitudes de clientes de corta duración. Este patrón de uso puede provocar la pérdida de conexiones en la base de datos sin posibilidad de implementar la agrupación de conexiones en la aplicación. El rendimiento de la base de datos podría degradarse solo por el número de conexiones simultáneas, o la base de datos podría superar su límite de conexiones y provocar errores en los clientes.

En estos escenarios, RDS Proxy puede ofrecer las siguientes ventajas:

Gestión de conexiones en aplicaciones distribuidas y basadas en contenedores

Una arquitectura de aplicaciones distribuidas y basadas en contenedores puede tener cientos o incluso miles de contenedores, cada uno de los cuales ejecuta una copia del código de la aplicación. Incluso si los contenedores individuales son capaces de agrupar conexiones, estos grupos son específicos de cada contenedor y, por lo tanto, son muy pequeños. El número de contenedores multiplicado por el tamaño de cada minigrupo de contenedores puede superar los límites de conexión de las bases de datos de Amazon RDS o Aurora.

En esta situación, la capacidad de RDS Proxy para agrupar conexiones (reutilizar conexiones) y multiplexar (prestar servicio a varios clientes mediante una sola conexión backend) es muy valiosa. Puede seguir utilizando la agrupación de conexiones dentro de cada contenedor para reducir la rotación entre los subprocesos de la aplicación y el proxy de RDS, pero el proxy puede ayudar a reducir el número de conexiones de bases de datos backend para que puedan administrarse.

Mejora de la utilización de réplica de lectura

Las bases de datos que realizan muchas operaciones de lectura pueden requerir varias réplicas de lectura para admitir el tráfico de solo lectura. Las aplicaciones pueden usar su propia lógica para elegir a qué réplica conectarse o, con mayor frecuencia, usan un mecanismo de distribución equilibrada basado en DNS, como, por ejemplo, el punto de conexión del lector de clústeres de Aurora. Sin embargo, un enfoque basado en DNS puede provocar una utilización desigual de las réplicas como resultado del almacenamiento en caché de DNS. Por ejemplo, los clientes podrían “fijarse” a una determinada réplica, podrían no reconocer las nuevas réplicas que se están añadiendo al clúster o podrían intentar conectarse a réplicas que ya no existen.

Cuando se utiliza un punto de conexión de solo lectura de RDS Proxy, el proxy enruta las conexiones de los clientes entre todas las réplicas disponibles mediante una lógica de “conexiones menos pendientes”. RDS Proxy no equilibra el tráfico de equilibrador de carga en función de las métricas de la base de datos, como, por ejemplo, el uso de la CPU, sino que intenta igualar el número de conexiones de cliente en cada réplica, ponderado según el límite de conexiones de la base de datos. Por ejemplo, si tiene tres réplicas de Aurora ejecutándose con un ajuste max_connections de 500, 500 y 1000 (respectivamente), el proxy intenta enviar aproximadamente el doble de conexiones a la tercera réplica que a las otras dos.

Puede utilizar puntos de conexión del lector RDS Proxy con clústeres de Aurora o implementaciones de clústeres de bases de datos de Amazon RDS Multi-AZ con dos esperas legibles. Los puntos de conexión del lector de proxy no son compatibles con las implementaciones de instancias de base de datos de Amazon RDS con réplicas de lectura.

Mejora de la eficiencia de la conexión

Al introducir un proxy entre las aplicaciones de cliente y la base de datos, el objetivo suele ser aumentar la eficiencia de la gestión de las conexiones y, al mismo tiempo, tener en cuenta el costo de latencia que supone un salto de red adicional a través del proxy. Una capa intermedia adicional puede parecer contradictoria para mejorar la eficiencia de la conexión, ya que cualquier conexión que se hubiera abierto directamente con la base de datos ahora se abre con el proxy. Los pasos de establecimiento de comunicación del protocolo son los mismos en ambos casos, por lo que si sigue dedicando recursos a establecimientos de comunicación de conexión, puede que no sea obvio de dónde proceden las mejoras en la eficiencia.

El proxy no necesariamente hace que las conexiones sean más baratas de establecer. En su lugar, traslada la mayor parte de la carga de la gestión de establecimiento de comunicación de la capa de base de datos a la capa de proxy. Cuando paga por los recursos de la base de datos, quiere que esos recursos se dediquen al trabajo de la base de datos y no en gastos auxiliares. Esto adquiere especial importancia cuando se utilizan conexiones cifradas: si bien el gasto general de la transmisión de datos cifrados a través de una conexión existente no es significativo, el gasto inicial que supone configurar una conexión cifrada es considerable. En entornos que pierden cientos o miles de conexiones por segundo, ese esfuerzo adicional puede acumularse rápidamente. Es posible que no desee dedicar ese tiempo de la CPU a recursos de bases de datos (relativamente costosos) y, en lugar de ello, transferirlos a una capa de proxy (relativamente baratos).

En cuanto a la latencia que supone un salto de red adicional, su importancia depende del grado de “conversación” de la aplicación y del número de instrucciones que ejecute por cada “conversación” con la base de datos. En RDS Proxy, normalmente se observa una latencia adicional en los milisegundos bajos de un solo dígito, pero no necesariamente tendrá un impacto visible en las aplicaciones. Por ejemplo:

Si la latencia adicional en su situación es notable e indeseable, debe compararla con las demás ventajas de utilizar un proxy (gestión de la conmutación por error, agrupación, multiplexación).

Alta disponibilidad

Las bases de datos de Multi-AZ que se ejecutan en Amazon RDS y Aurora (excepto Aurora DSQL) utilizan mecanismos de conmutación por error para restaurar la disponibilidad en caso de problemas con la instancia de base de datos principal. Las conmutaciones por error también se utilizan como parte de los flujos de trabajo operativos, como, por ejemplo, el escalado de computación de la instancia principal. Una conmutación por error implica un cambio de DNS que traslada el punto de conexión de la base de datos principal (con capacidad de lectura/escritura) de la instancia principal anterior a la que se ha promovido recientemente. Las aplicaciones de cliente deben observar y reconocer este cambio de DNS para que los clientes puedan seguir la instancia principal sin retraso.

Algunas aplicaciones pueden tener dificultades para reconocer de forma oportuna los cambios en DNS como resultado del almacenamiento en caché de DNS en el sistema operativo o en la aplicación. Si bien se recomienda abordar los problemas de almacenamiento en caché de DNS en la aplicación, no siempre es posible debido a la complejidad de las aplicaciones o al costo que supone introducir los cambios.

En este escenario, RDS Proxy es una forma eficaz de evitar los retrasos en la conmutación por error relacionados con DNS. Los puntos de conexión de lectura/escritura y los puntos de conexión de solo lectura opcionales que ofrece RDS Proxy son “estables” en el sentido de que las direcciones IP que se encuentran detrás de esos puntos de conexión no cambian cuando las instancias de bases de datos intercambian sus roles. RDS Proxy realiza un seguimiento continuo de la topología de la base de datos backend y resume los cambios en el rol de la instancia de los clientes.

Existen formas alternativas de gestionar los problemas de almacenamiento en caché de DNS, por ejemplo, mediante el uso de controladores avanzados capaces directamente de detectar la topología de la base de datos sin depender de DNS. Sin embargo, podría ser más fácil implementar un único proxy delante de la base de datos en lugar de introducir cambios en el código y nuevos controladores en la aplicación.

Disponibilidad de lectura

Además de mejorar la experiencia del cliente durante las conmutaciones por error de las bases de datos, RDS Proxy también ayuda a mejorar la disponibilidad de las aplicaciones en caso de problemas de réplica de lectura. Lo hace de dos formas:

Uso de varios proxies con un objetivo

Como práctica recomendada, utilice un RDS Proxy por destino de base de datos, como, por ejemplo, una instancia de Amazon RDS o un clúster de Aurora. Esto funciona correctamente en la mayoría de los escenarios, simplifica la configuración y hace que la experiencia del cliente sea más predecible. En comparación, el uso de varios proxies requiere alinear detenidamente la configuración en todos los proxies para evitar comportamientos inesperados. Por ejemplo, debe asegurarse de que el tamaño combinado de todos los grupos de proxies no supere los límites de conexión del único destino de la base de datos.

Es posible que aún estudie la idea de utilizar varios proxies en determinadas situaciones. En las siguientes secciones se analizan los escenarios más comunes y se describen las ventajas y desventajas de un enfoque de único proxy frente a uno de varios proxies.

Disponibilidad del proxy

La infraestructura de RDS Proxy cuenta con mucha disponibilidad y se ha implementado en varias zonas de disponibilidad (AZ). La capacidad del proxy se distribuye en muchos nodos con una supervisión continua del estado y se ajusta automáticamente en función del tamaño de la instancia aprovisionada o de la configuración máxima de ACU de Serverless v2 de la base de datos. Como resultado del diseño multi-AZ distribuido del proxy, no necesita ejecutar varios proxies delante de los clústeres de Amazon RDS o Aurora para lograr una alta disponibilidad.

De hecho, el uso de varios proxies delante de un único destino de base de datos significa que la pila de aplicaciones ahora es responsable de detectar los problemas y reaccionar ante ellos, en lugar de confiar en los sólidos mecanismos integrados en el proxy. Por lo tanto, se recomienda encarecidamente no utilizar varios proxies por motivos de alta disponibilidad, ya que es probable que genere más problemas de los que se pueden resolver.

Gestión de varios grupos de clientes

Cada proxy proporciona un punto de conexión de lectura o escritura y (de forma opcional) puntos de conexión adicionales de lectura o escritura o de solo lectura. Cuando se utiliza un único proxy para gestionar varios grupos de clientes o varias cargas de trabajo, esas cargas de trabajo pueden interferir. Por ejemplo, una carga de trabajo puede monopolizar el grupo de conexiones hasta el punto de que no queden suficientes conexiones libres para gestionar otras cargas de trabajo. El uso de proxies independientes para aislar las cargas de trabajo puede ser una solución atractiva, pero primero puede tener en cuenta otras opciones:

Si decide utilizar varios proxies delante del mismo destino, asegúrese de que el tamaño total de todos los grupos de conexiones no supere las capacidades de la base de datos de destino. Por ejemplo, la suma de MaxConnectionsPercent en todos los proxies debe ser inferior a 100; de lo contrario, es posible que los proxies intenten abrir más conexiones de las que puede gestionar la configuración de la base de datos.

Cada proxy se factura por separado y la tarifa de facturación depende del tamaño de los recursos de la base de datos subyacentes y no de la actividad de la carga de trabajo. Considere el costo de ejecutar varios proxies en comparación con el costo de implementar soluciones alternativas, si las hubiera.

Control de grupos de lectura y escritura de forma independiente

Cada proxy proporciona un punto de conexión de lectura o escritura y (opcionalmente) puntos de conexión adicionales de lectura o escritura o de solo lectura, pero los límites y los tiempos de espera se configuran para todo el destino del proxy y no de forma individual para cada punto de conexión del mismo.

Por ejemplo, es posible que tenga un clúster de Aurora que gestione un gran volumen de consultas de solo lectura mediante varias réplicas de lectura y el punto de conexión del lector del proxy, pero querrá limitar el número de conexiones de lectura o escritura para reducir la presión de recursos sobre el único escritor. Dado que el ajuste MaxConnectionsPercent se ha definido para todo el destino del proxy (clúster), no puede limitar el número de conexiones al punto de conexión de lectura o escritura sin afectar también a los límites del punto de conexión de solo lectura.

Este desafío se puede abordar de varias formas:

Puede lanzar réplicas de lectura adicionales en el clúster y reducir proporcionalmente el ajuste MaxConnectionsPercent del proxy. Esto conserva el tamaño total del grupo de conexiones de solo lectura y, al mismo tiempo, reduce el número máximo de conexiones permitidas en el escritor. Sin embargo, también aumenta el costo del clúster y es cada vez menos eficaz a medida que se dispone de más réplicas.

Puede usar grupos de parámetros de instancia para configurar los límites de conexiones de la base de datos (como, por ejemplo, max_connections en Aurora MySQL o PostgreSQL) para las réplicas de lectura, independientemente del escritor. Sin embargo, debe evitar utilizar una configuración de parámetros asimétrica, ya que las réplicas pueden promoverse a un rol de escritor durante una conmutación por error, por lo que la diferenciación inicial de los parámetros no será permanente. Podría pensar en cambiar la configuración de prioridad de la conmutación por error de la instancia para influir en las réplicas que se seleccionarán para su promoción durante las conmutaciones por error y utilizarla como un mecanismo de exclusión flexible de la conmutación por error que haga que la configuración asimétrica sea más predecible. Sin embargo, las prioridades de la conmutación por error solo sirven como sugerencias y no son una garantía firme del comportamiento de la conmutación por error. Por lo tanto, se recomienda encarecidamente no establecer configuraciones de varias instancias con ajustes asimétricos, ya que requieren una supervisión continua y pueden producir un comportamiento inesperado si se produce una conmutación por error en una instancia que usted no quería.

En este escenario, el uso de varios proxies podría ser la forma más sencilla de administrar los grupos de lectura y escritura de forma independiente. Puede crear dos proxies para el único destino de la base de datos y, a continuación, configurar las aplicaciones para que utilicen el punto de conexión de escritor desde el primer proxy y el punto de conexión de solo lectura desde el segundo proxy. Un proxy gestiona únicamente las cargas de trabajo de escritura, el otro gestiona únicamente las cargas de trabajo de lectura y MaxConnectionsPercent (así como otros ajustes) se pueden configurar de forma independiente para cada proxy. Esta solución implica un costo adicional por la ejecución del segundo proxy, pero es más sencilla y predecible que las alternativas anteriores.