로컬 부하 테스트 시 봐야 할 서버 지표 관련 질문입니다.

---

집에서 테스트 목적으로 로컬 서버를 꾸미고, 특정 서비스에 주기적인 부하 테스트를 해보려고 합니다.
일단 CPU나 메모리 사용량 같은 기본적인 지표는 어느 정도 확인하고 있어요.

그런데 서비스 특성상 부하 테스트를 할 때, 이 두 가지 외에 놓치기 쉬운 다른 모니터링 지표들이 있을지 궁금합니다.
특히 웹 서비스나 API 같은 경우, 어떤 부분을 중점적으로 살펴보는 게 좋을까요?

예를 들어, 네트워크 I/O 쪽 지표라든지, 아니면 데이터베이스 연결 풀 같은 애플리케이션 레벨의 지표 같은 것도 고려해야 할지 조언을 얻고 싶습니다.
너무 광범위하면 오히려 뭘 봐야 할지 감이 안 잡혀서요.
가장 우선순위로 봐도 좋을 '핵심 지표' 2~3가지만 추천해주시면 정리하는 데 큰 도움이 될 것 같아요.

와, 로컬에서 부하 테스트까지 직접 해보시려는 거 보면 정말 깊이 파고들려고 하시는 것 같네요.
진짜 현업에서 어느 정도 경험이 있으신 분들이 많이 하는 고민이기도 하고, 이 부분은 '어떤 부하를 넣느냐'와 '어떤 서비스가 핵심이냐'에 따라 답이 완전히 달라지거든요.
근데 일반적인 웹/API 서비스 관점에서 '이건 무조건 봐야 한다' 싶은 핵심 지표들을 중심으로, 너무 광범위하지 않게 몇 가지 정리해 드릴게요.
일단 질문자님이 이미 CPU랑 메모리까지 보고 계시니까, 그건 기본기 세팅은 잘 되어 있다고 보고 넘어가겠습니다.
여기서부터는 '병목 지점(Bottleneck)'을 찾아내는 관점으로 접근하시는 게 좋습니다.
병목 지점이 CPU인지, 메모리인지, 아니면 다른 자원 때문인지 판별하는 과정이니까요.
가장 우선순위로 봐도 좋을 '핵심 지표' 3가지 추천 (웹/API 중심) 제가 딱 꼽자면, 다음 세 가지를 최우선으로 체크하시는 걸 추천합니다.
이 세 가지가 대부분의 성능 문제의 원인일 가능성이 높거든요.
1.
응답 시간 분포 (Latency Distribution) 및 에러율 (Error Rate) 이건 서버 지표라기보다는 '서비스 지표'에 가깝지만, 부하 테스트의 최종 목표가 이겁니다.
단순히 "CPU 사용률 80%일 때 응답 시간이 3초가 나왔다"라고 보는 것보다, "동시 사용자 N명일 때, 95%의 요청이 1초 이내에 응답하는가?"를 보는 게 훨씬 중요합니다.
이걸 Percentile(백분위수) 개념으로 봐야 해요.
평균 응답 시간(Average)은 이상치(Outlier)에 속아 실제 체감 성능을 가릴 때가 많습니다.
예를 들어, 평균이 0.5초라고 해도, 10%의 요청이 갑자기 30초씩 걸린다면, 사용자 경험은 최악인 거죠.
그래서 **P95 (95번째 백분위수)**나 **P99 (99번째 백분위수)**를 꼭 확인해보세요.
이 수치가 갑자기 급증하는 지점을 찾으면, 그 시점에 시스템의 어떤 부분이 한계에 도달했는지 추론하기가 훨씬 수월해집니다.
그리고 당연히, 에러율(5xx 응답 코드 등)이 갑자기 올라가는 지점도 기록해야 합니다.
2.
데이터베이스 연결 풀(Connection Pool) 및 쿼리 지표 웹 서비스의 90% 이상의 지연 시간은 DB에서 발생한다고 해도 과언이 아닙니다.
여기서 DB 연결 풀 관리가 핵심입니다.

• 커넥션 풀 사용률(Usage Rate): 연결 요청 대비 실제로 사용 중인 연결의 비율을 보세요.
  이 수치가 지속적으로 90% 이상으로 치솟으면서, 요청이 들어올 때마다 'Connection Timeout' 같은 에러가 발생한다면, 연결 풀 사이즈를 늘리거나(임시방편) 아니면 쿼리 최적화가 시급하다는 신호입니다.
