실전 튜닝 Q&A: 요청 지연 파악부터 CDN-비용, 인덱스 설계까지 한 방에!

1. 요청 처리 시간, 무엇을 어떻게 잴까?

• 구간별 타이머
  • Micrometer Timer를 메소드·API 호출마다 삽입하면 총 시간뿐 아니라 외부 API 호출, DB 쿼리, 비즈니스 로직 을 세부 구간으로 나눠서 계측할 수 있다. 예시는 timer.record(() -> ... ) 한 줄이면 끝!
  • HTTP 필터/AOP로 시작 타임스탬프를 MDC(Logback) 에 넣어 요청-응답 로그를 한줄로 남기면 Kibana, Grafana 등에서 “slow-query” 대시보드가 자동 완성된다.
• 분산 트레이싱(OpenTelemetry)를 함께 쓰면 외부 마이크로서비스까지 hop-by-hop 지연을 눈으로 확인할 수 있어 SLA 협상 근거가 명확해진다.

---

2. “끊긴 DB 커넥션”이 풀 안에서 살아있는 이유

네트워크 장비가 TCP idle 세션을 자르더라도 소켓은 FIN 패킷을 받지 않을 때 애플리케이션이 모른다. 커넥션 풀(HikariCP 등)은

1. maxLifetime·idleTimeout에 따라 주기적으로 house-keeper 스레드로 ping/validation을 돌려 죽은 커넥션을 제거하고
2. connectionTestQuery·validationTimeout 으로 borrow 시점 검사도 지원한다.

팁

• DB ↔ Firewall의 idle timeout < maxLifetime 가 되도록 설정
• 중요한 배포 직후엔 softEvictConnections() 호출로 낡은 커넥션을 즉시 갈아치운다.

---

3. “캐시가 아직 안 찼는데 왜 청소해야 하죠?”

• 메모리 압박 : 오래된 키가 많으면 GC pause·메모리 파편화로 응답 지연이 커진다. Redis는 메모리가 가득 차기 직전에 샘플링 LRU로 키를 찾는데, 이미 full 상태에서 evict 모드가 돌면 처리량이 최대 15-20 %까지 떨어질 수 있다
• 권장 : TTL 혹은 LFU 정책으로 “사용 빈도↓ + 낡은 데이터”를 미리 털어내고, maxmemory-samples 를 3~5 로 유지해 CPU 오버헤드를 줄인다.

---

4. CDN 비용이 ‘생각보다’ 저렴한 이유

 

항목	CloudFront (한국 Edge)	S3 (서울 리전)
			Origin → Edge 전송	무료 아마존 웹 서비스	–
Edge → Internet (다음 9 TB)	$0.114/GB 아마존 웹 서비스	(동급 구간에서) 보통 $0.15 안팎
저장 비용	없음 – 캐시된 객체는 eviction 시 자동 삭제, 별도 스토리지 과금 없음 Server Fault	스토리지 요금 별도 부과

 

즉 동일 서울 리전에서 S3만 단독으로 외부 전송하는 것보다 CloudFront를 앞단에 두면 첫 1 TB 무료 + 전송 단가 할인 + 글로벌 캐싱 세 가지 모두 이득이다. 해외 이용자가 한 번 요청해서 캐시가 생성돼도, 객체 자체에는 저장료가 없으니 ‘유령 캐시’ 비용 걱정은 버려도 된다.

---

5. 필터 후에도 정렬이 느리다? 👉 복합 인덱스 설계

WHERE 절 필터링 뒤에도 레코드가 수만 건이라면 정렬 컬럼을 인덱스 끝에 포함해 두 번 스캔을 피한다.

-- 예: status 로 필터 후 updated_at DESC 정렬
CREATE INDEX idx_status_updated
  ON orders(status, updated_at DESC);

• 왼쪽 고정(prefix) 규칙을 지켜야 쿼리 플래너가 filesort 를 생략하고 인덱스만으로 정렬한다
• SELECT 항목이 모두 인덱스 컬럼이면 “Index Only Scan(= 커버링 인덱스)”가 되어 디스크-I/O가 완전히 사라진다.

---

6. 블루-그린 배포 때 DB 커넥션 수는 2배여야 할까?

• 스위치 전 Blue + Green 두 개의 애플리케이션이 동시에 살아있으므로, 이론상 DB 연결 합계가 평소의 두 배가 될 수 있다.
• 그러나 AWS RDS 기준으로 복제 슬롯·연결 수 자체가 리소스를 잡아먹어 랙을 유발할 수 있으므로
  • Green 쪽 풀 크기를 30-50 % 수준으로 제한
  • 혹은 RDS Proxy / PgBouncer 같은 멀티플렉서로 “논리-연결 >> 물리-연결” 구조를 만들면 DB max_connections를 굳이 2배로 늘리지 않아도 된다.

---

📌 정리

• Micrometer & 분산 트레이싱으로 구간-별 지연을 실시간 가시화
• 커넥션 풀은 validation/keep-alive 로 죽은 세션 자동 정리
• 캐시는 TTL+LFU 로 메모리·GC 부하를 예방
• CloudFront는 전송 단가·저장료 모두 절약, “서울→서울” 조합에서도 유리
• 필터 + 정렬 쿼리는 복합 인덱스로 한 번에 해결
• 블루-그린 배포 시 DB 연결은 “풀 조정 or Proxy”로 리소스를 균형 있게 분배