DB CPU가 미친듯이 튀었는데, 범인은 DB가 아니었다

 

1. 갑작스러운 DB CPU 스파이크

 

 

평화롭던 중 갑자기 DB CPU가 비정상적으로 치솟는 현상이 모니터링에 포착됨.

서서히 오르는 형태가 아니라, 특정 시점에 아주 순간적으로 확 튀어 오르는(Spike) 형태였음.

 

 

2. 1차 원인 파악     - DB 쿼리 로그 확인

 

DB CPU가 튀었으니 당연히 제일 먼저 DB 쿼리 로그를 까봄.

확인해 보니 특정 쿼리들이 무더기로 호출되고 있었음. 특히 평소에도 약간 무거웠던(느린) 쿼리들이 다량으로 발생함.

 

 

 

여기서 1차 의문 발생:

"대체 왜 갑자기 이 쿼리들이 한 번에 몰렸지?"

 

단순히 트래픽이 늘어난 거라기엔 패턴이 너무 부자연스러웠음.

 

 

3. 2차 원인 파악 — GW(Gateway) 트래픽 분석

 

 

원인을 찾기 위해 앞단 GW 로그를 확인함. 특정 시간대에 트래픽이 급증한 것을 확인했는데, gw01, gw02 두 대의 서버에서 동시에 트래픽이 치솟았음.

 

 

=== > 단일 서버나 특정 Pod의 문제가 아님을 확신함. 외부에서 한 번에 밀고 들어온 트래픽 문제로 판단.

 

 

 

4. 3차 원인 파악 — 소켓(Socket) 로그 확인

 

 

단서를 찾기 위해 소켓 서버 로그를 뜯어봄. 로그에서 ping timeout이 대량으로 발생한 직후, reconnect 요청이 미친 듯이 폭증한 것을 발견함.

즉, 기존 연결이 일제히 끊김 → 클라이언트들의 재연결 폭주가 일어난 상황이었음.

 

 

 

5. 중간 정리 — DB 부하의 진짜 이유

여기까지의 흐름을 정리해 보면 그림이 나옴.

1. 소켓 연결이 모조리 끊김
2. 클라이언트들이 동시에 재연결 시도
3. 기존 유저들의 접속 요청이 한 번에 몰림
4. 이 과정에서 무거운 쿼리들이 동시다발적으로 호출됨
5. DB CPU 급상승 !

 

핵심은 쿼리 자체가 아니라 동시 재접속 폭발(Reconnect Storm)"이었음.

 

 

6. 그렇다면 왜 소켓이 끊겼는가?

이제 진짜 근본적인 원인을 찾을 차례. 여기서부터가 중요함. 처음엔 GW나 Nginx 쪽 이슈를 의심했지만, 로그를 아무리 봐도 별다른 에러가 없었음. Pod Restart도 발생하지 않았고 내부망은 지극히 정상이었음.

 

 

->  즉, 우리 쪽 (내부 인프라/애플리케이션) 문제가 아니었음.

 

 

7. VIP / 네트워크 계층 의심

지금까지 파악한 조건을 종합해 보면 아래와 같음.

• 여러 GW pod에서 동시에 발생함
• 서버 내부 에러나 재시작 없음
• 오직 소켓 세션만 일괄적으로 끊김
• Reconnect 이후에는 또 귀신같이 정상 동작함

이건 거의 100% 중간 네트워크 계층 문제라고 판단함. 바로 인프라팀에 VIP 및 WAF(웹 방화벽) 쪽 확인을 요청함.

 

8. 인프라팀 확인 결과  -  범인!

 

인프라팀에서 확인해 준 답변 요약은 다음과 같음.

• 17:20경 WAF 내부 네트워크 프로세스 Down 발생
• 이 과정에서 세션이 일시적으로 끊겼을 가능성 높음
• 동일 현상이 지난 3월 9일에도 발생했었음 (소름)
• 현재 제조사 측 버그로 판단 중이며, 펌웨어 패치 예정 (제조사 리포트 대기 중)

 

 

 

9. 최종 장애 발생 트리거 요약

모든 퍼즐을 맞춘 최종 인과관계는 이렇다.

 

 

WAF 네트워크 프로세스 장애 → 세션 일괄 끊김 →
소켓 연결 전체 Drop → 클라이언트 재연결 폭증(Storm)
→ DB 쿼리 동시 호출 → DB CPU 떡상

 

 

 느낀 점 & 핵심 인사이트

이번 장애는 겉보기엔 DB 문제 같았지만, 실상은 트래픽 패턴 문제였음.

(네트워크 장애 → 재접속 폭발 → DB 부하로 이어지는 나비효과)

 

이번 장애를 겪으며 얻은 교훈

 

 

DB CPU가 튀었다고 해서 무조건 DB나 쿼리 문제가 아닐 수 있다.    

앞단부터의 트래픽 흐름을 봐야 함.

 

 

소켓 기반 서비스는 항상 '재연결 폭탄(Reconnect Storm)'을 고려해야 한다.

(클라이언트 측에 Exponential Backoff나 Jitter 같은 분산 재시도 로직이 필요한 이유)

 

 

 

내부 서버/GW가 정상인데 여러 Pod에서 동시에 에러가 터지면, 지체 없이 네트워크(VIP/WAF) 레벨을 의심하자.

로그 삽질 시간을 획기적으로 줄일 수 있음.