내가 만든 WebFlux가 느렸던 이유 발표 영상 필기

요즘 진행하는 프로젝트에 부분적으로 WebFlux가 들어가고 있는데요. Spring에서 WebMVC대신 WebFlux로 넘어가는 이유는 성능 향상 효과를 기대하는 경우가 많습니다. 그런데 WebFlux에 능숙하지 않으면 오히려 느려질 수도 있는데요. 그러한 내용들을 잘 정리한 발표입니다. WebFlux를 사용하고는 있는데 성능이 잘 안 나온다면 꼭 보시길 추천합니다.

 

NHN FORWARD

발표자료는 위의 링크에 들어가면 받아 볼 수 있습니다.

발표를 들으면서 간단히 메모를 해 보았습니다.

Spring MVC는 Thread에서 요청을 처리하게 되고 Thread개수는 200개입니다. 요청이 들어오면 Thread 하나를 잡고 처리를 하게 되고 해당 Thread에서 다른 REST API 같은 것을 호출하면 그동안 block 됩니다. API처리가 끝나면 block이 풀리고 진행됩니다.

200개의 스레드가 8개의 코어를 점유하려고 경합하는 거도 부하가 됩니다.

 

WebFlux는 EventLoop Model.

Thread 개수는 Core의 개수 * 2가 됩니다.

작업은 Event로 처리됩니다. REST API 호출될 때 block 되지 않고 끝나고 다른 Thread에서 받아서 이어서 작업하게 됩니다.

적은 Thread pool을 유지하여 CPU 사용이 적습니다.

동영상을 인코딩한다던가 하는 작업에는 WebFlux가 적합하지 않을 수 있습니다.

Redis가 성능이 좋지만 Redis 병목을 신경 쓰지 않도록 하려고 좋은 서버를 사용했습니다.

Spring WebMVC + Lettuce구성과 비교를 합니다. 이 환경에서 테스트한 결과와 비교합니다.

Spring Web Flux + Reactive Redis로 구성합니다.

성능 검사 결과

구글링 해 보니 LogBack의 AsyncAppender 적용해 보라고 합니다. 적용해 보았으나 이전과 다를 게 없었습니다.

게다가 JVM Heap메모리가 터지기 시작합니다.

로그를 보관했다가 비동기로 파일에 로그를 남기는데 이 때문에 메모리가 터지는 현상이 발생했습니다.

AsyncAppender는 성능 향상에 도움이 되지 않았습니다.

범인은. log()이고 제거했습니다. RollingFileAppender로 변경했습니다.

많은 향상이 있었습니다. WebMVC보다도 좋은 성능이 나왔습니다.

그런데 하위 95%의 응답속도는 여전히 WebMVC보다도 성능이 좋지 않았습니다.

map을 많이 조합하면 gc 문제가 생깁니다.

cacheStorageAdapter는 비동기인데 map을 사용해서 동기로 처리합니다.

불필요한 map을 줄입니다. map에서 log를 남깁니다. 비동기 처리하는 부분은 flatMap으로 변경했습니다.

 

좌측처럼 떠 있으면 block 되는 게 있다는 말입니다.

 

 

BlockHound는 Blocking코드를 찾아주는 라이브러리입니다. reactor-core 3.3.0부터 내장됩니다.