# Aspectos que hay que tener en cuenta sobre aplicaciones y cargas de trabajo **Topics** + [Entornos de varios inquilinos y de varios usuarios](#rds-proxy-best-practices.multi-tenant) + [Bases de datos que prestan servicio a varias aplicaciones o pilas de software](#rds-proxy-best-practices.multiple-applications) + [Uso de la agrupación de aplicaciones y los controladores avanzados con RDS Proxy](#rds-proxy-best-practices.application-pooling) ## Entornos de varios inquilinos y de varios usuarios En lo que respecta a la escalabilidad y a la mejora de la administración de las conexiones, las ventajas de utilizar RDS Proxy dependen de su capacidad para agrupar conexiones y, en gran medida, multiplexarlas. La agrupación de conexiones reduce la sobrecarga asociada a la apertura y el cierre de conexiones. La multiplexación de conexiones permite al proxy reutilizar una conexión de base de datos backend después de una transacción. Para obtener más información, consulte [Conceptos y terminología de RDS Proxy](rds-proxy.howitworks.md). Cuando una conexión no se puede multiplexar, el proxy recurre a un comportamiento denominado *fijación de conexión*. La fijación es una situación en la que un cliente se ve obligado a utilizar la misma conexión proxy subyacente durante toda la sesión. La conexión proxy está reservada para ese cliente, por lo que no está disponible para que otros clientes la reutilicen. Dicho de otro modo, la fijación crea una asociación 1:1 exclusiva entre una conexión de cliente a proxy y una conexión de proxy a base de datos. Evitar el bloqueo es importante en todos los escenarios en los que se utiliza RDS Proxy, principalmente por motivos de escalabilidad y eficacia. Para conocer el comportamiento de fijación más actual, consulte [Cómo evitar la fijación de RDS Proxy](rds-proxy-pinning.md). Como regla general, las conexiones se pueden multiplexar cuando tienen un estado idéntico. Las conexiones no se pueden multiplexar cuando incluyen información de estado personalizada específica de la sesión. Uno de los aspectos que definen el estado de la sesión es el nombre de usuario de la base de datos asociado a una conexión. Cuando se conecta al proxy como “usuario\_A”, el proxy también debe abrir una conexión de base de datos backend como “usuario\_A”. El proxy podría agrupar y reutilizar esta conexión backend para otros clientes que inicien sesión como “usuario\_A”, pero no para los clientes que utilicen otro nombre de usuario. Este comportamiento puede reducir considerablemente la eficacia de la agrupación y la multiplexación en entornos multiusuario con un gran número de cuentas de bases de datos únicas. Esto es particularmente cierto en las arquitecturas que utilizan varios inquilinos de base de datos o de esquema. Si la base de datos incluye mil esquemas (uno por inquilino) y cada inquilino se conecta a la base de datos con otro nombre de usuario, el grupo de conexiones se fragmenta en microgrupos específicos para cada usuario, lo que reduce la eficacia general. Además, algunos aspectos específicos del motor de base de datos pueden afectar aún más a la eficacia de la agrupación y a la capacidad del proxy para multiplexar conexiones: 1. En Amazon RDS y Aurora PostgreSQL, la opción de varios inquilinos se suele implementar mediante el uso de una base de datos por inquilino. Sin embargo, en PostgreSQL, las conexiones son específicas de cada base de datos: una conexión abierta con una base de datos no puede acceder a los datos de otras bases de datos. Por tanto, la opción de varios inquilinos de base de datos reduce la eficacia de la agrupación y la multiplexación de proxy. Este aspecto también se aplica si la carga de trabajo utiliza la opción de varios inquilinos de esquema y las sesiones de cliente utilizan una `search_path` personalizada. Sin embargo, si todas las sesiones utilizan la ruta de búsqueda predeterminada y hacen referencia a las tablas con nombres totalmente cualificados (`schema_name.table_name`), estas sesiones se pueden multiplexar. 1. En Amazon RDS y Aurora MySQL, los términos “base de datos” y “esquema” son sinónimos. La opción de varios inquilinos suele implementarse mediante el uso de un esquema por inquilino, que en MySQL equivale a una base de datos por inquilino. Las conexiones se abren con un servidor de MySQL en su conjunto y no están vinculadas a un esquema. Si la aplicación utiliza la opción de varios inquilinos de esquema, la multiplexación de conexiones sigue siendo posible para los clientes que utilizan el mismo nombre de usuario de la base de datos, incluso si esas conexiones necesitan acceder a los datos en esquemas diferentes. La multiplexación será más eficaz si la separación de los inquilinos se realiza en la aplicación en lugar de utilizar cuentas de base de datos diferentes para cada inquilino. En entornos con varios esquemas, la eficacia de la multiplexación depende de cómo se haga referencia a los nombres de las tablas: + En el caso de los clientes que eligen el esquema actual mediante variables de sesión (`SET search_path ...` en PostgreSQL y `USE schema;` en MySQL) y utilizan nombres de tablas no cualificados en las consultas (como, por ejemplo `SELECT ... FROM table_name`), la multiplexación de conexiones solo funciona entre clientes que utilizan el mismo esquema o la misma ruta de búsqueda. + En el caso de los clientes que no modifican el estado de la sesión para definir el esquema actual, sino que utilizan nombres totalmente cualificados en las instrucciones de SQL (como, por ejemplo, `SELECT ... FROM schema_name.table_name`), la multiplexación no está sujeta a restricciones similares. ## Bases de datos que prestan servicio a varias aplicaciones o pilas de software Tal y como se ha explicado en la sección anterior, determinadas características del estado de la conexión no provocan la fijación, pero aun así reducen la capacidad del proxy de reutilizar las conexiones entre diferentes clientes. Cuando se usa con destinos de MySQL, RDS Proxy realiza un seguimiento de una serie de instrucciones y variables de sesión que configuran el estado de la sesión, como, por ejemplo, el conjunto de caracteres, la zona horaria y los ajustes de intercalación. Cuando un cliente utiliza instrucciones o variables a las que se ha realizado un seguimiento para configurar los ajustes de la sesión, la conexión de proxy solo se puede reutilizar para otros clientes que tengan los mismos valores para esos ajustes. Como resultado, ciertos comportamientos de las aplicaciones y los controladores pueden reducir la capacidad de reutilizar las conexiones dentro del proxy. Por ejemplo, puede permitir que diferentes aplicaciones se conecten a la base de datos con el mismo nombre de usuario, lo que supone que el proxy pueda reutilizar y multiplexar las conexiones entre esas aplicaciones. Sin embargo, si una aplicación inicia las conexiones con la zona horaria A (`SET time_zone = ?`) y otra usa la zona horaria B, las conexiones se pueden reutilizar dentro de una aplicación, pero no entre aplicaciones. Esto provoca la fragmentación del grupo de conexiones, lo que afecta de forma negativa a la eficacia de la agrupación y la multiplexación. Para obtener más información, consulte [Qué seguimiento hace RDS Proxy para bases de datos de Aurora MySQL](rds-proxy-pinning.md#rds-proxy-pinning.mysql-tracked-vars). Actualmente, el seguimiento del estado de la sesión no se admite para destinos de bases de datos distintos de MySQL. Consulte [Directrices de configuración](rds-proxy-best-practices.configuration.md) para obtener las directrices de configuración y las prácticas recomendadas para administrar el estado de la sesión con fin de evitar la fijación de la conexión. ## Uso de la agrupación de aplicaciones y los controladores avanzados con RDS Proxy RDS Proxy ayuda a mejorar la escalabilidad y la eficacia de la conexión en situaciones en las que la propia aplicación no utiliza la agrupación de conexiones. Al mismo tiempo, muchos controladores y marcos incluyen características de agrupación. Es posible que también utilice contenedores o controladores avanzados que implementen algunas de las características del proxy del controlador. El uso de la agrupación de aplicaciones y otras mejoras en la gestión de la conexión no es intrínsecamente contrario al uso de RDS Proxy y no niega sus ventajas. Por ejemplo, puede que esté utilizando la agrupación de conexiones en los contenedores de aplicaciones, pero el número de contenedores es lo suficientemente grande como para quedarse sin límites de conexión a la base de datos sin usar un proxy. Al utilizar RDS Proxy con agrupaciones de aplicaciones y otras características relacionadas con la conexión, revise y comprenda las razones por las que existen funciones avanzadas de gestión de conexiones en la aplicación. Decida cuáles de esas características merecen la pena conservar (o no tienen consecuencias) y cuáles pueden superponerse o interferir con el comportamiento del proxy. Por ejemplo: 1. Las características de agrupación integradas en los controladores y los marcos pueden ser útiles, incluso si parece que se superponen con la funcionalidad de RDS Proxy. Si un grupo de aplicaciones mejora la eficacia de la conexión local con respecto a las ventajas que ofrece el proxy, puede conservarla. 1. Las características relacionadas con la gestión de la conmutación por error pueden interferir con la lógica de RDS Proxy o aumentar la complejidad general de la pila sin ofrecer ventajas. Por ejemplo, si la aplicación realiza un seguimiento activo de la topología de los clústeres de Aurora para evitar retrasos en la conmutación por error relacionados con DNS, ya no necesitará hacerlo con RDS Proxy. Mantener esta lógica de seguimiento de la topología puede provocar un comportamiento no deseado, como, por ejemplo, que los subprocesos de la aplicación pasen por alto el proxy y se conecten directamente a instancias de bases de datos individuales. En este escenario, puede deshabilitar la lógica de seguimiento de la aplicación y dejar que RDS Proxy extraiga la topología del clúster por usted. 1. Las bibliotecas de agrupaciones de conexiones pueden utilizar características de administración del estado que, en teoría, parecen ventajosas, pero que interfieren con el comportamiento del proxy. Un ejemplo de ello son las bibliotecas de PostgreSQL que llaman a la consulta de `DISCARD ALL` para restablecer el estado de la conexión entre préstamos. Puede parecer que el restablecimiento de las conexiones debería ayudar a la agrupación y la multiplexación, pero interfiere con la administración interna del estado de la sesión de Amazon RDS Proxy. Al utilizar `DISCARD`, el proxy fija la conexión del cliente al liberarla, lo que reduce la eficacia de la multiplexación. Para cualquier componente de gestión de conexiones de aplicaciones que conserve, asegúrese de que su configuración no interfiera con la lógica de gestión de conexiones que utiliza Amazon RDS Proxy. Por ejemplo: + Iguale el tamaño de los grupos en todas las capas de la pila. Si los grupos de aplicaciones son demasiado grandes (o el grupo de proxies es demasiado grande), es posible que la aplicación intente abrir conexiones que el proxy no está configurado para gestionar. Dichas conexiones pueden sufrir retrasos en el mejor de los casos y errores de rechazo en el peor. + Alinee la configuración de tiempo de espera para reducir la pérdida de clientes y evitar confusiones en torno al comportamiento de la conexión. Si el grupo de aplicaciones mantiene activas las conexiones durante 300 segundos, pero el proxy está configurado para cerrar las conexiones después de 60 segundos, la aplicación verá cierres prematuros de las conexiones en lugar del comportamiento previsto. Algunas de estas decisiones arquitectónicas y opciones de configuración pueden requerir pruebas y experimentación. No siempre es posible predecir con exactitud el comportamiento de las aplicaciones en un entorno con varias capas de administración de conexiones y agrupaciones. Consulte [Directrices de configuración](rds-proxy-best-practices.configuration.md) para obtener directrices comunes sobre la configuración.