리액티브 데이터 타입(Mono, Flux)을 사용하는 이유

스프링 웹플럭스를 사용하면 Mono와 Flux 타입을 만나게 됩니다. 이 두 개의 데이터 타입은 왜 필요하게 되었을까에 대해서 알아보려고 합니다. 

 

 

리액티브 타입의 도입

 

리액티브 타입은 request와 data의 빠른 처리 목적으로 도입된 개념이 아닌, 잦은 오버헤드를 줄이기 위해서 도입되었습니다. 전통적인 블로킹 작업에서는 기다리는 동안에 자원을 잡고 있었습니다. 그러나 논블로킹에서는 자원을 차지하지 않습니다. 그래서 이를 활용한 리액티브 프로그래밍에서는 request를 동시적으로 처리할 수 있는 장점과 원격 서버에서 오는 데이터 작업을 대기시간 없이 처리할 수 있는 장점이 있습니다. Reactive API는 개별 데이터를 하나씩 처리하는 것 뿐만 아니라 스트림 데이터를 다룰 수 있습니다.

 

 

비동기 처리를 위한 시도

 

Java 8 이전에는 Future 타입이 비동기 처리를 할 수 있게 해주었습니다. 그러나 결과를 가져오는 get()을 사용할 때에는 스레드를 블로킹하는 한계가 있었습니다. Java 8이 등장하면서 CompletationFuture이 도입되었습니다. 이것은 Future를 논블로킹으로 사용할 수 있게 하는 클래스 입니다. 또한 Steam이라는 개념도 도입되었습니다. Stream은 stream data를 대기시간이 거의 없이 접근하여 다룰 수 있게 디자인되었습니다. 이 Steam은 I/O 작업 같은 지연 처리 용도가 아닌, reactive 처리를 위해 디자인 되었기 때문에 한 번만 사용할 수 있고 병렬처리는 가능하지만 스레드풀을 지정할 수 없습니다.

 

 

Reactive API와 리액티브 데이터 타입의 필요 이유

리액티브 API는 여러 연산자(operator)를 제공합니다. 어느 stream sequence와도 작업이 가능하고, pipeline을 구성할 수 있습니다. 그리고 비동기와 동기 연산자도 사용할 수 있습니다. 이러한 연산자는 초기에만 하더라도 오직 스트림 데이터만 다루도록 디자인 되었습니다. 여기서 스트림 데이터라고 하면 Flux 같은 것을 말합니다. 즉, 2개 이상의 n개 요소들을 처리하는 것에 초점이 맞추어져 있었습니다. 그러나 Spring Framework 5에서 1개만 처리하는 스트림과 n개를 처리하는 스트림 타입을 분리하게 되었습니다.

이제 이 게시물을 쓰게 된 궁금증에 대한 해답입니다. 데이터를 효과적으로 다루기 위해서 1개와 n개를 분리했습니다. 개발자들이 1개를 데이터를 가져오는 시나리오라고 확정적으로 알고 있다면 해당 데이터 타입에 맞는 연산자를 적절하게 사용할 수 있습니다. 만약에 String을 기대했는데 List<String>이 나온다면 문제가 될 것 입니다. 그래서 1개의 데이터를 다루는 것을 Mono로, n개를 다루는 것을 Flux로 구분했습니다. 그리고 이에 맞추어 해당 데이터 타입에 맞는 연산자들도 적절하게 구현되어 있습니다. Mono의 경우, filter와 map과 같은 연산자가 있고, Flux의 경우, n개를 다루기 때문에 merge와 combine, flatmap과 같은 연산자가 있습니다. 뿐만 아니라 이렇게 구분해 놓으면 back pressure 처리에도 도움이 됩니다. back pressure는 consumer가 소비하는 것보다 producer가 더 많은 데이터를 보낼 때에 consumer가 producer에게 어느 정도 만큼의 데이터만 보내달라고 요청하는 메커니즘입니다.

 

 

참고

- https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#specification

- https://spring.io/blog/2016/04/19/understanding-reactive-types