Estratégia de pooling de conexão para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível usando o PgBouncer

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

Diretrizes estratégicas para selecionar o mecanismo de pool de conexões para o servidor flexível do Banco de Dados do Azure para PostgreSQL.

Introdução

Ao usar o servidor flexível do Banco de Dados do Azure para PostgreSQL, estabelecer uma conexão com o banco de dados envolve a criação de um canal de comunicação entre o aplicativo cliente e o servidor. Esse canal é responsável por gerenciar dados, executar consultas e iniciar transações. Depois que a conexão for estabelecida, o aplicativo cliente poderá enviar comandos para o servidor e receber respostas. No entanto, a criação de uma nova conexão para cada operação pode causar problemas de desempenho para aplicativos críticos. Sempre que uma nova conexão é criada, o servidor flexível do Banco de Dados do Azure para PostgreSQL gera um novo processo usando o processo de postmaster, que consome mais recursos.

Para atenuar esse problema, o pool de conexões é usado para criar um cache de conexões que podem ser reutilizados no servidor flexível do Banco de Dados do Azure para PostgreSQL. Quando um aplicativo ou cliente solicita uma conexão, ela é criada no pooling de conexões. Depois que a sessão ou transação for concluída, a conexão será retornada ao pool para reutilização. Ao reutilizar conexões, o uso de recursos é reduzido e o desempenho é melhorado.

Embora existam ferramentas diferentes para o pooling de conexões, nesta seção, discutiremos diferentes estratégias para usar o pooling de conexões com o PgBouncer.

O que é PgBouncer?

O PgBouncer é um pooler de conexão eficiente criado para PostgreSQL, que oferece a vantagem de reduzir o tempo de processamento e otimizar o uso de recursos no gerenciamento de várias conexões de cliente com um ou mais bancos de dados. O PgBouncer incorpora três modos de pooling diferentes para rotação de conexão:

• Pooling de sessões: esse método atribui uma conexão de servidor para o aplicativo cliente por toda a duração da conexão do cliente. Após a desconexão do aplicativo cliente, o PgBouncer retorna imediatamente a conexão de servidor para o pool. O mecanismo de pooling de sessões é o modo padrão no PgBouncer de Software Livre. Confira Configuração do PgBouncer
• Pooling de transações: com o pooling de transações, uma conexão de servidor é dedicada ao aplicativo cliente durante uma transação. Depois que a transação for concluída, o PgBouncer liberará a conexão de servidor ponderadamente, tornando-a disponível novamente no pool. O pooling de transações é o modo padrão no PgBouncer integrado no Servidor Flexível do PostgreSQL do Azure e não é compatível com transações preparadas.
• Pooling de instruções: no pooling de instruções, uma conexão de servidor é alocada para o aplicativo cliente para cada instrução individual. Após a conclusão da instrução, a conexão de servidor é retornada imediatamente ao pool de conexões. É importante observar que não há suporte para transações de várias instruções nesse modo.

A utilização efetiva do PgBouncer pode ser categorizada em três padrões de uso diferentes.

• Implantação do PgBouncer e colocação do aplicativo
• Implantações centralizadas do PgBouncer, independentemente do aplicativo
• Implantação interna do PgBouncer e do banco de dados

Cada um desses padrões tem suas próprias vantagens e desvantagens.

1. Implantação do PgBouncer e colocação do aplicativo

Ao utilizar essa abordagem, o PgBouncer é implantado no mesmo servidor em que o aplicativo está hospedado. O aplicativo e o PgBouncer podem ser implantados em máquinas virtuais tradicionais ou em uma arquitetura baseada em microsserviços, conforme destacado:

I. PgBouncer implantado na VM do aplicativo

Se o aplicativo for executado em uma VM do Azure, você poderá configurar o PgBouncer na mesma VM. Para instalar e configurar o PgBouncer como proxy de pool de conexões com o Banco de Dados do Azure para PostgreSQL, siga as instruções fornecidas no link abaixo.

Implantar o PgBouncer em um servidor de aplicativos pode fornecer várias vantagens, especialmente ao trabalhar com bancos de dados de servidor flexíveis do Banco de Dados do Azure para PostgreSQL. Alguns dos principais benefícios e limitações desse método de implantação são:

Benefícios:

• Latência reduzida: ao implantar o PgBouncer na mesma VM do aplicativo, a comunicação entre o aplicativo primário e o pooler de conexões é eficiente devido à proximidade. A implantação do PgBouncer na VM do aplicativo minimiza a latência e garante interações fáceis e rápidas.
• Segurança aprimorada: o PgBouncer pode atuar como intermediário seguro entre o aplicativo e o banco de dados, fornecendo uma camada extra de segurança. Ele pode impor a autenticação e a criptografia, garantindo que somente clientes autorizados possam acessar o banco de dados.

No geral, a implantação do PgBouncer em um servidor de aplicativos fornece uma abordagem mais eficiente, segura e escalonável para gerenciar conexões com bancos de dados PostgreSQL, melhorando o desempenho e a confiabilidade do aplicativo.

Limitações:

• Ponto único de falha: se o PgBouncer for implantado como uma única instância no servidor de aplicativos, ele se tornará um possível ponto único de falha. Se a instância do PgBouncer ficar inoperante, poderá interromper todo o pool de conexões de banco de dados, causando tempo de inatividade no aplicativo. Para atenuar o ponto único de falha, você pode configurar várias instâncias do PgBouncer atrás de um balanceador de carga para alta disponibilidade.
• Escalabilidade limitada: a escalabilidade do PgBouncer depende da capacidade do servidor em que ele é implantado. Se o servidor de aplicativos atingir seu limite de conexão, o PgBouncer poderá se tornar um gargalo, limitando a capacidade de dimensionar o aplicativo. Talvez seja necessário distribuir a carga de conexão em várias instâncias do PgBouncer ou considerar soluções alternativas, como o pool de conexões no nível do aplicativo.
• Complexidade de configuração: a configuração e o ajuste fino do PgBouncer podem ser complexos, especialmente ao considerar fatores como limites de conexão, dimensionamento de pool e balanceamento de carga. Os administradores precisam ajustar cuidadosamente a configuração do PgBouncer para corresponder aos requisitos do aplicativo e garantir o desempenho e a estabilidade ideais.

É importante avaliar essas limitações em relação aos benefícios e avaliar se o PgBouncer é a escolha certa para a configuração específica do aplicativo e do banco de dados.

II. PgBouncer implantado como sidecar do AKS

É possível utilizar o PgBouncer como contêiner sidecar, se o aplicativo estiver em contêineres e em execução no AKS (Serviço de Kubernetes do Azure), na ACI (Instância de Contêiner do Azure), no ACA (Aplicativos de Contêiner do Azure)ou no ARO (Red Hat OpenShift no Azure). O padrão Sidecar se inspira no conceito de um sidecar anexado a uma motocicleta, em que um contêiner auxiliar, conhecido como contêiner sidecar, é anexado a um aplicativo pai. Esse padrão enriquece o aplicativo pai estendendo suas funcionalidades e dando suporte complementar.

O padrão sidecar normalmente é usado com contêineres coagendados como um grupo de contêineres atômicos. A implantação do PgBouncer em um sidecar do AKS faz o acoplamento justo dos ciclos de vida do aplicativo e do sidecar e compartilha recursos como nome do host e rede para fazer um uso eficiente dos recursos. O sidecar do PgBouncer opera junto com o contêiner de aplicativo no mesmo pod do Serviço de Kubernetes do Azure (AKS) com mapeamento individual, servindo como proxy de pool de conexões para o Banco de Dados do Azure para PostgreSQL.

Esse padrão sidecar normalmente é usado com contêineres coagendados como um grupo de contêineres atômicos. O padrão sidecar associa fortemente os ciclos de vida do aplicativo e do sidecar e tem recursos compartilhados, como nome do host e rede. Ao usar essa configuração, o PgBouncer otimiza o gerenciamento de conexões e facilita a comunicação eficiente entre o aplicativo e o Banco de Dados do Azure para PostgreSQL.

A Microsoft publicou uma imagem de proxy sidecar do PgBouncer no registro de contêiner da Microsoft.

Confira este artigo para obter mais detalhes.

Alguns dos principais benefícios e limitações desse método de implantação são:

Benefícios:

