<Spring> Webflux + Coroutine vs MVC

📌 실험 개요

Webflux는 적은 리소스에서 MVC에 비해 많은 요청을 처리할 수 있고, Coroutine은 스레드를 사용하는 것보다 메모리 자원을 효율적으로 관리할 수 있다고 한다.

인터넷에 Webflux vs MVC를 비교한 글은 많아도, Webflux + Coroutine vs MVC를 비교하는 글은 없는 것 같다.

이에 위 두 환경을 만들어서 앞서 언급한 부분에 대해 증명하고자 한다.

 

수수에서 Reactive Stack을 사용했는데, Webflux + Coroutine + JPA 조합을 사용했다.

이와 흔히 사용하는 MVC + JPA 조합을 비교하고자 한다.

 

📌 실험 내용

🔵 실험 목표

이 실험을 통해 알아보고 싶은 점은 아래와 같다.

1. MVC와 비교했을 때 Webflux의 요청 처리 능력
2. Coroutine의 메모리 효율성
3. index를 통한 조회와, index를 사용하지 않은 조회의 차이
4. index를 이용한 조인과, 그렇지 않은 조인의 속도 차이

 

🔵 실험 환경

실험 환경은 이러하다.

AWS EC2 t3.micro

AWS RDS t3.xlarge

서버에 비해 DB를 엄청 좋은 것으로 설정했다.

DB에서 병목이 되는 것을 최대한 방지하기 위해서이다.

 

🔵 테스트 코드

서버가 DB에서 값을 조회하여 반환하는 간단한 로직을 이용해 테스트를 진행한다.

자세한 코드는 아래 레포를 참고하면 된다.

 

Spring_study/webfluxCoroutineJPA at main · wjdtkdgns/Spring_study

Spring_study/mvcJPA at main · wjdtkdgns/Spring_study

위는 webflux이고 아래는 mvc이다.

 

엔티티는 A, B, C 3개가 존재한다.

B, C는 각각 A와 연관관계를 맺으며, B, C의 column으로 A의 id를 가진다.

DDL은 아래와 같다.

