특정 시간대만 느려지는 서버 병목 현상 원인 찾기

---

최근 운영하는 백엔드 서버가 있거든요.
전체적인 CPU나 메모리 점유율 그래프를 보면 큰 이상은 없고, 전반적으로 안정적인 패턴을 보이는데 말이에요.

근데 이상하게도 특정 피크 시간대(예: 오후 2시~4시 사이)에만 응답 시간이 갑자기 늘어나면서 지연이 발생하는 현상이 관측돼요.
단순한 리소스 부족 이슈 같진 않은데, 어디서 병목이 발생하는 건지 감이 안 잡히네요.

이런 경우, 단순히 평균 부하량만 보는 것보다 어떤 종류의 모니터링 뷰나 지표를 추가적으로 봐야 할지 궁금해요.
예를 들어, I/O 대기 시간이나 특정 큐 길이 같은 거라던가, 전통적인 APM 툴 외에 '패턴 변화'를 잡아낼 만한 관찰 포인트가 있을까요?

와, 이거 진짜 흔하면서도 골치 아픈 문제네요.
백엔드 운영하다 보면 '평소엔 멀쩡한데 특정 시간대에만 왜 이러지?' 싶은 케이스가 진짜 많거든요.
CPU/메모리만 보고 판단하기에는 한계가 명확하죠.
질문자님이 말씀해주신 '특정 시간대 피크' 패턴은 보통 리소스 자체의 절대 부족보다는, 어떤 자원이 특정 패턴의 요청 부하를 받아들일 때 병목이 발생하는 경우가 많습니다.
제가 몇 번 비슷한 케이스를 겪어봐서 느낀 건데, 단순히 APM 툴의 트랜잭션 응답 시간만 보는 건 너무 겉핥기식일 때가 많다는 거예요.
몇 가지 관점에서 추가적으로 깊이 파고들 수 있는 모니터링 포인트들을 종류별로 정리해 드릴게요.
--- ### 1.
I/O 및 데이터베이스 관련 병목 지점 탐색 (가장 흔한 원인) 응답 시간 지연의 80% 이상은 결국 DB나 외부 I/O에서 발생합니다.
CPU 점유율이 낮아도 DB가 느리면 전체 서버가 느려지는 것처럼 보입니다.
A.
DB 커넥션 풀 및 쿼리 분석 (필수 체크) * 커넥션 풀 고갈/경합: 피크 타임에 갑자기 트래픽이 몰리면, 요청이 폭주하면서 DB 커넥션 풀이 전부 바쁘게 사용되고, 다음 요청들은 커넥션을 얻기 위해 대기(Wait)하는 시간이 길어집니다.

• 확인 지표: DB 연결 시도 대비 성공률, 커넥션 대기 큐 길이(Waiting Queue Length).
• 팁: 커넥션 풀의 max pool size를 늘리는 것도 임시방편일 수 있지만, 근본적으로는 느린 쿼리 최적화가 답입니다.
• 느린 쿼리 패턴: 특정 시간대에만 실행되는 배치 작업이나, 그 시간에만 많이 호출되는 API가 비효율적인 쿼리를 반복적으로 날리는 경우가 많아요.
• 확인 지표: DB의 Slow Query Log를 시간대별로 필터링해서 분석해야 합니다.
  (예: 14시~16시 사이에 가장 많이 실행되고, 평균 실행 시간이 급증하는 쿼리) * 주의: 쿼리가 느린 이유가 인덱스 누락일 수도 있지만, 때로는 데이터 구조 자체가 그 시간대 트래픽을 감당하기 어려워서 발생하는 경우도 있습니다.
  (예: 트랜잭션 격리 수준 문제) B.
  디스크 I/O 대기 시간 (Wait Time) * 만약 로깅이나 세션 저장소(Redis, Memcached 등)가 디스크 기반으로 동작하거나, DB가 디스크 I/O에 크게 의존한다면, 피크 시간에 디스크 I/O 대기 시간이 급증할 수 있습니다.
• 확인 지표: 운영체제 레벨에서 iowait 지표를 추적하세요.
  (Linux의 경우 top이나 vmstat에서 확인 가능) * 의미: 이 지표가 특정 시간대에 눈에 띄게 높아진다면, 서버가 CPU를 사용하기보다 **디스크가 데이터를 읽어줄 때까지 '기다리고 있다'**는 뜻입니다.
  --- ### 2.
  애플리케이션 레벨의 병목 (리소스 외적 요인) 위의 I/O나 DB가 문제가 아니라면, 애플리케이션 코드나 아키텍처 레벨에서 '경합'이 일어나고 있을 가능성이 높습니다.
  A.
  동시성 제어 및 락(Locking) 경합 * 가장 놓치기 쉬운 부분입니다.
  여러 요청이 동시에 특정 공유 자원(카운터 증가, 전역 상태 변경, 레코드 업데이트 등)에 접근할 때, 코드가 동기화(Synchronize) 로직을 사용하는데, 이 락을 획득하고 해제하는 과정 자체가 병목이 될 수 있습니다.