• Latência reduzida: ao implantar o PgBouncer como sidecar do AKS, a comunicação entre o aplicativo primário e o pooler de conexões é integrada e eficiente devido à proximidade. A implantação do PgBouncer como um sidecar do AKS minimiza a latência e garante interações fáceis e rápidas.
• Gerenciamento e implantação simplificados: o acoplamento justo do PgBouncer com o contêiner de aplicativo simplifica o processo de gerenciamento e implantação. Ambos os componentes são fortemente integrados, permitindo uma administração mais fácil e a coordenação contínua.
• Alta Disponibilidade e Resiliência da Conexão: se um contêiner de aplicativo falhar ou reiniciar, o contêiner sidecar do PgBouncer acompanhará atentamente, garantindo alta disponibilidade. Essa configuração garante a resiliência da conexão e mantém um desempenho previsível mesmo durante os failovers, contribuindo para um sistema confiável e robusto.

Ao considerar o PgBouncer como sidecar do AKS, você pode usar essas vantagens para aprimorar o desempenho do aplicativo, simplificar o gerenciamento e garantir a disponibilidade contínua do pooler de conexões.

Limitações:

• Problemas de Desempenho da Conexão: os aplicativos em grande escala que utilizam milhares de pods, cada um executando o sidecar PgBouncer, podem encontrar possíveis desafios relacionados ao esgotamento da conexão de banco de dados. Essa situação pode resultar em degradação do desempenho e interrupções de serviço. Implantar um sidecar PgBouncer para cada pod aumenta o número de conexões simultâneas com o servidor de banco de dados, o que pode exceder a capacidade. Como resultado, o banco de dados pode ter dificuldades para lidar com o alto volume de conexões de entrada, o que pode levar a problemas de desempenho, como maior tempo de resposta ou até mesmo interrupções de serviço.
• Implantação Complexa: a utilização do padrão sidecar introduz um nível de complexidade ao processo de implantação, pois envolve a execução de dois contêineres no mesmo pod. Isso pode complicar as atividades de solução de problemas e depuração, exigindo esforço extra para identificar e resolve problemas.
• Desafios de colocação em escala: é importante observar que o padrão sidecar pode não ser a opção ideal para aplicativos que exigem alta escalabilidade. A inclusão de um contêiner sidecar pode impor mais requisitos de recursos, possivelmente limitando o número de pods que podem ser criados e gerenciados efetivamente.

Ao considerar esse padrão sidecar, é crucial avaliar cuidadosamente as compensações entre a complexidade da implantação e os requisitos de escalabilidade para determinar a abordagem mais apropriada para o cenário de aplicativo específico.

2. Implantação centralizada do PgBouncer, independentemente do aplicativo

Ao utilizar essa abordagem, o PgBouncer é implantado como serviço centralizado, independentemente do aplicativo. O serviço PgBouncer pode ser implantado em máquinas virtuais tradicionais ou em uma arquitetura baseada em microsserviços, conforme destacado:

I. PgBouncer implantado na VM do ubuntu atrás do Azure Load Balancer

O proxy de conexão do pgBouncer é configurado entre o aplicativo e a camada de banco de dados atrás de um Azure Load Balancer, conforme mostrado na imagem. Nesse padrão, várias instâncias do PgBouncer são implantadas atrás de um balanceador de carga como um serviço para atenuar o ponto único de falha. Esse padrão também é adequado em cenários em que o aplicativo está em execução em um serviço gerenciado, como os Serviços de Aplicativo do Azure ou o Azure Functions, e se conecta ao serviço PgBouncer para facilitar a integração com sua infraestrutura existente.

Consulte o link para instalar e configurar o proxy de pooling de conexões do PgBouncer com o Banco de Dados do Azure para PostgreSQL.

Alguns dos principais benefícios e limitações desse método de implantação são:

Benefícios:

