쿠버네티스 및 jMetter를 사용한 서버 부하 테스트 With 가상스레드

jMeter를 사용한 부하테스를 해 보았습니다.

 

1000명의 사용자(Thread)가 각 10번(Loop)씩 1초(Ramp-up)동안 요청을 보내는 경우 아래와 같았습니다.

💡 Spring Boot의 default 쓰레드 풀의 쓰레드 개수는 200개

 

요청과 동시에 쿠버네티스의 노드 상황을 top 명령어로 확인해 봤습니다.

💡 각 노드는 t3.large 서버(2코어 8GB의 램)

 

서버의 종류는 8개, 레플리카셋은 2였고, 파드 하나당 리소스 제한은 아래와 같습니다.

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: 400m
    memory: 768Mi

 

위와 같이 리소스 제한을 했었는데, 막상 확인해 보니 절반 정도의 리소스들이 사용되지 못하고 있었습니다.

 

리소스를 아래와 같이 조정해 봤습니다.

resources:
  requests:
    cpu: 400m
    memory: 768Mi
  limits:
    cpu: 500m
    memory: 1300Mi

 

리소스를 조정하고 나니 유의미한 성과를 얻을 수 있었습니다.

 

하지만, 이 정도가 리소스의 한계이고 더 속도를 높이기 위한 방법이 어떤 것이 있을까 고민해 봤습니다.

 

저는 JDK 21을 쓰고 있었고, 공식적으로 가상스레드를 지원하기 때문에 이를 활용하여 속도를 높이고자 했습니다.

spring boot 가상 스레드 적용해보기

spring boot 가상 스레드 적용해보기

 

가상 스레드를 적용하고 나서,

단순 DB 조회 요청을 1000명의 사용자(Thread)가 각 10번(Loop)씩 100초(Ramp-up)동안 요청 보내는 경우를 테스트해 봤습니다.

 

가상쓰레드를 사용하지 않는 경우 (처리량 99.3/s)

가상쓰레드를 사용하는 경우 (처리량 99.5/s)

 

단순 DB 조회 요청의 경우 속도의 차이가 거의 발생하지 않았습니다.

제가 판단하기에 DB는 기본 커넥션 풀이 정해져있기 때문에 처리량의 증가가 보이지 않은거 같습니다.

 

이번에는 서버간의 통신이 필요한 요청을 해 보았습니다.

wo → api → jig → api→ wo → api → member → api → wo 서버 순으로 처리가 되는 요청일 경우입니다.

 

wo 서버의 가상 쓰레드를 사용하지 않는 경우 (처리량 3.2/s)

 

wo 서버의 가상 쓰레드를 사용하는 경우 (처리량 13.6/s)

 

유의미한 결과가 나왔습니다.

4배 이상의 처리량 향상이 결과로 나왔습니다.