# Considerações sobre aplicações e workloads
<a name="rds-proxy-best-practices.workload-considerations"></a>

**Topics**
+ [Ambientes multilocatário e multiusuário](#rds-proxy-best-practices.multi-tenant)
+ [Bancos de dados que atendem a várias aplicações ou pilhas de software](#rds-proxy-best-practices.multiple-applications)
+ [Usar o grupo em nível de aplicação e drivers avançados com o RDS Proxy](#rds-proxy-best-practices.application-pooling)

## Ambientes multilocatário e multiusuário
<a name="rds-proxy-best-practices.multi-tenant"></a>

 Com relação à escalabilidade e ao aprimoramento do gerenciamento de conexões, os benefícios do uso do RDS Proxy dependem da capacidade desse banco de dados de realizar o agrupamento de conexões e, muito mais do que isso, a multiplexação de conexões. O agrupamento de conexões reduz a sobrecarga associada à abertura e ao encerramento de conexões. A multiplexação de conexões permite que o proxy reutilize uma conexão de banco de dados de backend após uma transação. Para obter mais informações, consulte [Conceitos e terminologia do RDS Proxy](rds-proxy.howitworks.md). 

 Quando não é possível multiplexar uma conexão, o proxy recorre a um comportamento chamado *fixação de conexão*. A fixação é uma situação em que um cliente é forçado a usar a mesma conexão de proxy subjacente durante toda a sessão. A conexão de proxy é reservada para esse cliente; portanto, não está disponível para ser reutilizada por outros clientes. Em outras palavras, a fixação cria uma associação 1:1 exclusiva entre uma conexão cliente-proxy e uma conexão proxy-banco de dados. Evitar a fixação é importante em todos os cenários em que o RDS Proxy é usado principalmente por motivo de escalabilidade e eficiência. Para obter o comportamento de fixação mais atual, consulte [Evitar a fixação de um RDS Proxy](rds-proxy-pinning.md). 

 Como regra geral, as conexões podem ser multiplexadas quando têm um estado idêntico. As conexões não podem ser multiplexadas quando contêm informações personalizadas de estado específicas da sessão. Um dos aspectos que definem o estado da sessão é o nome de usuário do banco de dados associado a uma conexão. Quando você se conecta ao proxy como “usuário\_a”, o proxy também precisa abrir uma conexão de banco de dados de backend como “usuário\_a”. O proxy pode vir a agrupar e reutilizar essa conexão de backend para outros clientes que fazem login como “usuário\_a”, mas não para clientes que usam um nome de usuário diferente. 

 Esse comportamento pode reduzir significativamente a eficiência do agrupamento e da multiplexação em ambientes multiusuário com um grande número de contas de banco de dados exclusivas. Isso é particularmente verdadeiro em arquiteturas que usam multilocação em nível de banco de dados ou de esquema. Se o banco de dados contiver mil esquemas (um por inquilino) e cada locatário se conectar ao banco de dados com um nome de usuário diferente, o grupo de conexões se fragmentará em microgrupos específicos do usuário, reduzindo a eficiência geral. 

 Além disso, aspectos específicos do mecanismo de banco de dados podem afetar ainda mais a eficiência do grupo e a capacidade do proxy de multiplexar conexões: 

1.  No Amazon RDS e no Aurora PostgreSQL, a multilocação geralmente é implementada usando um único banco de dados por locatário. No entanto, no PostgreSQL, as conexões são específicas do banco de dados: uma conexão aberta em um banco de dados não pode acessar dados de outros bancos de dados. Portanto, a multilocação em nível de banco de dados reduz a eficiência do agrupamento e da multiplexação em nível de proxy. Essa consideração também se aplica se a workload usar multilocação em nível de esquema e as sessões de cliente usarem um `search_path` personalizado. Entretanto, se todas as sessões usarem o caminho de pesquisa padrão e fizerem referência a tabelas usando nomes totalmente qualificados (`schema_name.table_name`), essas sessões poderão ser multiplexadas. 

1.  No Amazon RDS e no Aurora MySQL, os termos “banco de dados” e “esquema” são sinônimos. A multilocação geralmente é implementada usando um único esquema por locatário, que no MySQL é o mesmo que um banco de dados por locatário. As conexões como um todo são abertas em um servidor MySQL e não estão vinculadas a um esquema. Se a aplicação usar multilocação em nível de esquema, a multiplexação de conexões ainda será possível para clientes que usam o mesmo nome de usuário de banco de dados, mesmo que essas conexões precisem acessar dados em esquemas diferentes. A multiplexação será mais eficaz se a separação de locatários for feita no nível da aplicação, em vez de usar contas de banco de dados diferentes para cada locatário. 

 Em ambientes com vários esquemas, a eficiência da multiplexação depende de como você se refere aos nomes de tabela: 
+  Para clientes que escolhem o esquema atual usando variáveis de sessão (`SET search_path ...` no PostgreSQL e `USE schema;` no MySQL) e depois usam nomes de tabela não qualificados nas consultas (como `SELECT ... FROM table_name`), a multiplexação de conexões só funciona entre clientes usando o mesmo esquema ou o mesmo caminho de pesquisa. 
+  Para clientes que não modificam o estado da sessão para definir o esquema atual, mas usam nomes de tabela totalmente qualificados nas instruções SQL (como `SELECT ... FROM schema_name.table_name`), a multiplexação não é restringida de modo semelhante. 

## Bancos de dados que atendem a várias aplicações ou pilhas de software
<a name="rds-proxy-best-practices.multiple-applications"></a>

 Conforme discutido na seção anterior, determinadas características do estado de conexão não causam fixação, mas ainda assim reduzem a capacidade do proxy de reutilizar conexões entre clientes diferentes. Quando usado com destinos do MySQL, o RDS Proxy rastreia várias instruções e variáveis de sessão que configuram o estado da sessão, como o conjunto de caracteres, o fuso horário e as configurações de agrupamento. Quando um cliente usa instruções ou variáveis rastreadas para definir as configurações da sessão, a conexão proxy só pode ser reutilizada para outros clientes que tenham os mesmos valores para essas configurações. 

 Por isso, determinados comportamentos de aplicações e drivers podem reduzir sua capacidade de reutilizar conexões dentro do proxy. Por exemplo, você pode permitir que aplicações diferentes se conectem ao banco de dados usando o mesmo nome de usuário, supondo que o proxy possa reutilizar e multiplexar conexões entre essas aplicações. No entanto, se uma aplicação inicializar conexões com o fuso horário A (`SET time_zone = ?`) e outra usar o fuso horário B, as conexões serão reutilizáveis dentro de uma aplicação, mas não entre aplicações. Isso provoca a fragmentação do grupo de conexões, afetando negativamente a eficácia do agrupamento e da multiplexação. 

 Para obter mais informações, consulte [O que o RDS Proxy monitora para bancos de dados do Aurora MySQL](rds-proxy-pinning.md#rds-proxy-pinning.mysql-tracked-vars). No momento, não é possível usar o rastreamento de estado de sessão para bancos de dados de destino que não sejam o MySQL. 

 Consulte [Diretrizes de configuração](rds-proxy-best-practices.configuration.md) para ver as diretrizes de configuração e as práticas recomendadas para gerenciar estados de sessão e evitar a fixação de conexão. 

## Usar o grupo em nível de aplicação e drivers avançados com o RDS Proxy
<a name="rds-proxy-best-practices.application-pooling"></a>

 O RDS Proxy ajuda a melhorar a escalabilidade e a eficiência da conexão em situações em que a própria aplicação não está usando o grupo de conexões. Ao mesmo tempo, muitos drivers e frameworks incluem recursos de agrupamento. Você também pode estar usando wrappers ou drivers avançados que implementam alguns dos recursos do proxy em nível de driver. 

 O uso de grupos em nível de aplicação e de outras melhorias no tratamento de conexão não conflita de forma inerente com o uso do RDS Proxy e não anula seus benefícios. Por exemplo, você pode estar usando o grupo de conexões em seus contêineres de aplicações, mas o número de contêineres pode ser tão grande que ainda assim você pode atingir seus limites de conexão com o banco de dados se não usar um proxy. Ao usar o RDS Proxy com grupos em nível de aplicação e outros recursos relacionados à conexão, analise e compreenda os motivos da existência de recursos avançados de tratamento de conexão em nível de aplicação. Decida quais desses recursos valem a pena manter (ou não são prejudiciais) e quais podem se sobrepor ou interferir no comportamento do proxy. Por exemplo: 

1.  Os recursos de agrupamento incorporados aos drivers e frameworks podem ser úteis mesmo que pareçam se sobrepor à funcionalidade do RDS Proxy. Se, além dos benefícios fornecidos pelo proxy, um grupo em nível de aplicação melhorar a eficiência da conexão local, você poderá mantê-lo. 

1.  Os recursos relacionados ao tratamento de failover podem interferir na lógica do RDS Proxy ou aumentar a complexidade geral da pilha sem oferecer benefícios. Por exemplo, se sua aplicação estiver monitorando ativamente a topologia dos seus clusters do Aurora para evitar atrasos de failover relacionados a DNS, ela não precisará mais fazer isso com o RDS Proxy. Manter essa lógica de rastreamento de topologia pode dar lugar a comportamentos indesejáveis, como threads da aplicação que ignoram o proxy e se conectam diretamente a instâncias individuais do banco de dados. Nesse cenário, você pode desabilitar a lógica de rastreamento no nível da aplicação e permitir que o RDS Proxy abstraia a topologia do cluster para você. 

1.  As bibliotecas de agrupamento de conexões podem usar recursos de gerenciamento de estado que parecem benéficos em teoria, mas interferem no comportamento do proxy. Um exemplo são as bibliotecas do PostgreSQL que chamam a consulta `DISCARD ALL` para redefinir o estado da conexão entre empréstimos. Pode até parecer que a redefinição das conexões pode ajudar no agrupamento e na multiplexação, mas isso interfere no gerenciamento interno do estado de sessão do Amazon RDS Proxy. Ao usar `DISCARD`, o proxy fixa a conexão do cliente na liberação, reduzindo a eficiência da multiplexação. 

 Para qualquer componente de tratamento de conexão em nível de aplicação que você mantenha, garanta que sua configuração não interfira na lógica de tratamento de conexão usada pelo Amazon RDS Proxy. Por exemplo: 
+  Alinhe o tamanho do grupo em todas as camadas da pilha. Se os grupos em nível de aplicação forem muito grandes (ou se o grupo de proxies estiver subdimensionado), a aplicação poderá tentar abrir conexões que o proxy não está configurado para lidar. Essas conexões podem sofrer atrasos, na melhor das hipóteses, e erros de rejeição, na pior das hipóteses. 
+  Alinhe as configurações de tempo-limite para reduzir a rotatividade e evitar confusão sobre o comportamento da conexão. Se o grupo da aplicação mantiver as conexões ativas por 300 segundos, mas o proxy estiver configurado para encerrar as conexões após 60 segundos, a aplicação verá encerramentos de conexão prematuros em vez do comportamento esperado. 

 Algumas dessas decisões de arquitetura e opções de configuração podem exigir testes e experimentação. Nem sempre é possível prever exatamente o comportamento da aplicação em um ambiente com várias camadas de gerenciamento de conexões e agrupamento. 

 Consulte [Diretrizes de configuração](rds-proxy-best-practices.configuration.md) para ver diretrizes de configuração comuns.