PgBouncer를 사용하는 Azure Database for PostgreSQL - 유연한 서버에 대한 연결 풀링 전략

아티클
02/23/2024

적용 대상: Azure Database for PostgreSQL - 유연한 서버

Azure Database for PostgreSQL 유연한 서버에 대한 연결 풀링 메커니즘을 선택하기 위한 전략적 지침입니다.

소개

Azure Database for PostgreSQL 유연한 서버를 사용하는 경우 데이터베이스에 대한 연결을 설정하려면 클라이언트 애플리케이션과 서버 간의 통신 채널을 만드는 것이 포함됩니다. 이 채널은 데이터 관리, 쿼리 실행 및 트랜잭션 시작을 담당합니다. 연결이 설정되면 클라이언트 애플리케이션은 서버에 명령을 보내고 응답을 받을 수 있습니다. 그러나 각 작업에 대해 새 연결을 만들면 업무상 중요한 애플리케이션에 성능 문제가 발생할 수 있습니다. 새 연결이 만들어질 때마다 Azure Database for PostgreSQL 유연한 서버는 더 많은 리소스를 소비하는 postmaster 프로세스를 사용하여 새 프로세스를 만듭니다.

이 문제를 완화하기 위해 연결 풀링을 사용하여 Azure Database for PostgreSQL 유연한 서버에서 다시 사용할 수 있는 연결 캐시를 만듭니다. 애플리케이션이나 클라이언트가 연결을 요청하면 연결 풀에서 만들어집니다. 세션이나 트랜잭션이 완료된 후 연결은 재사용을 위해 풀로 반환됩니다. 연결을 재사용하면 리소스 사용량이 줄어들고 성능이 개선됩니다.

Diagram for Connection Pooling Patterns.

연결 풀링을 위한 다양한 도구가 있지만 이 섹션에서는 PgBouncer를 사용하여 연결 풀링을 사용하는 다양한 전략을 토론합니다.

PgBouncer란?

PgBouncer는 PostgreSQL용으로 설계된 효율적인 연결 풀러로, 하나 이상의 데이터베이스에 대한 여러 클라이언트 연결을 관리할 때 처리 시간을 줄이고 리소스 사용을 최적화하는 이점을 제공합니다. PgBouncer는 연결 회전을 위해 세 가지 고유한 풀링 모드를 통합합니다.

세션 풀링: 이 방법은 클라이언트 연결 전체 기간 동안 클라이언트 애플리케이션에 서버 연결을 할당합니다. 클라이언트 애플리케이션 연결이 끊어지면 PgBouncer는 즉시 서버 연결을 풀로 다시 반환합니다. 세션 풀링 메커니즘은 오픈 소스 PgBouncer의 기본 모드입니다. PgBouncer 구성을 참조하세요.
트랜잭션 풀링: 트랜잭션 풀링을 사용하면 트랜잭션 중에 서버 연결이 클라이언트 애플리케이션 전용으로 설정됩니다. 트랜잭션이 성공적으로 완료되면 PgBouncer는 서버 연결을 지능적으로 해제하여 풀 내에서 다시 사용할 수 있도록 합니다. 트랜잭션 풀링은 Azure Database for PostgreSQL 유연한 서버의 기본 PgBouncer의 기본 모드이며 준비된 트랜잭션을 지원하지 않습니다.
문 풀링: 문 풀링에서는 각 개별 문에 대해 클라이언트 애플리케이션에 서버 연결이 할당됩니다. 문이 완료되면 서버 연결이 즉시 연결 풀로 반환됩니다. 이 모드에서는 다중 문 트랜잭션이 지원되지 않는다는 점에 유의해야 합니다.

PgBouncer의 효과적인 활용은 세 가지 사용 패턴으로 분류할 수 있습니다.

PgBouncer 및 애플리케이션 공동 배치 배포
애플리케이션에 독립적인 중앙 집중식 PgBouncer 배포
내장 PgBouncer 및 데이터베이스 배포

이러한 각 패턴에는 고유한 장점과 단점이 있습니다.

