TPS 개선을 위한 성능 테스트 결과 공유

[donghoony]

• 목표 TPS 설정과 최적화 방안 #868 에서 부하 테스트 측정 결과를 확인할 수 있다.

테스트 단계

1. Saturation Point(최대 허용 동시 사용자)를 찾기 위해 낮은 vu부터 TPS를 측정한다.
2. 특정 vu에 도달하면 더 이상 TPS가 오르지 않는다. 이 구간의 vu가 Saturation Point가 되고, 이때의 TPS가 서비스의 최대 TPS가 된다.
3. Saturation Point를 높인다는 것은 서비스의 최대 TPS를 늘리는 것이기 때문에 Saturation Point를 높이는 것을 목표로 한다.
4. Saturation Point의 목표(최대 허용할 동시 사용자 수)를 잡고 도달하기 위해 병목 지점을 찾고 개선한다.
5. 앞선 단계를 반복한다.

성능 테스트 시나리오

시나리오 항목

리뷰미 서비스의 주요 사용자 시나리오를 다음과 같이 정의한다.

• 리뷰 그룹 생성
• 리뷰 작성 (리뷰 작성페이지 조회, 리뷰 저장)
• 리뷰 그룹 진입(비밀번호 입력 후 세션 획득)
• 리뷰 목록 조회
• 리뷰 모아보기

시나리오 설정

• 우테코가 종료된 후 우테코의 모든 크루들이 서로 진행했던 프로젝트에 대하여 상호 리뷰를 진행한다.
• 우테코의 총 크루들은 x명이라 가정한다.
• 우테코의 크루들은 한 프로젝트당 10명으로 구성되어 있으며, 총 그룹은 (x*10)개다.
• 각 그룹의 크루들은 상호 리뷰를 진행한다.
• 그룹에 있는 자신을 제외한 모든 크루들에게 리뷰를 썼다면, 자신이 받은 리뷰를 확인하고, 모아본다.

테스트 스크립트

설정된 vu 수만큼 30초간 생성 후 각 유저들은 다음과 같은 작업을 진행한다.

1. 리뷰 그룹 생성 1회 (리뷰를 받기 위한 리뷰 그룹 생성) -> api 1회
2. 리뷰 작성 페이지 접속 및 리뷰 작성 각 9회 반복 (자신 제외 모든 프로젝트 팀원을 리뷰) -> api 18회
3. 리뷰 그룹 코드 인증(리뷰 그룹 세션 획득) -> api 1회
4. 리뷰 목록 조회 1회-> api 1회
5. 리뷰 모아보기에서 섹션 조회 5회 (섹션 5개 모두 조회) -> api 5회

테스트 목표

위 시나리오를 한 번 실행하는 경우, 최대 몇 명이 실행할 수 있는지 확인한다. 나아가 서버의 반응 속도도 매우 중요한 척도 중 하나이므로, 500ms 안으로 API 호출이 완료되도록 한다.

성능 테스트 흐름

흐름을 그림으로 그리고, 병목이 나타날 수 있는 부분을 먼저 짚어본다

1. 사용자는 서버에 요청을 보낸다.
2. 요청은 라우터를 통해 목적지에 도착한다.
3. AWS의 ALB를 사용하고 있으므로, ALB가 EC2로 요청을 전달한다.
4. 전달받은 요청을 토대로 최대 max_connections만큼 연결을 수립(establish)한다. 3-way handshake가 이 곳에서 이루어진다.
5. 수립된 연결 중 최대 max_thread만큼의 스레드가 생성된다 (혹은 min_spare를 미리 생성한 뒤 여유 스레드에 이를 할당한다).
6. 스레드에서 내부 비즈니스 로직을 수행한다. 이때, DB 요청이 발생한다면 아래 세 단계를 진행한다.
   6-1. DB 커넥션 풀에서 Idle한 커넥션을 가져온다. 이때 커넥션은 Active 상태가 된다. 만약 모든 커넥션이 Active라면 Pending 상태가 된다.
   6-2. 커넥션을 토대로 DB와 통신한다. DB 요청/응답을 위해 스레드는 대기한다.
   6-3. 커넥션을 모두 사용했다면 반납한다. Active였던 커넥션은 Idle 상태가 된다.
7. 비즈니스 로직을 마쳤다면 응답을 반환한다. 스레드가 모두 사용된 뒤에는 스레드 풀에 반납된다.

