NestJS + Prisma + AWS RDS 성능 최적화

Connection Pool 전략 완전 가이드

NestJS와 Prisma, 그리고 AWS RDS를 함께 사용하는 프로젝트는 매우 많습니다.
하지만 실무에서 꽤 흔하게 겪는 문제가 있습니다.

바로 Connection Pool 과부하로 인한 느려짐, DB 연결 에러, 대기 시간 증가 같은 성능 문제입니다.

특히 다음 상황에서는 문제가 더 자주 발생합니다.

NestJS API가 서버리스(Lambda) 또는 오토스케일링 환경일 때
Prisma가 매 요청마다 새로운 DB 커넥션을 생성할 때
RDS의 max_connections 값을 초과할 때
Prisma를 싱글턴으로 만들지 않고 DI로 여러 개 생성한 경우
대규모 읽기/쓰기 트래픽이 동시에 몰릴 때

이 글에서는 Prisma Connection Pool 이해 → 문제 발생 원인 → 최적화 전략 → 실전 코드 예제 순으로
정리해보겠습니다.

1. Prisma의 Connection Pool 동작 방식

Prisma는 내부적으로 데이터베이스 연결을 풀(pool) 형태로 관리합니다.
즉, DB에 연결을 여러 개 만들어두고 요청마다 필요한 연결을 빠르게 가져와 사용하게 하죠.

하지만 개발자가 잘못 설정하거나 NestJS 구조가 복잡하면 풀 생성 로직이 꼬이면서 다음과 같은 문제가 발생합니다.

❌ 문제 사례 1: 매 요청마다 PrismaClient가 새로 생성됨

예:

const prisma = new PrismaClient();

이 코드를 DI 없이 서비스마다 생성하거나, 서버리스에서 매 실행마다 초기화하면…

DB 연결 폭증
RDS max_connections 초과
Too many connections 발생

❌ 문제 사례 2: RDS의 기본 max_connections 한계

AWS RDS의 max_connections는 인스턴스 타입에 따라 정해집니다.

예:

db.t3.micro → 약 90개
db.t3.small → 약 150개
db.t3.medium → 약 300개

트래픽 많은 API는 금방 초과합니다.

2. NestJS + Prisma 환경에서 나타나는 전형적인 문제

① API 요청이 많을 때 속도가 급격히 저하됨

Connection Pool이 초과되면 DB가 새 연결을 거절하거나 대기 큐로 밀려납니다.

② 500 에러 - Too many connections

RDS에서 흔히 나타나는 오류:

ERROR: remaining connection slots are reserved for non-replication superuser connections

③ 서버리스 환경에서 Prisma가 폭발적으로 커넥션 생성

Lambda + Prisma 조합에서 악명 높아요.

④ NestJS 모듈 구조가 커지면서 PrismaClient가 여러 개 생김

싱글턴 패턴을 반드시 지켜야 함.

3. 성능 최적화를 위한 4가지 핵심 전략

전략 1. PrismaClient를 무조건 싱글턴으로 관리하기

NestJS에서는 Provider를 통해 PrismaClient를 싱글턴으로 구성할 수 있습니다.

PrismaService 구현 예제

import { Injectable, OnModuleInit, OnModuleDestroy } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit, OnModuleDestroy {
  async onModuleInit() {await this.$connect();
  }

  async onModuleDestroy() {await this.$disconnect();
  }
}

AppModule에 등록

@Module({
  providers: [PrismaService],
  exports: [PrismaService],
})
export class AppModule {}

이렇게 하면 NestJS 전체에서 PrismaClient는 단 하나만 사용됩니다.

전략 2. Prisma의 Connection Pool 크기 조절하기

Prisma는 DATABASE_URL 뒤에 pool 옵션을 부여할 수 있습니다.

예시 (PostgreSQL)

DATABASE_URL="postgresql://user:pass@host:5432/db?schema=public&connection_limit=5&pool_timeout=10"

주요 옵션

옵션	설명
`connection_limit`	Prisma가 생성하는 최대 DB 연결 수
`pool_timeout`	연결 대기 시간(ms)

전략 3. AWS RDS 설정 최적화

1) max_connections 확인

RDS PostgreSQL:

SHOW max_connections;

여기서 값이 너무 작다면 인스턴스 타입을 한 단계 올려주는 것이 좋습니다.

2) 파라미터 그룹 조정

idle_in_transaction_session_timeout
statement_timeout
max_connections

Timeout 값을 설정하면 불필요한 연결이 오래 점유되는 문제를 해결할 수 있어요.

3) RDS Proxy 고려 (강력 추천)

AWS Lambda·Fargate 같은 환경에서는
RDS Proxy를 끼우면 DB 연결 폭증 문제를 거의 해결할 수 있음.

전략 4. 요청 기반 쿼리 최적화

Connection Pool 튜닝만으로 해결되지 않는 경우도 많습니다.
특히 다음 상황은 애플리케이션 레벨에서 최적화가 필요합니다.

✔ N+1 쿼리가 발생하는 Prisma 구조

예:

await prisma.user.findMany({
  include: { posts: true },
});

대량 데이터면 Pool을 금방 채워버립니다.

✔ 대형 트랜잭션을 나누기

1개 요청이 Pool 10개를 잡아먹는 경우도 있음.

✔ read-only 쿼리를 replica로 분산

RDS read replica를 도입하면 읽기 트래픽을 분산시킬 수 있습니다.

4. 추천 Connection Pool 설정 조합

⭐ 소규모 서버 (t3.micro / t3.small)

connection_limit=3~5  
pool_timeout=10

⭐ 중형 서버 (t3.medium 이상)

connection_limit=10~20  
pool_timeout=5

⭐ 서버리스(Lambda)

connection_limit=1
반드시 RDS Proxy 사용
PrismaClient 재사용 코드 적용

5. 결론: Connection Pool 튜닝은 선택이 아니라 필수

NestJS + Prisma + AWS RDS 조합은 생산성과 구조가 뛰어난 반면,
DB 연결 관리가 조금만 잘못돼도 성능 문제가 즉시 튀어나오는 환경입니다.

핵심은 다음 네 가지입니다:

PrismaClient는 반드시 싱글턴으로 관리할 것
Connection Pool(connection_limit)을 서버 용량에 맞게 조절할 것
AWS RDS 파라미터 + RDS Proxy로 안정성 향상
쿼리 자체도 최적화 필요 (N+1, 과도한 include 등)

이 네 가지만 잡아도 API 반응 속도는 눈에 띄게 빨라지고
RDS connection 폭주 문제는 크게 줄어듭니다.