Estratégia de pool de conexões para servidor flexível do Banco de Dados do Azure para PostgreSQL usando PgBouncer

APLICÁVEL A: Servidor Flexível do Banco de Dados do Azure para PostgreSQL

Diretrizes estratégicas para selecionar o mecanismo de pool de conexões para 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 é estabelecida, o aplicativo cliente pode enviar comandos ao servidor e receber respostas. No entanto, criar uma 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 inicia um novo processo usando o processo postmaster, o que consome mais recursos.

Para mitigar esse problema, o pool de conexões é usado para criar um cache de conexões que pode ser reutilizado no servidor flexível do Banco de Dados do Azure para PostgreSQL. Quando um aplicativo ou cliente solicita uma conexão, ela é criada a partir do pool de conexões. Após a conclusão da sessão ou transação, a conexão será retornada ao pool para reutilização. Ao reutilizar conexões, o uso de recursos é reduzido e o desempenho é aprimorado.

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

O que é PgBouncer?

PgBouncer é um pool de conexões eficiente projetado para PostgreSQL, que oferece a vantagem de reduzir o tempo de processamento e otimizar o uso de recursos ao gerenciar várias conexões de cliente com um ou mais bancos de dados. PgBouncer incorpora três modos de pool distintos para rotação de conexões:

• Pool de sessões: esse método atribui uma conexão de servidor ao aplicativo cliente durante toda a duração da conexão do cliente. Após a desconexão do aplicativo cliente, o PgBouncer retornará imediatamente a conexão do servidor ao pool. O mecanismo de pool de sessões é o modo padrão no PgBouncer de Código Aberto. Confira a configuração do PgBouncer
• Pool de transações: com o pool de transações, uma conexão de servidor é dedicada ao aplicativo cliente durante uma transação. Depois que a transação for concluída com êxito, o PgBouncer liberará a conexão do servidor de forma inteligente, tornando-a novamente disponível no pool. O pool de transações é o modo padrão no PgBouncer interno do servidor flexível do Banco de Dados do Azure para PostgreSQL e não dá suporte a transações preparadas.
• Pool de instruções: no pool de instruções, uma conexão de servidor é alocada ao aplicativo cliente para cada instrução individual. Após a conclusão da instrução, a conexão do servidor será imediatamente retornada ao pool de conexões. É importante observar que transações com várias instruções não têm suporte nesse modo.

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

• Implantação de Colocação do PgBouncer e Aplicativo
• Implantações centralizadas do PgBouncer independentes de aplicativo
• Implantação interna do PgBouncer e banco de dados

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

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

Ao usar essa abordagem, o PgBouncer será 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 um proxy de pool de conexões com o servidor flexível do Banco de Dados do Azure para PostgreSQL, siga as instruções fornecidas no seguinte link.

Implantar o PgBouncer em um servidor de aplicativos pode proporcionar várias vantagens, especialmente ao trabalhar com bancos de dados do 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:

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

No geral, implantar o PgBouncer em um servidor de aplicativos proporciona uma abordagem mais eficiente, segura e escalonável para gerenciar conexões com bancos de dados do servidor flexível do Banco de Dados do Azure para 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 potencial ponto único de falha. Se a instância do PgBouncer for interrompida, ela poderá interromper todo o pool de conexões do banco de dados, causando tempo de inatividade para o aplicativo. Para mitigar 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 está implantado. Se o servidor de aplicativos atingir seu limite de conexões, o PgBouncer poderá se tornar um gargalo, limitando a capacidade de escalar o aplicativo. Talvez seja necessário distribuir a carga de conexão entre várias instâncias do PgBouncer ou considerar soluções alternativas, como o pool de conexões no nível do aplicativo.
• Complexidade da configuração: configurar e ajustar o PgBouncer pode ser complexo, 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 atender aos requisitos do aplicativo e garantir desempenho e 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 usar PgBouncer como contêiner sidecar se o aplicativo estiver conteinerizado e em execução no Serviço de Kubernetes do Azure (AKS), Instância de Contêiner do Azure (ACI), Aplicativos de Contêiner do Azure (ACA) ou Red Hat OpenShift no Azure (ARO). O padrão Sidecar se inspira no conceito de um sidecar conectado a uma motocicleta, em que um contêiner auxiliar, conhecido como contêiner sidecar, é conectado a um aplicativo pai. Esse padrão enriquece o aplicativo pai ao estender suas funcionalidades e oferecer suporte adicional.