1. PgBouncer 및 애플리케이션 공동 배치 배포

이 방식을 활용하면 PgBouncer는 애플리케이션이 호스트되는 동일한 서버에 배포됩니다. 애플리케이션 및 PgBouncer는 다음과 같이 기존 가상 머신이나 마이크로 서비스 기반 아키텍처 내에 배포할 수 있습니다.

9\. 애플리케이션 VM에 배포된 PgBouncer

애플리케이션이 Azure VM에서 실행되는 경우 동일한 VM에 PgBouncer를 설정할 수 있습니다. Azure Database for PostgreSQL 유연한 서버를 사용하여 PgBouncer를 연결 풀링 프록시로 설치하고 구성하려면 다음 링크에 제공된 지침을 따릅니다.

Diagram for App co-location on VM.

애플리케이션 서버에 PgBouncer를 배포하면 특히 Azure Database for PostgreSQL 유연한 서버 데이터베이스를 사용할 때 여러 가지 이점을 얻을 수 있습니다. 이 배포 방법의 주요 이점 및 제한 사항은 다음과 같습니다.

이점:

대기 시간 감소: 동일한 애플리케이션 VM에 PgBouncer를 배포하면 기본 애플리케이션과 연결 풀러 간의 통신이 근접해지기 때문에 효율적입니다. 애플리케이션 VM에 PgBouncer를 배포하면 대기 시간이 최소화되고 원활하고 신속한 상호 작용이 보장됩니다.
개선된 보안:PgBouncer는 애플리케이션과 데이터베이스 사이의 보안 매개자 역할을 하여 추가 보안 계층을 제공할 수 있습니다. 인증 및 암호화를 적용하여 권한이 부여된 클라이언트만 데이터베이스에 액세스할 수 있도록 보장합니다.

전반적으로, 애플리케이션 서버에 PgBouncer를 배포하면 Azure Database for PostgreSQL 유연한 서버 데이터베이스에 대한 연결을 관리하는 데 더 효율적이고 안전하며 확장 가능한 방식이 제공되어 애플리케이션의 성능과 안정성이 향상됩니다.

제한 사항:

단일 실패 지점: PgBouncer가 애플리케이션 서버에 단일 인스턴스로 배포되면 잠재적인 단일 실패 지점이 됩니다. PgBouncer 인스턴스가 다운되면 전체 데이터베이스 연결 풀이 중단되어 애플리케이션이 가동 중지 시간될 수 있습니다. 단일 실패 지점을 완화하려면 고가용성을 위해 부하 분산 장치 뒤에 여러 PgBouncer 인스턴스를 설정할 수 있습니다.
제한된 확장성: PgBouncer 확장성은 배포되는 서버의 용량에 따라 달라집니다. 애플리케이션 서버가 연결 제한에 도달하면 PgBouncer에 병목 현상이 발생하여 애플리케이션 크기 조정 기능이 제한될 수 있습니다. 여러 PgBouncer 인스턴스에 연결 로드를 분산하거나 애플리케이션 수준에서 연결 풀링과 같은 대체 솔루션을 고려해야 할 수도 있습니다.
구성 복잡성: PgBouncer 구성 및 미세 조정은 특히 연결 제한, 풀 크기 및 부하 분산과 같은 요소를 고려할 때 복잡할 수 있습니다. 관리자는 애플리케이션의 요구 사항에 맞게 PgBouncer 구성을 주의 깊게 조정하고 최적의 성능과 안정성을 보장해야 합니다.

이점과 이러한 제한 사항을 비교하고 PgBouncer가 특정 애플리케이션 및 데이터베이스 설정에 적합한 선택인지 평가해야 합니다.

II. AKS 사이드카로 배포된 PgBouncer

애플리케이션이 컨테이너화되어 AKS(Azure Kubernetes Service), ACI(Azure Container Instance), ACA(Azure Container Apps) 또는 ARO(Azure Red Hat OpenShift)에서 실행되는 경우 PgBouncer를 사이드카 컨테이너로 활용할 수 있습니다. 사이드카 패턴은 사이드카 컨테이너로 알려진 보조 컨테이너가 부모 애플리케이션에 연결되는 오토바이에 연결된 사이드카 개념에서 영감을 얻었습니다. 이 패턴은 기능을 확장하고 보충 지원을 제공하여 부모 애플리케이션을 보강합니다.

