Estratégia de pooling de conexões usando PgBouncer em Base de Dados do Azure para PostgreSQL flexible server

Este artigo fornece orientações estratégicas para selecionar um mecanismo de pooling de ligações para o seu Base de Dados do Azure para PostgreSQL Flexible Servers.

Introdução

Quando utiliza um servidor flexível Base de Dados do Azure para PostgreSQL, cria uma ligação à base de dados estabelecendo um canal de comunicação entre a aplicação cliente e o servidor. Este canal gere dados, executa consultas e inicia transações. Depois de estabelecer a ligação, a aplicação cliente pode enviar comandos para o servidor e receber respostas. No entanto, criar uma nova ligação para cada operação pode causar problemas de desempenho em aplicações críticas para a missão. Sempre que cria uma nova ligação, o Base de Dados do Azure para PostgreSQL inicia um novo processo usando o processo do postmaster, que consome mais recursos.

Para resolver este problema, utilize o pool de ligações para criar uma cache de ligações que o Base de Dados do Azure para PostgreSQL possa reutilizar. Quando uma aplicação ou cliente solicita uma ligação, esta vem do pool de ligações. Após a sessão ou transação terminar, a ligação volta ao pool para reutilização. Ao reutilizar ligações, reduz o uso de recursos e melhora o desempenho.

Diagrama dos padrões de agrupamento de ligações.

Embora existam diferentes ferramentas para o pooling de conexões, esta secção discute diferentes estratégias para usar o pooling de conexões utilizando o PgBouncer.

O que é PgBouncer?

O PgBouncer é um pooler de ligações eficiente concebido para PostgreSQL. Reduz o tempo de processamento e otimiza a utilização de recursos ao gerir múltiplas ligações de clientes a uma ou mais bases de dados. O PgBouncer oferece três modos distintos de agrupamento para a rotação de ligações:

  • Pool de sessões: Este método atribui uma conexão de servidor ao aplicativo cliente durante toda a duração da conexão do cliente. Quando a aplicação cliente se desconecta, o PgBouncer devolve prontamente a ligação ao servidor ao pool. O agrupamento de sessões é o modo padrão no PgBouncer open source. Para mais informações, veja configuração PgBouncer.
  • Pool de transações: Com o pool de transações, uma conexão de servidor é dedicada ao aplicativo cliente durante uma transação. Uma vez concluída com sucesso a transação, o PgBouncer liberta a ligação ao servidor, tornando-a novamente disponível dentro do pool. O agrupamento de transações é o modo predefinido no PgBouncer incorporado do Base de Dados do Azure para PostgreSQL e não suporta 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 ligação ao servidor é devolvida ao pool de ligações. Transações com múltiplos extratos não são suportadas neste modo.

Pode usar o PgBouncer em três padrões de uso distintos:

  • PgBouncer e implantação com co-localização da aplicação
  • Implementações centralizadas do PgBouncer independentes da aplicação
  • PgBouncer integrado e implantação da base de dados

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

PgBouncer e implementação de colocação de aplicações

Quando usas esta abordagem, implementas o PgBouncer no mesmo servidor onde a tua aplicação está alojada. Pode implementar a aplicação e o PgBouncer em máquinas virtuais tradicionais ou numa arquitetura baseada em microserviços, como destacado:

PgBouncer implementado na VM da aplicação

Se seu 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 agrupamento de ligações com o seu servidor flexível do Base de Dados do Azure para PostgreSQL, consulte Passos para instalar e configurar o proxy de agrupamento de ligações PgBouncer.

Diagrama para co-localização de aplicações na VM.

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

Benefícios:

  • Latência reduzida: Ao implementar o PgBouncer na mesma VM de aplicação, a comunicação entre a aplicação principal e o pooler de ligação é eficiente devido à proximidade. Implementar o PgBouncer numa VM de aplicação minimiza a latência e garante interações fluidas e rápidas.
  • Segurança melhorada:O PgBouncer pode atuar como um intermediário seguro entre a aplicação e a base de dados, fornecendo uma camada extra de segurança. Ele pode impor autenticação e criptografia, garantindo que apenas 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 escalável para gerenciar conexões com o Banco de Dados do Azure para bancos de dados de servidor flexíveis PostgreSQL, aprimorando o desempenho e a confiabilidade do aplicativo.

