서버 CPU 급증, 어디부터 뜯어봐야 할까요?

---

요즘 저희가 돌리는 웹 서비스가 특정 시간대에 갑자기 CPU 사용률이 튀어 오르는 현상이 발생했어요.
단순한 트래픽 폭증이 아니라, 뭔가 내부적인 구조적 문제 같은 느낌을 받아서요.

일단 기본적인 모니터링 툴로는 어느 정도까지는 보이는데, 원인을 좁혀 들어가는 게 어렵습니다.
어떤 계층(레이어)부터 병목 지점을 확인하는 게 가장 효율적일까요?

애플리케이션 레벨인지, 아니면 DB 쿼리 최적화가 필요한 백엔드 로직 자체의 구조적 문제인지, 이런 걸 체계적으로 추적하고 싶습니다.
개발 리소스 낭비 없이, 가장 영향도가 큰 병목 지점부터 파고들 만한 체크리스트 같은 게 있을지 궁금합니다.

아...
CPU 급증 현상 때문에 골치 아프시겠네요.
특히 트래픽 폭증이 아닌 '구조적 문제' 같다는 느낌을 받으셨다니, 단순히 트래픽 탓으로 돌리기는 어려우신 상황이신 것 같습니다.
저도 이쪽 분야에서 몇 번 겪어봐서 어느 정도 감이 오거든요.
이런 건 정말 체계적으로 접근해야 시간 낭비를 줄일 수 있어요.
'어디부터 봐야 할지'가 가장 어렵잖아요.
일단 결론부터 말씀드리자면, 한 번에 모든 레이어를 다 보려고 하면 진짜 리소스 낭비입니다.
가장 효율적인 접근 순서와 체크리스트를 단계별로 정리해서 말씀드릴게요.
이거 참고하셔서 순서대로 훑어보시면 원인에 한 걸음 더 가까워지실 겁니다.
--- ### 1단계: 가장 가볍고 범용적인 '현상 재확인 및 범위 좁히기' (Monitoring & Scope) 일단 툴을 만지기 전에, '언제' 문제가 터지는지 시간 축으로 좁히는 게 최우선입니다.
이게 제일 빠르고, 가장 큰 원인을 걸러낼 수 있어요.
1.
시간대별/기능별 상관관계 분석: * CPU가 급증하는 '특정 시간대'가 있나요?
(예: 점심시간, 퇴근 직전 등) * 그 시간대에 사용자들이 주로 사용하는 기능이 있나요?
(예: 특정 리포트 조회, 결제 시도, 게시글 작성 등) * 팁: 만약 특정 기능 A를 사용할 때만 CPU가 터진다면, 일단 A 기능의 백엔드 로직과 DB 쿼리부터 의심해야 합니다.

• 만약 특정 시간대(예: 매일 새벽 2시)에 무조건 터진다면, 이건 '스케줄링 작업(Cron Job)'이나 백그라운드 배치 작업이 원인일 확률이 매우 높습니다.
  이걸 제일 먼저 점검해보세요.

트래픽 패턴 확인: * 정말로 '사용자 수' 때문인지, 아니면 '요청의 복잡도' 때문인지 확인해야 합니다.

• 예시: 사용자 수는 그대로인데, 갑자기 '전체 기간 데이터 조회' 같은 무거운 API 요청이 몰리면 CPU가 터집니다.
• 확인 포인트: 요청 빈도(RPS) 자체가 폭증했는지, 아니면 요청당 처리하는 데이터의 양(Payload Size/Complexity)이 폭증했는지 확인하세요.
  --- ### ️ 2단계: 애플리케이션 레벨 진단 (Application Layer Deep Dive) 1단계에서 '특정 기능'과 연관성이 확인되었다면, 이제 코드 레벨을 뜯어볼 차례입니다.
  이 단계에서는 '어떤 함수'가 CPU를 많이 쓰는지 찾는 게 목표입니다.

애플리케이션 성능 모니터링(APM) 툴 활용: * 만약 사내에서 APM 툴(New Relic, Datadog, Pinpoint 등)을 쓰신다면, 그걸로 '가장 많은 시간을 소모하는 트랜잭션(Transaction)' 순서로 정렬해보세요.

• 이걸로 1차 필터링을 해서, 'DB 호출'이 많이 걸리는지, 아니면 '복잡한 연산(CPU 바운드)'이 많이 걸리는지 큰 그림을 파악할 수 있습니다.

코드 레벨 분석 (Profiling): * 이게 핵심입니다. 단순히 요청이 많이 온다고 해서 CPU가 터지는 게 아니에요.
특정 로직이 비효율적으로 돌아가서 CPU를 100% 점유하는 경우도 많습니다.

• Profiling: 해당 요청이 들어왔을 때, 어떤 메소드 호출에 시간이 가장 오래 걸리는지 '스택 트레이스'를 받아서 봐야 합니다.
• 흔한 실수 체크: * N+1 쿼리 문제: 이게 제일 흔하고 치명적입니다.
  ORM을 사용하면 눈에 안 띄게 수많은 쿼리가 날아가서 DB 연결 풀이나 CPU를 고갈시킵니다.
