Java Virtual Thread (13), 병목 현상(bottleneck)

Virtual Thread를 적용했을 때 운영적인 측면에 대해 생각해보자. 

 

 

 

1) tomcat-biz 가 하나의 spring boot application이다. 즉 두 개의 서버가 있고, 하나의 db가 있다.

2) client 요청이 오면 톰켓이 받고 biz 로직에 따라 db 쿼리를 처리한다.

 

 

 

여기에 virtual thread를 사용하여 성능을 높일 수 있다. 그리고 서버 한 대를 줄이는 것을 고민하였다.

 

 

이 경우 아무런 이슈가 생기지 않을까? 

 

 

tomcat 은 200개의 요청이 400개로 늘어났다. 다만 virtual thread이기 때문에 thread의 개수 제한이 거의 없다고 볼 수 있기 때문에 이는 문제가 되지 않는다. 

 

 

생각해야할 지점은 DB이다. 기존은 HikariCP를 이용해 Connection Pool을 이용하였다. Max Connection = 50 이라면, db 입장에서는 서버가 두 대 였을 땐 100개의 max connection이 생겼지만 서버가 한 대이므로 50개가 된다. 

 

 

만약 100개의 db 쿼리가 필요하게 된다면, 50개로 줄었기에 pending 상태가 될 것이다. 

 

 

그렇기에 virtual thread 사용 시엔 서버 수 뿐만 아니라 db connection 수도 반드시 신경을 써야 한다.

 

 

...

 

 

또 다른 문제는 request 가 들어오면 socket 이 생긴다. 서버당 만들 수 있는 socket의 수는 제한되어 있다. 무작정 서버를 줄이면 thread는 제한이 없지만 socket 에는 제한이 생긴다.

 

 

기존에 서버 두 대를 사용할 때 socket을 max로 쓰고 있었다면 서버를 한 대 없앨 경우엔 두 배의 소켓을 생성해야 한다. 이 경우 socket을 못 만들어서 connection failure 등의 문제가 생길 수 있다. 

 

 

...

 

 

그리고 기존 비즈니스 코드에 어떠한 (세마포라, 싱크로나이저) lock을 이용해 동기화를 하고 있었고 기존엔 문제가 없었을 수 있다. 즉 200개의 요청이 들어왔고 200개의 lock이 문제가 되지 않았다. 

 

 

서버를 날릴 경우 비즈니스 코드에서 처리되는 lock 이 증가한다. 이는 비즈니스 코드에서 몇 천, 몇 만 개의 thread가 비즈니스 코드를 호출하면서 경합이 생길 수 있게된다.

 

 

즉, 기존 세라포마 등의 lock 에서는 문제가 아니였는데 virtual thread를 쓰면서 많은 thread가 lock을 잡고 풀고 함으로써 부하가 생길 수 있다. 

 

 

성능 테스트 중 생각보다 개선되지 않았다면 이런 부분 또한 점검을 해 볼 필요가 있다. 

 

 

...

 

 

정리

 

1) virtual thread 는 개수 제한이 없기에 기존 서버 개수를 줄이는 것을 고민하게 된다.

2) 이 때, DB를 사용하고 있다면 max connection 을 점검해야 한다. 한 대에 설정되어 있는 max connection 만 가지고 서는 기존 query 양을 감당하지 못할 수도 있다.

3) 서버 당 만들 수 request socket 수도 정해져 있다. socket 이 부족할 경우 connection failure 와 같은 에러가 발생할 수 있다.

4) 비즈니스 코드에서 lock 을 사용하고 있었다면 virtual thread로 변환됨과 동시에 수천, 수만개의 thread가 생성되어 버릴 수 도 있다. 이 경우 많은 thread가 lock 을 잡고 풀고 함으로써 부하가 생길 수 있다.