• 느린 쿼리(Slow Query) 추적: 부하 테스트 중 가장 많은 리소스를 잡아먹는 쿼리가 무엇인지 확인해야 합니다.
  단순히 DB CPU만 보는 게 아니라, "어떤 쿼리가 평균적으로 몇 밀리초를 소비하는가?"를 추적하는 게 중요합니다.
  인덱스 누락이나 비효율적인 JOIN이 원인인 경우가 태반입니다.
  3.
  네트워크 I/O 및 세션/스레드 상태 이건 시스템 레벨에서 조금 더 깊게 볼 수 있는 부분입니다.
  네트워크 I/O 자체도 중요하지만, 더 눈여겨봐야 할 건 **'대기 상태(Waiting State)'**와 **'스레드 풀(Thread Pool)'**입니다.
• 스레드 풀 고갈: 웹 서버(예: Tomcat, Jetty 등)가 내부적으로 사용하는 스레드 풀이 만개(Exhaustion) 되는 경우가 있습니다.
  동시 요청이 폭주하면, 스레드가 부족해져서 요청이 아무리 와도 처리할 스레드가 없으면 대기 상태에 빠지게 되는데, 이게 지연 시간 급증의 원인이 됩니다.
  어떤 언어/프레임워크를 쓰시는지에 따라 이 지표를 확인하는 방법이 다릅니다.
• TCP 연결 상태: 과도한 연결/해제(Connection Rate)가 발생하거나, ESTABLISHED 상태의 연결이 비정상적으로 많이 쌓이는지 확인하는 것도 좋습니다.
  이는 리소스 누수(Leak)의 초기 징후일 수 있습니다.
  --- 실무 팁 및 주의점 (이걸 놓치면 안 돼요!) ️ 흔한 실수 1: 부하 테스트 환경과 실제 운영 환경의 차이 무시하기 로컬 환경에서 테스트한다고 너무 안심하면 안 됩니다.
  로컬 서버는 보통 고성능한 네트워크 카드나 대용량 RAM을 가지고 있어서, 실제 클라우드 환경(예: AWS t3.micro 같은 T-시리즈 인스턴스)에서 받을 수 있는 I/O 제한이나 네트워크 대역폭 제한 같은 제약 조건이 빠져있을 수 있습니다.
  테스트 시에는 '최대 성능'이 아닌, **'예상되는 최대 트래픽'**에 맞춰서 부하를 주는 것이 중요합니다.
  ️ 흔한 실수 2: 테스트 부하를 너무 점진적으로 올리기만 하기 단순히 10명 -> 50명 -> 100명으로 늘리는 것(Ramp-up)만으로는 부족합니다.
  실제 트래픽은 '계단식'으로 오르지 않아요.
  갑자기 피크가 오거나, 특정 시간대에 트래픽이 몰리죠.
  테스트 설계 시, **'최대 부하 시점(Peak Load)'**을 명확히 설정하고, 그 지점에서 시스템이 얼마나 오래 버티는지(Sustained Load)를 테스트하는 것이 중요합니다.
  추가적으로 고려할 만한 지표 (레벨별) * 애플리케이션 레벨 (추가 점검): 캐시 히트율(Cache Hit Ratio).
  만약 Redis 같은 캐시를 사용한다면, 이 비율이 갑자기 떨어지면서 DB 호출이 폭증하는 패턴이 보이면, 캐시 자체가 문제의 원인일 수 있습니다.
• 운영체제 레벨 (추가 점검): 파일 디스크립터(File Descriptor) 사용량.
  서버가 수많은 파일이나 연결을 열고 닫으면서 리소스를 누수시키면, 이 디스크립터 제한에 걸려 아예 요청 처리가 안 되는 경우가 있습니다.
  요약 정리 (순서대로 체크리스트로 활용해 보세요) 1.
  [서비스 지표] P95/P99 응답 시간 변화 추이 및 에러율 변화 지점 포착.
  (가장 중요) 2.
  [DB 지표] 연결 풀 사용률 및 Top N 느린 쿼리 패턴 분석.

[WAS/OS 지표] 스레드 풀 포화 여부 및 자원 고갈 징후(Timeout 등) 확인.
이 세 가지 관점에서 '어떤 지표가 먼저 깨지기 시작했는가?'를 역추적해 나가시면, 병목 지점을 굉장히 좁혀서 원인 분석을 하실 수 있을 겁니다.
너무 많은 지표를 한 번에 보려고 하면 오히려 뭘 봐야 할지 막막하니까, 우선순위를 정해서 하나씩 파헤치는 방식으로 접근하시는 것을 추천드립니다.
화이팅하시고, 테스트 잘 진행하시길 바랍니다!