[D'art-gallery] 선착순 쿠폰(3) - 부하테스트 (12만 RPM)

소개

안녕하세요! D'art-gallery 프로젝트 백엔드 팀장 박창민입니다.

선착순 쿠폰 이벤트를 구현하면서 발생한 트러블슈팅을 포스트에 작성하겠습니다

 

본 글은 해당 게시글에 이어서 시작됩니다.

2024.06.18 - [구름톤 트레이닝 풀스택 회고] - [D'art-gallery] 선착순 쿠폰(2) - 글로벌 캐싱 도입

[D'art-gallery] 선착순 쿠폰(2) - 글로벌 캐싱 도입

 

 

 

쿠폰 대기열 구축 및 캐싱을 통한 성능 개선

이전 작업을 통해 쿠폰 대기열을 구축하고, 캐싱을 적용하여 시스템 성능을 개선하였습니다.

이제 대용량 트래픽 상황에서도 쿠폰 시스템이 안정적으로 동작하는지 확인하기 위해 부하테스트를 진행하겠습니다.

 

부하테스트 환경

• 장비: MacBook Air
• 칩: Apple M1
• 메모리: 16GB

부하 테스트 도구로는 Jmeter를 사용했습니다. (Jmeter의 사용법은 별도로 설명하지 않겠습니다.)

 

실제 서비스 환경에서 10만 명 또는 20만 명의 회원 데이터를 확보하는 데 어려움이 있었기 때문에, 동일한 로직을 활용한 사이드 프로젝트를 작성하여 테스트를 진행했습니다. 테스트에서는 회원 ID를 랜덤 값으로 설정하여 시뮬레이션했습니다.

 

---

 

문제점

JMeter로 부하 테스트를 진행하는 중, 분당 요청 건수가 3만 건을 초과하면 BindException 예외가 발생했습니다.

 

이 예외는 이미 해당 포트가 사용중이라는 의미였습니다. 짧은 시간 내에 새로운 네트워크 연결이 과도하게 생성될 경우, BindExceptiond이 발생할 수 있다고 확인했습니다.

 

짧은 시간 동안 많은 TCP 연결 요청이 발생하면서, 서버 작업이 끝난 후 소켓 연결을 닫는 Socket.close() 작업이 이루어지더라도, TCP 4-way handshake 과정의 마지막 단계인 TIME_WAIT 상태가 유지됩니다.

이 상태에서는 해당 포트가 즉시 해제되지 않으며, 반환되지 않은 소켓들이 누적되면서 큐에 요청이 쌓이고, 결국 시스템 리소스가 고갈되어 예외가 발생한 것입니다.

 

이를 해결하기 위해, 로컬 환경인 macOS에서 임시로 사용할 수 있는 포트 수를 늘려 부하테스트를 진행했습니다.

 

기본값

net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535

이 범위는 사용 가능한 포트의 시작과 끝을 의미합니다. 

 

임시로 설정 변경

sudo sysctl -w net.inet.ip.portrange.first=1024
sudo sysctl -w net.inet.ip.portrange.last=65535

포트의 시작을 1024 부터 시작하여, 범위를 늘려주었습니다.

참고: 이 변경은 재부팅하면 초기화됩니다.

---

부하테스트 시작

공통조건: 모든 테스트는 100명의 사용자가 반복 요청을 하는 방식으로 진행하겠습니다.

 

1분 동안 총 60,000번의 요청

 

결과 - Summary Report, Redis 대기열 값 (ZRANGE "coupon: 1" 0 -1)

 

결론 

60초 동안 100명의 사용자가 각각 600번씩 반복 요청한 결과, 1분 동안 대기열에 정확히 60,000명이 담겼고, 에러율은 0%였습니다.

---

 

1분 동안 총 100,000번 요청

 

결과 - Summary Report, 레디스 대기열 값 (ZRANGE "coupon: 1" 0 -1)

 

결론 

60초 동안 100명의 사용자가 각각 1000번씩 반복 요청한 결과, 1분 4초 동안 대기열에 정확히 100,000명이 담겼고, 에러율은 0%였습니다.

---

 

 

1분 동안 총 120,000번 요청

 

결과 - Summary Report, 레디스 대기열 값 (ZRANGE "coupon: 1" 0 -1)

 

 

결론

60초 동안 100명의 사용자가 각각 1200번씩 반복 요청한 결과, 1분 10초 동안 대기열에 정확히 120,000명이 담겼고, 에러율은 0%였습니다.

---

 

 

이 이상, 쓰레드 수를 늘리거나 반복 횟수를 증가시키면 다시 BindException 예외가 발생했습니다.

그럼에도 불구하고, 로컬 환경에서 부하 테스트를 진행한 결과, 12만 RPM으로 만족스러운 성능을 얻을 수 있었습니다.

 

결과적으로, 로컬 환경에서 벗어나 Redis 클러스터링을 도입하거나 서버 스케일링을 통해 더 많은 트래픽을 처리할 수 있을 것으로 예상됩니다. :)

 

 

지금까지 D'art Gallery 트러블 슈팅에 대하여 읽어주셔서 감사합니다.

 

 

 

 

Reference

https://sunshower99.tistory.com/19

[JMeter] 최대 Test thread 수 늘리기 - java.net.BindException 오류 해결