Limitations:

  • Ponto único de falha: Se implementares o PgBouncer como uma única instância no servidor de aplicações, torna-se um potencial ponto único de falha. Se a instância PgBouncer ficar inativa, ela poderá interromper todo o pool de conexões do banco de dados, causando tempo de inatividade para o aplicativo. Para mitigar este ponto único de falha, configure várias instâncias do PgBouncer por trás de um balanceador de carga para alta disponibilidade.
  • Escalabilidade limitada: a escalabilidade do PgBouncer depende da capacidade do servidor onde está implantado. Se o servidor de aplicações atingir o seu limite de ligação, o PgBouncer pode tornar-se um gargalo, limitando a capacidade de escalar a aplicação. Pode ser necessário distribuir a carga de ligação entre várias instâncias PgBouncer ou considerar soluções alternativas como o pooling de ligações ao nível da aplicação.
  • Complexidade da configuração: configurar e ajustar o PgBouncer pode ser complexo, especialmente quando se consideram fatores como limites de conexão, dimensionamento do pool e balanceamento de carga. Os administradores precisam ajustar cuidadosamente a configuração do PgBouncer para atender aos requisitos do aplicativo e garantir o desempenho e a estabilidade ideais.

Pese estas limitações face aos benefícios e avalie se o PgBouncer é a escolha certa para a sua aplicação específica e configuração de base de dados.

PgBouncer implantado como um sidecar AKS

Pode usar o PgBouncer como um contentor sidecar se a sua aplicação for containerizada e a correr no Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA), ou Azure Red Hat OpenShift (ARO). O padrão de sidecar inspira-se no conceito de um sidecar acoplado a uma mota. Um contentor auxiliar, conhecido como contentor sidecar, está ligado a uma aplicação principal. Esse padrão enriquece o aplicativo pai, estendendo suas funcionalidades e fornecendo suporte suplementar.

Implementar o PgBouncer num sidecar AKS acopla de forma estreita os ciclos de vida da aplicação e do sidecar, partilhando recursos como nome de host e redes para fazer uma utilização eficiente dos recursos. O sidecar PgBouncer funciona juntamente com o contentor da aplicação no mesmo pod no Azure Kubernetes Service (AKS), com um mapeamento 1:1, servindo como proxy de agrupamento de ligações para os servidores flexíveis do Base de Dados do Azure para PostgreSQL.

Microsoft publica uma imagem de proxy sidecar PgBouncer no registo de contentores da Microsoft.

Consulte isto para obter mais detalhes.

Diagrama para co-localização de aplicações no Sidecar.

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

Benefícios:

  • Latência reduzida: Ao implantar o PgBouncer como um sidecar AKS, a comunicação entre o aplicativo principal e o pool de conexões é contínua e eficiente devido à sua proximidade. A implantação do PgBouncer em um sidecar AKS minimiza a latência e garante interações suaves e rápidas.
  • Gerenciamento e implantação simplificados: O acoplamento estreito do PgBouncer com o contêiner do aplicativo simplifica o processo de gerenciamento e implantação. Ambos os componentes estão fortemente integrados, por isso pode administrá-los mais facilmente e coordena-los de forma fluida.
  • Alta Disponibilidade e Resiliência da Ligação: Se ocorrer uma falha ou um reinício de um contentor de aplicação, o contentor sidecar do PgBouncer acompanha-o de perto, garantindo elevada disponibilidade. Essa configuração garante a resiliência da conexão e mantém um desempenho previsível mesmo durante failovers, contribuindo para um sistema confiável e robusto.

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

Limitations:

  • Problemas de desempenho das conexões: As aplicações de grande escala que utilizam milhares de pods, cada um a executar um sidecar PgBouncer, podem enfrentar desafios relacionados com o esgotamento das conexões à base de dados. Essa situação pode resultar em degradação do desempenho e interrupções do serviço. A implementação de um sidecar PgBouncer para cada pod aumenta o número de ligações simultâneas ao servidor de base de dados, o que pode exceder a capacidade do servidor. Como resultado, a base de dados pode ter dificuldades em lidar com o elevado volume de ligações recebidas, levando a problemas de desempenho como tempos de resposta aumentados ou até falhas de serviço.
  • Complexidade da implantação: A utilização do padrão sidecar introduz um nível de complexidade no processo de implantação, pois envolve a execução de dois contentores no mesmo pod. Esta complexidade pode potencialmente complicar as atividades de resolução de problemas e depuração, exigindo um esforço extra para identificar e resolver problemas.
  • Desafios de Escalabilidade: O padrão sidecar pode não ser a escolha ideal para aplicações que exigem elevada escalabilidade. A inclusão de um contentor sidecar pode aumentar os requisitos de recursos, podendo limitar o número de pods que consegue criar e gerir eficazmente.

Ao considerar este padrão sidecar, avalie cuidadosamente o equilíbrio entre a complexidade de implantação e os requisitos de escalabilidade para determinar a abordagem mais adequada para o cenário específico da sua aplicação.

Independente de aplicação - implementação centralizada do PgBouncer

