소프트웨어 마에스트로에서 "온라인 강의 큐레이션 서비스 - curady"를 개발하며 생긴 일

프로젝트 완성 후 무얼해볼까?

[온라인 강의 큐레이션 서비스 curady] 프로젝트가 완성되었다.

내가 만든 서버가 어느정도의 트래픽, 부하를 감당할 수 있는지 궁금해졌다.
찾아보던 중 Jmeter라는 도구를 이용하여,
TPS(Transaction Per Second)를 측정할 수 있다는 것을 알았다.

Jmeter

brew install jmeter

나는 mac os를 사용하고 있어서 brew를 통해 간편하게 설치할 수 있었다.

Test 환경 설정

우선 위와 같이 Thread Group을 설정했다.
10명의 유저가 1초에 300개씩 요청을 보내는 상황을 가정한 것이다.
즉 1초에 총 3000개의 요청을 보내는 것이다.

위와 같이 호기심삼아 http와 https로 각각 요청을 보내보았다.

우리 서비스의 메인기능 중 하나인 강의 목록 조회 요청으로 테스트를 진행했다.

결과

1. http 요청

위 사진은 View Results Tree의 일부분이다.
발생항 요청과 그에 대한 응답에 대한 정보를 확인할 수 있다.
보면 nginx에서 301 reidirect을 통해 https로 리다이렉션 해주는 것도 확인할 수 있었다. 리다이렉션 후 200 Response를 받았다.
위 사진은 Summary Report의 일부분이다. 다음과 같은 결과 레포트를 확인할 수 있다.
Average - Sample Time의 평균
Min - Sample Time의 최소
Max - Sample Time의 최대
Std. Dev. - Sample Time의 표준편차
Error % - 에러율
Throughput - 시간당 처리량(=쓰루풋)
Received KB/sec - 시간당(sec) 받은 데이터(KB)
Sent KB/sec - 시간당(sec) 보낸 데이터(KB) 사진이 너무 커서 잘 안보이지만, 요청을 모두 처리하는데 8초가 걸렸고,
그래프에서 가장 높은점은 대략 475정도 되는 것 같다...
최대 TPS가 475라는 의미인 것 같은데,, 내 기대에 비해 너무 낮았다.

2. https

두 번째로 https 요청을 보내봤다.
생각보다 유의미한 차이가 있었다. 요청을 모두 처리하는데 http로 보냈을 때보다 2초 적은 6초가 걸렸고, 그래프에서 가장 높은 점은 대략 520~530정도?로 나왔다.
http로 요청을 보낼 경우 80을 443으로 redirect시키는 과정에서 차이가 발생하는 것 같다.

TPS 개선 방안

Jmeter를 통해 내 서버는 대략 초당 500개의 요청을 감당할 수 있다는 것을 파악했다.
이에 대해 SW 마에스트로 expert님과 멘토님께 조언을 구했을 때 TPS가 2~3000정도 나오면 괜찮은 서버라고 하셨다.
따라서 TPS를 개선하기 위한 방법을 몇가지 생각해봤다.

1. 로드 밸런싱

현재 AWS 클라우드 상에 배포를 하고 있기 때문에 ALB를 이용하여 요청을 분산시켜보려 한다. (하는 김에 무중단 배포도 도전해봐야지)

2. EC2 유형 변경

일종의 스케일 업이라고 할 수 있을까? 현재 비용절감을 위해 t2-micro를 사용하고 있는데 이것을 좀 업그레이드 해봐야겠다.

3. RDS

이건 RDS 모니터링 탭에서 가져온 DB연결 개수인데, 보니까 계속 꾸준히 연결이 10개로 유지되고 있었다. 이것에 대해서 좀 더 알아보고 개선할 수 있는 방법도 존재할 것 같다.
(Spring Boot에서 DB연결을 위한 커넥션 풀을 10개 만들어놓고 쓴다는 것이 어렴풋이 기억이 나는데 이것과 관련있을 수도 있겠다. 더 찾아봐야겠다.)

4. 더 공부하기

다른 방법에 대해서도 더 공부해서 추후에 성능 개선을 통해 다시 글을 작성해야겠다 !