DB 커넥션 풀과 Redis — 확장 가능한 서버 구조를 위한 핵심 정리

 

개인 프로젝트라도 대규모 트래픽을 대비한 구조로 설계해두면 훗날 큰 도움이 된다. 이 글은 서버 개발자의 관점에서 DB 커넥션 풀과 Redis 캐싱을 어떻게 이해해야 하는지 정리한 내용이다.

 

1. DB 커넥션 풀은 왜 필요한가?

DB 연결을 새로 여는 작업은 생각보다 매우 무겁다.

• 네트워크 연결
• 인증
• 소켓 오픈

요청마다 커넥션을 새로 열고 닫으면:

• 응답 속도가 느려지고
• 동시 요청이 많아질수록 DB가 먼저 죽는다

1-1. 커넥션 풀의 역할

Connection Pool

• 서버 시작 시 미리 여러 개의 DB 연결을 만들어 둔다.
• API 요청이 들어오면 → 커넥션 1개를 빌려간다.
• DB 작업 후 → 커넥션을 닫지 않고 풀에 반환한다.

스프링 부트는 기본적으로 HikariCP를 사용한다.

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      max-lifetime: 1800000

정리: 커넥션 풀은 실서비스에서 “필수”에 가깝다.

2. 동시 요청 = 필요한 커넥션 수

2-1. 요청 1개는 커넥션 1개를 사용한다

• MyBatis / JPA / JDBC 관계 없음
• 쿼리가 실행되는 순간 커넥션 1개가 필요
• 트랜잭션 안에서 여러 쿼리를 실행해도 커넥션은 1개만 유지

예를 들어:

• 100명이 동시에 “게시글 리스트 조회” API 요청
• → 100개의 스레드 → 100개의 커넥션 필요

2-2. 커넥션 풀이 부족하면?

maximum-pool-size=10인 상태에서 100명 동시 조회:

• 10명 처리
• 90명 대기
• 대기 시간이 timeout 넘으면 500 에러 발생

핵심: 중요한 건 “사용자 수”가 아니라 “동시 요청 수”다.

 

3. 느린 쿼리는 커넥션을 오래 점유한다

예를 들어 어떤 SELECT 쿼리가 7~8초 걸린다면?

• 그 7~8초 동안 커넥션 1개가 계속 점유된다.
• 이런 쿼리가 여러 개라면 → 풀 전체 커넥션이 묶여 버린다.
• 새 요청들이 커넥션을 얻지 못해 타임아웃 발생

즉, 느린 쿼리 몇 개만 있어도 전체 API가 멈출 수 있다.

 

4. API 서버만 늘리면 되는 게 아니다

많은 초심자들이 “서버를 늘리면 해결되겠지?”라고 생각하지만 실제로는 DB가 먼저 병목에 도달한다.

• API 서버는 Auto Scaling으로 쉽게 늘릴 수 있음
• 하지만 DB는 모든 요청이 몰리기 때문에 확장이 어렵고 비쌈
• 심지어 API 서버를 늘릴수록 DB 부하는 더 증가함

예:

• API 서버 5대 × 풀 크기 20 = 최대 100개 DB 연결
• MySQL 기본 max_connections = 151
• → 조금만 늘어도 DB가 먼저 터진다

 

5. 그래서 Redis가 필요하다

5-1. Redis는 “DB를 보호하는 캐시 계층”

Redis = 메모리 기반 캐싱 서버

• 조회가 많고 자주 변하지 않는 데이터를 캐싱
• DB보다 10~100배 빠른 접근 속도
• 메모리 기반이어서 디스크 IO 병목이 없음

Redis로 캐싱하면 DB에 가지 않아도 되는 데이터의 예:

• 사용자 프로필
• 게시글 목록
• 일정 리스트
• 공지사항
• 설정값

5-2. Redis도 부하는 있지만 매우 강하다

• 초당 수만~수십만 요청 처리 가능
• cpu spike는 TTL 몰림, 큰 데이터 저장 시 발생 가능
• 그래도 DB에 비하면 훨씬 가벼움

Redis의 역할: DB가 감당해야 할 읽기 트래픽을 대규모로 줄여주는 “방패”.

 

6. 개인 프로젝트라도 Redis를 넣는 게 이득인 이유

트래픽이 많지 않아도 개인 프로젝트에 Redis를 도입하면:

• 확장성을 고려한 서버 설계 경험이 생기고
• 캐싱·TTL·무효화·분산락 같은 실무 기술을 익힐 수 있고
• 이력서에 강력한 문장으로 녹여낼 수 있다

예시로 구현 가능한 것:

• 게시글 리스트 캐싱
• 댓글 개수 캐싱
• 사용자 기본 정보 캐싱
• 데이터 수정 시 캐시 무효화
• HikariCP 풀 튜닝

 

7. 전체 요약

• DB 커넥션 풀은 DB 커넥션을 재사용하여 성능과 안정성을 확보한다.
• 요청 1개는 커넥션 1개를 사용하며, 동시 요청이 많아지면 풀이 쉽게 소진된다.
• 느린 쿼리는 커넥션을 오래 잡아 전체 API를 마비시킬 수 있다.
• API 서버만 늘려서는 해결되지 않는다. DB는 쉽게 병목된다.
• Redis는 조회 트래픽을 DB 대신 처리하는 캐시 계층이다.
• 개인 프로젝트라도 Redis 적용은 큰 실무 경험을 제공하며 이력서에도 강하게 어필된다.

“API를 만드는 개발자”에서 나아가, 확장성과 트래픽을 고려한 서버 엔지니어로 성장하기 위해 반드시 알아야 하는 내용이라 생각한다.