WebFlux는 무엇이고, 왜 나왔고, 언제 쓰이는가?

어제 Cart API 코드 리팩터링을 마무리하고, 리뷰를 받기 위해 PR을 올렸다.

클린 한 코드로 작성하려고 노력하기 위해 리뷰어님이 주신 의견을 되뇌고, 클린 코드를 작성하기 위한 방법을 구글링을 통해 하루 종일 모니터를 노려보며 클래스 간 책임을 나누어 보았다. 빨리 성장하고 싶다!!

리뷰를 앞두고, 카카오페이를 이용한 도메인 코드들을 리팩터링 하기 앞서, 기존에 외부 API와 통신하기 위해 사용하던 템플릿인 RestTemplate의 대체 여부에 대해 떠올랐다.

RestTemplate은 deprecated 되었으므로, WebClient의 사용을 고려해보라는 의견을 받았다.

WebClient에 대해 알아보다가 동기/비동기, 블로킹/논블로킹이라는 개념의 정의에 대해 다시 공부하게 되었고, 나아가 WebFlux라는 큰 틀을 조금이나마 이해하고 코드를 작성하는 게 좋겠다는 판단 하에 간략하게 개념을 공부 후 나름대로 정리했다.

 

기존 통신 Flow

클라이언트가 서버에게 요청을 한다. 

서버는 DB에 요청 처리에 대한 Data 조회를 한다. 그 과정이 5~10초가 걸린다. 

5~10초 동안 서버는 다른 요청을 받지 못하고, 가만히 있는 상태가 된다. => 상당히 비효율적임.

 

이를 해결하기 위해 사용하는 방식인 Thread 방식 

하지만, Context Switching이 많아져 Thread 생성을 계속되어 속도가 매우 느려지게 된다.

 

어떻게 해야 이 문제를 해결할 수 있을까.

 

=> 비동기 방식 이용

비동기 방식 도입

위와 같이 클라이언트는 똑같은 요청을 했다.

이번엔 무려 20초나 걸린단다. (뭐길래..) 이번에는 20초를 기다리는게 아니라 대략적으로 20초 정도가 걸린다는 즉각적인 응답을 클라이언트에게 준다.

 

그리고, 20초 동안에 서버는 다른 요청을 받을 수 있다. => 비동기 처리 가능.

하지만, 기존 요청을 잊지 말아야 하기에 Event Roof를 통해 요청에 대한 이벤트를 저장한다.

 

20초 후, Data 조회가 완료 되면 이벤트 루프에 적혀 있던 대로 클라이언트에게 Data 응답을 해준다.

=> 한 가지 요청이 처리 되는 시간 동안, 다른 요청들을 동시에 받을 수 있다.

 

 

Stream 사용

다수가 사용하는 통신 프로토콜인 HTTP는 Stateless 하다.

따라서 요청과 응답의 1사이클로 끊긴다.

 

비동기 방식을 사용하기 위해 이벤트 루프에 저장되어 있던 응답 내용을 보내주지 못하는 참사가 발생한다.

따라서 응답을 끊지 않고 Stream을 생성하여 유지시키게 되었다.

 

이를 SSE 프로토콜이라고 한다.

=> Stream을 사용하여 응답을 지속할 수 있게 되었다. 이벤트 루프에 저장되어 있는 요청 건에 완료된 데이터를 응답하기 위해 따로 요청을 받는 일도 필요 없게 되었다.

 

Webflux 란

SSE 프로토콜 방식을 사용하며, 반응형 프로그래밍이 가능해졌다.

Spring이 적용한 반응형 프로그래밍을 Spring Webflux라고 한다.

 

Reactive를 지원하는 MongoDb나, Redis를 사용하며, RDBMS는 지원하지 않는다.

R2dbc 라이브러리를 사용하여 Mysql을 비동기식으로 사용할 수 있게 되었다.