사이드카 패턴은 일반적으로 원자성 컨테이너 그룹으로 공동 예약되는 컨테이너와 함께 사용됩니다. AKS 사이드카에 PgBouncer를 배포하면 애플리케이션과 사이드카 수명 주기가 긴밀하게 결합되고 호스트 이름 및 네트워킹과 같은 리소스를 공유하여 리소스를 효율적으로 사용할 수 있습니다. PgBouncer 사이드카는 1:1 매핑을 통해 AKS(Azure Kubernetes Service)의 동일한 Pod 내의 애플리케이션 컨테이너와 함께 작동하며 Azure Database for PostgreSQL 유연한 서버에 대한 연결 풀링 프록시 역할을 합니다.

이 사이드카 패턴은 일반적으로 원자성 컨테이너 그룹으로 공동 예약되는 컨테이너에 사용됩니다. 사이드카 패턴은 애플리케이션과 사이드카 수명 주기를 강력하게 바인딩하며 호스트 이름 및 네트워킹과 같은 리소스를 공유합니다. PgBouncer는 이 설정을 사용하여 연결 관리를 최적화하고 애플리케이션과 Azure Database for PostgreSQL 유연한 서버 인스턴스 간의 효율적인 통신을 촉진합니다.

Microsoft는 Microsoft 컨테이너 레지스트리에 PgBouncer 사이드카 프록시 이미지를 게시했습니다.

자세한 내용은 이 정보를 참조하세요.

Diagram for App co-location on Sidecar.

이 배포 방법의 주요 이점 및 제한 사항은 다음과 같습니다.

이점:

대기 시간 감소:PgBouncer를 AKS 사이드카로 배포하면 기본 애플리케이션과 연결 풀러 간의 통신이 근접성으로 인해 원활하고 효율적입니다. AKS 사이드카에 PgBouncer를 배포하면 대기 시간이 최소화되고 원활하고 신속한 상호 작용이 보장됩니다.
간소화된 관리 및 배포:PgBouncer와 애플리케이션 컨테이너의 긴밀한 결합으로 관리 및 배포 프로세스가 간소화됩니다. 두 구성 요소 모두 긴밀하게 통합되어 있어 관리가 더 쉽고 원활한 조정이 가능합니다.
고가용성 및 연결 복원력: 애플리케이션 컨테이너가 실패하거나 다시 시작되면 PgBouncer 사이드카 컨테이너가 밀접하게 뒤따라 고가용성을 보장합니다. 이 설정은 연결 복원력을 보장하고 장애 조치(failover) 중에도 예측 가능한 성능을 유지하여 안정적이고 강력한 시스템에 기여합니다.

PgBouncer를 AKS 사이드카로 고려하면 이러한 이점을 활용하여 애플리케이션 성능을 향상하고 관리를 간소화하며 연결 풀러의 지속적인 가용성을 보장할 수 있습니다.

제한 사항:

연결 성능 문제: 각각 사이드카 PgBouncer를 실행하는 수천 개의 Pod를 활용하는 대규모 애플리케이션은 데이터베이스 연결 소진과 관련된 잠재적인 문제에 직면할 수 있습니다. 이러한 상황은 성능 저하 및 서비스 중단을 초래할 수 있습니다. 각 Pod에 사이드카 PgBouncer를 배포하면 데이터베이스 서버에 대한 동시 연결 수가 늘어나 용량을 초과할 수 있습니다. 결과적으로, 데이터베이스는 들어오는 많은 양의 연결을 처리하는 데 어려움을 겪을 수 있으며 응답 시간 증가 또는 서비스 중단과 같은 성능 문제가 발생할 수 있습니다.
복잡한 배포: 사이드카 패턴을 활용하면 동일한 Pod 내에서 두 개의 컨테이너를 실행해야 하므로 배포 프로세스가 어느 정도 복잡해집니다. 이로 인해 잠재적으로 문제 해결 및 디버깅 작업이 복잡해질 수 있으며 문제를 식별하고 해결하는 데 추가 활동이 필요할 수 있습니다.
크기 조정 문제: 사이드카 패턴은 높은 확장성을 요구하는 애플리케이션에 이상적인 선택이 아닐 수 있다는 점에 유의해야 합니다. 사이드카 컨테이너를 포함하면 더 많은 리소스 요구 사항이 부과되어 잠재적으로 효과적으로 만들고 관리할 수 있는 Pod 수가 제한될 수 있습니다.

