Webflux 진짜로 대용량 처리에서 MVC 보다 빠를까??

Question

동시 접속 사용자 대용량 처리에 관심이 많아서 찾아보다가 Webflux 까지 오게되었습니다.
일반 MVC 와 Webflux 성능 차이를 정리한 블로그글, 유튜브 영상까지 모두 찾아보았고 둘의 엄청난 차이에 Webflux 매력에 빠져서 정말 많은것을 찾아보았습니다. 하지만 직접 테스트 해보고 경험해 봐야 알 수 있는것 직접 테스트 해보기로 합니다.

아래의 논문집을 참고해서 테스트 하였습니다.
자바 기반의 스프링 WebMVC 와 WebFlux 성능 분석 논문집

테스트를 진행한 컴퓨터 성능

OS : MAC OS
CPU : 2.3 GHz 8코어 Intel Core i9
메모리 : 64GB 2667 MHz DDR4

테스트 프로그램

Jmeter 5.5 버전

스레드 : 200
스레드 : 1000
스레드 : 5000
스레드 : 10000

테스트 진행한 코드 깃허브 저장소

Webflux : https://github.com/alalstjr/non-blocking-webflux
MVC : https://github.com/alalstjr/blocking-mvc

프로젝트 각각의 버전과 DB

Webflux

DB : MongoDB 4.2 커넥션 풀 1만 이상
Java 버전 : 17
Spring 버전 : 3.0.2

MVC

DB : MySQL 8.0.2 커넥션 풀 1만 이상
Java 버전 : 17
Spring 버전 : 3.0.2

테스트 결과

Response Time 과 트랜잭션(초당) 만 비교해보았습니다.

Select 만

SELECT	MVC	Webflux
동시접속 : 200	Response Time (ms) ㄴ 최소값 : 3 ㄴ 중간값 : 5 ㄴ 최대값 : 122 트랜잭션 (초당) ㄴ 199.40 Fail : 0%	Response Time (ms) ㄴ 최소값 : 3 ㄴ 중간값 : 5 ㄴ 최대값 : 141 트랜잭션 (초당) ㄴ 200 Fail : 0%
동시접속 : 1000	Response Time (ms) ㄴ 최소값 : 35 ㄴ 중간값 : 364 ㄴ 최대값 : 879 트랜잭션 (초당) ㄴ 900 Fail : 0%	Response Time (ms) ㄴ 최소값 : 168 ㄴ 중간값 : 770 ㄴ 최대값 : 1166 트랜잭션 (초당) ㄴ 486 Fail : 0%
동시접속 : 5000	Response Time (ms) ㄴ 최소값 : 398 ㄴ 중간값 : 1957 ㄴ 최대값 : 3727 트랜잭션 (초당) ㄴ 859 Fail : 0%	Response Time (ms) ㄴ 최소값 : 30 ㄴ 중간값 : 3225 ㄴ 최대값 : 5025 트랜잭션 (초당) ㄴ 703 Fail : 1.56%
동시접속 : 10000	Response Time (ms) ㄴ 최소값 : 1 ㄴ 중간값 : 5362 ㄴ 최대값 : 10882 트랜잭션 (초당) ㄴ 669 Fail : 11.02%	Response Time (ms) ㄴ 최소값 : 19 ㄴ 중간값 : 5210 ㄴ 최대값 : 8460 트랜잭션 (초당) ㄴ 748 Fail : 0%

Insert 만