• Remoção do ponto único de falha: a conectividade do aplicativo pode não ser afetada pela falha de uma única VM do PgBouncer, pois há várias instâncias do PgBouncer atrás do Azure Load Balancer.
• Integração contínua com Serviços Gerenciados: se o aplicativo estiver hospedado em uma plataforma de serviço gerenciada, como o Serviço de Aplicativo do Azure ou o Azure Functions, a implantação do PgBouncer em uma VM permitirá a integração fácil com a infraestrutura existente.
• Configuração Simplificada na VM do Azure: se você já estiver executando o aplicativo em uma VM do Azure, configurar o PgBouncer na mesma VM será simples. A implantação do PgBouncer na VM garante que o PgBouncer seja implantado próximo ao aplicativo, minimizando a latência de rede e maximizando o desempenho.
• Configuração Não Intrusiva: ao implantar o PgBouncer em uma VM, você pode evitar a modificação dos parâmetros de servidor no PostgreSQL do Azure. Isso é útil quando você deseja configurar o PgBouncer em uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Por exemplo, alterar o parâmetro SSLMODE para "obrigatório" na Base de Dados Azure para o servidor flexível PostgreSQL pode fazer com que determinadas aplicações que dependem de SSLMODE=FALSE falhem. Implantar o PgBouncer em uma VM separada permite que você mantenha a configuração de servidor padrão, enquanto ainda aproveita os benefícios do PgBouncer.

Ao considerar esses benefícios, a implantação do PgBouncer em uma VM oferece uma solução prática e eficiente para melhorar o desempenho e a compatibilidade do aplicativo em execução na infraestrutura do Azure.

Limitações:

• Sobrecarga de gerenciamento: como o PgBouncer está instalado na VM, pode haver sobrecarga de gerenciamento para gerenciar vários arquivos de configuração. Isso torna difícil lidar com atualizações de versão, novas versões e atualizações de produtos.
• Paridade de recursos: se você estiver migrando do PostgreSQL tradicional para o PostgreSQL do Azure e usando o PgBouncer, poderá haver algumas lacunas de recursos. Por exemplo, falta de suporte md5 no servidor flexível do Banco de Dados do Azure para PostgreSQL.

II. PgBouncer centralizado implantado como serviço no AKS

Se você estiver trabalhando com grandes implantações conteinerizadas e altamente escalonáveis no AKS (Serviço de Kubernetes do Azure), que consistem em centenas de pods, ou em situações em que vários aplicativos precisam se conectar a um banco de dados compartilhado, o PgBouncer pode ser empregado como serviço autônomo, em vez de contêiner sidecar.

Ao utilizar o PgBouncer como serviço separado, você pode gerenciar e manipular com eficiência o pool de conexões para seus aplicativos em uma escala mais ampla. Essa abordagem permite centralizar a funcionalidade de pool de conexões, permitindo que vários aplicativos se conectem ao mesmo recurso de banco de dados, mantendo o desempenho ideal e a utilização de recursos.

A imagem de proxy sidecar do PgBouncer publicada no registro de contêiner da Microsoft pode ser usada para criar e implantar um serviço.

Alguns dos principais benefícios e limitações desse método de implantação são:

Benefícios:

• Maior Confiabilidade: implantar o PgBouncer como serviço autônomo permite a configuração com alta disponibilidade. Isso melhora a confiabilidade geral da infraestrutura de pool de conexões, garantindo a disponibilidade contínua mesmo diante de falhas ou interrupções.
• Utilização Ideal de Recursos: se o aplicativo ou o servidor de banco de dados tiver recursos limitados, pode ser interessante optar por um computador separado dedicado à execução do serviço PgBouncer. Ao implantar o PgBouncer em um computador com recursos amplos, você pode garantir o desempenho ideal e evitar problemas de contenção de recursos.
• Gerenciamento Centralizado de Conexões: quando o gerenciamento centralizado de conexões de banco de dados é um requisito, um serviço PgBouncer autônomo fornece uma abordagem mais simplificada. Ao consolidar as tarefas de gerenciamento de conexões em um serviço centralizado, você pode monitorar e controlar efetivamente as conexões de banco de dados em vários aplicativos, simplificando a administração e garantindo a consistência.

Ao considerar o PgBouncer como serviço autônomo no AKS, você pode usar esses benefícios para obter maior confiabilidade, eficiência de recursos e gerenciamento centralizado de conexões de banco de dados.

Limitações:

• Mais Latência N/W: ao implantar o PgBouncer como serviço autônomo, é importante considerar que a latência pode aumentar. Isso ocorre devido à necessidade de que as conexões passem entre o aplicativo e o serviço PgBouncer pela rede. É crucial avaliar os requisitos de latência do aplicativo e considerar as compensações entre o gerenciamento centralizado de conexões e possíveis problemas de latência.

