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

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

Orientação estratégica para selecionar o mecanismo de pool de conexões para o Banco de Dados do Azure para servidor flexível PostgreSQL.

Introdução

Ao usar o Banco de Dados do Azure para servidor flexível 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. Uma vez estabelecida 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 de missão crítica. 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 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 reutilizadas no Banco de Dados do Azure para o servidor flexível 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 é retornada ao pool para reutilização. Ao reutilizar conexões, o uso de recursos é reduzido e o desempenho é melhorado.

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

O que é PgBouncer?

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

• 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. Após a desconexão do aplicativo cliente, o PgBouncer retorna imediatamente a conexão do servidor de volta ao pool. O mecanismo de pool de sessões é o modo padrão no Open Source PgBouncer. Consulte 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. Quando a transação é concluída com sucesso, o PgBouncer libera inteligentemente a conexão do servidor, tornando-a disponível novamente dentro do pool. O pool de transações é o modo padrão no Banco de Dados do Azure para PgBouncer integrado do servidor flexível 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 é prontamente retornada ao pool de conexões. É importante notar que as transações com várias instruções não são suportadas neste modo.

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

• Implantação de PgBouncer e Application Colocation
• Implantações PgBouncer centralizadas independentes de aplicativos
• Implantação integrada de PgBouncer e banco de dados

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

1. Implantação de PgBouncer e colocation de aplicativos

Ao utilizar essa abordagem, o PgBouncer é implantado no mesmo servidor em que seu aplicativo está hospedado. O aplicativo & 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 aplicativo

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 pool de conexões com o Banco de Dados do Azure para servidor flexível PostgreSQL, siga as instruções fornecidas no link a seguir.

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 desse método de implantação são:

Benefícios:

• Latência reduzida: Ao implantar o PgBouncer na mesma VM de aplicativo, a comunicação entre o aplicativo principal e o pool de conexões é eficiente devido à sua proximidade. A implantação do PgBouncer na VM do aplicativo minimiza a latência e garante interações suaves 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.

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 PgBouncer ficar inativa, ela poderá interromper todo o pool de conexões do banco de dados, causando tempo de inatividade para o aplicativo. Para atenuar um único ponto de falha, você pode configurar várias instâncias PgBouncer atrá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 aplicativos atingir seu limite de conexão, o PgBouncer pode se tornar um gargalo, limitando a capacidade de dimensionar 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 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.

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

II. PgBouncer implantado como um sidecar AKS

É possível utilizar o PgBouncer como um contêiner sidecar se seu aplicativo estiver em contêiner e em execução no Serviço Kubernetes do Azure (AKS), na Instância de Contêiner do Azure (ACI), nos Aplicativos de Contêiner do Azure (ACA) ou no Azure Red Hat OpenShift (ARO). O padrão Sidecar inspira-se no conceito de um sidecar ligado a um motociclo, onde um contentor auxiliar, conhecido como contentor sidecar, é ligado a uma aplicação-mãe. Esse padrão enriquece o aplicativo pai, estendendo suas funcionalidades e fornecendo suporte suplementar.

O padrão sidecar é normalmente usado com contêineres sendo coprogramados como um grupo de contêineres atômicos. A implantação do PgBouncer em um sidecar AKS combina firmemente os ciclos de vida do aplicativo e do sidecar e compartilha recursos como nome do host e rede para fazer uso eficiente dos recursos. O sidecar PgBouncer opera ao lado do contêiner de aplicativos dentro do mesmo pod no Serviço Kubernetes do Azure (AKS) com mapeamento 1:1, servindo como um proxy de pool de conexões para o Banco de Dados do Azure para servidor flexível PostgreSQL.

Este padrão de sidecar é normalmente usado com contêineres sendo coprogramados como um grupo de contêineres atômicos. O padrão sidecar vincula fortemente o aplicativo e os ciclos de vida do sidecar e tem recursos compartilhados, como nome de host e rede. Usando 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 a instância flexível do servidor PostgreSQL.

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

Consulte isto 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 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, permitindo uma administração mais fácil e uma coordenação perfeita.
• Alta disponibilidade e resiliência de conexão: Se um contêiner de aplicativo falhar ou reiniciar, o contêiner do sidecar PgBouncer segue de perto, garantindo alta 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.

Limitações:

• Problemas de desempenho de conexão: aplicativos de grande escala que utilizam milhares de pods, cada um executando o sidecar PgBouncer, podem encontrar desafios potenciais relacionados ao esgotamento da conexão do banco de dados. Essa situação pode resultar em degradação do desempenho e interrupções do serviço. A implantação de um PgBouncer sidecar para cada pod aumenta o número de conexões simultâneas com o servidor de banco de dados, que podem exceder sua capacidade. Como resultado, o banco de dados pode ter dificuldades para lidar com o alto volume de conexões de entrada, pode levar a problemas de desempenho, como tempos de resposta aumentados 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 dentro do 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 escala: É importante notar que o padrão sidecar pode não ser a escolha ideal para aplicações 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 podem ser efetivamente criados e gerenciados.

Ao considerar esse padrão de 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 seu cenário de aplicativo específico.

