연결 풀 구성

연결 풀러는 데이터베이스 연결을 관리하는 소프트웨어 구성 요소입니다. 이는 여러 가지 방법으로 리소스 활용도를 향상하고 로드 밸런싱 또는 장애 조치에 도움이 되며 트랜잭션 시간을 크게 줄일 수 있습니다. 이번 블로그 게시물에서는 연결 풀러가 무엇이고 어떻게 구성하는지 알아보겠습니다.

연결 풀러는 소프트웨어 구성 요소입니다. 데이터베이스 연결을 관리합니다. 이는 여러 가지 방법으로 리소스 활용도를 향상하고 로드 밸런싱 또는 장애 조치에 도움이 되며 트랜잭션 시간을 크게 줄일 수 있습니다. 이번 블로그 게시물에서는 연결 풀러가 무엇이고 어떻게 구성하는지 알아보겠습니다.

연결 풀러가 무엇이며 왜 유용한가요

데이터베이스에 대한 연결을 열려면 시간이 걸립니다. 많은 단계. 서버에 연결하고 초기 핸드셰이크를 수행하고 암호화 및 연결 설정에 동의한 다음 모든 계층(네트워크 드라이버, OS 계층, 데이터베이스 계층 등)에서 새로운 연결 리소스를 유지해야 합니다. 각 연결은 데이터베이스 엔진에 따라 크기가 달라지는 메모리를 소비합니다. PostgreSQL의 경우 한 연결에 대해 1.3MB의 메모리가 될 수도 있습니다. 연결을 여는 것도 새 연결의 설정을 협상해야 하기 때문에 시간이 걸립니다.

각 SQL 쿼리에 대해 새 연결을 계속 열면 데이터베이스 서버에 여러 가지 문제가 발생할 수 있습니다.

• 연결을 열려면 시간과 리소스가 필요하므로 거래 속도가 느려집니다

• 활성 연결의 한도를 초과할 수 있습니다(기본적으로 다음과 같이 설정할 수 있음). 100개의 연결 정도)

• 데이터베이스가 더 많은 메모리를 소비하여 캐시 적중률과 쿼리에 사용할 수 있는 여유 메모리에 부정적인 영향을 미칠 수 있습니다.

열지 않고 각 SQL 쿼리에 대해 새 연결을 생성하면 연결을 풀링할 수 있습니다. 연결 양을 유지하고 모든 클라이언트에 대해 재사용하는 연결 풀러를 구성할 수 있습니다. 이런 방식으로 애플리케이션은 데이터베이스 대신 풀러에 직접 연결되고 풀러는 데이터베이스에 연결됩니다. 이는 다음과 같은 여러 가지 이점을 제공합니다.

• 연결 풀러는 연결을 훨씬 더 오랫동안 열어두어 데이터베이스 끝에서 연결을 열고 닫는 오버헤드를 줄이고 대기 시간을 줄입니다.

• 연결 간 또는 데이터베이스 간 로드 밸런싱을 통해 성능을 높일 수 있습니다.

• 풀러는 안정적인 연결 수를 유지할 수 있으므로 문제를 피할 수 있습니다. 활성 연결이 너무 많아 리소스 사용량이 줄어듭니다.

• 풀러는 기본 서버와 대기 서버 간의 연결을 리디렉션하여 안정성과 확장성을 높이는 장애 조치를 제공할 수 있습니다.

• 풀러는 데이터베이스의 비밀번호를 중앙 위치에 저장할 수 있어 보안이 강화됩니다.

• 풀러는 결과를 캐시하여 쿼리 성능을 향상시킬 수 있습니다.

연결 풀러에는 몇 가지 단점도 있습니다.

• 실패 지점이 될 수 있는 시스템의 또 다른 구성 요소입니다.

• 애플리케이션과 데이터베이스 간의 또 다른 네트워크 홉으로 인해 네트워크 대기 시간이 약간 증가할 수 있습니다.

• 비효율적인 연결 풀러는 병목 현상을 일으킬 수 있습니다.

