Supabase에서 제공하는 PostgreSQL 데이터베이스를 사용하는 Spring Boot 애플리케이션에서 발생한 “max connection error” 관련 정리.
문제 상황
- Supabase(무료 요금제) + PostgreSQL DB + Spring Boot(HikariCP) 구성
- 애플리케이션 구동 시 “
max connection error”라는 에러 메시지가 발생하면서, 서비스가 정상적으로 동작하지 않음 - 특히 동시에 여러 명이 개발/테스트를 진행할 때 에러 빈도가 증가
무료 플랜에서의 제한
- Supabase 무료 플랜에서는 DB 커넥션 수에 제한이 있습니다.
- 예를 들어, “동시에 20개 미만의 연결” 같은 식으로 리소스가 제한되어 있을 수 있습니다(플랜별로 상이).
- 또한, 서버 측 스레드(쓰레드 풀)나 연결 대기 큐가 적어서, HikariCP의 풀 사이즈가 너무 크면 자주 장애가 일어날 수 있습니다.
원인 분석
-
HikariCP의
maximum-pool-size- Spring Boot에서 HikariCP는 기본적으로 최대 풀 사이즈를 대략 10으로 잡거나,
spring.datasource.hikari.maximum-pool-size로 조정할 수 있습니다. - 만약 Supabase의 “동시 연결 제한”이 10보다 작거나, 커넥션의 여유가 별로 없다면 쉽게 초과될 수 있습니다.
- Spring Boot에서 HikariCP는 기본적으로 최대 풀 사이즈를 대략 10으로 잡거나,
-
Supabase 무료 요금제의 제한
- Supabase의 무료 요금제(Nano 스펙 등)에서 PostgreSQL 리소스를 확보할 수 있는 양이 매우 제한적입니다.
- 특정 시점에 동시 트래픽이 몰리거나, 다수의 개발자가 동시에 DB를 요청하면 커넥션이 모자라거나, 커넥션이 너무 오래 걸려 타임아웃이 발생할 수 있습니다.
-
스레드 풀(서버 측)
- 애플리케이션 서버가 클라우드나 호스팅 환경에서 구동되는 경우, 스레드 풀이나 OS 레벨 리소스 제한도 고려해야 합니다.
- 쓰레드가 부족해도 문제가 생기고, 너무 많아도 오버로드가 발생할 수 있습니다.
해결 과정
-
HikariCP 커넥션 풀 사이즈 축소
- 기존 설정:
spring.datasource.hikari.maximum-pool-size=5 - 새로운 설정:
spring.datasource.hikari.maximum-pool-size=3 - Supabase 무료 플랜에서 리소스가 빠듯하다 보니, 풀 사이즈를 조금 더 줄여서 DB와 연결을 맺을 때 과부하가 걸리지 않도록 했습니다.
- 기존 설정:
-
무료 요금제의 스레드 풀 확장
- Supabase 자체 스레드 풀이 아닌, 우리가 배포한 환경(예: 서버, PaaS)의 스레드 풀 설정값을 확인했습니다.
- 원래는 기본 15로 설정되어 있던 것을 30으로 늘렸습니다.
- 이 조정으로, 요청 처리를 위한 스레드가 어느 정도 확보되어 병렬 요청에서 병목 현상이 줄어들었습니다.
-
동료 개발자 인원 고려
- 우리 팀은 동시에 4명이 개발/테스트를 진행합니다.
- “동시에 n명의 개발자가 쿼리를 날린다면, 커넥션이 몇 개 필요할까?”를 계산했습니다.
- 실제로는 db 콘솔, 애플리케이션, 배치 잡 등을 고려하면 한두 번의 요청으로 끝나는 게 아니라 여러 개의 세션이 열릴 수 있습니다.
- 이에 따라, 풀 사이즈를 너무 작게 만들면 성능 저하가 생길 수 있고, 너무 크게 만들면 “max connection error”를 다시 유발할 수 있으므로, 적절한 타협점을 찾았습니다.
조정 후 결과
- 최종 설정
spring.datasource.hikari.maximum-pool-size=3- 서버 스레드 풀: 30 (기존 15)
- 에러 발생
- 이전보다 “
max connection error”가 발생하지 않음 - 오히려 커넥션 풀 사이즈가 줄었음에도, 정상적으로 동작하고 성능상 큰 이슈 없음
- 이전보다 “
TIL 정리
-
무료 플랜 환경 제한
- Supabase, Heroku 등 무료/저가 요금제에서는 DB 연결 수, CPU/메모리, 스레드 제한 등이 낮을 수밖에 없습니다.
- “무조건 큰 풀 사이즈 = 좋은 성능”이 아니라, 실제 리소스 한도를 고려해 적절한 풀 사이즈를 잡는 것이 중요합니다.
-
동시접속자 수 계산
- 우리 팀의 경우, 개발자들이 동시에 접속해 단시간에 여러 쿼리를 날리면 커넥션 풀이 쉽게 바닥날 수 있음.
- 따라서 HikariCP나 서버 스레드 풀을 설정할 때, 최대 동시 처리량을 추정하여 알맞게 튜닝해야 합니다.
-
문제 발견 시 빠른 테스트
- 설정을 하나씩 바꿔보며 어떤 지점에서 에러가 사라지는지, 성능이 정상인지 테스트를 반복했습니다.
- 초기에 애매하게 큰 값으로 설정해두고 “왜 에러가 날까?” 고민하기보다는, 주어진 환경에서 동작 가능한 최소치부터 늘려가는 방식이 효과적이었습니다.
마무리
- 이번 경험을 통해, 무료 플랜 환경에서는 DB 및 스레드 리소스가 극히 제한적이므로 최대한 가볍게 설정해야 한다는 점을 다시금 깨달았습니다.
- HikariCP의
maximum-pool-size를 무작정 높이는 것보다, Supabase에서 허용하는 커넥션 수에 맞춰 세팅해야 합니다.
TIL 결론: “실제 DB와 서버 리소스 제한을 인지하고, HikariCP와 스레드 풀을 적절히 맞추는 것이 중요하다.”
Dreamer