부하테스트 단계와 발생 문제 유형

현재 진행중인 실험이 전체 부하 테스트의 단계에서 어느 단계에 있고, 발생한 원인은 어떤 유형인지 파악하고자 이 글을 썼습니다. 아래 내용은 책 <아마존 웹 서비스 부하 테스트 입문>에서 발췌했다.

단계에 따른 부하 테스트

부하 테스트는 보통 1)로컬 호스트에서 ab 등으로 간단히, 2) 부하 테스트 서버에서 ab로 한 다음 마지막으로 3)전용 툴로 진행하는 것이 좋다고 책에서는 제안했다. 처음에는 가볍게 테스트 해보란 말이다. 가볍게 테스트를 끝낸 뒤 본격적으로 테스트를 할 때 어떤 플로우로 접근을 해야할 지 알아보겠다.

부하 테스트를 체계적으로 접근하기 위한 단계는 아래와 같다.

1. 도구와 환경 검증
2. 웹 프레임워크 검증
3. DB 참조계 성능 검증
4. DB 갱신계 성능 검증
5. 외부 서비스 연동 성능 검증
6. 스케일 업/아웃 테스트 + loop(1-6단계)
7. 한계 성능 테스트 + loop(1-6단계)

도구와 환경 검증

• 테스트 도구의 경우, 클라이언트를 따로 둘 수 있거니와 우리 주변에 관련 경험이 있는 개발자분들이 있어 피드백을 빠르게 얻을 수 있다고 판단되어서 nGrinder로 선정했다.
• 실제 서비스의 경우 유저와 서버 간 거리가 있다. 따라서 테스트 서버도 거리를 둬야 된다고 생각하지만 만약 그렇게 되면 적절한 부하를 주는 것이 어렵다고 한다.

웹 프레임워크 검증

• nestjs를 선택했다. 특별이 이에 대해 성능 이슈는 없을 것으로 판단된다.

DB 성능 검증

• 참조계 : partial entity를 적용할 필요가 있다
• 갱신계 : 이에 대해서도 추가로 연구가 필요하다
• 캐싱 : 꼭 적용이 필요한 기술이다

외부 서비스 연동 성능 검증

• 우리 어플리케이션에 해당되지 않음

스케일 업/아웃 테스트 및 한계 성능 테스트

• 추후 인프라 관련 기능도 다룰 예정이다. 인프라는 AWS를 사용할 예정

부하 테스트 시 발생할 수 있는 문제 유형

• 인프라 이슈
  • 로드 밸런서
  • 네트워크 설정
  • 네트워크 대역
• 웹서버 CPU/메모리 리소스 부족 이슈
• 어플리케이션 이슈
  • 웹 프레임워크
  • 캐시 설정
  • 불필요한 요청
  • 로직
  • CPU/Mem 효율이 좋지 않은 코드
• DB 이슈
  • 참조 SQL
  • 갱신 SQL
  • 적절한 실행 계획이 없음
  • 적절한 인덱스의 부재
  • CPU/메모리 리소스 부족
  • 락 발생
• 미들웨어 설정 이슈