2. Aplicação independente - Implementação centralizada do PgBouncer

Ao utilizar essa abordagem, o PgBouncer é 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. PgBouncer implantado na 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 Balanceador de Carga do Azure, conforme mostrado na imagem. Nesse padrão, várias instâncias PgBouncer são implantadas atrás de um balanceador de carga como um serviço para mitigar um único ponto 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 Azure Functions, e se conectando ao serviço PgBouncer para facilitar a integração com sua infraestrutura existente.

Consulte o link para instalar e configurar o proxy do pool de conexões PgBouncer com o Banco de Dados do Azure para o servidor flexível PostgreSQL.

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

Benefícios:

• Removendo um único ponto de falha: a conectividade do aplicativo pode não ser afetada pela falha de uma única VM PgBouncer, pois há várias instâncias PgBouncer por trás do Azure Load Balancer.
• 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 Azure Functions, 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. implantar o PgBouncer na VM garante que o PgBouncer seja implantado na proximidade do seu aplicativo, minimizando a latência da rede e maximizando o desempenho.
• Configuração não intrusiva: ao implantar o PgBouncer em uma VM, você pode evitar modificar parâmetros de servidor no Banco de Dados do Azure para servidor flexível PostgreSQL. Isso é útil quando você deseja configurar o PgBouncer em um Banco de Dados do Azure para instância de servidor flexível do PostgreSQL. Por exemplo, alterar o parâmetro SSLMODE para "required" no Banco de Dados do Azure para servidor flexível PostgreSQL pode fazer com que determinados aplicativos que dependem de SSLMODE=FALSE falhem. 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.

Limitações:

• Sobrecarga de gerenciamento: como o PgBouncer é 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 Banco de Dados do Azure para servidor flexível PostgreSQL e usando o PgBouncer, pode haver algumas lacunas de recursos. Por exemplo, falta de suporte a md5 no Banco de Dados do Azure para servidor flexível PostgreSQL.

II. PgBouncer centralizado implantado como um serviço dentro do AKS

Se você estiver trabalhando com implantações altamente escaláveis e grandes em contêineres no Serviço Kubernetes do Azure (AKS), consistindo 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 um serviço autônomo em vez de um contêiner sidecar.

Ao utilizar o PgBouncer como um serviço separado, você pode gerenciar e lidar com o pool de conexões para seus aplicativos em uma escala mais ampla. Essa abordagem permite centralizar a funcionalidade do 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 dos recursos.

A imagem de proxy do sidecar 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 uma maneira altamente disponível. 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 seu aplicativo ou o servidor de banco de dados tiver recursos limitados, optar por uma máquina separada dedicada à execução do serviço PgBouncer pode ser vantajoso. Ao implantar o PgBouncer em uma máquina com amplos recursos, 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 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.

Limitações:

• Maior latência N/W: Ao implantar o PgBouncer como um serviço autônomo, é importante considerar a possível introdução de mais latência. Isto é devido à necessidade de conexões a serem passadas entre o aplicativo e o serviço PgBouncer através da rede. É crucial avaliar os requisitos de latência do seu aplicativo e considerar as compensações entre o gerenciamento centralizado de conexões e possíveis problemas de latência.

Embora o PgBouncer executado 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 seu aplicativo para garantir que ele esteja alinhado com seus requisitos específicos.

3. PgBouncer incorporado na Base de Dados do Azure para servidor flexível 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. Isso é 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 flexível do servidor 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.

Consulte o link para habilitar e configurar o pool de conexões PgBouncer no Banco de Dados do Azure para o servidor flexível 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 Banco de Dados do Azure para servidor flexível PostgreSQL, não há necessidade de uma instalação separada ou configuração complexa. Ele pode ser facilmente configurado diretamente a partir dos parâmetros do servidor, garantindo uma experiência sem complicações.
• Conveniência do Serviço Gerenciado: Como um 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 a conexões públicas e privadas: o PgBouncer interno no banco de dados do Azure para servidor flexível PostgreSQL fornece 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 de 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. Isso garante disponibilidade contínua e minimiza interrupções no 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, pois é outro processo em execução na mesma máquina.

Com o PgBouncer integrado 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 para vários modos de pool e a alta disponibilidade contínua durante cenários de failover.

Limitações:

• Não suportado com Burstable: PgBouncer não é suportado atualmente com a camada de computação do servidor Burstable. Se você alterar a camada de computação de Uso Geral ou Memória Otimizada para a camada Burstable, perderá o recurso PgBouncer .
• Restabelecer conexões após reinicializações: sempre que o servidor é reiniciado durante operações de escala, failover de HA ou uma reinicialização, o PgBouncer também é reiniciado junto com a máquina virtual do servidor. Por conseguinte, as ligações existentes devem ser restabelecidas.

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

Critérios de Seleção	PgBouncer na VM do aplicativo	PgBouncer na VM usando ALB*	PgBouncer no AKS Sidecar	PgBouncer como um serviço	Banco de Dados do Azure para PostgreSQL servidor flexível interno PgBouncer
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
Fácil
Médio
Difícil

*ALB: Azure Load Balancer.