• 특징: 전체 CPU 사용률은 평소와 비슷한데, 특정 API 엔드포인트의 응답 시간만 피크 타임에 폭발적으로 증가합니다.
• 분석 팁: 가능하다면, 어떤 Lock 메커니즘을 사용하고 있는지 코드 레벨에서 확인하고, 해당 락을 거는 범위를 최대한 좁히거나, 가능하다면 분산 락(Redis 기반 등)으로 변경하여 경합 지점을 분산시켜야 합니다.
  B.
  캐시 무효화(Cache Invalidation) 패턴 문제 * 캐시를 사용할 때, '데이터가 변경되었으니 캐시를 무효화해야 한다'는 로직이 들어갑니다.
• 만약 이 무효화 로직이 '전역적으로 모든 캐시를 삭제하는' 방식으로 구현되어 있다면, 트래픽이 몰리는 시간에 모든 캐시가 한 번에 삭제/재구축되면서 엄청난 부하가 걸릴 수 있습니다.
• 해결 방향: 캐시를 무효화하기보다, TTL(Time To Live) 기반으로 자연스럽게 만료되도록 하거나, 변경된 데이터의 Key만 정교하게 삭제(Invalidate)하는 방식으로 수정하는 것이 좋습니다.
  --- ### 3.
  네트워크 및 외부 의존성 문제 (가장 예측하기 어려운 부분) 서버 자체의 문제가 아닐 수 있습니다.
  외부 서비스나 네트워크 레이어에서 병목이 생기는 경우입니다.
  A.
  외부 API 호출 제한 (Rate Limiting) * 만약 백엔드 서버가 외부 결제 게이트웨이나, 제3자 인증 서비스(OAuth 등)를 호출하는 로직이 있다면, 해당 외부 서비스가 피크 타임에 요청을 너무 많이 받아서 우리 서버 쪽으로도 요청을 거부하거나 지연시키는 경우가 있습니다.
• 확인 지표: 외부 서비스 호출 실패 로그(HTTP 429 Too Many Requests 등)를 시간대별로 체크하세요.
  B.
  로드 밸런서(L4/L7) 또는 방화벽 검사 지연 * 매우 드물지만, 트래픽이 특정 시간대에 급증하면서 로드 밸런서나 WAF(웹 방화벽) 같은 미들웨어에서 세션 테이블 조회나 복잡한 규칙 검사가 과부하되어 지연을 일으키는 경우도 있습니다.
• 점검: 이 경우, 서버 자체의 모니터링보다 L4/L7 스위치나 로드 밸런서 자체의 메트릭을 확인해야 합니다.
  (연결 세션 수, 처리량 대비 지연 시간 등) --- ### 종합적인 접근 및 체크리스트 요약 질문자님께 드리는 가장 실질적인 조언은, '단일 지표'에 의존하지 말고, '병목이 의심되는 영역별로 슬라이스'해서 모니터링하는 것입니다.

시간대 분할: 전체 모니터링 데이터를 15분 단위로 쪼개서, 피크 시간대(14시~16시)와 비피크 시간대(예: 10시~11시)의 모든 지표(DB 쿼리 시간, API 응답 시간, I/O Wait, 커넥션 풀 대기 시간)를 나란히 비교하세요.
2.
Correlation (상관관계) 찾기: * 가설 A: 14시~16시에 A API 호출이 급증 $\rightarrow$ DB 쿼리 로그 확인 $\rightarrow$ 특정 쿼리 X의 실행 시간이 급증.
(→ DB 최적화 필요) * 가설 B: 14시~16시에 B API 호출이 급증 $\rightarrow$ 서버의 Lock 경합 로그 확인 $\rightarrow$ 락 획득 대기 시간이 증가.
(→ 동시성 제어 로직 개선 필요) * 가설 14시~16시에 C API 호출이 급증 $\rightarrow$ 외부 API 호출 로그 확인 $\rightarrow$ 429 에러가 발생하기 직전에 지연 발생.
(→ 외부 서비스 정책 검토 필요) 결론적으로, APM 툴에서 트랜잭션 흐름을 따라가면서, 각 단계(외부 호출 $\rightarrow$ 캐시 조회 $\rightarrow$ DB 접근 $\rightarrow$ 비즈니스 로직 수행)별로 평균 응답 시간 변화 추이를 시간대별로 캡처하는 것이 가장 중요합니다.
이런 문제는 '원인'을 찾기보다 '가설을 세우고 검증'하는 과정의 싸움이라, 위의 체크리스트들을 순서대로 점검해보시면 분명히 뭔가 꼬인 부분을 발견하실 수 있을 겁니다.
화이팅하시고, 꼭 원인 찾으시길 바랍니다!