Estratégia de pool de conexões usando o PgBouncer no Servidor Flexível do Banco de Dados do Azure para PostgreSQL

Este artigo fornece diretrizes estratégicas para selecionar um mecanismo de pool de conexões para seus servidores flexíveis Banco de Dados do Azure para PostgreSQL.

Introdução

Ao usar um servidor Banco de Dados do Azure para PostgreSQL flexível, você cria uma conexão com o banco de dados estabelecendo um canal de comunicação entre o aplicativo cliente e o servidor. Esse canal gerencia dados, executa consultas e inicia transações. Depois de estabelecer a conexão, o aplicativo cliente pode 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 você cria uma nova conexão, Banco de Dados do Azure para PostgreSQL inicia um novo processo usando o processo de postmaster, que consome mais recursos.

Para resolver esse problema, use o pool de conexões para criar um cache de conexões que o Banco de Dados do Azure para PostgreSQL possa reutilizar. Quando um aplicativo ou cliente solicita uma conexão, ele vem do pool de conexões. Após a conclusão da sessão ou transação, a conexão volta para o pool para reutilização. Ao reutilização de conexões, você reduz o uso de recursos e melhora o desempenho.

Diagrama para Padrões de Pool de Conexões.

Embora existam ferramentas diferentes para o pool de conexões, esta seção discute diferentes estratégias para usar o pool de conexões usando PgBouncer.

O que é PgBouncer?

PgBouncer é um pooler de conexões eficiente projetado para PostgreSQL. Ele reduz o tempo de processamento e otimiza o uso de recursos ao gerenciar várias conexões de cliente com um ou mais bancos de dados. O PgBouncer oferece três modos distintos de pooling 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. Quando o aplicativo cliente é desconectado, o PgBouncer retorna prontamente a conexão do servidor de volta ao pool. O pool de sessões é o modo padrão no PgBouncer de código aberto. Para obter mais informações, consulte 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, tornando-a disponível novamente dentro do pool. O pooling de transações é o modo padrão no PgBouncer integrado do Banco de Dados do Azure para PostgreSQL e não oferece 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 é retornada para o pool de conexões. Transações com várias instruções não são suportadas neste modo.

Você pode usar PgBouncer em três padrões de uso distintos:

  • Implantação de colocalização do PgBouncer e do aplicativo
  • Implantações centralizadas do PgBouncer independentes de aplicativo
  • PgBouncer integrado e implantação do banco de dados

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

Implantação conjunta do PgBouncer e da aplicação

Ao usar essa abordagem, você implanta o PgBouncer no mesmo servidor em que seu aplicativo está hospedado. Você pode implantar o aplicativo e o PgBouncer em máquinas virtuais tradicionais ou em uma arquitetura baseada em microsserviços, conforme realçado:

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 seu servidor flexível Banco de Dados do Azure para PostgreSQL, consulte Etapas para instalar e configurar o proxy de pool de conexões PgBouncer.

Diagrama para colocalização de aplicativo na VM.

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:

Benefits:

  • Latência reduzida: Ao implantar o PgBouncer na mesma VM de 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 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.

Limitations:

  • Ponto único de falha: Se você implantar o PgBouncer 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 for interrompida, ela poderá interromper todo o pool de conexões do banco de dados, causando tempo de inatividade para o aplicativo. Para atenuar esse 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 em que está 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 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.

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

PgBouncer implantado como sidecar do AKS

Você pode usar o PgBouncer como um contêiner de sidecar se o aplicativo estiver em contêineres e em execução em AKS (Serviço de Kubernetes do Azure), Azure ACI (Instância de Contêiner),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 que se acopla a uma motocicleta. Um contêiner auxiliar, conhecido como sidecar, é anexado a uma aplicação principal. Esse padrão enriquece o aplicativo pai ao estender suas funcionalidades e oferecer suporte adicional.