Quando usa esta abordagem, implementa o PgBouncer como um serviço centralizado que é independente da aplicação. Pode implementar o serviço PgBouncer em máquinas virtuais tradicionais ou dentro de uma arquitetura baseada em microserviços, como destacado nas secções seguintes:

PgBouncer implantado numa VM Ubuntu por trás do Balanceador de Carga do Azure

Configure o proxy de ligação PgBouncer entre a camada de aplicação e base de dados atrás de um Balanceador de Carga do Azure, como mostrado na imagem seguinte. Neste padrão, implementam-se múltiplas instâncias do PgBouncer por trás de um balanceador de carga como serviço para mitigar um ponto único de falha. Esse padrão também é adequado em cenários em que o aplicativo está sendo executado em um serviço gerenciado, como os Serviços de Aplicativo do Azure ou o Funções do Azure, e se conectando ao serviço PgBouncer para facilitar a integração com sua infraestrutura existente.

Para instalar e configurar o proxy de agrupamento de ligações PgBouncer com os servidores flexíveis do Base de Dados do Azure para PostgreSQL, consulte Passos para instalar e configurar o proxy de agrupamento de ligações PgBouncer.

Diagrama para co-localização de aplicações na VM com Balanceador de Carga.

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

Benefícios:

  • Remoção do Ponto Único de Falha: A conectividade da aplicação não é afetada pela falha de uma única VM PgBouncer, pois várias instâncias PgBouncer estão atrás do Balanceador de Carga do Azure.
  • Integração perfeita com serviços gerenciados: se seu aplicativo estiver hospedado em uma plataforma de serviço gerenciado, como os Serviços de Aplicativo do Azure ou o Funções do Azure, a implantação do PgBouncer em uma VM permite uma fácil integração com sua infraestrutura existente.
  • Configuração simplificada na VM do Azure: se você já estiver executando seu aplicativo em uma VM do Azure, configurar o PgBouncer na mesma VM é simples. Implementar o PgBouncer em VM garante que o PgBouncer é implementado em proximidade próxima da sua aplicação, minimizando a latência da rede e maximizando o desempenho.
  • Configuração Não Intrusiva: Ao implementar o PgBouncer numa VM, pode evitar modificar parâmetros no seu servidor flexível Base de Dados do Azure para PostgreSQL. Esta configuração é útil quando quer configurar o PgBouncer num servidor flexível Base de Dados do Azure para PostgreSQL. Por exemplo, alterar o parâmetro SSLMODE para "obrigatório" num servidor flexível Base de Dados do Azure para PostgreSQL pode causar a falha de certas aplicações que dependem de SSLMODE=FALSE. Implantar o PgBouncer em uma VM separada permite que você mantenha a configuração padrão do servidor enquanto ainda usa os benefícios do PgBouncer.

Ao considerar esses benefícios, implantar o PgBouncer em uma VM oferece uma solução conveniente e eficiente para aprimorar o desempenho e a compatibilidade de seu aplicativo em execução na infraestrutura do Azure.

Limitations:

  • Custos de gestão: Ao instalar o PgBouncer numa VM, pode ter sobrecarga de gestão para gerir vários ficheiros de configuração. Esta configuração dificulta a gestão de atualizações de versões, novos lançamentos e atualizações de produtos.
  • Paridade de funcionalidades: Se estiver a migrar do PostgreSQL tradicional para um servidor flexível Base de Dados do Azure para PostgreSQL e usar o PgBouncer, podem existir algumas lacunas de funcionalidades. Por exemplo, falta de suporte a md5 no Banco de Dados do Azure para PostgreSQL.

PgBouncer centralizado implementado como serviço no AKS

Se estiver a trabalhar com implementações containerizadas altamente escaláveis e grandes no Azure Kubernetes Service (AKS), consistindo em centenas de pods, ou em situações em que múltiplas aplicações precisam de se ligar a uma base de dados partilhada, use o PgBouncer como um serviço autónomo em vez de um contentor sidecar.

Ao usar o PgBouncer como um serviço separado, pode gerir e gerir de forma eficiente o pooling de ligações para as suas aplicações numa escala mais ampla. Esta abordagem centraliza a funcionalidade de pooling de ligações, permitindo que múltiplas aplicações se liguem ao mesmo recurso de base de dados mantendo o desempenho e a utilização de recursos ótimos.

Utilize a imagem do proxy sidecar PgBouncer publicada no registo de contentores da Microsoft para criar e implementar um serviço.

Diagrama de PgBouncer como um serviço no AKS.

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