이 사이드카 패턴을 고려하는 동안 배포 복잡성과 확장성 요구 사항 간의 균형을 신중하게 평가하여 특정 애플리케이션 시나리오에 가장 적절한 방식을 결정해야 합니다.

2. 애플리케이션 독립적 - 중앙 집중식 PgBouncer 배포

이 방식을 활용하면 PgBouncer는 애플리케이션과 별개로 중앙 집중식 서비스로 배포됩니다. PgBouncer 서비스는 다음과 같이 기존 가상 머신이나 마이크로 서비스 기반 아키텍처 내에 배포할 수 있습니다.

9\. Azure Load Balancer 뒤의 Ubuntu VM에 배포된 PgBouncer

PgBouncer 연결 프록시는 이미지에 표시된 대로 Azure Load Balancer 뒤의 애플리케이션과 데이터베이스 계층 사이에 설정됩니다. 이 패턴에서는 단일 실패 지점을 완화하기 위해 여러 PgBouncer 인스턴스가 부하 분산 장치 뒤에 서비스로 배포됩니다. 이 패턴은 애플리케이션이 Azure App Services 또는 Azure Functions와 같은 관리되는 서비스에서 실행되고 기존 인프라와 쉽게 통합하기 위해 PgBouncer 서비스에 연결하는 시나리오에도 적합합니다.

Azure Database for PostgreSQL 유연한 서버를 사용하여 PgBouncer 연결 풀링 프록시를 설치하고 설정하려면 링크를 참조하세요.

Diagram for App co-location on Vm with Load Balancer.

이 배포 방법의 주요 이점 및 제한 사항은 다음과 같습니다.

이점:

단일 실패 지점 제거: Azure Load Balancer 뒤에는 여러 PgBouncer 인스턴스가 있으므로 단일 PgBouncer VM 오류가 애플리케이션 연결에 영향을 미치지 않을 수 있습니다.
관리되는 서비스와의 원활한 통합: 애플리케이션이 Azure App Services 또는 Azure Functions와 같은 관리되는 서비스 플랫폼에서 호스트되는 경우 VM에 PgBouncer를 배포하면 기존 인프라와 쉽게 통합할 수 있습니다.
Azure VM에서 간소화된 설정: 이미 Azure VM에서 애플리케이션을 실행하고 있는 경우 동일한 VM에서 PgBouncer를 설정하는 것은 간단합니다. VM에 PgBouncer를 배포하면 PgBouncer가 애플리케이션에 가까운 위치에 배포되어 네트워크 대기 시간이 최소화되고 성능이 최대화됩니다.
비침해적 구성: VM에 PgBouncer를 배포하면 Azure Database for PostgreSQL 유연한 서버에서 서버 매개 변수 수정을 방지할 수 있습니다. 이는 Azure Database for PostgreSQL 유연한 서버 인스턴스에서 PgBouncer를 구성하려는 경우에 유용합니다. 예를 들어, Azure Database for PostgreSQL 유연한 서버에서 SSLMODE 매개 변수를 "필수"로 변경하면 SSLMODE=FALSE를 사용하는 특정 애플리케이션이 실패할 수 있습니다. PgBouncer를 별도의 VM에 배포하면 PgBouncer의 이점을 계속 사용하면서 기본 서버 구성을 유지할 수 있습니다.

이러한 이점을 고려하여 VM에 PgBouncer를 배포하면 Azure 인프라에서 실행되는 애플리케이션의 성능과 호환성을 향상시키기 위한 편리하고 효율적인 솔루션을 제공합니다.

