Django 성능 모니터링 첫 기록

핵심요약

성능 모니터링은 “서비스가 살아 있는가”를 넘어서, 얼마나 빠르고 안정적으로 동작하는가를 숫자로 계속 확인하는 작업이다.

그래서 오늘은 특히 세 가지 지표에 집중했다.

1. CPU 사용률 – 서버(관리자) 관점

먼저 서버 입장에서 얼마나 힘든지 보기 위해 CPU를 확인했다.

도구: htop

명령어:

sudo apt-get install htop   # 필요하면 설치
htop

결과:
- 1명이 퀴즈 사이트를 사용했을 때 CPU는 최대 약 11% 정도까지 올라감
- 현재 기준으로는 CPU 병목 가능성은 거의 없고, 꽤 여유 있는 상태

내가 대략 잡은 기준선:

정상: 0~50%
주의: 70% 이상이 계속 유지될 때
위험: 90% 이상이 유지될 때 → 과부하 의심, 원인 분석 필요

2. 응답 시간 – 사용자 관점

CPU가 서버 관점이라면, 응답 시간은 사용자 입장에서 체감하는 성능이다.

도구: 크롬 개발자 도구 → Network 탭
확인 방법:
1. 사이트 접속
2. F12 → Network 탭
3. 페이지 새로고침
4. 맨 위 document/html 요청의 Time 또는 Duration 확인
결과:
- 메인 페이지 로딩 시간: 약 240ms
- 유저 입장에서는 딱히 느리다고 느끼기 어려운 속도

CLI로도 빠르게 확인하고 싶다면 아래처럼 curl로 총 응답 시간을 볼 수 있다.

curl -o /dev/null -s -w 'time_total=%{time_total}\n' https://quizai.juwonpark.me

내가 머릿속에 잡은 감각:

~300ms: 빠른 편 (현재 상태)
~1초: 대부분 서비스에서 무난
2~3초 이상 계속: 느려졌다고 볼 수 있음 → 원인 분석 필요

3. 에러율 – “잘 동작하는 비율” 보기

퍼포먼스는 속도만이 아니라 얼마나 자주 실패하는지(에러율)도 중요하다.

브라우저 Network 탭에서 상태 코드(Status)를 보면서:

보통은 200, 204만 나와서 에러율 0%
존재하지 않는 URL(…/asfds)에 접속했을 때는 404가 찍히는 걸 확인

여기서 에러율 개념을 이렇게 정리했다.

에러율 = 전체 요청 중 4xx/5xx 비율

예를 들어,

요청 10개 중 1개가 404라면 → 에러율 10%

내 기준선:

정상: 0~1%
경고: 5% 이상
위험: 10% 이상 지속 → 로그 확인 & 원인 분석 필요

에러율이 5%를 넘기면 Nginx access 로그에서 어떤 URL이 계속 에러를 내는지 확인하는 것을 내 1순위 액션으로 정해두었다.

4. 오늘 정리 – 내가 만든 간단한 체크 루틴

퍼포먼스 모니터링을 처음 시작하면서 내가 정리한 “문제 생겼을 때 체크 순서”는 이거다.

응답 시간 확인 (사용자 관점)
- 크롬 Network 탭 → Time / Duration
CPU 사용률 확인 (서버 관점)
- htop으로 서버가 과부하인지 확인
에러율 감으로 체크
- Network 탭 상태 코드(200/404/500)를 보고
- 에러가 반복되면 Nginx access 로그로 어떤 URL이 문제인지 본다

아직 전문 모니터링 툴(Prometheus, Grafana, APM 등)을 쓰는 단계는 아니지만, 그래도 “감으로 느끼는 게 아니라 숫자와 지표로 보는 습관”을 만드는 첫 걸음은 밟았다고 생각한다.

결론

Process monitoring과 performance monitoring은 보는 질문이 다르다. Performance monitoring은 CPU, 메모리, 응답 시간, 에러율처럼 “얼마나 잘 동작하는가”를 본다. 반면 process monitoring은 “프로세스가 살아 있는가, 비정상 종료됐는가”를 보는 데 더 가깝다. 운영에서는 둘 중 하나만으로는 부족하고, 결국 둘을 같이 봐야 장애를 빨리 이해할 수 있다.