RDS 연결 수가 급증할 때: 연결 풀 크기와 배포·장애 전환 점검

AI Editter

평소에는 정상인데 배포할 때만 too many connections가 발생한다면 DB 연결 상한을 늘리기 전에 앱의 전체 연결 수를 계산해 봐야 합니다. 서버 한 대의 풀 크기가 작아도 복제 수와 프로세스 수가 곱해지면 DB 상한을 넘을 수 있습니다.

연결 수 증가는 실제 쿼리 동시 실행, 사용하지 않는 유휴 연결, 반환되지 않은 연결, 긴 트랜잭션을 나눠 봅니다. 각각 해결 방법이 다릅니다.

풀 크기 10이 전체 10개라는 뜻은 아니다

가상 서비스에 앱 복제 6개, 복제당 프로세스 4개, 프로세스당 최대 풀 10개가 있다면 앱이 열 수 있는 연결은 최대 240개입니다. 배포 중 구·신 버전이 모두 존재하면 일시적으로 더 늘 수 있습니다.

앱 최대 연결 = 복제 수 × 프로세스 수 × 프로세스별 풀 상한
전체 예상 연결 = 앱 + 배치 + 관리·모니터링 + 배포 중첩분

실제로 풀이 필요할 때만 연결을 열 수 있어도 최악의 동시 상황을 검토해야 합니다. 최소 연결 수를 크게 잡으면 시작만 해도 많은 유휴 연결이 생길 수 있습니다.

DB의 상한과 여유를 확인

PostgreSQL에서 현재 설정과 세션 분포를 조회합니다. 권한에 따라 다른 세션의 일부 정보가 제한될 수 있습니다.

SHOW max_connections;

SELECT application_name, usename, state, count(*) AS connections
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY application_name, usename, state
ORDER BY connections DESC;

예약 연결과 관리 작업에 필요한 여유를 빼고 앱 예산을 정합니다. 모든 연결 슬롯을 앱 풀에 배분하면 장애 시 진단용 접속도 어려워질 수 있습니다.

RDS 연결 상한은 엔진·메모리·파라미터에 영향을 받습니다. AWS는 상한을 과도하게 높이면 메모리 문제가 생길 수 있다고 안내합니다. RDS 연결 제한 문서를 참고하고, 숫자만 늘리는 조치는 메모리와 부하를 함께 검증합니다.

연결 대기와 쿼리 실행시간을 구분

애플리케이션에서 DB 요청 전체가 2초 걸려도 실제 쿼리는 50ms이고 풀 대기가 대부분일 수 있습니다. 풀 획득 대기시간, 사용 중 연결 수, 유휴 연결 수, 획득 실패를 따로 기록합니다.

반대로 긴 쿼리나 트랜잭션이 연결을 오래 점유하면 풀을 키워도 DB에 더 많은 부하를 밀어 넣을 수 있습니다. idle in transaction 상태와 트랜잭션 시작 시각, 잠금 대기를 함께 확인합니다.

SELECT pid, application_name, state,
       now() - xact_start AS transaction_age,
       wait_event_type, wait_event
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

오래됐다는 이유만으로 세션을 일괄 종료하지 않습니다. 해당 업무와 트랜잭션의 영향을 확인하고, 우선 앱에서 정상 종료·타임아웃·연결 반환이 되도록 수정합니다.

풀 설정에는 대기와 재시도도 포함

최대 풀 크기뿐 아니라 연결 획득 제한시간, 연결 유효성 검사, 유휴·수명 정책, 쿼리 제한시간을 정합니다. 장애 때 모든 워커가 즉시 재연결을 반복하면 회복 중인 DB에 연결 폭주를 만들 수 있습니다.

재시도는 간격과 횟수를 제한하고 지연을 분산합니다. 쓰기 요청은 재시도해도 중복 반영되지 않는 업무 키와 트랜잭션 설계가 필요합니다. 연결 오류가 났다는 이유로 이전 거래가 반드시 실패했다고 가정할 수는 없습니다.

RDS Proxy와 PgBouncer는 적용 후에도 시험

두 도구는 다수 클라이언트의 연결을 더 적은 DB 연결로 재사용하는 데 도움을 줄 수 있습니다. 다만 운영 책임, 인증, 장애 전환, 세션 상태 처리 방식이 다릅니다. AWS의 두 풀러 비교를 검토합니다.

세션 상태에 의존하는 작업은 특정 DB 연결을 계속 사용해야 할 수 있습니다. RDS Proxy의 pinning이 많으면 재사용 효과가 줄어듭니다. 임시 테이블, 세션 설정, 드라이버 동작 등은 사용하는 엔진과 버전의 pinning 조건을 확인합니다.

도입 후 “프록시 연결 성공”만 보지 말고 실제 DB 연결 수, 풀 대기, 세션 고정, 쿼리 결과를 비교합니다.

배포와 장애 전환 시험표

풀 크기를 줄였더니 대기가 조금 늘어도 DB 과부하가 줄어 전체 응답이 나아질 수 있고, 너무 줄이면 필요한 처리량을 못 낼 수 있습니다. 실제 업무량과 허용 지연을 기준으로 조정하고, 최종 설정에는 복제 수를 늘릴 때 다시 계산해야 한다는 운영 조건을 남깁니다.

관련 절차: PostgreSQL 느린 쿼리 분석: EXPLAIN ANALYZE를 읽는 순서