Benefícios:

  • Fiabilidade Reforçada: Implementar o PgBouncer como um serviço autónomo permite-lhe configurá-lo de forma altamente disponível. Esta configuração melhora a fiabilidade geral da infraestrutura de pooling de ligações, garantindo disponibilidade contínua mesmo perante falhas ou interrupções.
  • Utilização Ótima de Recursos: Se a sua aplicação ou o servidor de base de dados tiver recursos limitados, uma máquina separada dedicada a executar o serviço PgBouncer pode ser vantajosa. Ao implementar o PgBouncer numa máquina com recursos abundantes, assegura um desempenho ótimo 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 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 um serviço independente dentro do 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.

Limitations:

  • Aumento da latência de rede: Ao implementar PgBouncer como um serviço autónomo, considere o possível aumento adicional da latência. Esta latência ocorre porque a aplicação e o serviço PgBouncer precisam de passar ligações pela rede. Avalie os requisitos de latência da sua aplicação e considere os compromissos entre a gestão centralizada da ligação e potenciais problemas de latência.

Embora o PgBouncer a correr como serviço autónomo ofereça benefícios como gestão centralizada e otimização de recursos, avalie o impacto da latência potencial no desempenho da sua aplicação para garantir que está alinhada com os seus requisitos específicos.

PgBouncer incorporado no Base de Dados do Azure para PostgreSQL

O Banco de Dados do Azure para PostgreSQL oferece o PgBouncer como uma solução interna de pool de conexões. Pode ativar este serviço opcional em cada servidor de base de dados. O PgBouncer corre na mesma máquina virtual que o servidor flexível Base de Dados do Azure para PostgreSQL. À medida que o número de ligações ultrapassa algumas centenas ou milhares, o Base de Dados do Azure para PostgreSQL pode enfrentar 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.

Para aprender como ativar e configurar o pool de conexões PgBouncer no Base de Dados do Azure para PostgreSQL, consulte PgBouncer no Base de Dados do Azure para PostgreSQL flexible server.

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

Benefícios:

  • Configuração Contínua: Ao usar o PgBouncer incorporado no seu servidor flexível Base de Dados do Azure para PostgreSQL, não precisa de uma instalação separada nem de uma configuração complexa. Pode configurá-lo facilmente diretamente a partir dos parâmetros, garantindo uma experiência sem complicações.
  • Conveniência do Serviço Gerido: Como serviço gerido, pode usufruir das vantagens de outros serviços geridos do Azure. Este benefício inclui atualizações automáticas, eliminando a necessidade de manutenção manual e garantindo que o PgBouncer se mantém atualizado com as funcionalidades e patches de segurança mais recentes.
  • Apoio à Ligação Pública e Privada: O PgBouncer incorporado no seu servidor flexível Base de Dados do Azure para PostgreSQL oferece suporte tanto para ligações públicas como privadas. Este suporte permite-lhe estabelecer ligações seguras através de redes privadas ou conectar-se externamente, dependendo das suas necessidades específicas.
  • Alta disponibilidade (HA): No caso de um failover, em que um servidor em espera é promovido para a função principal, o PgBouncer reinicia perfeitamente no modo de espera recém-promovido sem nenhuma alteração necessária na cadeia de conexão do aplicativo. Esta funcionalidade assegura disponibilidade contínua e minimiza as perturbações na aplicação.
  • Eficiente em Custos: É eficiente em termos de custos, pois não precisas de pagar por cálculo extra como VM ou containers, embora tenha algum impacto na CPU, pois é outro processo a correr na mesma máquina.

Ao utilizar o PgBouncer integrado num servidor flexível Base de Dados do Azure para PostgreSQL, pode usufruir da conveniência de uma configuração simplificada, da fiabilidade de um serviço gerido, suporte para vários modos de pooling e alta disponibilidade fluida durante cenários de failover.

Limitations:

  • Não suportado com Burstable:O PgBouncer não é atualmente suportado pelo nível de computação do servidor Burstable. Se alterar o escalão de computação de Uso Geral ou Memória Otimizada para o escalão Burstable, perderá a funcionalidade PgBouncer.
  • Restabeleça as ligações após reinicializações: Sempre que o servidor reinicializa durante operações de escalamento, ativação pós-falha de HA ou uma reinicialização, o PgBouncer reinicializa juntamente com a máquina virtual do servidor. Por conseguinte, as ligações existentes devem ser restabelecidas.

Este artigo discute diferentes formas de implementar o PgBouncer. A tabela seguinte resume o método de implementação a optar:

Critérios de Seleção PgBouncer na VM da aplicação PgBouncer na VM usando ALB* PgBouncer no AKS Sidecar PgBouncer como um serviço Azure Database para PostgreSQL com PgBouncer integrado
Gestão Simplificada
HA
Aplicativos em contêineres
Redução da sobrecarga de rede & latência
Controle de grão fino no monitoramento e depuração

Legenda

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

*ALB: Balanceador de Carga Azure.

Conteúdo relacionado

  • Last updated on