핵심요약

“서비스가 살아만 있는지”가 아니라 **얼마나 빠르고 안정적으로 잘 돌아가는지 숫자로 계속 확인하는 것**

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

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
    • 유저 입장에서는 딱히 느리다고 느끼기 어려운 속도

내가 머릿속에 잡은 감각:

  • ~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. 오늘 정리 – 내가 만든 간단한 체크 루틴

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

  1. 응답 시간 확인 (사용자 관점)

    • 크롬 Network 탭 → Time / Duration

  2. CPU 사용률 확인 (서버 관점)

    • htop으로 서버가 과부하인지 확인

  3. 에러율 감으로 체크

    • Network 탭 상태 코드(200/404/500)를 보고
    • 에러가 반복되면 Nginx access 로그로 어떤 URL이 문제인지 본다

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

결론

ProcessMonitoring과 Performance Monitoring모니터링은 다르다

  • Performance Monitoring: 프로세스의 퍼포먼스를 모니터링 서버의 점의률(cpu, mem), 응답 시간 등을 확인함 일정 부분을 넘어가면 관리자한테 알람을 보냄

  • ProcessMonitoring:프로세스가 잘 작동하고 있는지 모니터링, 비정상적으로 종료되었는지 등을 확인