주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 ‐ 처음 해보는 성능 테스트를 위한 기본 정리 - thought-corner/backend-roadmap GitHub Wiki

포화점과 버클존

• 부하를 증가시키면 초기에는 처리량도 함께 증가한다.
• 그러다 일정 부하 구간에 도달하면 처리량의 증가 폭이 줄어들기 시작하고 어느 시점부터는 처리량과 응답 시간이 급격히 저하된다.
• 이 때, 성능이 저하되기 전에 최대 처리량을 포화점(saturation point)이라고 한다.
• 포화점은 시스템이 감당할 수 있는 성능 한계 지점이다. 포화점을 지나 성능이 꺾이기 시작하는 구간을 버클존(buckle zone)이라고 한다.

주요 측정 지표 정리

• 응답 시간 : 응답 시간은 여러 값(평균, 최대/최소, 중앙, 99%나 95% 백분위)을 측정한다.
• 처리량 : TPS(Transaction Per Second)는 초당 트랜잭션 처리 건수를 말하며, 초 단위로 얼마나 많은 요청을 처리했는지를 나타내는 지표이다. 테스트를 진행하는 동안 처리량은 변화하므로 최대, 평균, 최소값을 함께 구한다.
• 에러율 : 전체 요청 중에서 에러가 발생한 비율을 의미한다. 부하 테스트를 하다 보면 처리량은 높은데 에러도 함께 증가하는 상황이 생긴다. 에러가 발생한다는건 시스템이 부하를 감당하지 못하고 있다는 신호일 수 있다. 에러가 증가하기 시작하는 지점이 시스템의 한계일 가능성이 높다.
• CPU 사용률 : 일반적으로 웹 서버 성능 문제는 DB나 외부 연동에서 발생하지만 높은 CPU 사용률로 인해 문제가 생기는 경우도 있다. CPU 사용률을 측정하면 문제 원인을 분석할 때 범위를 좁히는 데 도움이 된다.

성능 테스트 설계 시 고려사항⭐

• 개발 → 테스트 코드 → 관찰 코드 심기 → 기준선 측정 → 부하 실험 → 병목 분석 → 개선 → 재측정
  • 관찰 코드를 미리 심어두기
  • 기준선(baseline)부터 재기
  • 일부러 부하를 올려 한계를 찾는 실험
  • 병목을 바꿔가며 원인 좁히기(핵심 습관)
  • 흔한 병목을 재현해보며 익히기
  • 성능 회귀 방지 자동화

성능 테스트 설계 시 주의사항

• 성능 테스트를 진행할 때 흔히 하는 실수 중 하나가 바로 테스트 대상 시스템과 부하기를 한 장비에서 실행하는 것이다.
• 부하 생성은 그 자체로 많은 자원을 사용한다. 따라서 테스트 대상 시스템과 부하기를 한 장비에서 실행하면 테스트 대상 시스템이 자원을 온전히 활용하지 못해 실제 성능보다 낮은 결과가 나온다. 성능 테스트를 진행할 때, 반드시 부하 발생기와 테스트 대상 시스템을 분리해야 한다.
• 서버 설정에 제한을 두고 부하 테스트를 실행하는 것도 자주 하는 실수 중 하나이다. 예를 들어 Nginx를 사용하는데 DDos 공격을 막기 위해 limit_req_zone을 사용해서 IP당 요청 개수를 10개로 제한했다고 가정하면 초당 10개의 제한이 걸리게 된다. 이러면 많은 요청에 대해 오류 응답이 발생하므로 제대로 부하 테스트를 할 수 없다. 비슷하게 서버 쓰레드를 개수나 DB 커넥션 풀의 크기가 작으면 부하 테스트가 제대로 이루어지지 않으니 테스트할 부하 규모에 맞게 풀의 크기를 미리 설정해야 한다.
• 운영 시스템과 동일한 네트워크 환경에서 부하 테스트를 진행하는 것도 조심해야 한다. 스트레스 테스트처럼 대량의 요청을 발생시킬 때는 테스트 대상 시스템에 많은 네트워크 트래픽이 발생한다. 실 운영 시스템과 테스트 대상 시스템을 동일 네트워크에 넣고 테스트를 실행하면 테스트가 발생시키는 트래픽이 실 운영 환경에 영향을 줄 수 있다.
• 외부 서비스를 연동하는 기능을 테스트할 때는 실제 외부 서비스를 사용하지 않게 주의해야 한다. 테스트하고 싶은 대상은 우리 시스템이지 외부 시스템이 아니기 때문이다. 외부 시스템 연동을 그대로 둔 채로 부하 테스트를 진행하면 외부 시스템이 트래픽을 견디지 못하고 장애가 발생할 수 있다. 이런 경우 실제 외부 서비스 대신에 가짜 외부 서비스로 대체해야 한다.
• 테스트 대상 시스템은 실제 운영 환경과 동일하게 구성해야 한다. 간혹 실제 운영 환경 대비 저사양 환경을 사용해서 테스트 대상을 구성할 때가 있다. 이렇게 되면 실제 환경에서 얼마나 성능을 낼 수 있는지 확인할 수 없다. 유효한 성능 지표를 구하려면 최대한 실제 환경에 맞춰야 한다.