[부하 테스트] 결과 (1차)

지금까지 부하 테스트를 진행하기 위해서 클라이언트 (Jmeter)를 설치하고 서버 설정을 진행하였다.
이번 장부터는 본격적으로 부하테스트를 진행하고 결과를 확인해보는 시간을 가져본다.
정확히는 필자의 환경에서 테스트를 진행하고 분석하는 과정을 살펴볼 것이다.

---

Dataset

부하 테스트는 개발DB에 연결해서 진행한다.
부하 테스트를 위해 개발DB에 dummy 데이터를 Insert하였다. 상용DB와의 차이는 아래와 같다.

	개발	상용	개발 - 상용
company	50	436	-386
company_manager	49	436	-387
company_member	92,985	8,022	84,963
comapny_settlement	2,224	0	2,224
allocation_mapping	455,396	22,395	433,001
allocation	482,916	2,187,567	-1,704,651
chauffeur	564	49,507	-48,943
deal_ledger	5,458,256	788,667	4,669,589

실제로 Select 속도에 가장 영향을 주는 테이블은 company_member와 allocation_mapping, deal_ledger 테이블이다.
이러한 테이블들은 상용DB 대비 더 많은 데이터를 넣어두었다.
필자가 운영하는 서비스의 경우 상용DB가 개발DB보다 더 좋은 Instance를 사용하고 있다.(RDS 기준)
이번 부하테스트를 진행하고 최대 동접자를 측정한 결과보다 실제 상용 환경에서는 더 많은 동접자를 처리하게 될 것이다.
하지만 실제로 고객의 요청이 몰렸을 때 병목 현상이 발생하는 지점을 파악하는데 큰 의미가 있다고 생각한다.

테스트 결과

작성일 기준 인스턴스 유형(m5.xlarge), RDS 인스턴스 클래스(db.t3.small)에서 수용가능한 최대 동접자 수는 50명미만 이다.

• 동접자 수: 요청하는 Threads (유저)의 수.
• 요청 Count: 테스트 기간 동안 모든 Thread들의 요청의 합.
• 에러 Count: 테스트 기간 동안 발생한 에러 응답의 합. 단 404코드와 같이 서버 리소스 사용량과 무관한 에러코드는 200코드로 간주한다.
• 컨테이너 재기동 유무: 리소스 부족으로 인해 컨테이너 재기동 유무 (X = 긍정, O = 부정)

동접자 수	요청 Count	에러 Count	에러율	평균 TPS	컨테이너 재기동 유무
50	1045	45	4.31% (502: 4.31%)	0.87	O (2회)
100	2084	94	4.51%(502: 4.22%, 504: 0.29%)	1.70	O (2회)
150	3105	709	22.83% (500: 10.14%, 502: 10.76%, 504: 1.93%)	2.48	O (4회)
200	4099	1406	34.3% (500: 19.57%, 502: 12.52%, 504: 2.22%)	3.29	O (3회)

---

지금까지 1차 부하테스트 결과를 살펴보았다.
다음 장에서는 1차 부하테스트를 분석해서 50명도 버티지 못하고 컨테이너가 재시작된 이유를 찾아본다.