[최종프로젝트] 테스트 시나리오

최종프로젝트 테스트 시나리오 참고사항

---

nGrinder Controller/Agnet 실행 환경

- 로컬 환경에 설치해서 EC2 서버에 요청을 보내는 방식으로 테스트

- nGrinder Controller/Agent를 실행하는 비용도 존재하기 때문에 서버와 동일한 환경에 설치해서 진행하는것은 바람직하지 않고, 서버 환경에 대한 스펙은 명시하되 Controller/Agent가 실행되는 환경의 스펙은 명시하지 않아도 무관하다.

 

서버 스펙에 대한 참고사항

- t2.micro: amazon linux 2023 ami / 1 vCPU / 1 GiB memory

- 위 서버 스펙은 aws freetier 스펙인데 실무에서는 4vCPU, 16GiB 환경을 주로 쓴다고 한다. 본 프로젝트는 학습의 목적이 크기 때문에 낮은 스펙으로 시작해 스펙을 올려가면서 테스트를 진행하고자함

- 고민해본 결과 spring application은 실행 시키기만 해도 메모리를 800mb나 잡아먹기 때문에 위 스펙으로 테스트를 진행했을시에 기대하는 테스트를 진행할 수 없을 것으로 판단. 테스트 머신의 최초 스펙은 아래와 같이 설정하고 시작하는 것으로 결정.

- t3.medium: amazon linux 2023 ami / 2 vCPU / 4 GiB memory

 

 

상품 검색 기능 부하테스트 시나리오 설계

---

• 테스트 개요
  • 상품 검색 기능의 성능 최적화 전/후 서버에 부하를 발생시켜 상품 검색 서비스의 성능이 어느정도 개선되었는지 측정하고 최적화 후 서비스에서 어느정도의 트래픽을 견딜 수 있는지 안정성을 측정하기 위함
• 테스트 환경
  • 서버 환경: AWS EC2 > DockerImage로 구동되는 Spring서버
    • t2.micro: amazon linux 2023 ami / 1 vCPU / 1 GiB memory
    • Docker 24.0.7, Spring Boot 3.2.1
• 테스트 시나리오 설계
  • 성능 최적화 전/후의 상품 검색 코드를 서버에 올린 후 10명의 agent로 시작해 100, 1000명 단위로 늘려서 테스트를 진행한다. 요청 Duration은 30분으로 설정한다. 성능 최적화 전/후 상황에서 서버가 감당 가능한 agent의 수를 찾는다.
  • Optional: 위 테스트 시나리오와 별도로 테스트 진행시 SQL이 예상한대로 날아가고 있는지(2번의 쿼리가 나가도록 개발했는데 3개가 나간다는 등) 테스트를 진행
  • 테스트 주소는 GET: http://13.125.46.61:8080/api/products 로 진행
  • 각 요청은 nGrinder Groovy 스크립트를 이용해 페이지 정보(offset, size)와 검색 키워드를 파라미터로 함께 전달
  • 성능 최적화 전/후의 TPS, MTT(nGrinder에서 확인 가능)와 서버의 CPU, MEM 사용률을 측정 비교한다.
    • CPU, MEM 사용률을 편하게, 그래프화해서 보고싶다면 AWS에서 제공하는 모니터링 기능을 사용해도 괜찮다.
    • 하지만, 본 프로젝트를 학습의 목적으로 진행하는 것이기 때문에 EC2 상에서 직접 shell script를 작성해 5초에 한번씩 CPU, MEM 사용률을 기록한다. (간단하게 하려면 도커로 오픈소스를 불러와 사용)
• 기대하는 테스트 결과
  • Postman을 이용해 간단한 테스트를 해봤을때, 최적화 이전에는 평균 1500ms의 응답시간을 보여주고 있고 최적화 이후에는 평균 50ms의 응답시간을 보여주었음. 따라서, 성능 최적화 이후의 테스트에서 TPS, MTT 지표가 더 좋게 나올것으로 예상함
  • CPU, MEM 사용률의 경우에는 측정 후 분석을 해봐야할 것 같음

 

 

상품 HotDeal 동시성, 정합성 테스트 시나리오 설계

---

• 테스트 개요
  • 재고가 100개인 핫딜 상품에 대해 3000명의 사용자가 거의 동시에 (약 7.5초)구매 요청을 하는 시나리오. 동시성 처리 및 데이터베이스 무결성확인을 중점으로함
• 테스트 환경
  • 서버 환경: AWS EC2 > DockerImage로 구동되는 Spring서버
    • t2.micro: amazon linux 2023 ami / 1 vCPU / 1 GiB memory
    • Docker 24.0.7, Spring Boot 3.2.1
• 테스트 시나리오 설계
  • 3000명의 사용자가 약 7.5초 이내로 3개씩 핫딜 상품구매 요청을 보내는 테스트 진행
  • 테스트 주소는 Post: http://13.125.46.61:8080/api/hotdeals/purchase로 진행
  • 각 요청은 사용자, 상품 정보를 포함한 Groovy 스크립트를 작성해서 서버에 전송
• 기대하는 테스트 결과
  • 재고 관리 정확성: 모든 구매 요청이 처리된 후, 핫딜 상품의 재고 수량이 정확하게 1이 되어야함
  • 동시성 처리 능력: 시스템은 동시에 들어오는 대량의 요청을 효율적으로 처리할 수 있어야함
  • 데이터 무결성: 데이터베이스의 무결성이 유지되며, 어떠한 경우에도 재고가 음수가 되지 않아야함

 

 

WebSocket Connection 부하테스트 시나리오 설계

---

 

실시간 댓글 개발기(part.2) - 험난했지만 유익했던 웹소켓 스트레스 테스트 및 안정화 작업

 

Using nGrinder to perform load test for a socket.io app

 

위 자료들을 읽고난후… nGrinder로 WebSocket Connection/부하 테스트를 진행하기에는 관련 자료가 적을 뿐더러 최적화가 되어있지 않아 WebSocket 연결을 수행하는 별도의 스크립트 작성에 시간이 많이 들 것이라고 판단했습니다. 프로젝트 마감 기한이 얼마 남지 않아 WebSocket에 대한 테스트는 테스트 환경이 잘 구축되어 있는 Jmeter로 진행하고자 합니다.