위 흐름 중 1 ~ 3단계는 테스트를 통해 개선할 수 있는 부분이 아니다. 따라서 4 ~ 7단계를 집중적으로 테스트하기 위해 클라이언트, 서버, DB 서버를 모두 같은 VPC에 두어 내부적으로 통신하도록 한다.
최대한 운영 서버와 같은 환경에서 테스트하기 위해서 아래와 같은 사양으로 테스트한다.
실제 운영 서버:

• 어플리케이션 : EC2 t4g-micro/small (어플리케이션 서버, vCPU-2, 1,2GB Ram)
• DB: RDS vCPU-2, 8GB Ram *2 (Read-Write replication)
  테스트용 서버:
• 어플리케이션: EC2 t4g-small (테스트 서버, vCPU-2, 2GB Ram)
• DB: EC2 t4g-medium * 2 (vCPU-2, 4GB Ram, Read-Write replication)

테스트 진행

주어진 시나리오가 존재하므로, 모두 진행되는 데 필요한 최소 시간이 존재한다. 이를 최소화하고, 원활하게 돌아간다면 VU를 높여가면서 반복했다.

테스트를 수행하면서 진행한 최적화

JVM Warm-up

Java 코드는 .class 파일인 바이트코드로 변환되고, 이들이 JAR/WAR로 아카이빙된다. JVM은 이를 읽어들여 기계어로 번역한다.
Interpreter 방식의 JVM은 JIT Compiler를 도입해 적시에 기계어로 만드는 방식을 도입하여 컴파일 기반 언어와의 격차를 줄이게 된다. Oracle에서는 Hotspot이라고 부르며, JDK 1.3부터 반영되어 있다.

어플리케이션이 처음 실행되었을 때에는 코드캐싱 및 최적화된 내역이 없기 때문에 응답 지연이 발생할 수 있다. 따라서 의도적으로 Warm-up을 위한 부하 테스트를 실행했다. 실제로 어플리케이션이 실행된 뒤 처음 수행한 테스트에서는 10~30배의 응답 속도 차이를 보였다.

DB Connection Pool Size hikaricp.maximumPoolSize

테스트를 수행하면서 DB의 병목이 발생하는 것을 발견했다. DB의 Pending Connection이 늘어남에 따라 대기 시간이 늘어난다고 생각했고, Connection pool size를 늘리면 해결할 수 있을 것이라고 생각했다.
하지만 실제 커넥션이 DB를 사용하는 시간 자체는 크지 않았다. Context switching으로 인한 부하가 더해져 Connection pool size를 키우니 응답 속도가 더 낮아지는 모습을 보였다. OS의 매트릭에서 확인했듯, IO로 인한 프로세스의 Waiting 상태로 이동하지 않았으므로 커넥션 개수를 늘리는 것이 해법이 될 수 없었다.

DB OS의 프로세스 상태. IO로 대기하는 프로세스가 적은 것을 볼 수 있다.

이후 DB Connection pool 개수를 한 개부터 늘려가면서 실험해본 결과, 4개 ~ 5개일 때 가장 좋은 성능을 보였다. 따라서 Hikaricp의 커넥션 풀 개수를 5개로 결정했다. (커넥션 풀 1 ~ 10에 대한 K6 결과)

환경 일치: DB Replication

