오늘은 Spring Webflux 를 사용할지 고민하고 계시는 분들이 있다면 조금이나마 도움이 되도록 몇가지 의견과 단점에 대해서 잘 정리한 블로그를 소개하고자 한다. (단점이 잘 정리된 블로그를

오늘은 Spring Webflux 를 사용할지 고민하고 계시는 분들이 있다면 조금이나마 도움이 되도록 몇가지 의견과 단점에 대해서 잘 정리한 블로그를 소개하고자 한다. (단점이 잘 정리된 블로그를 소개한 이유는 단점을 잘 알고 있어야 사용 여부를 판단하기 용이하고 실제 사용시에도 단점을 극복하기 위한 고민을 할 수 있기 때문이지 사용을 권장하지 않기 위해 소개한게 아님을 미리 언급합니다.) 혹시나 Spring Webflux 를 들어본적 없는 분들을 위해 간단하게 설명하자면 C10K 문제와 같이 대량의 트래픽을 처리할 수 있는 대안으로 서버 개발자들 사이에서 논블록킹에 대한 관심이 커지게 되었는데 이 관심에 보답하듯 Spring 에서 야심차게 만든게 Spring Webflux 다. 그럼 Reactive Streams 는 무엇인가? Reactive Streams 는 코시국에 집콕 생활을 유지하게 해준 Netflix 와 Spring Framework 를 개발한 Pivotal, Akka 를 개발한 Lightbend 의 엔지니어들이 합심하여 개발한 프로젝트인데 비동기 스트림 처리를 위한 표준화된 스펙을 정의하고 각 회사가 이에 대한 구현체들을 개발했다. (흥미로운 점은 각 회사에서 만든 구현체들이 각각 다르지만 앞서 정의한 표준화 스펙을 준수했기 때문에 서로다른 구현체간에 연동이 가능하다.) Pivotal 에서는 Project Reactor 라는 이름으로 구현체를 만들었고 Spring Webflux 는 이 Project Reactor 를 기반으로 개발된 논블록킹 서버 프래임워크인 것이다. 실제로 Spring Webflux 를 사용하고 운영을 해본 결과 논블록킹 처리에 대해 매우 잘 만들어진 프래임워크 라는 의견에 동의한다. 다만, 세상에 완벽한건 없고 어떤 솔루션이든 잘 알고 써야 최상의 효과를 볼 수 있는것이기 때문에 Spring Webflux 도 잘 알고 써야 한다. 흔히들 사람들이 Spring Webflux 나 논블록킹 처리를 하면 무조건 빠를 것이라고 생각하는데 절대 그렇지 않다. C10K 와 같은 대량의 트래픽을 처리할 수 있고 서버 리소스 자원을 효율적으로 사용하는것 뿐이지 Spring Webflux 나 논블록킹 처리가 무조건 빠르진 않다. 경우에 따라서는 Spring MVC 가 더 빠른 처리를 할 수도 있다. 다른 단점들은 블로그글에 잘 설명되어 있으니 개인적으로 Spring Webflux 를 사용할 때 가장 크게 아쉬운점을 얘기하자면 MVC 때는 잘 쓰던 솔루션을 못쓸 수 있는 상황이 발생할 수 있다는 것이다. 최근에 R2DBC 가 어느정도 안정화되면서 관계형 데이터베이스에 대한 연동도 가능해졌지만 아직까지 다양한 솔루션이나 라이브러리에 대한 지원이 확실치 않다보니 Spring Webflux 전환시 기존에 사용하고 있는 솔루션이나 라이브러리가 Spring WebFlux 에서 사용 가능한지(혹은 Reactive Streams 구현체가 있는지) 등을 잘 확인해봐야한다. 자꾸 안좋은 얘기만 해서 본의아니게 사용을 지양하게 만드는것 같아 좋은점도 얘기하자면 확실히 서버 리소스 사용에 대한 효율이 좋고 대량의 트래픽을 잘 처리할 수 있다. 그래서 비용과 동시처리에 대한 부담이 많이 줄어든다. 만약 Spring Webflux 로 어떤걸 만들면 좋겠냐는 질문을 받는다면 Gateway 서버와 같이 비지니스 로직이 단순하고 솔루션간의 연동이 범용 프로토콜로 연동이 가능한 프로젝트가 좋지 않을까 싶다.(물론 이것도 Spring Webflux 를 기반으로 만든 Spring Cloud Gateway 라는게 있으니 참고하면 좋겠다.)