제한 사항:

관리 오버헤드:PgBouncer가 VM에 설치되므로 여러 구성 파일을 관리하기 위한 관리 오버헤드가 있을 수 있습니다. 이로 인해 버전 업그레이드, 새 릴리스, 제품 업데이트에 대처하기가 어려워집니다.
기능 패리티: 기존 PostgreSQL에서 Azure Database for PostgreSQL 유연한 서버로 마이그레이션하고 PgBouncer를 사용하는 경우 일부 기능 차이가 있을 수 있습니다. 예를 들어, Azure Database for PostgreSQL 유연한 서버에서는 md5 지원이 부족합니다.

II. AKS 내에서 서비스로 배포된 중앙 집중식 PgBouncer

수백 개의 Pod로 구성된 AKS(Azure Kubernetes Service)에서 확장성이 뛰어나고 컨테이너화된 대규모 배포로 작업하는 경우 또는 여러 애플리케이션이 공유 데이터베이스에 연결해야 하는 상황에서는 PgBouncer가 사이드카 컨테이너가 아닌 독립형 서비스로 사용될 수 있습니다.

PgBouncer를 별도의 서비스로 활용하면 더 넓은 규모의 애플리케이션에 대한 연결 풀링을 효율적으로 관리하고 처리할 수 있습니다. 이 방식을 사용하면 연결 풀링 기능을 중앙 집중화할 수 있으므로 최적의 성능과 리소스 사용률을 유지하면서 여러 애플리케이션이 동일한 데이터베이스 리소스에 연결할 수 있습니다.

Microsoft 컨테이너 레지스트리에 게시된 PgBouncer 사이드카 프록시 이미지를 사용하여 서비스를 만들고 배포할 수 있습니다.

Diagram for PgBouncer as a service within AKS.

이 배포 방법의 주요 이점 및 제한 사항은 다음과 같습니다.

이점:

안정성 향상:PgBouncer를 독립형 서비스로 배포하면 가용성이 높은 방식으로 구성할 수 있습니다. 이는 연결 풀링 인프라의 전반적인 안정성을 개선시켜 장애나 중단이 발생하는 경우에도 지속적인 가용성을 보장합니다.
최적의 리소스 사용률: 애플리케이션이나 데이터베이스 서버의 리소스가 제한되어 있는 경우 PgBouncer 서비스 실행 전용으로 별도의 컴퓨터를 선택하는 것이 유리할 수 있습니다. 리소스가 충분한 컴퓨터에 PgBouncer를 배포하면 최적의 성능을 보장하고 리소스 경합 문제를 방지할 수 있습니다.
중앙 집중식 연결 관리: 데이터베이스 연결의 중앙 집중식 관리가 필요한 경우 독립형 PgBouncer 서비스가 보다 효율적인 방식을 제공합니다. 연결 관리 작업을 중앙 집중식 서비스로 통합하면 여러 애플리케이션에 걸쳐 데이터베이스 연결을 효과적으로 모니터링하고 제어하여 관리를 간소화하고 일관성을 보장할 수 있습니다.

PgBouncer를 AKS 내의 독립형 서비스로 고려하면 이러한 이점을 활용하여 개선된 안정성, 리소스 효율성 및 데이터베이스 연결의 중앙 집중식 관리를 달성할 수 있습니다.

제한 사항:

늘어난 N/W 대기 시간:PgBouncer를 독립형 서비스로 배포할 때 추가 대기 시간이 발생할 가능성을 고려해야 합니다. 이는 네트워크를 통해 애플리케이션과 PgBouncer 서비스 간에 연결이 전달되어야 하기 때문입니다. 애플리케이션의 대기 시간 요구 사항을 평가하고 중앙 집중식 연결 관리와 잠재적인 대기 시간 문제 간의 균형을 고려해야 합니다.

독립형 서비스로 실행되는 PgBouncer는 중앙 집중식 관리 및 리소스 최적화와 같은 이점을 제공하지만 애플리케이션 성능에 대한 잠재적인 대기 시간의 영향을 평가하여 애플리케이션이 특정 요구 사항에 부합하는지 확인해야 합니다.

