Unit 4.1 — 매 요청마다 연결의 비효율
F-LAB JAVA · 6주차 · Phase 4 · Connection Pool과 DB 세션
🔗 Phase 4 시작 — DB 접근 성능의 핵심
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- DB 연결의 비용 3가지는?
- TCP 3-way handshake 란?
- DB 인증 비용은?
- DB 세션 생성 은?
- 매 요청마다 연결의 문제 는?
- 연결 설정 시간 vs 응답 시간 비교는?
- 연결 1회 설정 시간 은?
- 자원 해제 비용 은?
- 해결 방향 (Connection Pool) 은?
🎯 핵심 한 문장
DB 연결 1회에는 TCP 3-way handshake (네트워크 왕복) + DB 인증 (ID/PW 검증) + DB 세션 생성이라는 비싼 비용이 들어 수~수백 ms 가 걸리므로, 매 요청마다 연결하면 100만 요청 = 100만 번의 handshake 가 되어 DB 응답시간보다 연결 설정 시간이 더 길어진다.
DB 연결 1회에는 세 가지 비용이 든다 — (1) TCP 3-way handshake (SYN → SYN-ACK → ACK 네트워크 왕복), (2) DB 인증 (ID/PW 검증), (3) DB 세션 생성 (서버 자원 할당).
이 비용이 합쳐져 연결 1회에 수~수백 ms 가 걸린다 (네트워크 거리/DB 부하에 따라 다름).
매 요청마다 새로 연결하면 100만 요청 = 100만 번의 handshake + 인증 + 세션 생성이 되어, 실제 쿼리 실행 시간보다 연결 설정 시간이 더 길어지는 본말전도가 일어난다.
자원 해제 (close) 도 비용이 들고, 너무 많은 연결은 DB 서버에 부담을 주므로 (세션 한계), 매번 연결 대신 미리 N개를 만들어두고 재사용 하는 Connection Pool 이 필요하다 (다음 Unit).
비유 — 매번 신용카드 발급 vs 카드 들고 다니기
매 요청 연결 = 매번 신용카드 발급:
매 요청 연결 (낭비):
- 결제마다 새 카드 발급
- 1. 은행 방문 (TCP)
- 2. 본인 인증 (DB 인증)
- 3. 카드 발급 (세션 생성)
- 4. 결제
- 5. 카드 폐기 (close)
- → 다음 결제 또 반복
비용:
- 발급 시간 > 결제 시간 (본말전도)
- 은행 부하
Connection Pool:
- 카드 몇 장 들고 다님 (미리 발급)
- 결제 시 꺼냄 (재사용)
- 결제 후 지갑에 (반환)
- 발급 비용 분산
TCP 3-way handshake:
- SYN: "안녕"
- SYN-ACK: "안녕, 받았어"
- ACK: "알았어"
- 3번 왕복 (지연)→ 매 요청 연결 = TCP + 인증 + 세션 비용 반복 (본말전도), Connection Pool 필요.
🧭 9개 섹션 로드맵
1. DB 연결 비용 3가지
2. TCP 3-way handshake
3. DB 인증
4. DB 세션 생성
5. 매 요청 연결 문제
6. 연결 시간 vs 응답 시간
7. 연결 1회 설정 시간
8. 자원 해제 비용
9. 해결 방향1️⃣ DB 연결 비용 3가지
1.1 세 가지 비용
DB 연결 비용:
1. TCP/IP 3-way handshake (네트워크 왕복)
2. DB 인증 (ID/PW 검증)
3. DB 세션 생성 (서버 자원)
→ 모두 합쳐 수~수백 ms1.2 누적 비용
누적 비용:
3가지 합:
- 네트워크 + CPU + 메모리
- 모두 비쌈
→ 무시 못 함1.3 비용의 의미
비용의 의미:
연결 1회 = 비싼 작업:
- 가볍게 X
- 빈번 시 문제
- 재사용 필요1.4 ILIC 의 맥락
DB 연결 비용 (ILIC)
ILIC 431 API:
- 매 요청 = DB 작업
- 매 요청 새 연결?
- TCP handshake
- 인증
- 세션 생성
- = 수십 ms
- 초당 1000 요청:
- 1000 × 수십 ms = 부담
- DB 도 부하
→ Connection Pool 필수 (다음 Unit)1.5 자기 점검 답변
DB 연결의 비용 3가지는?
답:
1. 3가지:
- TCP handshake/인증/세션
-
누적:
- 수~수백 ms
-
의미:
- 비싼 작업
-
결과:
- 재사용 필요
2️⃣ TCP 3-way handshake
2.1 3-way handshake
TCP 3-way handshake:
연결 수립 절차 (3단계):
클라이언트 → 서버: SYN ("연결?")
서버 → 클라이언트: SYN-ACK ("OK, 너도?")
클라이언트 → 서버: ACK ("OK")
→ 3번 왕복2.2 단계별
단계별:
1. SYN (Synchronize):
- 클라이언트가 시작 알림
- 시퀀스 번호
2. SYN-ACK:
- 서버 응답 + 인정
- 서버 시퀀스 번호
3. ACK (Acknowledge):
- 클라이언트 인정
- 연결 수립2.3 네트워크 비용
네트워크 비용:
3번 왕복 = 1.5 RTT:
- 거리 멀수록 비쌈
- 같은 호스트: 빠름 (수 ms)
- 다른 지역: 느림 (수십~수백 ms)
→ 네트워크 지연2.4 시각화
시각화:
[클라이언트] [DB 서버]
│ │
│─────── SYN ──────────→ │
│ │
│←──── SYN-ACK ──────── │
│ │
│──────── ACK ─────────→ │
│ │
│ (연결 수립) │2.5 ILIC 의 맥락
TCP handshake (ILIC)
ILIC 시나리오:
같은 호스트 (Docker 컨테이너):
- backend ↔ mysql 컨테이너
- handshake 빠름 (수 ms)
- 같은 머신 (네트워크 짧음)
분산 환경:
- 다른 머신/리전
- handshake 수십 ms
- 비용 ↑
매 요청 새 connection:
- handshake × 요청 수
- 누적 부담2.6 자기 점검 답변
TCP 3-way handshake란?
답:
1. 3단계:
- SYN → SYN-ACK → ACK
-
목적:
- 연결 수립
-
비용:
- 1.5 RTT 왕복
-
거리:
- 멀수록 비쌈
3️⃣ DB 인증
3.1 DB 인증
DB 인증:
연결 후 인증 단계:
- ID/PW 전송
- DB 가 검증
- 권한 확인3.2 인증 절차
인증 절차:
1. 클라이언트: ID/PW 전송 (암호화)
2. DB: 사용자 정보 조회
3. DB: 비밀번호 검증 (해시 비교)
4. DB: 권한 확인
5. DB: 인증 완료/실패3.3 인증 비용
인증 비용:
- 비밀번호 해시 계산 (CPU)
- 사용자 테이블 조회
- 권한 확인
→ DB 서버 CPU 사용3.4 매번 인증
매번 인증 (매 요청):
매 요청 새 연결:
- 매번 인증
- DB CPU 부담
- 같은 사용자 반복
→ 낭비3.5 ILIC 의 맥락
DB 인증 (ILIC)
ILIC 시나리오:
- ilic_user 가 1000번 연결 요청
- 매번 비밀번호 검증?
- DB CPU 낭비
Connection Pool:
- 1번 인증 (풀 초기화 시)
- 1000번 재사용
- 인증 비용 분산
→ 인증 비용 절약3.6 자기 점검 답변
DB 인증 비용은?
답:
1. 인증:
- ID/PW 검증
-
절차:
- 전송 → 검증 → 권한
-
비용:
- DB CPU
-
매번 인증:
- 낭비
4️⃣ DB 세션 생성
4.1 DB 세션
DB 세션:
연결당 하나의 세션:
- DB 서버 자원
- 메모리 할당
- 트랜잭션 컨텍스트4.2 세션의 구성
세션의 구성:
- 메모리 (PGA, 캐시)
- 트랜잭션 상태
- 임시 데이터
- 세션 변수4.3 세션 생성 비용
세션 생성 비용:
- DB 서버 메모리 할당
- 자원 초기화
- 백그라운드 프로세스 (Oracle)
→ DB 서버 부담4.4 세션 한계
세션 한계:
DB 서버:
- 최대 세션 수 한계
- max_connections (MySQL)
- 너무 많으면 거부
→ 무한 X4.5 ILIC 의 맥락
DB 세션 (ILIC)
ILIC MySQL:
- max_connections = 151 (기본)
- 너무 많은 동시 연결 → 거부
매 요청 새 세션이면:
- 1000 동시 요청 = 1000 세션
- 한계 초과
- 거부 발생
Connection Pool (10개):
- DB 세션 10개만
- 재사용
- DB 부담 ↓
→ DB 보호4.6 자기 점검 답변
DB 세션 생성은?
답:
1. 세션:
- 연결당 하나
-
구성:
- 메모리/상태
-
비용:
- 서버 자원
-
한계:
- max_connections
5️⃣ 매 요청 연결 문제
5.1 문제 시나리오
매 요청 연결:
100만 요청 = 100만 번:
- TCP handshake
- 인증
- 세션 생성
→ 비용 폭증5.2 누적 효과
누적 효과:
요청 × 연결 비용:
- 1000 요청 × 50ms = 50초 (연결만)
- DB 응답 시간 외에 추가
→ 응답 느림5.3 DB 서버 부하
DB 서버 부하:
연결 폭증:
- 메모리 폭증
- CPU (인증)
- 세션 한계
→ DB 다운 가능5.4 네트워크 부담
네트워크 부담:
매번 handshake:
- 패킷 폭증
- 대역폭 낭비
- 라우터 부담5.5 ILIC 의 맥락
매 요청 연결 시나리오 (ILIC)
ILIC 가정 (Connection Pool 없으면):
- 사용자 100명 동시 작업
- 각자 페이지 조회 (API 5개)
- 동시 500 요청
매 요청 새 연결:
- 500 handshake
- 500 인증
- 500 세션 (한계 초과 가능)
- 응답 지연
결과:
- DB 부하 ↑
- 응답 시간 ↑
- 사용자 경험 ↓
→ Connection Pool 필수5.6 자기 점검 답변
매 요청마다 연결의 문제는?
답:
1. 시나리오:
- 100만 × 비용
-
누적:
- 연결만 수십 초
-
DB 부하:
- 세션 한계
-
네트워크:
- 패킷 폭증
6️⃣ 연결 시간 vs 응답 시간
6.1 본말전도
본말전도:
연결 설정 시간 > 쿼리 실행 시간:
- 본 작업보다
- 준비가 더 김
→ 잘못된 구조6.2 비교
비교:
쿼리 실행: 1~10 ms (간단 쿼리)
연결 설정: 50~200 ms (handshake+인증+세션)
→ 연결이 5~200배
(같은 호스트라도 연결 더 비쌈)6.3 함의
함의:
단순 쿼리:
- 연결 비용 압도적
- 사용자가 기다리는 건
- 연결 설정 (낭비)
→ 재사용 필수6.4 캐시 무효화
캐시 무효화:
매 연결 새 세션:
- 세션 캐시 X
- 매번 워밍업
- 성능 ↓6.5 ILIC 의 맥락
연결 vs 응답 시간 (ILIC)
ILIC GET /api/shipments/{id}:
Connection Pool 없으면:
- 연결 설정: 50ms
- 쿼리 실행: 5ms
- 응답: 55ms (90% 가 연결)
Connection Pool 사용:
- 연결 가져오기: 0.1ms (재사용)
- 쿼리 실행: 5ms
- 응답: 5.1ms (10배 빠름)
→ Connection Pool 의 효과6.6 자기 점검 답변
연결 설정 시간 vs 응답 시간 비교는?
답:
1. 본말전도:
- 연결 > 쿼리
-
비교:
- 5~200배
-
함의:
- 재사용 필수
-
캐시:
- 세션 캐시 X
7️⃣ 연결 1회 설정 시간
7.1 대략적 시간
연결 1회 설정 시간:
로컬 (같은 호스트):
- 1~10 ms
같은 데이터센터:
- 5~50 ms
다른 리전:
- 100~500 ms
+ SSL/TLS 시: 추가 비용7.2 변동 요인
변동 요인:
- 네트워크 거리
- DB 부하
- 인증 복잡도
- SSL 사용
- 방화벽7.3 SSL 추가 비용
SSL/TLS 추가:
- TLS handshake (추가 왕복)
- 인증서 검증
- 키 교환
→ 비용 ↑ (보안 트레이드오프)7.4 누적 시간
누적 시간:
100 요청 × 50ms:
- 5초 (연결만)
- 쿼리 시간 별개
→ 무시 못 함7.5 ILIC 의 맥락
연결 1회 시간 (ILIC)
ILIC Docker 환경:
backend ↔ mysql 컨테이너:
- 같은 머신, 컨테이너 네트워크
- 연결: ~5ms (빠름)
하지만 ILIC 가 클라우드 RDS:
- 다른 인스턴스
- 연결: ~30ms
- SSL 사용 시 더
매 요청 연결이면:
- 30ms × 1000 = 30초 (1000 요청)
- 응답 지연 누적
→ HikariCP (Connection Pool) 필수7.6 자기 점검 답변
연결 1회 설정 시간은?
답:
1. 시간:
- 수~수백 ms
-
변동:
- 거리/부하/SSL
-
SSL:
- 추가 왕복
-
누적:
- 무시 못 함
8️⃣ 자원 해제 비용
8.1 해제 비용
자원 해제 비용:
Connection.close():
- 세션 정리 (DB)
- TCP 종료 (4-way handshake)
- 메모리 해제
→ 닫는 것도 비싸다8.2 TCP 4-way handshake
TCP 4-way handshake (종료):
FIN → ACK → FIN → ACK
- 양방향 종료
- 4번 왕복
- 시간 소요8.3 TIME_WAIT
TIME_WAIT:
종료 후 대기 상태:
- 60초 (기본)
- 포트 점유
- 빈번한 close → 포트 고갈8.4 누수 위험
close 누락 위험:
finally 누락 시:
- Connection 누수
- 세션 누적
- DB 한계 초과
→ JdbcTemplate 자동 (Phase 7)8.5 ILIC 의 맥락
자원 해제 (ILIC)
매 요청 connection:
- 열기: TCP handshake + 인증 + 세션 (수십 ms)
- 닫기: TCP 종료 (수 ms) + DB 세션 정리
+ close 누락 위험:
- Connection 누수
- DB 세션 누적
- max_connections 초과
- 서비스 장애
Connection Pool:
- close 가 진짜 close X
- 풀에 "반환"
- 재사용
→ 진짜 close 비용 회피8.6 자기 점검 답변
자원 해제 비용은?
답:
1. 해제:
- TCP 종료 (4-way)
-
TIME_WAIT:
- 포트 점유
-
누락:
- 누수 위험
-
Pool:
- 진짜 close X
9️⃣ 해결 방향
9.1 Connection Pool
해결 — Connection Pool:
미리 N 개 연결:
- 풀에 보관
- 요청 시 빌림
- 사용 후 반환
- 재사용
→ 연결 비용 분산9.2 핵심 아이디어
핵심 아이디어:
연결 비싸다 → 재사용:
- 한 번 만들고
- 여러 번 사용
- 분산
→ 비용 1/N9.3 효과 예고
효과 예고:
Connection Pool:
- 응답 시간 ↓ (재사용)
- DB 부하 ↓ (세션 적음)
- 안정성 ↑
→ 다음 Unit (4.2 ★깊이)9.4 ILIC 의 맥락
해결 방향 (ILIC)
ILIC Spring Boot:
- HikariCP 기본 (Connection Pool)
- 미리 10개 연결 (기본)
- 모든 요청이 풀 공유
설정 (application.yml):
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
→ 매 요청 연결 X
→ 재사용으로 빠름
→ Unit 4.2 에서 ★깊이9.5 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 연결 비용 3? | TCP/인증/세션 |
| TCP handshake? | SYN→SYN-ACK→ACK |
| DB 인증? | ID/PW 검증 |
| 세션? | 연결당 하나 |
| 매 요청 문제? | 비용 폭증 |
| 연결 시간? | 수~수백 ms |
| 본말전도? | 연결 > 쿼리 |
| 해제 비용? | TCP 종료/TIME_WAIT |
| 해결? | Connection Pool |
| max_connections? | DB 세션 한계 |
9.6 자기 점검 체크리스트
연결 비용
- 3가지
TCP handshake
- 3단계
인증
- 비용
세션
- 생성
매 요청 문제
- 폭증
시간
- 수~수백 ms
해제
- 비용
해결
- Pool
9.7 추가 심화 질문
Q1: TCP Keep-Alive?
답:
- 연결 유지
- 주기적 신호
- 끊김 감지
- 풀과 함께 사용
Q2: Idle 연결?
답:
- 사용 안 하는 연결
- 풀에서 유지
- 너무 오래는 정리 (idle timeout)
- DB 측에서도 wait_timeout
Q3: 연결 검증?
답:
- 풀의 연결이 살아있나
- validation query (SELECT 1)
- 사용 전 검증
- 끊긴 연결 회피
Q4: 멀티플렉싱?
답:
- 한 연결로 여러 요청
- HTTP/2 와 유사
- DB 는 보통 1:1
- 프록시 (PgBouncer) 일부
Q5: 영구 연결?
답:
- 한 번 만들고 계속
- Pool 의 기본 동작
- close 시 풀로 반환
- 진짜 close X
🎯 핵심 요약 — 3줄 정리
1. DB 연결 비용 3가지
- TCP 3-way handshake (SYN→SYN-ACK→ACK, 네트워크 왕복)
- DB 인증 (ID/PW 검증, CPU) + DB 세션 생성 (서버 자원)
2. 매 요청 연결의 문제
- 연결 설정 시간 (수~수백 ms) > 쿼리 실행 (수 ms) — 본말전도
- DB 세션 한계 (max_connections) 초과 위험
3. 해결
- 미리 연결 N 개 만들어 재사용 = Connection Pool
- 다음 Unit (4.2 ★깊이) 에서 상세
📚 다음으로...
Unit 4.2 — Connection Pool 개념 ★깊이
이번 Unit에서 연결 비효율을 봤다면, 다음은 Connection Pool (★ 깊이 파기).
- 풀 동작 (미리 N개, 빌림/반환)
- HikariCP 기본
- 풀 크기 결정
- 풀 부족 시 대기
Phase 4 진행 상황
🔗 Phase 4 — Connection Pool과 DB 세션
✅ Unit 4.1 매 요청마다 연결의 비효율 ← 여기
⏭ Unit 4.2 Connection Pool 개념 ★깊이
⏭ Unit 4.3 DB 세션과 연결 구조
⏭ Unit 4.4 DB Lock 개념6주차 누적 진행
🧪 Part A (9 Unit) ✅
💾 Part B — DB 접근의 진화
✅ Phase 3 — JDBC (3 Unit)
🔗 Phase 4 — Connection Pool (1/4 진행)
총: 13/28 Unit (절반!)🔗 Phase 4 시작 — DB 접근 성능의 핵심
Software Developer