A implantação do PgBouncer em um sidecar do AKS agrupa firmemente os ciclos de vida do aplicativo e do sidecar e compartilha recursos como nome de host e rede para fazer uso eficiente dos recursos. O sidecar do PgBouncer opera junto com o contêiner do aplicativo dentro do mesmo pod no Serviço de Kubernetes do Azure (AKS) com mapeamento 1:1, servindo como um proxy de pool de conexões para servidores flexíveis do Banco de Dados do Azure para PostgreSQL.

A Microsoft publica uma imagem de proxy sidecar do PgBouncer no registro de contêineres da Microsoft.

Consulte este para obter mais detalhes.

Diagrama para colocalização de aplicativos no Sidecar.

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

Benefits:

  • 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 são fortemente integrados, para que você possa administrá-los com mais facilidade e coordená-los perfeitamente.
  • Alta disponibilidade e resiliência de conexão: Se ocorrer uma falha ou reinicialização de um contêiner de aplicativo, o contêiner de sidecar pgBouncer seguirá 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.

Limitations:

  • Problemas de desempenho de conexão: Aplicativos em larga escala que usam 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 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 alto volume de conexões de entrada, levando a problemas de desempenho, como o aumento dos tempos de resposta ou até mesmo interrupções de 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. Essa complexidade pode potencialmente complicar as atividades de solução de problemas e depuração, exigindo esforço extra para identificar e resolver problemas.
  • Desafios de dimensionamento: 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, potencialmente limitando o número de pods que você pode criar e gerenciar com eficiência.

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

Aplicativo independente – implantação centralizada do PgBouncer

Ao usar essa abordagem, você implanta o PgBouncer como um serviço centralizado independente do aplicativo. Você pode implantar o serviço PgBouncer em máquinas virtuais tradicionais ou em uma arquitetura baseada em microsserviços, conforme destacado nas seções a seguir:

PgBouncer implantado na VM do Ubuntu por trás de Azure Load Balancer

Configure o proxy de conexão PgBouncer entre o aplicativo e a camada de banco de dados por trás de um Azure Load Balancer, conforme mostrado na imagem a seguir. Nesse padrão, você implanta várias instâncias do PgBouncer 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.

Para instalar e configurar o proxy de pool de conexões PgBouncer com os servidores flexíveis do Banco de Dados do Azure para PostgreSQL, consulte Etapas para instalar e configurar o proxy de pool de conexões PgBouncer.

Diagrama para colocalização de Aplicativos em VM com Load Balancer.

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

Benefits:

  • Eliminando um ponto único de falha: A conectividade do aplicativo não é afetada pela falha de uma única VM do PgBouncer, pois várias instâncias do PgBouncer estão atrá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. A implantação do PgBouncer na VM garante que o PgBouncer seja implantado próximo ao seu 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 de parâmetros em seu servidor Banco de Dados do Azure para PostgreSQL flexível. Essa configuração é útil quando você deseja configurar o PgBouncer em um servidor Banco de Dados do Azure para PostgreSQL flexível. Por exemplo, alterar o parâmetro SSLMODE para "obrigatório" em um servidor flexível 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.

Limitations:

  • Sobrecarga de gerenciamento: Ao instalar o PgBouncer em uma VM, você pode ter sobrecarga de gerenciamento para gerenciar vários arquivos de configuração. Essa configuração dificulta o 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 um servidor Banco de Dados do Azure para PostgreSQL flexível e usando o PgBouncer, algumas lacunas de recursos poderão existir. Por exemplo, falta de suporte md5 no Banco de Dados do Azure para PostgreSQL.

PgBouncer centralizado implantado como serviço no AKS

Se você estiver trabalhando com implantações em contêineres altamente escaláveis e de grande porte no AKS (Serviço de Kubernetes do Azure), compostas por centenas de pods, ou em situações em que vários aplicativos precisam se conectar a um banco de dados compartilhado, use PgBouncer como um serviço autônomo em vez de um contêiner sidecar.

