DSQL 실험 노트
실험 목록으로 돌아가기
E003완료P0

연결 수, 연결 폭증, 풀링

DSQL의 인증·연결 갱신·급증 대응에 어떤 부담이 있는가?

이슈 #3 측정 계획 측정일 2026-09-29

결과 요약

이 실험은 애플리케이션이 DSQL에 연결할 때 IAM 인증과 연결 수립이 얼마나 부담이 되는지, 그리고 연결이 한꺼번에 몰릴 때 거절이나 지연이 생기는지를 확인했습니다. 최소 범위(MVP)로, E002 규모 데이터가 들어 있는 DSQL 클러스터 하나에 대해 부하 발생기 한 대에서 토큰 서명, 순차 연결, 연결 유지와 요청마다 새 연결의 비교, 연결 500개·1,000개 동시 요청을 측정했습니다. 대조군은 이번에 측정하지 않았습니다.

DSQL은 비밀번호 대신 IAM으로 서명한 토큰으로 인증합니다. 토큰 서명은 네트워크 호출 없이 러너 안에서 이루어져 p50 0.2 ms였고, 첫 호출만 클라이언트 초기화로 131 ms가 걸렸습니다. 새 연결을 맺고 첫 조회를 끝내기까지는 순차 실행 100회에서 p50 15.5 ms, p95 109 ms, p99 120 ms였습니다.

연결을 유지한 16개 작업자는 상품 조회를 초당 8,370건(p50 1.9 ms) 처리했지만, 요청마다 새 연결을 맺으면 초당 121건(p50 131 ms)으로 약 70분의 1이 되었습니다. 연결 500개와 1,000개를 한꺼번에 요청했을 때는 모두 거절 없이 성공했지만, 전부 맺어지기까지 각각 3.7초와 8.2초가 걸렸습니다. 이 속도(초당 약 120–135개)는 요청마다 새 연결을 맺을 때의 처리량과 비슷해, DSQL의 연결 수립 속도 제한인지 러너의 단일 Python 프로세스가 TLS 연결을 처리하는 한계인지 이번 측정으로는 구분하지 못했습니다. 폭증 직후 새 연결은 p50 16.2 ms로 평소와 같았습니다.

프로덕션 사용 관점

DSQL의 IAM 토큰 인증 자체는 부담이 작았습니다. 서명은 0.2 ms였고, 토큰을 몇 분씩 재사용하면 연결마다 서명할 필요도 없습니다. 연결 1,000개를 한꺼번에 요청해도 거절되지 않았습니다. 그러나 새 연결 한 번에 15–120 ms가 걸려, 요청마다 연결을 새로 맺는 구조(예: 연결 풀 없이 동작하는 짧은 함수)는 처리량이 연결을 유지할 때의 약 1/70로 떨어졌습니다. 연결 풀을 쓰고, DSQL이 1시간이 지난 연결을 끊으므로 풀이 연결을 주기적으로 교체하게 설정해야 합니다. 대조군과 RDS Proxy 비교는 하지 않았습니다.

확인할 질문

DSQL의 인증·연결 갱신·급증 대응에 어떤 부담이 있는가?

실행 조건

  • 리전과 일시: 서울(ap-northeast-2), 2026-09-29 10:25–10:27 UTC.
  • 구성: D1 Aurora DSQL 단일 리전 클러스터(퍼블릭 엔드포인트), E002 규모 데이터(주문 1,100만 행 등 약 5 GiB). E002 2차 측정과 같은 클러스터입니다.
  • 클라이언트: m7g.4xlarge Spot 러너 1대, Python 3.11, psycopg 3, TLS sslmode=verify-full. 토큰은 generate_db_connect_admin_auth_token으로 서명했습니다.
  • 측정 항목:
    • 토큰 서명 50회.
    • 순차 연결 100회: 새 연결 → SELECT 1 → 닫기.
    • 16개 작업자가 30초 동안 상품 조회: 연결 유지 대 요청마다 새 연결.
    • 연결 500개, 1,000개 동시 요청(비동기 단일 프로세스).
    • 폭증 직후 순차 연결 20회.
  • 계획과 달라진 점: 앱 동시성 16/64/256/1,024와 풀 크기 16/64/128 조합, 60초간 10배 연결 시도, RDS Proxy, 대조군(R1·A1·A2) 비교, 메모리·거부율 측정은 실행하지 않았습니다.

성능 결과

측정 결과
토큰 서명 p50 0.2 ms, p95 0.3 ms, 최대 131.5 ms(첫 호출)
순차 새 연결 + 첫 조회 p50 15.5 ms, p95 109.0 ms, p99 119.7 ms, 오류 0
조회, 연결 유지(16개) 8,370 TPS, p50 1.9 ms, p99 2.4 ms
조회, 요청마다 새 연결(16개) 121 TPS, p50 130.9 ms, p99 247.1 ms
동시 연결 500개 500개 성공, 3.7초, 연결당 p50 3.6초
동시 연결 1,000개 1,000개 성공, 8.2초, 연결당 p50 3.9초, p99 8.2초
폭증 직후 새 연결 p50 16.2 ms, p95 24.6 ms

개발·운영 편의성

  • 인증: 비밀번호를 저장하지 않고 IAM 역할 권한(dsql:DbConnectAdmin)으로 접속합니다. 비밀 정보 교체 작업은 없지만, 연결을 맺는 모든 곳에 토큰 서명 코드가 필요합니다.
  • 동시 서명 문제: E002에서 연결 256개가 동시에 처음 연결할 때 모든 스레드가 토큰을 서명하려 인스턴스 자격 증명을 조회하다 실패(NoCredentialsError)했습니다. 프로세스마다 서명을 한 번만 하도록 잠그고 재시도를 넣어 해결했습니다. 연결 풀 초기화처럼 연결이 몰리는 코드에서 주의가 필요합니다.
  • 연결 수명: DSQL은 1시간이 지난 연결을 끊습니다. E002에서는 50분마다 연결을 교체했습니다.
  • 진단 값의 오해: E004에서 SHOW max_connections가 20을 돌려주었지만 공식 쿼터는 클러스터당 연결 1만 개입니다. 이번에 1,000개 동시 연결이 모두 성공했습니다.

비용

같은 클러스터를 쓴 E002 2차 측정의 일부로, 이 시험 구간(10:26–10:28 UTC)의 DSQL 사용량은 2,603 DPU(약 $0.03)였습니다. 클러스터와 러너 비용은 E002 보고서의 비용 절에 포함했습니다.

결론과 한계

  • IAM 토큰 인증과 연결 폭증은 DSQL에서 큰 부담이 아니었고, 요청마다 새 연결을 맺는 구조가 가장 큰 성능 위험이었습니다.
  • 한계: 1회 실행, 러너 1대의 단일 프로세스 측정입니다. 폭증 시 연결 속도가 클라이언트 한계인지 서비스 제한인지 구분하지 못했습니다. 대조군과 RDS Proxy 비교가 없어 “몇 배”를 말할 수 없습니다.

정리 기록

  • 이 시험은 E002 2차 측정 실행(e002-20260929t081139z-4dce)의 클러스터와 러너를 썼습니다. 자원은 11:08–11:10 UTC에 삭제했고, e002.py verify의 remaining_count=0(11:10:30 UTC)과 수동 교차 확인(DSQL 클러스터·실험 VPC·실험 IAM 역할·열린 Spot 요청 0개)을 마쳤습니다.