3. Azure Database for PostgreSQL 유연한 서버에 기본 제공 PgBouncer

Azure Database for PostgreSQL 유연한 서버는 기본 제공 연결 풀링 솔루션으로 PgBouncer를 제공합니다. 이는 데이터베이스 서버별로 사용하도록 설정할 수 있는 선택적 서비스로 제공됩니다. PgBouncer는 Azure Database for PostgreSQL 유연한 서버 인스턴스와 동일한 가상 머신에서 실행됩니다. 연결 수가 수백 또는 수천 개 이상으로 증가하면 Azure Database for PostgreSQL 유연한 서버에서 리소스 제한 사항이 발생할 수 있습니다. 이러한 경우 기본 제공된 PgBouncer는 데이터베이스 서버에서 유휴 및 단기 연결 관리를 개선하여 상당한 이점을 제공할 수 있습니다.

Azure Database for PostgreSQL 유연한 서버에서 PgBouncer 연결 풀링을 사용하도록 설정하고 설정하려면 링크를 참조하세요.

이 배포 방법의 주요 이점 및 제한 사항은 다음과 같습니다.

이점:

원활한 구성: Azure Database for PostgreSQL 유연한 서버에 기본 제공된 PgBouncer를 사용하면 별도의 설치나 복잡한 설정이 필요하지 않습니다. 서버 매개 변수에서 직접 쉽게 구성할 수 있어 번거로움 없는 환경을 보장합니다.
관리되는 서비스 편의성: 관리되는 서비스로서 사용자는 다른 Azure 관리되는 서비스의 이점을 누릴 수 있습니다. 여기에는 자동 업데이트가 포함되어 수동 유지 관리가 필요 없으며 PgBouncer가 최신 기능과 보안 패치를 통해 최신 상태로 유지됩니다.
공용 및 프라이빗 연결 지원: Azure Database for PostgreSQL 유연한 서버에 기본 제공된 PgBouncer는 공용 및 프라이빗 연결을 모두 지원합니다. 이를 통해 사용자는 특정 요구 사항에 따라 개인 네트워크를 통해 보안 연결을 설정하거나 외부로 연결할 수 있습니다.
HA(고가용성): 대기 서버가 기본 역할로 승격되는 장애 조치(failover)의 경우 PgBouncer는 애플리케이션 연결 문자열을 변경하지 않고 새로 승격된 대기 상태에서 원활하게 다시 시작합니다. 이를 통해 지속적인 가용성이 보장되고 애플리케이션 중단이 최소화됩니다.
비용 효율성: 사용자가 VM이나 컨테이너와 같은 추가 컴퓨팅 비용을 지불할 필요가 없으므로 비용 효율적입니다. 단, 동일한 컴퓨터에서 실행되는 다른 프로세스이므로 CPU에 어느 정도 영향을 미칩니다.

Azure Database for PostgreSQL 유연한 서버에 기본 제공되는 PgBouncer를 통해 사용자는 간소화된 구성의 편리함, 관리되는 서비스의 안정성, 다양한 풀링 모드 지원 및 장애 조치(failover) 시나리오 중 원활한 고가용성을 누릴 수 있습니다.

제한 사항:

Burstable에서 지원되지 않음:PgBouncer는 현재 Burstable 서버 컴퓨팅 계층에서 지원되지 않습니다. 컴퓨팅 계층을 범용 또는 메모리 최적화에서 버스트 가능 계층으로 변경하면 PgBouncer 기능이 손실됩니다.
다시 시작한 후 연결 재설정: 크기 조정 작업, HA 장애 조치(failover) 또는 다시 시작 중에 서버가 다시 시작될 때마다 PgBouncer도 서버 가상 머신과 함께 다시 시작됩니다. 따라서 기존 연결을 다시 설정해야 합니다.

우리는 PgBouncer를 구현하는 다양한 방법을 토론했으며 표에는 선택할 배포 방법이 요약되어 있습니다.