최근에 갑자기 DB CPU나 WAS CPU가 이유 없이 치솟는 일이 종종 있었음.
트래픽도 같이 비정상적으로 높아져서 살짝 당황함.
‘우리 서비스가 DDOS 맞을 정도로 유명하진 않을텐데…?’
의문 들면서 로그 타임라인 맞춰서 살펴봄.
그랬더니 그 시간대에 docker 컨테이너가 꺼졌다가 다시 켜진 흔적이 있었음.
여기서부터 느낌이 옴: 뭔가 서버가 죽어서 재시작됐구나.
조금 더 뒤져보니 문제의 원인은 의외로 단순했음.
chat_uid 중복 → 예외처리 실패 → await 안 걸림 → Promise 터짐
- chat_uid가 중복으로 들어오는 특정 케이스가 있었음
- 예외처리가 잘못되어 있어서
- try/catch로 감싸도
- await 누락된 비동기 부분에서 Promise rejection이 튀어나와버림
- 결국 노드 프로세스가 제대로 처리 못하고 컨테이너가 죽어버림
- 그 시점에서 Docker가 자동 재시작 → 서버가 전체적으로 흔들림
이게 근본 원인이었음.
🤔 그런데 CPU/트래픽/DB까지 왜 다 올라갔을까?
컨테이너가 재시작되면:
- 서버 부팅 과정에서 DB 커넥션 생성 폭주
→ 커넥션 풀 다시 구성하면서 일시적으로 DB CPU 올라감 - 재시작 이후 클라이언트 요청이 몰리면서
→ 트래픽이 순간적으로 스파이크 - WAS도 모든 캐시/세션 초기화됨
→ 부팅 직후 CPU가 더 높게 튐
“컨테이너 한 번 켜졌다고 이렇게까지?” 싶었는데,
서비스 구조상 부팅 시 동시 요청이 몰리면 CPU/트래픽이 자연스럽게 같이 뛰는 구조였음.
일단 이건 메모해둠.
서버 재시작 = 부하 급증은 어느 정도 자연스러운 현상임.
결론: chat_uid 예외처리 고치고 문제 해결됨
문제 핵심은 chat_uid 중복 케이스 처리 실패였음.
await 누락되어 promise rejection으로 인해 컨테이너가 죽는 문제 발생.
해당 부분 예외처리 정리하고 나선 동일 문제 재발 안 함.
'TIL' 카테고리의 다른 글
| redis 남아있는 죽은 socket.id 정리하기. (0) | 2025.11.24 |
|---|---|
| proxy_temp 파일이 날뛰어서 디스크 꽉 찼던 사건 정리 (1) | 2025.11.18 |
| Redis 한쪽노드에 메모리 몰린 경우 (0) | 2025.11.03 |
| Redis keys vs Scan 차이 (1) | 2025.11.02 |
| Node Exporter 네트워크 수집 문제 (0) | 2025.10.29 |