리액티브. (2024-07-11)

1. Non-Blocking I/O 방식의 통신이 적합한 시스템

Spring Framework 기반의 두 가지 방식의 애플리케이션 코드를 직접 실행해 보면서 Non-Blocking I/O 방식을 지원하는 Spring WebFlux 기반의 애플리케이션이 요청 처리 면에서 월등한 성능을 보여준다는 사실을 확인했다.

 

그렇다면 Spring MVC보다 Spring WebFlux 기반의 애플리케이션을 무조건적으로 도입하는것이 나을까? 하지만 현실적으로 Spring WebFlux를 도입하기 위해서는 고려해야 할 사항이 몇 가지 있다.

 

1. 학습 난이도

DI(Dependency Injection), AOP(Aspect Oriented Programming), 서비스 추상화 등 Spring Framework에서 사용되는 핵심 개념들을 어느 정도 이해하고 있다는 가정하에 Spring MVC 기반의 개발 방식은 Spring WebFlux에 비해서 상대적으로 학습 난이도가 낮다.

 

그런데 Spring Framework의 핵심 개념들을 제대로 이해하려면 많은 노력과 시간, 경험이 필요하다.

 

Spring WebFlux 역시 핵심이 되는 리액티브 스트림즈라는 표준 사양을 구현한 구현체를 능숙하게 사용하기까지 학습에 대한 노력과 시간이 상당히 많이 필요하다.

---

 

2. 리액티브 프로그래밍 경험이 있는 개발 인력을 확보하는 것이 과연 쉬운가

Spring MVC의 경우 10년 이상 사용된 명령형 프로그래밍 방식의 기술이기 때문에 경험 많고 숙련된 개발 인력을 확보하기가 용이하다. 하지만 선언형 프로그래밍이자 Non-Blocking I/O 방식인 리액티브 프로그래밍 지식을 갖춘 숙련된 개발 인력을 확보하는 것은 상대적으로 어렵다. 

 

이런 이유로 Spring MVC 기반의 프로젝트는 안정적으로 진행될 가능성이 높지만 Spring WebFlux 기반의 프로젝트는 개발 인력면이나 기술적 측면에서 위험 부담을 더 감수해야 될 가능성이 높다. 높은 성능을 얻고자 도입한 기술이 오히려 발목을 잡을 가능성이 있다는 의미이다.

 

---

 

Spring WebFlux이 어울리는 애플리케이션이 있다.

 

1. 대량의 요청 트래픽이 발생하는 시스템

일반적으로 애플리케이션에 발생하는 요청 트래픽이 충분히 감당할 수준이라면 서블릿 기반의 Blocking I/O 방식의 애플리케이션으로 충분하다.

 

하지만 대량의 요청 트래픽으로 자주 애를 먹는 시스템이라면 Spring WebFlux기반 애플리케이션으로의 전환을 고려해 볼 만하다.

 

Spring WebFlux 기반 애플리케이션은 상대적으로 적은 컴퓨팅 파워를 사용함으로써 저비용으로 고수준의 성능을 이끌어 내는 괜찮은 선택이 될 수 있을것이다.

---

 

2. 마이크로 서비스 기반 시스템

마이크로 서비스 기반 시스템은 특성상 서비스들 간에 많은 수의 I/O가 지속적으로 발생한다. 따라서 특정 서비스들 간의 통신에서 Blocking으로 인한 응답 지연이 발생하게된다면 해당 서비스 뿐만 아니라 다른 서비스들에도 영향을 미칠 가능성이 높다. 심지어 응답 지연의 연쇄 작용으로 시스템 자체가 마비될 수도 있다. 그렇기 때문에 마이크로 서비스 기반 시스템에서는 Spring WebFlux같은 Non-Blocking I/O 방식의 기술이 반드시 필요하다

---

 

3. 스트리밍 또는 실시간 시스템

리액티브 프로그래밍은 HTTP 통신이나 데이터베이스 조회와 같은 일회성 연결뿐만 아니라 끊임없이 들어오는 무한한 데이터 스트림을 전달받아서 효율적으로 처리할 수 있다. Spring WebFlux를 이용하면 이러한 무한 데이터 스트림을 처리하기 위한 스트리밍 또는 실시간 시스템을 쉽게 구축할 수 있다.