실제 서버 환경은 DB가 두 대로 나뉘어져 있는 상황이다. 최대한 운영 서버의 환경과 알맞게 설정하기 위해 DB Replication을 테스트 환경에서도 진행했다. R/W 모두 5의 커넥션을 가지도록 했고, 이를 통해 성능 향상을 보았다. (같은 시나리오, 300 -> 500 VU 추가 부하임에도 비슷한 성능과 응답 속도를 보였다.

accept-count	max-connections	max-threads	min-spare	CP Size	VU	Total Req Count	Min	Sec	Total Sec
100(default)	8192(default)	200(default)	10(default)	5	500	13000	2	22.70	143

환경 일치: DB Indexing

운영 환경과 불일치했던 것 중 하나가 인덱싱 적용이었다. 새로운 환경에서 테스트를 진행했기에 해당 부분을 놓쳤고, 이를 추가함으로써 추가 성능 향상을 보았다. (관련 실험 결과): VU 700부터 응답이 느려짐을 확인했다.

VU 300:
 review_creation_waiting..............: avg=55.65ms  min=36.73ms med=47.55ms max=658.46ms p(90)=61ms     p(95)=69.64ms 
 review_gathering_waiting.............: avg=18.35ms  min=11.41ms med=16.86ms max=70.74ms  p(90)=24.93ms  p(95)=28.55ms 
 review_group_creation_waiting........: avg=12.97ms  min=11.51ms med=12.51ms max=50.29ms  p(90)=14.14ms  p(95)=14.79ms 
 review_list_retrieval_waiting........: avg=46.2ms   min=35.4ms  med=43.96ms max=114.22ms p(90)=56.41ms  p(95)=62.07ms 
 review_question_view_waiting.........: avg=51.71ms  min=34.78ms med=43.49ms max=737.62ms p(90)=54.81ms  p(95)=63.38ms 
 review_session_acquisition_waiting...: avg=8.04ms   min=6.06ms  med=7.09ms  max=29.1ms   p(90)=10.23ms  p(95)=11.97ms 
 
VU 500:
 review_creation_waiting..............: avg=81.98ms min=38.07ms med=71.7ms  max=732.11ms p(90)=117.69ms p(95)=142.49ms
 review_gathering_waiting.............: avg=44.17ms min=11.29ms med=21.91ms max=422.33ms p(90)=116.49ms p(95)=178.79ms
 review_group_creation_waiting........: avg=22.75ms min=10.98ms med=14.85ms max=306.2ms  p(90)=37.1ms   p(95)=55.33ms 
 review_list_retrieval_waiting........: avg=82.26ms min=35.69ms med=54.43ms max=409.75ms p(90)=190.7ms  p(95)=230.23ms
 review_question_view_waiting.........: avg=87.99ms min=34.68ms med=67.64ms max=846.16ms p(90)=156.42ms p(95)=211.68ms
 review_session_acquisition_waiting...: avg=25.76ms min=5.78ms  med=9.27ms  max=229.49ms p(90)=78.64ms  p(95)=100.45ms
 
VU 700:
 review_creation_waiting..............: avg=151.14ms min=37.56ms med=125.89ms max=701.58ms p(90)=236.61ms p(95)=314.04ms
 review_gathering_waiting.............: avg=977.81ms min=11.68ms med=852.87ms max=5.5s     p(90)=2.27s    p(95)=2.48s   
 review_group_creation_waiting........: avg=55.17ms  min=8.95ms  med=20.57ms  max=401.82ms p(90)=182.89ms p(95)=214.01ms
 review_list_retrieval_waiting........: avg=1.7s     min=36.21ms med=1.56s    max=6.69s    p(90)=3.34s    p(95)=4.01s   
 review_question_view_waiting.........: avg=2.57s    min=35.5ms  med=3s       max=8.93s    p(90)=3.83s    p(95)=3.91s   
 review_session_acquisition_waiting...: avg=1.28s    min=5.93ms  med=1.07s    max=7s       p(90)=2.76s    p(95)=3.37s   

Caching: 질문지

조회 로직에서 병목을 확인하고, 이를 해결하기 위해 캐싱을 진행했다. 리뷰미에서는 주어진 질문지에 대해 답변하는 방식으로, 기존에는 사용자가 리뷰를 쓸 때 매번 DB에 질문지를 받아와 응답했다. 질문지는 사용자가 변경하지 않으므로, 변경 가능성이 매우 낮다. 따라서 인-메모리 캐시를 사용해 질문지를 캐싱하고, DB와 통신하지 않도록 진행했더니 VU 700을 안정적으로 응답할 수 있었다.

왼쪽: 캐싱 이전 VU 700, 오른쪽: 질문지 캐싱 후 VU 700

기존 VU 700
 review_creation_waiting..............: avg=151.14ms min=37.56ms med=125.89ms max=701.58ms p(90)=236.61ms p(95)=314.04ms
 review_gathering_waiting.............: avg=977.81ms min=11.68ms med=852.87ms max=5.5s     p(90)=2.27s    p(95)=2.48s   
 review_group_creation_waiting........: avg=55.17ms  min=8.95ms  med=20.57ms  max=401.82ms p(90)=182.89ms p(95)=214.01ms
 review_list_retrieval_waiting........: avg=1.7s     min=36.21ms med=1.56s    max=6.69s    p(90)=3.34s    p(95)=4.01s   
 review_question_view_waiting.........: avg=2.57s    min=35.5ms  med=3s       max=8.93s    p(90)=3.83s    p(95)=3.91s   
 review_session_acquisition_waiting...: avg=1.28s    min=5.93ms  med=1.07s    max=7s       p(90)=2.76s    p(95)=3.37s  
 
캐싱 후 VU 700
 review_creation_waiting..............: avg=69.25ms  min=37.7ms  med=54.36ms  max=673.36ms p(90)=105.71ms p(95)=146.11ms
 review_gathering_waiting.............: avg=125.64ms min=12.29ms med=58.69ms  max=1.15s    p(90)=323.41ms p(95)=446.13ms
 review_group_creation_waiting........: avg=24.27ms  min=9.63ms  med=13.52ms  max=581.13ms p(90)=20.91ms  p(95)=32.14ms 
 review_list_retrieval_waiting........: avg=164.88ms min=35.99ms med=111.32ms max=956.16ms p(90)=362.39ms p(95)=432.23ms
 review_question_view_waiting.........: avg=15.54ms  min=4.18ms  med=6.19ms   max=588.24ms p(90)=11.34ms  p(95)=66.46ms 
 review_session_acquisition_waiting...: avg=75.16ms  min=5.94ms  med=31.55ms  max=630.49ms p(90)=196.98ms p(95)=271.24ms

보다 나은 성능을 위해 사용자가 만들지 않는 모든 데이터에 대해서 캐싱을 진행했다. 대표적으로 질문(Question), 선택지(Option), 질문지 내부의 섹션 (Section) 등이다. 캐싱의 범위를 넓혀 보았고, 미미했으나 성능적인 이득을 볼 수 있었다.

Thread Pool Size

Tomcat의 스레드 풀 개수도 성능의 영향이 있을까 하여 조절했다. 특히나 스레드의 개수는 곧 힙 메모리의 크기와 직결되고, 힙 메모리를 많이 쓸 수록 GC가 자주 실행된다. GC가 잦을수록 응답 시간이 느려지므로 이를 최소화해야 한다. 따라서 2GB의 램 용량을 가지는 t4g-small에서는 스레드 풀 크기를 줄이는 것이 낫다고 생각했다. 기본값은 200이다.

thread 값을 20, 50, 100, 200, 300으로 했을 때의 DB 커넥션과 이용 시간, 얻기까지 걸린 시간

스레드 수가 증가할수록 전체적으로 응답 시간의 편차가 커지는 경향을 확인했다. (중앙값, 최댓값, 90%, 95%) 이중 가장 좋은 지표를 가지는 100으로 결정했다.

http_req_waiting...................20: avg=2.19s    min=4.49ms  med=1.96s    max=4.75s   p(90)=4.03s    p(95)=4.3s    
http_req_waiting...................50: avg=2.16s    min=4.51ms  med=2.05s    max=5.2s     p(90)=4.05s    p(95)=4.32s   
http_req_waiting..................100: avg=2.07s    min=4.34ms   med=2.03s    max=5.35s   p(90)=3.81s    p(95)=4.06s   
http_req_waiting..................200: avg=2.18s    min=4.52ms   med=2.45s    max=7.18s   p(90)=4.04s    p(95)=4.5s    
http_req_waiting..................300: avg=2.22s    min=4.39ms   med=2.49s    max=10.01s  p(90)=4.3s     p(95)=4.95s   

결론

• Tomcat Thread pool: 100
• Hikaripool size: 5
• 변하지 않는 내용 캐싱 (템플릿, 질문 등)
• 이외 설정은 변경에 큰 변화를 불러오지 않아 기본값으로 둔다.

더 생각해볼 수 있는 점

• MySQL의 트랜잭션 격리 레벨을 READ_COMMITTED로 낮추는 것을 고려한다. 리뷰 내용은 수정할 수 없는 정책이 존재하기 때문에 격리 수준을 한 단계 내리더라도 사용자가 불편함을 겪지 않는다.
• 어플리케이션 구동 시 JVM Warm-up을 위해 내부 API를 호출한다.
• 전체적으로 조회 시 병목이 잦았다. 조회 로직에서의 부담을 최소화한다. 캐시 도입, 어플리케이션 로직의 단순화를 고려한다.
• 리뷰 또한 캐싱을 할 수 있다. 대체로 리뷰 작성 이후 며칠간 리뷰를 자주 확인하므로, 기간을 두고 캐싱하는 것을 생각해볼 수 있다.

[nayonsoso]

10.24 인프라 기준, 한 EC2에 최대로 동시 요청을 보낼 수 있는 사용자 수는 700명 (대기 시간 약 1초) 이다