[ webtooniverse ] 내가 만든 서비스는 얼마만큼의 사용자를 견딜 수 있을까? - 서버 스트레스 테스트 (1)

본 포스팅은 성능 테스트를 진행하면서 겪은 이슈와 이를 해결해나가며 겪은 개인적인 경험을 공유하고자 작성하였습니다.

고로 포스팅에 잘못된 점은 지적해주시면 감사하겠습니다 :)

 

* 테스트는 가장 자주 호출되고, 필수적인 API 위주로 측정하였습니다.

 

현재 구조

---

[ 과정 ]

성능 테스는 다음과 같은 순서로 진행하고자 합니다.

 

1. 단일 요청에 대한 Latency 확인해보자

 

- 만약 Latency가 기대하는 Latency보다 높다면 scale out으론 해결되지 않을 것이다.

단일 요청에 대한 Latency를 먼저 확인해보고, 결과를 바탕으로 병목을 의심해보고자합니다.

- Latencty는 500ms를 기준으로 잡았습니다.

 

2. scale out을 해보고

 

- Latency는 현재 500ms 이내를 기대하고 있다.

- 만약 Latency가 기대하는 Latency보다 높다면 scale out으론 해결되지 않을 것이다. 코드의 비효율이나 I/O병목을 의심해보자

---

1. 단일 요청에 대한 Latency가 기대하는 Latency인 500ms 이내인지 확인

- webtooni/naver/kakao 랭킹 -

 

 

[ 개요 ]

해당 API의 Latency가 기대하는 Latency보다 높을 경우, 이는 다른 곳에 병목현상이 발생하고있거나 코드가 비효율적으로 작성됐을 가능성이 높다고 생각하여 scale out으로 해결되지 않을 것이라고 생각했다.

따라서 단일 요청에 대한 Latency를 측정해보고, scale out을 통해 얼마나 성능이 향상되었는지 측정해보려고한다.

 