INSERT	MVC	Webflux
동시접속 : 200	Response Time (ms) ㄴ 최소값 : 9 ㄴ 중간값 : 12 ㄴ 최대값 : 252 트랜잭션 (초당) ㄴ 198 Fail : 0%	Response Time (ms) ㄴ 최소값 : 4 ㄴ 중간값 : 160 ㄴ 최대값 : 640 트랜잭션 (초당) ㄴ 199 Fail : 0%
동시접속 : 1000	Response Time (ms) ㄴ 최소값 : 188 ㄴ 중간값 : 864 ㄴ 최대값 : 1359 트랜잭션 (초당) ㄴ 474 Fail : 0%	Response Time (ms) ㄴ 최소값 : 2 ㄴ 중간값 : 4 ㄴ 최대값 : 171 트랜잭션 (초당) ㄴ 994 Fail : 0%
동시접속 : 5000	Response Time (ms) ㄴ 최소값 : 405 ㄴ 중간값 : 4201.50 ㄴ 최대값 : 7402 트랜잭션 (초당) ㄴ 543 Fail : 0%	Response Time (ms) ㄴ 최소값 : 3 ㄴ 중간값 : 5 ㄴ 최대값 : 240 트랜잭션 (초당) ㄴ 1867 Fail : 2.56%
동시접속 : 10000	Response Time (ms) ㄴ 최소값 : 1 ㄴ 중간값 : 7807 ㄴ 최대값 : 14213 트랜잭션 (초당) ㄴ 527 Fail : 5.11%	Response Time (ms) ㄴ 최소값 : 2 ㄴ 중간값 : 5 ㄴ 최대값 : 282 트랜잭션 (초당) ㄴ 2746 Fail : 12.56%

결과로 알 수 있는거

단순 Insert 만 진행한다면 Webflux 의 처리 성능이 좋다는 것을 알 수 있었습니다.

하지만 Select 의 경우 오히려 성능이 MVC 보다 안좋게 나오는 것을 보고 혼란이 오고 있습니다.
무려 2주를 검색하고 찾아보았지만 해당 결과의 이유를 이해할 수 없었습니다.

웹플럭스를 왜 사용할까?

가장 기본적인 이유는 많은 요청을 서버 프로그램이 효율적으로 동작을 해서 Thread, CPU, Memory 의 자원을 낭비하지 않고 더 많은 요청을 처리할 수 있는 고성능 웹 어플리케이션을 개발하는 것이 목적입니다.

Spring MVC는 1:1로 요청을 처리하기 때문에 트래픽이 몰리면 많은 쓰레드가 생겨납니다. 쓰레드가 전환될때 context switching 비용이 발생하게 되는데 쓰레드가 많을 수록이 비용이 커지게 되기 때문에 적절한 쓰레드의 수를 유지해야하는 문제가 있습니다.

이에 반해서 WebFlux 는 Event-Driven 과 Asynchronous Non-blocking I/O 을 통해 리소스를 효율적으로 사용할 수 있도록 만들어 줍니다.

그렇다면 insert 와 동일하게 select 조회도 동일한 속도가 나와야 한다고 저는 생각합니다.

과연 모두가 Webflux 를 효율적으로 사용중일까요?

모두들 답변 감사합니다. 1년이 지난 지금 제가 경험한 내용을 다시 공유하고자 글을 수정합니다.

해당 게시글에 추가 조사된 내용을 실무 경험을 바탕으로 작성하려고 합니다.
회사 프로젝트로 하루 평균 30 ~ 50 만건의 카카오 챗봇 로그를 적재하는 API 개발을 담당하게 되었습니다.
제가 가지고있는 개념으로 개발을 하자니 Webflux 로 API 를 개발하고 Kafka 로 메세지를 받고 MongoDB(지금은 엘라스틱 서치) 로 저장하는 방향으로 개발하였습니다.

당시 테스트한 내용을 공유하자면 다음과 같습니다.

Webflux 와 MVC 성능 테스트

챗봇로그 데이터 적재를 위해 Non-Blocking 방식과 Blocking 방식 간의 데이터 전송 속도와 효율성을 비교하여 성능 측정 진행

- 테스트환경

non-blocking : Webflux(MongoDB)

blocking : MVC(MySQL)

가상 컴퓨팅 공간내부의 설치된 DB 와 Docker 로 가동된 Spring Application 에서 진행 (옛날 테스트는 개인 컴퓨터 docker 에서 실행)

Insert 테스트

non-blocking

blocking

요약

총 표본 수 : 100,000

