[주니어 백엔드 개발자가 반드시 알아야 할 실무 지식] 2장. 느려진 서비스, 어디부터 봐야 할까

📄 본문

1. 처리량 vs 응답 시간

• 응답 시간(TTFB, TTLB) : 최초 바이트 도착 시간과 마지막 바이트 도착 시간. 특히 네트워크 상태나 응답 크기에 따라 TTFB와 TTLB 간 격차가 크게 벌어질 수 있어요. 응답 시간 단축을 위해 DB 연동과 외부 API 연동 쪽부터 살펴봐야 합니다. 
• 처리량(TPS/RPS) : 초당 얼마나 많은 요청을 처리할 수 있는지. TPS가 한계를 넘으면 요청이 대기하게 되고, 결과적으로 응답 지연이 발생하죠.

2. 서버 성능 개선 기초

• 병목(Bottleneck) 지점 식별:
  모니터링 도구 없이도 로그 기반으로 응답 시간 지연 구간을 찾아낼 수 있어요. 대부분 DB나 외부 API 호출 구간에서 문제 발생빈도가 높습니다. 
• 스케일링 전략:
  • 수직 확장(Scale-Up): CPU, 메모리 등 자원을 통째로 업그레이드 — 빠르지만 비용 부담 있음.
  • 수평 확장(Scale-Out): 서버를 여러 대 두는 방식 — 무턱대고 늘리면 DB 병목만 악화될 수 있어요. 반드시 병목 식별 후 결정해야 합니다. 

3. DB 커넥션 풀

• 이유: 매번 DB 연결-종료하면 처리량 급감 → 커넥션 풀을 통해 연결 초기화 비용 절감.
• 핵심 설정 요소:
  • 최대/최소 풀 크기
  • 커넥션 대기 시간 설정: 길게 두는 건 응답 시간 지연, 짧게 두면 오류 유발 가능. 때로는 빠른 오류가 무응답보다 나을 수 있습니다. 
  • 유휴 시간, 유효성 검사 주기, 최대 유지 시간 등도 조정해야 합니다.

4. 서버 캐시

• 캐시 활용 시점: DB 확장이 부담될 때 캐시가 유용합니다.
• 캐시 적중률(히트율): 캐시 내 조회 성공 비율 → 효율성 증가, DB 부하 감소
• 삭제 전략: LRU, LFU, FIFO, TTL 등을 적절히 조합해 메모리 확보와 효율 균형 맞추기
• 로컬 vs 리모트 캐시:
  • 로컬: 속도 빠르지만 서버 재시작 시 사라지고 메모리에 제약이 있음.
  • 리모트(Redis 등): 확장성 뛰어나고 지속성 있음. 구조 복잡도 있지만 안정적.

5. 정적 자원과 CDN

• 정적 자원(이미지, CSS, JS)은 서버가 아닌 CDN에서 제공하면 네트워크 대역폭 절감과 응답 속도 향상 가능합니다.

6. 대기 처리

• 대기 큐를 사용해 일시적으로 요청을 순차 처리하거나 백그라운드 배치로 넘기는 전략도 유효합니다. 특히 사용자에게 에러를 빠르게 알리고, 내부적으로는 재시도 로직을 관리하는 식으로요.

"긴 시간동안 무응답 상태로 유지되는 것보다 빠르게 에러를 반환하는 것이 더 낫다"는 책의 메시지가 현실 경험과 맞닿아 있어 인상 깊었어요. 급한 시간에는 무조건 응답이 빠른 게 핵심이니까요.

외부 API가 오래 걸릴 것 같으면, 앞단에서 타임아웃을 걸고 빠르게 실패 처리한 뒤 리트라이하거나 사용자 메시지를 주는 게 훨씬 나은 사용자 경험이 될 수 있습니다.