Usando o PgBouncer como um 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 centraliza 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.

Use a imagem de proxy sidecar do PgBouncer publicada no registro de contêineres da Microsoft para criar e implantar um serviço.

Diagrama do PgBouncer como serviço no AKS.

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

Benefits:

  • Confiabilidade aprimorada: Implantar o PgBouncer como um serviço autônomo permite configurá-lo de maneira altamente disponível. Essa configuração melhora a confiabilidade geral da infraestrutura de pooling 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, um computador separado dedicado à execução do serviço PgBouncer poderá 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.

Limitations:

  • Aumento da latência de N/W: Ao implantar o PgBouncer como um serviço autônomo, considere a possível introdução de mais latência. Essa latência ocorre porque o aplicativo e o serviço PgBouncer precisam passar conexões pela rede. Avalie os requisitos de latência do aplicativo e considere as compensações entre o gerenciamento de conexões centralizado e possíveis problemas de latência.

Embora o PgBouncer em execução como um serviço autônomo ofereça benefícios como gerenciamento centralizado e otimização de recursos, avalie o impacto da latência potencial no desempenho do aplicativo para garantir que ele esteja alinhado com seus requisitos específicos.

PgBouncer integrado no Banco de Dados do Azure para PostgreSQL

O Banco de Dados do Azure para PostgreSQL oferece PgBouncer como uma solução interna de pooling de conexões. Você pode habilitar este serviço opcional para cada servidor de banco de dados. O PgBouncer é executado na mesma máquina virtual que o servidor Banco de Dados do Azure para PostgreSQL flexível. À medida que o número de conexões aumenta além de algumas centenas ou milhares, 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.

Para saber como habilitar e configurar o pool de conexões PgBouncer no Banco de Dados do Azure para PostgreSQL, consulte PgBouncer no servidor flexível Banco de Dados do Azure para PostgreSQL.

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

Benefits:

  • Configuração perfeita: Usando o PgBouncer interno em seu servidor Banco de Dados do Azure para PostgreSQL flexível, você não precisa de uma instalação separada ou configuração complexa. Você pode configurá-lo facilmente diretamente dos parâmetros, garantindo uma experiência sem problemas.
  • Conveniência do Serviço Gerenciado: Como um serviço gerenciado, você pode aproveitar as vantagens de outros serviços gerenciados Azure. Esse benefício 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 à conexão pública e privada: O PgBouncer interno em seu servidor Banco de Dados do Azure para PostgreSQL flexível fornece suporte para conexões públicas e privadas. Esse suporte permite que você estabeleça conexões seguras em redes privadas ou conecte-se 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. Esse recurso garante a disponibilidade contínua e minimiza a interrupção do aplicativo.
  • Econômico: É econômico, pois você não precisa 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.

Usando o PgBouncer interno em um servidor Banco de Dados do Azure para PostgreSQL flexível, você pode desfrutar da conveniência da configuração simplificada, da confiabilidade de um serviço gerenciado, do suporte para vários modos de pool e da alta disponibilidade perfeita durante cenários de failover.

Limitations:

  • Não compatível com Burstable:PgBouncer no momento não é compatível com a camada de computação de servidor Burstable. 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 a reinicialização: Sempre que o servidor é reiniciado durante operações de escala, failover de HA ou uma reinicialização, o PgBouncer é reiniciado junto com a máquina virtual do servidor. Portanto, as conexões existentes devem ser restabelecidas.

Este artigo discute diferentes maneiras de implementar PgBouncer. A tabela a seguir resume qual método de implantação optar por:

Critérios de Seleção PgBouncer na VM do Aplicativo PgBouncer na VM usando ALB* PgBouncer no Sidecar do AKS PgBouncer como Serviço Banco de Dados do Azure para PostgreSQL com PgBouncer integrado
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
Easy
Medium
Difícil

*ALB: Azure Load Balancer.

Conteúdo relacionado

  • Last updated on