평균 응답 시간 (Response Times - 평균) :
- blocking 결과 테이블: 12.32 ms
- non-blocking결과 테이블: 4.35 ms
Throughput (트랜잭션(초당)) :
- blocking 결과 테이블: 772.27
- non-blocking 결과 테이블: 1996.49
Network 수신 및 전송 (Network (KB/sec)) :
- blocking 결과 테이블: 수신 - 172.40 KB/sec, 전송 - 174.97 KB/sec
- non-blocking 결과 테이블: 수신 - 516.45 KB/sec, 전송 - 2749.07 KB/sec

Select 테스트

non-blocking

blocking

총 표본 수 : 100000(Thread 1000 - 사용자 수)

평균 응답 시간 (Response Times - 평균) :
- blocking 결과 테이블: 1817.11 ms
- non-blocking결과 테이블: 26.82 ms

Throughput (트랜잭션(초당)) :
- blocking 결과 테이블: 541.68
- non-blocking 결과 테이블: 1141.91
Network 수신 및 전송 (Network (KB/sec)) :
- blocking 결과 테이블: 수신 - 117.96 KB/sec, 전송 - 80.93 KB/sec
- non-blocking 결과 테이블: 수신 - 289.94 KB/sec, 전송 - 301.09 KB/sec

결론

non-blocking의 평균 응답 시간이 낮고 Throughput이 높으며, Network 수신 및 전송량도 높은 것을 확인할 수 있습니다.
Webflux는 데이터 전송 속도 측면에서 수신이 매우 높으므로, 대용량 데이터 전송에 용이할 것으로 보입니다.

옛날에는 개인 컴퓨터로 테스트를 했다면 이번에는 가상 커퓨팅 공간에 테스트를 진행하였습니다.
확실히 많은 데이터를 처리할 때 속도는 webflux 앞서 있다는 것을 확인할 수 있었습니다.

록록록 · Answer

좋은 실험을 해주셔서 감사합니다. 고생이 많으셨네요~! 참고가 되었습니다.

다만 현재 실험에는 DB가 서로 다르다는 것 때문에 혼란이 더 오실 것 같습니다.

차라리 MongoDB대신 MySQL을 쓰되 webflux테스트 시 jdbc드라이버를 R2DBC로 써서 I/O 작업의 변수를 더 줄일 수 있을 것 같아요.

WebFlux는 아시다시피 작업의 처음부터 끝까지 비동기 넌블러킹이 보장이 되어야 최대의 효율을 발휘할 수 있을 것입니다.

Select는 아시겠지만 다양한 원인으로 Blocking이 일어날 소지가 있겠지요? 아마 그런것 때문에 Select테스트 시 예상치 못한 결과가 나온 것 같아요.

이렇게 webflux 사용에 제약조건이 많고 예민하다보니 저도 실무에 사용하기가 정말 꺼려지더군요.

그나마 Spring Cloud Gateway에서 조금 써봤던 기억을 돌이켜보자면,

사용자 입장에서 비동기 매커니즘을 계속 신경쓰면서 익숙하지 않은 코딩을 하자니 배우는 데 애먹었습니다 ㅜㅜ

다행히 요즘에는 spring 3.0 이상부터 자바 가상쓰레드를 실험적으로 쓸 수 있게 만든 모양이더군요.

사용자는 평소대로 web Mvc에서 하던것 처럼 코딩하면 되고, 내부적으로는 스레드 속의 가벼운 가상스레드을 이용해서 비동기처럼 I/O작업을 하게끔 개선을 하고 있는 모양입니다 ㅎㅎ

세월이 좀만 더 지나면 굳이 webflux를 도입하지 않고도 더 성능 좋은 i/o처리를 할 수 있을 것으로 기대됩니다.

나땅 · Answer

지난 전자정부 레퍼런스에서 이 얘기가 한번 나왔었죠 ㅋㅋ

결론이 대용량 트래픽을 처리해야하는 서비스가 아니면 MVC와 차이가없다.. 였어서 좀 놀랐던 기억이있습니다

selfless · Answer

실험 재밌게 잘 봤습니다.

궁금하신 점이 insert는 non blocking인 mongodb가 blocking인 mysql보다 빠른지는 알겠는데,

