[Spring Boot] 18. 리액티브 프로그래밍 좀 더 알아보기

들어가며

유튜브에서 kakao tech와 같은 빅테크 기업들의 기술 영상을 보면서 항상 언급되는 것이 있다.

그건바로 "대규모 트래픽을 효과적으로 처리하기 위한 리액티브"이다.

리액티브 프로그래밍(Reactive Programming)은 어원 그대로 reaction이 있다. 즉, 반응이 있는 프로그래밍이라는 뜻이다.

엥 ? 반응이 있다고 ? 이게 무슨 뜻인가 ? 일반적인 프로그램들도 다 반응을 하는데 ? 라고 생각할 수 있지만 여기서의 반응은 사뭇 다르다.

데이터 소스가 변경이 있을 때마다 데이터를 전파한다라는 의미이다. (그냥 응답이 아닌, 즉각적인 응답성을 제공한다는 점이 차이가 있다.)

리액티브 프로그래밍은 비동기 및 이벤트 기반 프로그래밍의 개념을 기반으로 하는 프로그래밍 패러다임 중 하나이다.

이 패러다임은 주로 사용자 인터페이스, 네트워크 통신, 데이터 스트림 등과 같이 다양한 이벤트에 반응할 수 있는 프로그램을 작성하는 데 사용된다.

4가지 특징

이번에는 기술 문서로 리액티브 프로그래밍의 특징에 대해서 알아보자.

Spring Boot의 리액티브 프로그래밍의 기술문서에는 총 4가지의 특징을 지내고 있다고 기술한다.

응답성, 회복성, 탄력성, 메시지 기반이다.

응답성(Reactive)은 프로그래밍이 요청에 즉각적으로 반응할 수 있음을 의미한다.

회복성(Resilient)은 장애 상태에서도 응답을 할 수 있음을 의미한다.

따라서, 부분적인 실패가 발생해도 전체 시스템이 완전히 중단되지 않고 계속해서 동작할 수 있다.

탄력성(Elastic)은 작업량이 다양해도 높은 응답성을 보이는 것을 의미한다.

따라서, 다양한 작업량에 대해 조절이 가능하며, 부하가 증가하거나 감소할 때 탄력적으로 대처할 수 있다.

마지막으로 메시지 기반(Message-Driven)은 Kafka나 RabbitMQ와 같이 메시지를 통해서 전달되고 전송함을 뜻한다.

리액티브 프로그래밍은 컴포넌트 간 통신이 주로 메시지 기반으로 이루어지기 때문에 이벤트나 데이터의 변경은 메시지로 전달되어 처리된다.

기존과 다른점은?

일반 프로그래밍과 리액티브 프로그래밍의 차이는 형태라고 할 수 있다.

선언형 프로그래밍이라고 들어본 적이 있는가?

필자도 아직 사용해보지 못하고 본 적만 있어서 선언형 프로그래밍에 대해서 간단히 설명하자면, 동작이 아닌 목표만을 정의하는 형태라고 할 수 있다.

정확한 내용은 아니지만 이해를 위해서 설명하자면 "->"와 같이 화살표를 자주 사용하며, 반복문과 조건문을 선언하지 않는다는 특징이 있다.

리액티브 프로그래밍의 구현체로는 리액티브 스트림즈(Reactive Streams)가 있다.

이는 리액티브 프로그래밍을 표준화한 명세로 Publisher, Subsrciber, Subscription, Processor 등의 인터페이스를 정의하고 있다.

따라서 여러 언어와 라이브러리 간의 일관된 리액티브 프로그래밍 환경을 제공한다.

(Java에서는 RxJava, Java 9의 Flow API, Akka Streams, Reactor 등이 리액티브 프로그래밍을 지원하는 라이브러리 및 프레임워크로 사용된다.)

리액티브 프로그래밍의 단점

그렇다면 리액티브 프로그래밍만 쓰면 되지 않나?

물론 장점만 있는 것은 아니다.

주로 Non-Blocking I/O의 방식을 사용하고 있기 때문에 Thread를 사용한다.

하나의 작업이 아닌 매우 많은 작업을 동시에 실행하고자 하면 당연히 Multi thread 환경을 구축할 것이다.

하지만, 이는 매우 비효율적이다.

물론 Thread가 Process의 자원을 공유하고 있기 때문에 소모량이 작다고 하지만, 이 역시도 Process와 마찬가지로 Context switching에서의 비용이 발생하기 때문이다. (메모리 사용으로 인한 오버헤드 문제도 발생할 수가 있다.)

그리고 Servlet 기반은 Thread를 다 사용한 후에는 Thread Pool에 반납을 해야하는데, 반납 과정에서 응답이 지연되는 문제 역시 발생한다.

H/W의 관점에서 벗어나서 리액티브 프로그래밍은 Blocking I/O 역시 사용하는데, 사용자의 요청에서 응답까지의 과정에서 Blocking I/O 요소가 포함되어 있을 경우에 Non-Blocking I/O의 이점을 발휘하기 힘들다는 단점이 있다.