Embora o PgBouncer em execução como serviço autônomo ofereça benefícios como gerenciamento centralizado e otimização de recursos, é importante avaliar o impacto da possível latência no desempenho do aplicativo para garantir que esteja em alinhamento com os requisitos específicos.

3. PgBouncer Interno no servidor flexível do Banco de Dados do Azure para PostgreSQL

O servidor flexível do Banco de Dados do Azure para PostgreSQL oferece o PgBouncer como uma solução interna de pooling de conexões. Isso é oferecido como serviço opcional que pode ser habilitado de acordo com o servidor por banco de dados. O PgBouncer é executado na mesma máquina virtual que o servidor de banco de dados do servidor flexível do Banco de Dados do Azure para PostgreSQL. À medida que o número de conexões aumenta além de algumas centenas ou milhares, o servidor flexível do Banco de Dados do Azure para PostgreSQL pode encontrar limitações de recursos. Nesses casos, o PgBouncer integrado pode fornecer uma vantagem significativa melhorando o gerenciamento de conexões ociosas e de curta duração no servidor de banco de dados.

Veja o link para habilitar e configurar o pool de conexões do PgBouncer no servidor flexível do Banco de Dados do Azure para PostgreSQL.

Alguns dos principais benefícios e limitações desse método de implantação são:

Benefícios:

• Configuração perfeita: com o PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL, não há necessidade de uma instalação separada ou configuração complexa. Ele pode ser facilmente configurado diretamente dos parâmetros do servidor, garantindo uma experiência sem complicação.
• Praticidade do Serviço Gerenciado: como serviço gerenciado, os usuários podem aproveitar as vantagens de outros serviços gerenciados do Azure. Isso inclui atualizações automáticas, acabando com a necessidade de manutenção manual e garantindo que o PgBouncer permaneça atualizado com os recursos e patches de segurança mais recentes.
• aSuporte p vários tipos de conexão: o PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL oferece suporte para conexões públicas e privadas. Isso permite que os usuários estabeleçam conexões seguras em redes privadas ou se conectem externamente, dependendo dos seus requisitos específicos.
• HA (Alta Disponibilidade): no caso de um failover, em que um servidor em espera é promovido para a função primária, o PgBouncer reinicia diretamente no modo de espera recém-promovido sem nenhuma alteração necessária para a cadeia de conexão do aplicativo. Isso garante a disponibilidade contínua e minimiza a interrupção do aplicativo.
• Economia: é econômico, pois os usuários não precisam pagar por computação extra, como VM ou contêineres, embora tenha algum impacto na CPU, pois é outro processo em execução no mesmo computador.

Com o PgBouncer interno no Servidor Flexível, os usuários podem aproveitar a praticidade da configuração simplificada, a confiabilidade de um serviço gerenciado, o suporte a vários modos de pooling e a alta disponibilidade contínua nos cenários de failover.

Limitações:

• Incompatível com capacidade de intermitência: No momento, não há suporte para PgBouncer na camada de computação do servidor com capacidade de intermitência. Se você alterar a camada de computação de Uso Geral ou Otimizado para Memória para a camada Com Capacidade de Intermitência, perderá a funcionalidade do PgBouncer.
• Restabelecer conexões após as reinicializações: sempre que o servidor é reiniciado durante operações de escala, failover de HA ou reinicialização, o PgBouncer também é reiniciado junto com a máquina virtual do servidor. Portanto, as conexões existentes devem ser reestabelecidas.

Discutimos diferentes maneiras de implementar o PgBouncer e a tabela resume o método de implantação a ser escolhido:

Critérios de Seleção	PgBouncer na VM de Aplicativo	PgBouncer na VM usando ALB*	PgBouncer no Sidecar do AKS	PgBouncer como Serviço	PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL
Gerenciamento simplificado
HA
Aplicativos Conteinerizados
Menor Sobrecarga de Rede e Latência
Controle fino de granularidade sobre monitoramento e depuração

Legenda

Nível de Dificuldade	Símbolo
Fácil
Médio
Difícil

*ALB: Azure Load Balancer.