왜 select는 더 느릴까? 이잖아요?

그건 아마 mysql와 mongodb의 자료구조 저장방식의 차이 때문이지 않을까? 라는 생각이 듭니다.

먼저 mysql의 경우, b+tree 라는 자료구조를 사용합니다.

b+tree는 b-tree에서 파생되었고, b-tree는 binary search tree에서 파생되었습니다.

binary search tree를 먼저 살펴보자면,

자식이 항상 2명인데,

left child가 부모보다 작고, right child가 부모보다 큰 자료구조입니다.

근데 BST(binary search tree)로 저장하면 문제점이,

만약 계속 부모보다 큰 자식이 insert 된다면, 계속 right child에 붙어버리거나,

아니면 계속 부모보다 작은 자식이 insert가 된다면, 계속 left child에 붙거나 하겠죠?

그럼 이건 BST가 아니라 linked list가 되는데, 더 열화판 버전의 linked list겠죠.

왜냐하면, linked list의 node에는 다음 node에 대한 포인터 밖에 없는데,

BST의 노드에는, 안쓰는 자식 노드 포인터도 있고, 애초에 다음 노드 넘어갈 때도, 비교연산해서 넘어가야 하니까요.

여하튼 이러한 BST의 문제점을 보완해서 나온게 b-tree 입니다.

b-tree에서 b는 'self-Balance'에 B를 따왔습니다.

b-tree는 부모보다 큰 자식을 계속 insert해도, 한쪽으로 쭉 길게 무한정 늘어지지 않고, 어느 시점이 되면, 스스로 self-balancing 해서 left child, right child의 밸런스를 맞춥니다.

또한 BST는 자식을 2명밖에 못가져서, 한 level 내려갈 때마다 시간복잡도가 log2씩 되었다면,

b-tree는 자식을 3개 이상도 가질 수 있기 때문에, 3개라고 가정하면, 한 depth 내려갈 때마다 시간복잡도가 log3 씩 되는 효과를 누릴 수 있습니다.

그런데 이렇게 좋아보이는 b-tree도 단점이 있었는데요,

바로 database에서 전체검색 자주 하잖아요? (SELECT * FROM PRODUCT; 라던지)

b-tree는 데이터가 이렇게 저장되어있는데, 전체검색하려면, in-order-traveral 해야겠죠?

이걸 어떻게 최적화 할 수 있을까? 하다 나온게 b+tree 입니다.

b+tree는 루드노드 부트 중간 노드들은 값을 저장하는 기준만 제시하고, 모든 데이터들은 leaf node들에 저장됩니다.

그런데 여기서 핵심은

모든 leaf node들이 마치 linkedlist처럼 순서대로 연결되어있습니다.

따라서 b-tree에서 SELECT * 를 하려면, in-order-traversal 해서 느렸는데,

b+tree에서는 SELECT * 를 하면, 그냥 linked list를 for loop한 것과 같아 O(N)의 속도가 나옵니다.

(물론 BST의 pre/in/out order traversal의 time complexity 또한 O(N)이긴 하나, O(N)도 다 같은 O(N)아니고 어쩌고 설명하는건 이 글의 범위 밖이라 생략합니다)

b+tree는 전체검색만 빠를까요?

범위검색도 빠르겠죠? SELECT * WHERE x > 4 AND x < 10; 한다고 하면,

이미 오름차순 정렬이 되있기 때문에, 4를 찾아서 간 후, 연결된 leaf들 따라 쭉 가다가 10 에서 멈춘후 반환하면 되니까요.

그래서 b+tree는 SELECT는 빠릅니다.

근데 INSERT는 어떨까요?

값을 INSERT하면, 저 위에 조건들 비교해서 넣어줬는데, 만약 한쪽 leaf가 너무 비대해졌다면?

자체적으로 self-balancing 합니다. 예를들어 right most leaf가 너무 비대해졌으면,

b+tree가 insert한 후, 이를 감지하고, right most leaf의 부모로 가서, 조건 변경 후, right most leaf를 쪼개서 그 값을 새로운 노드를 만들어 insert해줍니다.