CREATE TABLE `a`
(
    `id`          bigint       NOT NULL AUTO_INCREMENT,
    `varchar256`  varchar(256) NOT NULL,
    `varchar512`  varchar(512) NOT NULL,
    `intt`         int          NOT NULL,
    `bigintt`      bigint       NOT NULL,
    `created_at`  datetime DEFAULT CURRENT_TIMESTAMP,
    `modified_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='a';

CREATE TABLE `b`
(
    `id`          bigint       NOT NULL AUTO_INCREMENT,
    `aid`         bigint       NOT NULL,
    `varchar256`  varchar(256) NOT NULL,
    `varchar512`  varchar(512) NOT NULL,
    `intt`         int          NOT NULL,
    `bigintt`      bigint       NOT NULL,
    `created_at`  datetime DEFAULT CURRENT_TIMESTAMP,
    `modified_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='b';

CREATE TABLE `c`
(
    `id`          bigint       NOT NULL AUTO_INCREMENT,
    `aid`         bigint       NOT NULL,
    `varchar256`  varchar(256) NOT NULL,
    `varchar512`  varchar(512) NOT NULL,
    `intt`         int          NOT NULL,
    `bigintt`      bigint       NOT NULL,
    `created_at`  datetime DEFAULT CURRENT_TIMESTAMP,
    `modified_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='c';
CREATE INDEX idx__aid ON c (aid);

B, C는 내용은 모두 같지만, 인덱스가 다르다.

B는 인덱스를 추가적으로 설정하지 않았고, C는 aid에 인덱스를 추가했다.

 

각 테이블의 row 수는 아래와 같다.

A : 2000

B, C : 10000

실험 이전에 미리 넣어두고 사용했다.

값 주입에 대한 코드는 아래에서 확인하면 된다.

Spring_study/webfluxCoroutineJPA/src/main/kotlin/com/example/webfluxCoroutineJPA/application/AService.kt at main · wjdtkdgns/Sp

 

실행시키는 함수는 총 6가지이다.

1. id로 A 조회
2. A의 id로 A, B를 조인하여 조회
3. A의 id로 A, C를 조인하여 조회
4. intt로 A 조회
5. A의 intt로 A, B를 조인하여 조회
6. A의 intt로 A, C를 조인하여 조회

 

🔵 테스트 툴 및 설정

부하 테스트를 위해 jmeter를 사용했다.

위와 같이 구성했으며, 스레드 그룹의 사용자 수와 요청 횟수를 조절하며 실험했다.

ramp-up 시간을 0.1로 해둔 이유는 실제 서버에이 1초마다 들어오는 것은 말이 안 된다고 생각했기 때문이다.

실제와 같은 상황을 최대한 구현하고자 0.1로 설정했다.

아래는 실험했던 사용자 수와 요청 횟수이다.

1. 사용자 수 : 1 / 요청 횟수 : 100
2. 사용자 수 : 10 / 요청 횟수 : 100
3. 사용자 수 : 30 / 요청 횟수 : 100
4. 사용자 수 : 50 / 요청 횟수 : 100
5. 사용자 수 : 70 / 요청 횟수 : 100
6. 사용자 수 : 100 / 요청 횟수 : 100
7. 사용자 수 : 120 / 요청 횟수 : 50
8. 사용자 수 : 140 / 요청 횟수 : 50
9. 사용자 수 : 160 / 요청 횟수 : 50
10. 사용자 수 : 180 / 요청 횟수 : 50
11. 사용자 수 : 200 / 요청 횟수 : 50
12. 사용자 수 : 300 / 요청 횟수 : 10
13. 사용자 수 : 400 / 요청 횟수 : 10
14. 사용자 수 : 500 / 요청 횟수 : 10
15. 사용자 수 : 600 / 요청 횟수 : 10
16. 사용자 수 : 700 / 요청 횟수 : 10
17. 사용자 수 : 800 / 요청 횟수 : 10
18. 사용자 수 : 900 / 요청 횟수 : 10
19. 사용자 수 : 1000 / 요청 횟수 : 10

 

📌 실험 결과

사진이 너무 많아서 아래 노션 링크에 정리해 뒀다

Webflux + Coroutine vs MVC | Notion

 

위에 언급한 이 실험의 목표를 재차 서술하겠다

1. MVC와 비교했을 때 Webflux의 요청 처리 능력
2. Coroutine의 메모리 효율성
3. index를 통한 조회와, index를 사용하지 않은 조회의 차이
4. index를 이용한 조인과, 그렇지 않은 조인의 속도 차이

 

 

 

🔵 MVC와 비교했을 때 Webflux의 요청 처리 능력

이는 아래 그래프를 참고하면 된다.

필자의 처참한 엑셀 실력을 이해해 주길 바란다.

MVC에 비해 Webflux + Coroutine이 2배가량 좋은 성능을 보인다.

동시 요청 수가 늘어날수록 이 둘의 격차는 더 커진다.

 

이는 아래의 영향이 존재한다고 생각한다.

왼쪽 : Webflux + Coroutine / 오른쪽 : MVC

우선 CPU 사용률이다. 

작업들을 처리하는데 CPU를 더 많은 시간 이용할 수 있다면, 더 많은 작업을 처리할 수 있을 것이다.

 

이 부분에 있어서 Webflux + Coroutine이 월등히 좋은 수치를 가진다.

이는 non-blocking 하게 작동하는 시스템과 Context Switching 최소화가 이에 중요한 역할을 했다고 생각한다.

Netty의 이벤트 루프는 코어 수만큼 작동하며 Context Switching을 최소화하고, non-blocking 하게 동작한다.

또한 Coroutine은 suspend 기능을 통해 non-blocking 하게 작동한다.

이는 새로운 스레드를 만들어서 처리하여 Context Switching이 발생한다

하지만 non-blocking 하게 작동하기 때문에 같은 작업을 적은 수의 스레드를 통해 처리할 수 있으므로, Context Switching 횟수를 줄일 수 있다.

이 두 부분이 합쳐져서 더 높은 CPU 사용률로 나타났다고 생각한다.

 

하지만 MVC는 Thread Per Request로 작동하며, 한정된 CPU를 스레드끼리 공유하며 작동한다.

이 과정에서 Request를 처리하기 위해 만들어진 수많은 스레드의 동작을 위해 Context Switching은 불가피하다.

또한 스레드가 blocking 하게 작동하므로 스레드가 작동하지 못하는 시간이 생긴다.

또한 RDB CPU 사용률이 영향을 미쳤다고 생각한다.

Webflux 테스트 시와 달리 MVC 테스트 시 99%를 찍었다. 

CPU 사용률이 높아질 때, 성능이 떨어진다고 알고 있다.

이는 IO 대기 시간 증가로 인해 blocking 시간의 증가로 이어지고, 이는 CPU 사용시간의 감소로 이어진다.

그래서 CPU 사용률의 감소하게 된다.

이러한 점 때문에 CPU 사용률이 비교적 낮게 나왔다고 생각한다.

 

🔵 Coroutine의 메모리 효율성

Coroutine은 스레드를 더 효율적으로 사용할 뿐 결국 스레드를 사용하는 것이다.

스레드풀을 사용하며, 이는 Dispatcher에 따라 다르게 설정된다.

위 테스트에서 사용한 Dispatcher.IO의 경우 기본값으로 64개가 max이다.

즉, 요청이 많으면 64개의 새로운 스레드가 생성된다는 것이다.

그러므로 스레드 생성에 따라 메모리 사용량이 증가하게 된다.

하지만 생성된 스레드를 더 효율적으로 사용할 수 있기 때문에, 더 적은 스레드가 사용되어 더 적은 메모리 사용량을 가진다.

 

아래는 이와 관련된 그래프이다.

Webflux + Coroutine의 경우 64~65% 부근에 도달했을 때, 증가량이 감소됨을 볼 수 있다.

정확히 어떤 시점에 스레드가 몇 개 생성되어 사용하고 있는지 파악하지 못했으나, 그래프 모양을 보아 유저수가 100명 이상일 때 64개의 스레드가 생성되었다고 판단된다.

그 이후는 요청의 증가에 따른 메모리 사용의 증가라 판단된다.

MVC는 처음부터 끝까지 일관된 기울기로 증가한다.

tomcat은 default max pool size로 200을 사용하는 것으로 알고 있다.

요청을 처리함에 따라 스레드 수가 계속 증가하므로, 메모리 사용량 또한 계속 증가하는 것을 볼 수 있다.

 

두 그래프의 추세를 볼 때, 요청이 증가할수록 메모리 사용률 차이는 더 크게 벌어질 것이라고 생각한다.

또한 각 사용자 수에 따른 테스트 시 메모리 사용량을 봤을 때, Coroutine을 사용한 쪽이 더 적은 메모리를 사용함을 알 수 있다.

그러므로 Coroutine은 메모리를 더 효율적으로 사용한다 할 수 있다.

 

🔵 index를 통한 조회와, index를 사용하지 않은 조회의 차이

위는 MVC에서 사용자 수 100, 요청 횟수 100에 해당하는 테스트의 결과이다.

 

3번에 대한 답은 randomAById와 randomAByIntt를 비교하면 된다.

id는 기본적으로 인덱스가 설정되고, intt는 일반적인 칼럼 중 하나이다.

그러므로 id를 통해 조회하면 인덱스를 이용하고, intt를 통해 조회하면 인덱스를 이용하지 않는다.

randomAById query

 

 

randomAByIntt query

위는 randomAById 실행 시 발생하는 쿼리이고, 아래는 randomAByIntt 실행 시 발생하는 쿼리이다.

위에서 type 부분이 옵티마이저가 어떤 키를 이용했냐를 나타내는 부분이다.

ref의 경우 index, ALL의 경우 전체 탐색을 말한다.

즉 randomAById는 인덱스를 이용했고, 그 키는 PRIMARY key 임을 알 수 있다.

 

인덱스 이용 여부는 조회 속도의 차이로 나타난다.

randomAById는 245ms, randomAByIntt는 250ms라는 값을 보인다.

즉, 인덱스를 통한 조회가 더 빠르다

 

🔵 index를 이용한 조인과, 그렇지 않은 조인의 속도 차이

4번에 대한 답은 randomAById-withB와 randomAById-withC를 비교하면 된다.

이 둘은 각각 A, B 그리고 A, C 테이블을 조인해서 반환하는 쿼리를 발생한다.

조인의 기준은 A.id == B.aid / A.id == C.aid이다.

위 DDL에서 볼 수 있듯이, C의 aid에는 인덱스가 걸려있다.

randomAById-withB query

이를 해석해 보면, A, B 테이블에서 각각 조건에 맞는 조회를 하여 조인했다.

A의 경우 기본키를 이용했으며, B는 where을 이용했다.

즉, 인덱스를 이용하지 않고, 전체 탐색을 통해 where에 알맞은 B를 찾아냈다.

randomAById-withC query

이 또한 A, C에서 각각 조회를 하여 조인했다.

A는 키본키를 이용했고, C는 idx__aid라는 이름을 가진 인덱스를 이용했다.

즉, 위는 조인 연산을 위해 인덱스를 이용하지 않았으며, 아래는 인덱스를 이용했다.

 

이 차이 또한 조회 시간 차이로 나타난다.

randomAById-withB : 279 ms

randomAById-withC : 248 ms

31ms의 차이가 발생한다.

이를 통해 인덱스를 이용한 조인이 더 빠름을 알 수 있다.

 

그러므로 인덱스를 타는 것이 조회 시간에 있어서 큰 이점으로 작용한다.

 

📌 의문점

1. MVC의 randomAById에서 오류가 발생한다.

MVC에서 요청 수가 많아졌을 경우에만 발생한다.

tomcat에서 max-connection 수 때문에 안 받은 건가 싶은데, 저 api에서만 발생하니까 그건 또 아닌 것 같다.

 

아래와 같은 테스트를 추가로 만들어서 테스트해 봤다

그 결과는 이러했다.

요청을 많이 보냈을 때, 아무리 기다려도 response가 돌아오지 않는 상황이 몇몇 있었다.

이를 감안하여 봐주길 바란다.

또한 테스트 중 MVC, Webflux + Coroutine 모두에서 이런 에러를 발견했다.

java.net.SocketException: Connection reset
	at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:318)
	at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346)
	at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796)
	at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1099)
	at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
	at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
	at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
	...

org.apache.http.conn.HttpHostConnectException: Connect to .... [....] failed: Operation timed out
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
	at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:409)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
	...
Caused by: java.net.ConnectException: Operation timed out
	at java.base/sun.nio.ch.Net.connect0(Native Method)
	at java.base/sun.nio.ch.Net.connect(Net.java:589)
	at java.base/sun.nio.ch.Net.connect(Net.java:578)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:583)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base/java.net.Socket.connect(Socket.java:751)
	at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	... 19 more

connection reset에 대한 원인은 다양하다고 한다.

그중 서버 과부하, tcp connection 제한, 시간 초과가 문제인 것 같다.

동시에 많은 요청을 했기 때문에 그렇다고 생각한다.

실제로 비슷한 테스트 케이스를 만들어서 했을 때, 지표가 끊기는 부분이 발생했다.

서버 과부하로 인해 지표 전달에 문제가 발생하여 그렇다고 추정된다.

앞서 의문을 가졌던 부분도 이와 비슷한 상황이지 않았을까 생각한다.

 

2. 인덱스를 타도록 만들어놓은 api가 인덱스를 안타는 것보다 더 느린 경우가 있다.

이 현상은 동시 요청 사용자 수가 많을 때만 발생하는 것을 볼 수 있다.

요청이 많은 경우, 서버가 앞선 요청을 처리하느라 도착한 요청을 바로 처리 못하는 경우가 발생할 수 있다.

그러므로 요청은 받았지만 요청을 처리하지 못하고 대기하는 시간이 영향을 미친 것 같다.

 

3. 둘 모두 hikari cp max connection은 25로 동일하다. 근데 MVC만 RDB CPU 사용률이 99%가 나왔다.

이 부분은 진짜 모르겠다.

같은 JPA에 같은 쿼리를 요청하는데, CPU 사용률은 저렇다.

DB를 껐다가 다시 켜서 실행해도 이렇다.

 

 

테스트 피드백 대환영입니다!!