• 유지 관리 부담을 증가시키는 연결 풀러를 조정하고 유지 관리해야 합니다.

다양한 유형의 연결 풀링

여러 가지가 있습니다. 연결 풀링을 구현하는 방법. 이 섹션에서는 다양한 구현 세부 사항을 살펴봅니다.

외부 또는 내부 연결 풀러

일반적인 경우 애플리케이션에서 데이터베이스로 연결합니다. 이제 애플리케이션 자체 또는 애플리케이션과 데이터베이스 사이의 두 위치 중 하나에 연결 풀러를 배치할 수 있습니다.

애플리케이션에 연결 풀을 배치하는 것은 매우 쉬울 수 있습니다(애플리케이션 측 연결 풀러). 많은 ORM이나 데이터베이스 드라이버가 즉시 이를 지원합니다. 예를 들어 JDBC는 c3p0을 통해 이를 지원하고 ODBC는 기본적으로 이를 지원합니다. 이는 많은 이점을 가져옵니다. 풀러가 애플리케이션 내부에 있으므로 추가 구성 요소를 설치하고 유지 관리할 필요가 없습니다. 새 버전의 애플리케이션만 배포하고 풀링을 준비하면 됩니다. 추가 네트워크 홉이 없기 때문에 네트워크 대기 시간도 줄어듭니다(모든 것이 애플리케이션 내에 있음).

안타깝게도 애플리케이션 측 연결 풀러에는 몇 가지 단점이 있습니다. 가장 큰 점은 하나의 애플리케이션에만 구성되어 있다는 것입니다. 애플리케이션이 많은 경우(특히 분산 환경)에는 여러 위치에서 풀러를 구성해야 합니다. 풀러가 서로에 대해 모르기 때문에 서버 측에서 여전히 연결 수 제한에 도달할 수 있다는 점은 말할 것도 없습니다. 연결 풀러가 많으면 리소스 사용량이 늘어나고 일반적으로 성능이 저하됩니다.

애플리케이션과 데이터베이스 사이에 위치하는 외부 연결 풀러를 사용할 수도 있습니다. 이는 다양한 애플리케이션에서 작동할 수 있으며 연결 제한을 정확하게 제어할 수 있습니다. 중앙 집중식 연결 풀러는 리소스를 더 효과적으로 제어할 수 있으며 장애 조치 또는 부하 분산을 달성할 수 있습니다.

외부 연결 풀러에도 몇 가지 단점이 있습니다. 무엇보다도 이는 시간이 지남에 따라 설치, 구성, 조정 및 유지 관리해야 하는 또 다른 구성 요소입니다. 또한 연결 풀러를 사용하도록 모든 애플리케이션을 재구성해야 합니다. 이는 일부 연결 문자열을 변경하고 애플리케이션을 재배포하는 것만큼 간단해야 합니다. 외부 풀러는 애플리케이션과 데이터베이스 사이의 또 다른 네트워크 구성 요소이므로 약간의 네트워크 대기 시간을 추가합니다.

외부 연결 풀러도 실패 지점이 될 수 있습니다. 어떤 이유로든 풀러가 다운되면 애플리케이션은 더 이상 데이터베이스에 연결할 수 없습니다. 풀러가 느리거나 비효율적이면 이를 사용하는 모든 응용 프로그램에 영향을 미칩니다. 따라서 전체 성능이 저하되지 않도록 풀러의 품질이 높아야 합니다.

풀링 유형

각 풀러는 클라이언트에 연결을 할당하는 방법을 결정해야 합니다. 일반적으로 세 가지 접근 방식이 있습니다.

첫 번째는 세션 풀링입니다. 이 접근 방식에서는 세션이 진행되는 동안 클라이언트에 연결이 할당됩니다(클라이언트 연결이 끊기거나 시간 초과에 도달할 때까지). 이는 가장 쉬운 접근 방식이지만 일반적으로 각 클라이언트가 하나의 연결을 소비하므로 클라이언트 수를 효과적으로 제한합니다.

