post/ro-spring-virtual-thread/

[giscus[bot]]

post/ro-spring-virtual-thread/

어제도 오늘도 내일도 일 수천만건 이상의 트래픽을 받아내고있는 머니플랫폼에서 Virtual Thread를 적용한 경험을 공유합니다.

https://tech.kakaopay.com/post/ro-spring-virtual-thread/

[joonki34]

안녕하세요~ 질문이 있습니다. 결과 분석 기준으로 Virtual Thread 적용의 주요 이슈가 제한되지 않은 대량 트래픽 수용으로 보이는데요. spring.task.execution.simple.concurrency-limit로 동시성을 제어할 수 있는 걸로 아는데 요것도 적용을 했는데 위 이슈가 발생한 걸까요?

[rostradamus]

안녕하세요 :) 먼저 답변이 늦어져 죄송합니다..!
트래픽을 제어할 수 있는 방법은 다수 존재합니다. 말씀주신대로 Default AsyncTaskExecutor에 대한 제어는 spring.task.execution.simple.concurrency-limit를 통해 제어가 가능하고 최대 Tomcat Connnection에 대한 제어는 server.tomcat.max-connections로 가능할 것으로 기대됩니다. 다만 spring.threads.virtual.enabled=true를 통해 모든 비동기 Task를 Virtual Thread를 통해 처리하는 것 만큼이나 전역적인 동시성 제어로 인해 특정 Task가 다른 Task의 execution 우선순위에 영향을 줌으로써 큰 그림에서의 기대효과를 저해하는 현상을 발생시킬 수 있을 것으로 생각됩니다. 따라서, Virtual Thread를 활용한다면 Semaphore 등을 활용하여 각 구간에 맞는 동시성 제어를 하는 것이 과도기에 따른 영향을 최소화 할 수 있을 것이라 판단하였습니다.

[leeshinyook]

안녕하세요~ 좋은 글 감사합니다.
질문 하나가 있는데요. MySQL은 mysql-connector-java의 몇 버전을 사용하셨는지 궁금합니다.

최근 9.0.0버전에서 mysql에서 동기화 블록들이 ReentrantLocks으로 변경한 릴리즈가 있어서 여쭙습니다.
(테스트에 사용된 라이브러리 버전정보도 같이 내용에 포함되면 좋을 것 같습니다.ㅎㅎ)

https://dev.mysql.com/doc/relnotes/connector-j/en/news-9-0-0.html

[rostradamus]

안녕하세요 :) 답변이 늦어져 죄송하다는 말씀 먼저 드립니다.

테스트간 사용된 mysql-connector-java 버전은 8.1.0 입니다. 주기적으로 각 라이브러리에서 Loom 대응에 대한 트래킹을 하고 있는데 해당 내용은 꽤나 고무적이라고 생각합니다.
사용 버전을 기준으로 말씀해주신대로 테스트 환경에서 -Djdk.tracePinnedThreads=full JVM 설정을 통해 주요 테스트 구간에서 Pinning이 발생함으로 인한 성능저하가 존재하지는 않는지 확인을 먼저 진행했습니다. 그 과정에서 스키마 또는 쿼리 캐싱 등과 같은 작업에서 몇몇 synchronized 구간이 보였으나 해당 구간 이후 쿼리 실행 자체에서 Pinning 구간은 탐지되지 않아 그로인한 성능저하는 원인이 아닌 것으로 판단하였습니다. 또한, 실제로 synchronized가 쿼리 수행간 발생하였다면 요청 load에 따른 Carrier thread 고갈로 인해 훨씬 더 심각한 성능저하가 있었을 것이라 생각됩니다.

[kindtiger95]

@rostradamus 안녕하세요, 추가로 궁금한 사항이 있습니다. 답변 달아주신 대댓글의 내용에 대해서 궁금한 사항이 생겼습니다. �

1. mysql-connector-j:9.0.0으로 테스트를 진행해봤고, 테스트를 진행하면서 확인한 결과 스키마 또는 쿼리 캐싱 과정에서 pinning 확인했으나 쿼리 실행에서는 pinning이 확인되지 않음. 즉, v8.1.0, v9.0.0 둘 다 pinning이 발생한 위치는 같음.
   -> 요렇게 이해하면 될까요??
2. synchronized가 쿼리 수행간 발생하였다면 요청 load에 따른 Carrier thread 고갈로 인해 훨씬 더 심각한 성능저하가 있었을 것이라 생각됩니다
   -> 요렇게 생각하신 이유가 궁금합니다. 캐리어 쓰레드의 개수가 기존 톰 캣 쓰레드 풀 개수보다 현저히 적게 설정이 되어있을까요?

[heli-os]

좋은 글 감사합니다 :)

오랜만에 인사드리네요! 혹시 내부적으로 Virtual Thread의 Pinning을 회피하기 위해 사용하시는 라이브러리나 별도 검토 프로세스가 있으실까요?

Reactor 생태계에는 blocking operation을 감지해주는 BlockHound 같은 agent가 존재하는데, Virtual Thread 생태계에는 마땅히 없는듯하여 여쭈어봅니다.

[rostradamus]

안녕하세요 :) 오랜만에 뵙습니다~ 잘 지내시죠?

위에 댓글에서도 언급한 바와 같이 테스트 전 pinning 구간 발생으로 인한 테스트 목적에 부합하지 않는 노이즈를 최대한 제거하기 위해 -Djdk.tracePinnedThreads=full를 통해 주요 테스트 구간에서 pinning이 발생하고 있지 않은지 면밀히 검토해보았습니다.

말씀해주신대로 Reactor 생태계에는 BlockHound와 같은 라이브러리가 존재합니다만 제가 이 댓글을 쓰고있는 현재시점에는 JVM 옵션으로 제공되고 있는 -Djdk.tracePinnedThreads플래그를 제외하고는 특별히 Customize가 가능한 라이브러리는 존재하지 않는 것으로 보입니다. 해당 옵션을 활성화하면 stdout을 통해 pinning이 걸리는 구간에 대한 리포트를 제공해줍니다.
추후에 좋은 정보 있으면 공유 부탁드립니다 :)

[jws1837]

현업에서 적용한 케이스를 보고싶었는데 주의사항과 벤치마킹들 볼 수 있어 너무 도움 됐습니다. 역시 신기술도입은 신중함 검토와 근거가 있어야 된다는 교훈을 얻게 되었네요. 감사합니다

[rostradamus]

도움이 되었다니 너무나도 다행입니다 :) 시간이 지날수록 Virtual thread 패러다임은 더더욱 확장되고 개선될 것이라 믿어 의심치 않습니다. 나중에 더 유용한 글로 돌아오겠습니다~
다시한번 감사드립니다!

[Dayon-Hong]

안녕하세요, 좋은 글 감사합니다. 제가 최근에 느낀 부분은 카카오페이 교통카드 적립금 쿠폰 지급시간이 굉장히 빨라졌던 부분이였습니다.
첫달 6월에는 40분이 지나서 쿠폰을 받았는데, 지난달에는 2-3분 만에 받을 수 있었습니다. 이부분도 virtual Thread의 도입으로 가능했던 건지 아니면
ThreadPoolTaskExecutor 등을 활용해 스레드의 개수를 늘려서 해결하였는지 궁금합니다!