O padrão sidecar é normalmente usado com contêineres agendados em conjunto como um grupo atômico de contêineres. implantar o PgBouncer em um sidecar do AKS acopla firmemente os ciclos de vida do aplicativo e do sidecar e compartilha recursos, como nome de host e sistema de rede, para usar os recursos de forma eficiente. O sidecar PgBouncer opera ao lado do contêiner do aplicativo no mesmo pod no Serviço de Kubernetes do Azure (AKS) com mapeamento individual, funcionando como um proxy de pool de conexões para o servidor flexível do Banco de Dados do Azure para PostgreSQL.

Esse padrão sidecar é normalmente usado com contêineres agendados em conjunto como um grupo de contêineres atômicos. O padrão sidecar vincula fortemente os ciclos de vida do aplicativo e do sidecar e tem recursos compartilhados, como nome de host e sistema de rede. Com essa configuração, o PgBouncer otimiza o gerenciamento de conexões e facilita a comunicação eficiente entre o aplicativo e a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL.

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

Consulte este 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 principal e o pool de conexões é perfeita e eficiente devido à proximidade. Implantar o PgBouncer como sidecar do AKS minimiza a latência e garante interações suaves e rápidas.
• Gerenciamento e Implantação Simplificados: o acoplamento firme do PgBouncer com o contêiner do aplicativo simplifica o gerenciamento e o processo de implantação. Ambos os componentes estão totalmente integrados, permitindo uma administração mais fácil e uma coordenação perfeita.
• Alta Disponibilidade e Resiliência de Conexão: em caso de falha ou reinicialização do contêiner do aplicativo, o contêiner sidecar PgBouncer o acompanha de perto, garantindo alta disponibilidade. Essa configuração garante a resiliência da conexão e mantém o desempenho previsível mesmo durante 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 pool de conexões.

Limitações:

• Problemas de Desempenho da Conexão: aplicativos em grande escala que usam milhares de pods, cada um executando o PgBouncer sidecar, podem enfrentar desafios potenciais relacionados ao esgotamento de conexões de banco de dados. Essa situação pode resultar em degradação do desempenho e interrupções do serviço. Implantar um PgBouncer sidecar para cada pod aumenta o número de conexões simultâneas ao servidor de banco de dados, o que pode exceder sua capacidade. Como resultado, o banco de dados pode ter dificuldades para lidar com o grande volume de conexões recebidas, o que pode causar problemas de desempenho, como aumento dos tempos de resposta ou até mesmo interrupções do serviço.
• Implantação Complexa: o uso do padrão sidecar introduz um nível de complexidade no processo de implantação, pois envolve a execução de dois contêineres no mesmo pod. Isso pode complicar potencialmente as atividades de solução de problemas e depuração, exigindo esforço extra para identificar e resolver problemas.
• Desafios de Escalonamento: é importante observar que o padrão sidecar pode não ser a escolha ideal para aplicativos que exigem alta escalabilidade. A inclusão de um contêiner sidecar pode impor mais requisitos de recursos, limitando potencialmente o número de pods que podem ser criados e gerenciados de forma eficaz.

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

2. Independente do aplicativo - Implantação centralizada do PgBouncer

Ao usar essa abordagem, o PgBouncer será implantado como um serviço centralizado, independente 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. O PgBouncer implantado em VM Ubuntu por trás do Azure Load Balancer

O proxy de conexão PgBouncer é configurado entre o aplicativo e a camada de banco de dados, por trás de um Azure Load Balancer, conforme mostrado na imagem. Neste padrão, várias instâncias do PgBouncer são implantadas por trás de um balanceador de carga como serviço para mitigar 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 este link para instalar e configurar o proxy de pool de conexões PgBouncer com o 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:

• Eliminação do ponto único de falha: a conectividade do aplicativo pode não ser afetada pela falha de uma única VM PgBouncer, pois há várias instâncias do PgBouncer por trás do Azure Load Balancer.
• Integração perfeita com Serviços Gerenciados: se o aplicativo estiver hospedado em uma plataforma de serviços gerenciados, como Serviços de Aplicativos do Azure ou Azure Functions, implantar o PgBouncer em uma VM permite a integração fácil com a infraestrutura existente.
• Configuração Simplificada em VM do Azure: se o aplicativo já estiver em execução em uma VM do Azure, a configuração do PgBouncer na mesma VM será simples. implantar o PgBouncer em uma VM garante que ele seja implantado próximo ao aplicativo, minimizando a latência da rede e maximizando o desempenho.
• Configuração não intrusiva: ao implantar o PgBouncer em uma VM, é possível evitar a modificação de parâmetros de servidor no Servidor Flexível do Banco de Dados do Azure para PostgreSQL. Isso é útil quando você deseja configurar o PgBouncer em uma instância do Servidor Flexível do Banco de Dados do Azure para PostgreSQL. Por exemplo, alterar o parâmetro SSLMODE para "obrigatório" no Servidor Flexível do Banco de Dados do Azure para PostgreSQL pode fazer com que determinados aplicativos que dependem de SSLMODE=FALSE falhem. Implantar o PgBouncer em uma VM separada permite manter a configuração padrão do servidor e ainda aproveitar os benefícios do PgBouncer.