그리고 오름차순 정렬도 해줘야 겠죠.

이러한 이유 때문에 b+tree는 read는 빠른데, insert는 느립니다.(update delete도 동일한 이유로 느립니다)

mysql의 자료구조인 b+tree는 끝났으니,

mongodb의 자료구조인 lsm tree는 어떤 특징이 있을까요?

이 친구도 깊게 알면 한세월이니 그나마 좀 요약하자면,

lsm tree는 log structure storage engine에서 파생되었는데요,

쉽게말해 key:value store인데

insert할 때, b+tree처럼 self-balancing하거나, 정렬하거나 그런거 없이 그냥 맨 마지막에 때려박고 끝입니다.

심지어 예전에 "santa":"clause" 라고 입력했는데, 나중에 "santa":"baby" 라고 입력해서 키가 겹치면 당연히 기존에 있던 "santa":"clause"를 지우고 업데이트 시켜야 하잖아요?

근데 얜 그냥 맨 끝에 때려박아서 "santa":"clause", "santa":"baby"가 동시에 존재합니다.

아니 insert가 빠른건 알겠는데, 그럼 read할 때 정합성 어쩌죠?

그래서 얘는 get할 때 전체조회한 다음에, 제일 끝애나온 "santa"를 반환합니다.

그러니 insert는 빠르나 read는 당연히 느리겠죠.

이걸 성능 최적화 하겠다고 hash index를 쓰고, index 범위별로 segmentation 하고, segment된 데이터들 중에 중복되는애를 자체적으로 제거시켜줘야 하니까 compaction이란걸 하고 등등을 해서 나온게 LSM tree입니다.

(여담으로, 중복 데이터를 삭제시키는게 compaction인데, compaction이 끝난 데이터는 lsm tree가 immutable로 관리하기 때문에, 동시성 문제에서 자유로워집니다. 따라서 이러한 점 때문에 non-blocking에서 lsm tree를 사용하는 것이겠죠.)

여하튼 이러한 이유 때문에 mongodb가 사용하는 lsm tree는 insert는 빠릅니다. 그냥 맨 끝에 넣으면 땡이니까요.

대신 read할 때 업보를 청산합니다. 넣을 때 대충 넣었으니까 찾을 때 빡쎄지죠.

여태 적은 내용을 정리하자면,

spring mvc는 blocking이기 때문에, mysql를 사용하는데, mysql의 자료구조는 b+tree이고, b+tree는 read는 빠른데 insert,update,delete는 느립니다.

spring webflux는 nonblocking이기 때문에, mongodb를 사용하는데, mongodb의 자료구조는 lsm tree이고, lsm tree는 insert, update, delete는 빠른데 read는 느립니다.

JJunpro · Answer

어렵네요
SELECT 쿼리 조회하는 로직에서만 성능이 안나와서 mvc, webflux 둘다 쿼리조회 하는 기능을 빼니까
둘의 성능차이는 10배 정도 차이났습니다 웹플럭스가 더 좋은방향으로요

여기서 추측되는게 SELECT 시 블로킹 되는게 아닌가 생각이 들어 BlockHound 추가해서
SELECT, INSERT 를 테스트 하려고 했지만 둘다 아래와 같은 Blocking Call!! 이 출력되더라구요
(DB 조회 코드 삭제하면 해당 Blocking Call 오류는 출력되지않음)

i.netty.util.concurrent.DefaultPromise : An exception was thrown by com.mongodb.connection.netty.NettyStream$OpenChannelFutureListener.operationComplete()

reactor.blockhound.BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes

at java.base/java.io.FileInputStream.readBytes(FileInputStream.java) ~[na:na]
at java.base/java.io.FileInputStream.read(FileInputStream.java:276) ~[na:na]
at java.base/java.io.FilterInputStream.read(FilterInputStream.java:132) ~[na:na]

둘 다 출력되는 거 보고 해당 문제는 Blocking Call 때문에 성능이 안좋게 나오는건 아니다 라고 생각은 합니다만 찜찜합니다..
일단 이건 무시하고..