다음 솔루션은 트랜잭션 풀링입니다. 이 접근 방식에서 풀러는 각 트랜잭션과 트랜잭션 기간 동안에만 연결을 할당합니다. 클라이언트가 다른 트랜잭션을 실행하려면 다른 연결을 얻어야 합니다(그리고 다른 연결이 사용 가능해질 때까지 기다려야 할 수도 있습니다). 이렇게 하면 풀러가 더 많은 클라이언트를 처리할 수 있으므로 권장되는 접근 방식입니다.

마지막 접근 방식은 각 SQL 문에 대한 연결을 독립적으로 할당하는 것입니다. 이론적으로 이는 최고의 유연성과 연결 활용도를 제공합니다. 그러나 이로 인해 하나의 트랜잭션이 여러 연결에 걸쳐 있게 됩니다. 많은 트랜잭션 설정이 연결에 묶여 있으므로 이는 기술적인 제한이 될 수 있습니다.

연결 풀링 솔루션

사용하는 데이터베이스 유형에 따라 일부 내장 솔루션이 있을 수 있거나, 수동으로 구성해야 할 수도 있습니다. 몇 가지 예를 살펴보겠습니다.

내장 솔루션

인프라 제공업체에 따라 내장 또는 거의 내장된 솔루션을 사용할 수 있습니다.

• Neon PostgreSQL 데이터베이스에는 PgBouncer가 내장되어 있습니다

• Supabase에는 Supavisor가 내장되어 있습니다

• PostgreSQL용 Azure 데이터베이스 내장 PgBouncer 지원

• DigitalOcean의 PostgreSQL에는 PgBouncer가 포함됩니다

• Azure 데이터베이스는 ProxySql과 함께 사용할 수 있습니다

• Azure 데이터베이스는 Heimdall 데이터베이스 프록시와 함께 사용할 수 있습니다

• ADO.NET은 내장 연결 풀을 지원합니다

• Oracle은 범용 연결 풀을 지원합니다 JDBC용

• Oracle Autonomous Database는 데이터베이스 상주 연결 풀을 지원합니다

외부 솔루션

다양한 외부 솔루션이 있습니다 사용:

• Amazon RDS Proxy

• Pgpool

• PgBouncer

• odyssey

• Heimdall 데이터베이스 프록시

• ProxySQL

• pgcat

사례 연구: PgBouncer 구성

이 예에서는 PgBouncer를 살펴보겠습니다.

문서에 나온 대로 설치부터 시작합니다.

그런 다음 구성해야 합니다. 가장 중요한 설정은 다음과 같습니다.

• pool_mode: 연결 처리 방법; 트랜잭션을 사용할 수 있습니다

• max_client_conn: 연결 풀러에 연결할 수 있는 클라이언트 수를 구성합니다.

• default_pool_size: 허용되는 서버 연결 수를 구성합니다. 각 사용자 데이터베이스에 대해

• min_pool_size: 보관할 대기 연결 수

풀러를 구성한 후 pgbench를 사용하여 성능을 확인할 수 있습니다.

pgbench -c 10 -p -j 2 -t 1000 database_name

PgBouncer는 벤치마크에서 볼 수 있듯이 초당 트랜잭션 수를 60%까지 쉽게 늘릴 수 있습니다.

• PostgreSQL 연결 풀러 벤치마킹: PgBouncer, PgCat 및 Supavisor

• 연결 풀링으로 데이터베이스 성능 향상

• PgBouncer로 PostgreSQL 강화

요약

연결 풀러는 성능을 향상시키고 리소스 소비를 줄일 수 있습니다. 호스팅 위치와 사용 중인 데이터베이스 엔진에 관계없이 데이터베이스와 함께 쉽게 사용할 수 있는 내장 솔루션이 많이 있습니다. 연결 풀러는 또 다른 실패 지점이므로 주의해서 처리해야 한다는 점을 명심해야 합니다. 잘 구성된 연결 풀러는 초당 트랜잭션 수를 거의 두 배로 늘려 성능을 크게 향상시킬 수 있습니다.

위 내용은 연결 풀 구성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!