Considerando 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 dificulta a adaptação a atualizações de versão, novos lançamentos e atualizações de produtos.
• Paridade de recursos: se você estiver migrando do PostgreSQL tradicional para o Servidor Flexível do Banco de Dados do Azure para PostgreSQL e usando o PgBouncer, poderá haver algumas lacunas de recursos. Por exemplo, a falta de suporte a 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 implantações conteinerizadas grandes e altamente escaláveis no Serviço de Kubernetes do Azure (AKS), com centenas de pods, ou em cenários em que vários aplicativos precisam se conectar a um banco de dados compartilhado, o PgBouncer pode ser utilizado como um serviço independente em vez de um contêiner sidecar.

Ao usar o PgBouncer como um serviço separado, você pode gerenciar e lidar 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:

• Confiabilidade aprimorada: implantar o PgBouncer como um serviço independente permite a configuração de alta disponibilidade. Isso melhora a confiabilidade geral da infraestrutura de pool de conexões, garantindo disponibilidade contínua mesmo em caso de falhas ou interrupções.
• Utilização ideal de recursos: se o aplicativo ou o servidor de banco de dados tiver recursos limitados, optar por um computador separado dedicado à execução do serviço PgBouncer pode ser vantajoso. Ao implantar o PgBouncer em um computador com recursos amplos, você garante o desempenho ideal e evita 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 independente oferece 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 um serviço independente no AKS, você pode usar esses benefícios para obter mais confiabilidade, eficiência de recursos e gerenciamento centralizado de conexões de banco de dados.

Limitações:

• Maior Latência da Rede: ao implantar o PgBouncer como um serviço independente, é importante considerar a possível introdução de mais latência. Isso ocorre devido à necessidade de passar as conexões entre o aplicativo e o serviço PgBouncer pela rede. É fundamental avaliar os requisitos de latência do seu aplicativo e considerar os trade-offs entre o gerenciamento centralizado de conexões e os possíveis problemas de latência.

Embora o PgBouncer em execução como um serviço independente ofereça benefícios como gerenciamento centralizado e otimização de recursos, é importante avaliar o impacto da latência potencial no desempenho do aplicativo para garantir que ele atenda aos seus 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 pool de conexões. Esse recurso é oferecido como um serviço opcional que pode ser habilitado por servidor de banco de dados. O PgBouncer é executado na mesma máquina virtual que a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL. À medida que o número de conexões aumenta para 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 interno pode oferecer uma vantagem significativa ao melhorar o gerenciamento de conexões ociosas e de curta duração no servidor de banco de dados.

Consulte 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 Automática: com o PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL, não há necessidade de instalação separada ou configuração complexa. Ele pode ser facilmente configurado diretamente nos parâmetros do servidor, garantindo uma experiência prática.
• Comodidade de 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, eliminando a necessidade de manutenção manual e garantindo que o PgBouncer permaneça atualizado com os recursos e patches de segurança mais recentes.
• Suporte para Conexões Públicas e Privadas: o PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a 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 de seus requisitos específicos.
• Alta Disponibilidade (HA): em caso de failover, quando um servidor em espera é promovido à função primária, o PgBouncer reinicia automaticamente no servidor em espera recém-promovido, sem que seja necessário alterar a cadeia de conexão do aplicativo. Isso garante disponibilidade contínua e minimiza a interrupção do aplicativo.
• Custo Eficiente: é 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, já que é outro processo em execução no mesmo computador.

Com o PgBouncer interno no servidor flexível do Banco de Dados do Azure para PostgreSQL, os usuários podem aproveitar a conveniência da configuração simplificada, a confiabilidade de um serviço gerenciado, o suporte a vários modos de pool e a alta disponibilidade automática durante cenários de failover.

Limitações:

• Sem suporte com capacidade de intermitência: atualmente, o PgBouncer não tem suporte com a 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 capacidade PgBouncer.
• Restabelecer conexões após reinicializações: sempre que o servidor for reiniciado durante operações de escala, failover de HA ou reinicialização, o PgBouncer também será reiniciado junto com a máquina virtual do servidor. Portanto, as conexões existentes devem ser restabelecidas.

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

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

Legenda

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

*ALB: Azure Load Balancer.