요약) 코드 처리량은 Webflux 가 엄청 빠름 하지만 DB 조회가 처리속도를 따라가지 못함 어플리케이션도 답변을 못받아서 일부분 Fail 발생 이는 특정 상황과 환경에 따라 다르게 나오는거 같음 결국 댓글 답변 처럼 DB 가 문제 같음

댓글 답변의 의견을 참고해보면 MongoDB 의 환경 차이 있을 수 있으니 직접 mysql 과 mongodb 두개의 DB 응답 처리속도를 봐야겠네요.

좀 더 조사해보고 결과를 정리해서 답글 달아야겠네요.

빠른 시간에 Redis 로 변경해서 테스트 해볼 예정입니다.
결과는 답글로 달겠습니다.

다들 좋은 답변 감사합니다.

---
컴퓨터 상태에 따라 다르게 나올 수 있을까? 궁금해서
2023년 3월 11일 다시한번 10000 개의 스레드로 SELECT 조회만 해보았다.

SELECT

동시접속 : 10000

Response Time (ms)
ㄴ 최소값 : 3
ㄴ 중간값 : 7
ㄴ 최대값 : 278

트랜잭션 (초당)
ㄴ 1686

Fail : 5.7%

Response Time (ms)
ㄴ 최소값 : 17
ㄴ 중간값 : 787
ㄴ 최대값 : 2181

트랜잭션 (초당)
ㄴ 1657

Fail : 25.35%

컴퓨터 상태에 따라 결과의 차이도 심하다는 것을 알 수 있었습니다.

아무래도 가상의 공간에 띄워서 테스트를 진행해야 할 거 같네요

육아와개발사이 · Answer

오래된 글이지만 도움이 될까해서 댓글을 남깁니다.

저도 webflux 를 적용하면서 여러가지 비교 테스트를 해봤지만..

insert, update, delete, 1건 select 같은 경우 webflux 가 1.5배 정도 우수한 성능을 보였지만

10건을 select 의 경우 오히려 mvc의 절반수준으로 성능이 떨어졌었습니다.

제가 테스트 했던 환경은 아래와 같고 모두 위와 같은 결과를 보여줬습니다.

webflux(mysql, r2dbc, undertow) vs mvc(mysql, jdbc, undertow)

webflux(mongo, mongoTemplate, undertow) vs mvc(mongo, reactiveMongoTemplate, undertow)

위에 댓글들을 보면 mysql과 mongo의 기본 성능 차이나 인덱스 스캔 여부,

reactive 드라이브 사용여부, 로직 내부 blocking 존재 여부를 의심하시는 분들이 있지만..

저는 동일한 DB를 사용했었고 단순하게 select 한 결과를 그대로 리턴하는 기능만 있었으며

webflux 를 사용하는 곳에서는 모두 blocking 없이 reactive 드라이브를 사용했었습니다.

물론 index도 정상적으로 활용되었구요.

이 테스트로 인해 webflux 적용에 대해선 회의적이 됐습니다.

많은 건수도 아니고 10건을 읽어오는데 mvc 대비 절반의 성능이라면..이걸 사용하는 의미가 있나 싶네요.

구성과 사용의 복잡성 대비 만족스러운 성능을 보여주지 못했고

그냥 mvc를 사용하거나 지금에 와서는 virtual thread를 사용하는게 낫다는 생각입니다.

물론 insert, update, delete 나 1건 select만 있는 서비스라면 webflux를 사용해도 좋습니다.

그런데 지금에 와서는 다 건 select 에서도 mvc보다 우수한 성능을 보이는

virtual thread를 사용하는 편이 낫다는 생각입니다.

Webflux 진짜로 대용량 처리에서 MVC 보다 빠를까??

5개의 답변

Q&A 목록

Webflux 진짜로 대용량 처리에서 MVC 보다 빠를까??

5개의 답변

Q&A 목록

Webflux 진짜로 대용량 처리에서 MVC 보다 빠를까??