[ 테스트 환경 #1 ]

- 가벼운 테스트 툴을 빠르게 사용하기 위해 Artillery를 사용하였습니다.

- 메인 페이지의 웹투니버스/네이버/카카오 랭킹 기능을 테스트하였습니다.

- Redis 캐시를 이용해 각 조회 기능을 빠르게 가능하도록 구현했습니다.

- 단일 서버 구성에도 scale out시에 사용할 로드밸런싱을 추가함으로써 Scale out 시에도 순수하게 서버가 늘어났을 때 증가하는 성능을 측정하고자하였습니다.

- Target 서버 사양은 2vCPU, 2GB 메모리 서버 한대이고 Redis 서버 사양은 1vCPU, 2GB 메모리 서버 한대입니다.

 

[ 시나리오 #1 ]

-duration 300 arrivalRate 1

 

[ 결과 ]

 

1. 웹투니버스 웹툰 랭킹

- 단일 요청 Latency : 77ms

2. 네이버/카카오 웹툰 랭킹

- 단일 요청 Latency : 78ms

 

VM은 인접하고 있는 인스턴스들과 자원을 공유하기 때문에 항상 똑같은 수준의 퀄리티를 보장할 순 없기에 중간에 가끔씩 튀지만.. 랭킹 모두 다행히 평균적으로 좋은 성능이 나왔다.

 

그렇다면 ramp up을 도입하여 좀 더 고도화 된 시나리오를 작성해보자

---

2. ramp up을 도입하여 고도화된 시나리오 테스트가 기준 성능에 부합하는지 확인

 

 

[ 시나리오 #2 ]

1. 총 1만명의 vuser

- duration 100, arrivalRate 100

 

[ 결과 ]

TPS :100, Latency: 175 ms

 

 

2. 총 5만명의 vuser

- duration 300, arrivalRate 100

- duration 100 arrivalRate 200 ramp up 

 

[결과]

200-300초 사이부터 High CPU usage warning이 뜨기 시작했고, ramp up되는 순간부터 튀기 시작한다. 그럼에도 불구하고 모두 실패없이 응답을 잘 받아왔다.

 

TPS: 200, Latency: 200ms

 

3. 총 10만명의 vuser

- duration 200, arrivalRate 200

- duration 100 arrivalRate 300 ramp up 

- duration 100 arrivalRate 300 sustained

 

시작하자마자 High CPU usage warning이 뜨기 시작한다. 사용률이 25% 정도 넘어가면 warning을 띄워주는 것 같다.

worker

 

nginx

TPS: 300, Latency: 300ms

 

캐싱하기 전엔 TPS 200 넘어가면 응답을 제대로 못했었는데 이젠 TPS 300도 버텨낸다.

 

---

1. 단일 요청에 대한 Latency가 기대하는 Latency인 500ms 이내인지 확인

- 웹툰 평론가 추천/ 완결 작품 추천 -

 

 

[ 테스트 환경 #2 ]

- 추천 페이지의 웹툰 평론가 추천, 완결 작품 추천 기능을 테스트하였습니다.

- 업데이트가 빈번한 곳이기 때문에 Redis 캐시를 적용하지 않았습니다.

- Target 서버 사양은 2vCPU, 2GB 메모리 서버 한대입니다

 

[ 시나리오 #1 ]

-duration 300 arrivalRate 1

 

[ 결과 ]

Latency 70ms

---

2. ramp up을 도입하여 고도화된 시나리오 테스트가 기준 성능에 부합하는지 확인

 

[ 시나리오 #2 ]

1. 총 1만명의 vuser

- duration 100, arrivalRate 100

 

[ 결과 ]

high cpu warning

2. 총 5만명의 vuser

- duration 300, arrivalRate 100

- duration 100 arrivalRate 200 ramp up 

 

TPS를 200번 정도로 올리자, TIMEOUT이 발생하면서 29개 정도의 요청을 실패하기 시작했다.

Latency는 평균 100ms로, 높지 않은 수치이다.

---

1. 단일 요청에 대한 Latency가 기대하는 Latency인 500ms 이내인지 확인

- 톡톡 페이지 글 작성, 조회 -

 

[ 테스트 환경 #3 ]

- 톡톡 페이지의 톡톡 작성, 조회 기능을 테스트하였습니다.

- 게시글 데이터 10만개를 가공하여 테스트 데이터로 사용하였습니다.

 * 출처 : Naver sentiment movie corpus v1.0

- 업데이트가 빈번한 곳이기 때문에 Redis 캐시를 적용하지 않았습니다.

- Target 서버 사양은 2vCPU, 2GB 메모리 서버 한대입니다.

 

[ 시나리오 #1 ]

-duration 300 vuser1

- post -> think:1 ->get

 

[ 결과 ]

총 300개의 게시글을 작성후 1페이지 조회

---

2. ramp up을 도입하여 고도화된 시나리오 테스트가 기준 성능에 부합하는지 확인

 

[ 시나리오 #2 ]

1. 총 1만명의 user

- duration 100, vuser 100

 

추가로 1만개의 데이터 작성후, 1페이지 조회시

 

여기서 이상한 점은 300초 동안의 단일요청이 100초동안 100개의 요청보다 Latency가 높다는 점이다.

 

더 오랜 시간동안 요청을 보낼 경우, 톰캣의 큐가 더 빨리 차서 놀고 있는 스레드가 점점 줄어드는 것인가를 의심 중이다. 

 

2. 총 5만명의 user

- duration 300, vuser 100

- duration 100 vuser 200 ramp up 

 

300초부터 200으로 ramp up이 되면서  

high cpu warning이 뜨기 시작했고 TIMEOUT이 뜨면서 서버가 뻗어버렸다.

슬로우 쿼리로그를 살펴보면 0.3 초 이상인 쿼리들만 로그로 기록하도록 했는데 대부분이 0.3초 이내에 쿼리가 수행되었다는 것을 확인했고 이는 DB의 부하가 아님을 알 수 있었다.

그렇다면 어디에 부하가 걸린 것일까? 단순히 Latency가 길어지면서 큐가 더이상 요청을 받지 못하고 뻗어버리는 것은 아닐까 의심이 되었다.

 

이것 저것 해보면서 무엇이 문제인지 더 고민해보고 성능을 개선시켜보자