• 반복문 내에서 DB 호출: for (item in list) { db.query(item); } 같은 코드는 절대 피해야 합니다.
  무조건 일괄 처리(Batch)로 묶어야 합니다.
• 비효율적인 데이터 구조 처리: 리스트에서 매번 검색(list.find(x))하는 대신, 딕셔너리/맵(Hash Map)을 사용해서 O(n)을 O(1)로 줄이는 등 자료구조 최적화가 필요한 부분이 있는지 보세요.
  --- ### 3단계: 데이터베이스 레벨 진단 (Database Bottleneck) 애플리케이션 레벨에서 'DB 호출이 너무 많다'는 결과가 나왔다면, DB로 시선을 돌려야 합니다.
  이 단계에서는 '쿼리' 자체의 문제인지, 아니면 'DB 서버 자체의 부하' 문제인지를 분리해야 합니다.

쿼리 튜닝 (가장 높은 확률의 원인): * Slow Query Log 확인: DB에서 제공하는 슬로우 쿼리 로그를 켜서, 가장 오래 걸리는 쿼리 5개를 뽑아내세요.

• EXPLAIN 사용 습관화: 해당 쿼리를 복사해서 EXPLAIN 또는 EXPLAIN ANALYZE를 붙여서 실행해보세요.
  이게 가장 중요합니다.
• 주요 확인 사항: * Full Table Scan: 만약 WHERE 절에 사용된 컬럼에 인덱스가 없거나, 쿼리가 인덱스를 아예 무시한다면, 이건 치명적입니다.
  인덱스를 추가하거나, 쿼리 로직을 수정해야 합니다.
• JOIN 방식: 너무 많은 테이블을 불필요하게 JOIN하거나, JOIN 조건 자체가 비효율적일 수 있습니다.

DB 자원 모니터링: * CPU 외에 I/O Wait 시간을 반드시 확인하세요.
CPU가 아무리 낮아 보여도, 디스크 I/O가 지속적으로 발생하며 병목이 생길 수 있습니다.

• 커넥션 풀(Connection Pool) 고갈: 요청이 몰릴 때, 커넥션을 요청하고 반납하는 과정이 원활하지 않아 대기열(Queue)에서 쌓여서 지연이 발생할 수 있습니다.
  커넥션 풀 크기 설정값 검토가 필요합니다.
  --- ### 🧩 4단계: 아키텍처 및 인프라 관점 (System Level Review) 위의 세 가지 단계를 모두 거쳤는데도 원인을 못 찾았거나, 원인이 너무 광범위하다면, 시스템 설계 자체의 문제일 수 있습니다.

캐싱 전략 검토: * 가장 효과적인 비용 절감책입니다. 모든 요청이 DB를 직접 때리게 두지 마세요.

• 자주 변하지 않지만 자주 조회되는 데이터 (예: 설정값, 메인 페이지 공통 데이터)는 Redis 같은 인메모리 캐시에 걸어두는 것만으로도 CPU/DB 부하가 드라마틱하게 줄어듭니다.
• 주의: 캐시 무효화(Cache Invalidation) 로직이 복잡해지면 이게 또 다른 버그 포인트가 될 수 있으니, 캐싱 도입 시 로직을 최대한 단순하게 유지하는 게 좋습니다.

비동기 처리(Asynchronous Processing) 도입 검토: * 사용자에게 즉각적인 응답이 필요하지 않은 작업(예: 이메일 발송, 파일 업로드 후 처리, 통계 집계 등)은 **메시지 큐(Kafka, RabbitMQ 등)**를 이용해 백그라운드로 분리하세요.

• 요청이 들어오면 일단 큐에 메시지만 넣고 '성공 응답'을 바로 주면, 주 서버의 부하가 급격히 줄어듭니다.
  --- ### 요약 및 최종 체크리스트 (Action Plan) 시간 낭비를 최소화하려면, 이 순서로 딱 3가지만 먼저 체크해보세요.

[시간/기능] 상관관계 분석: 언제, 무슨 기능 할 때 터지는가?
(-> 범위 좁히기) 2.
[APM/Profiling] 병목 트랜잭션 확인: 가장 오래 걸리는 API 호출이 무엇인가?
(-> 코드 문제 유추) 3.
[DB] Slow Query Log & EXPLAIN: 그 API가 호출할 때 가장 무거운 쿼리는 무엇이며, 인덱스가 제대로 작동하는가?
(-> DB 문제 유추) 이 세 가지를 통해 80% 이상의 원인은 발견할 수 있을 겁니다.
만약 이 과정에서 'A 기능'이 문제라고 좁혀졌는데, 코드를 아무리 봐도 이해가 안 되는 비효율적인 부분이 발견되면, 그때는 주저하지 마시고 해당 로직만 따로 빼서 '프로파일링'을 다시 돌려보시는 걸 추천합니다.
너무 스트레스 받지 마시고, 하나씩 단계적으로 접근하시면 분명 원인을 찾으실 수 있을 거예요.
응원하겠습니다!