[Spring] Spring WebFlux + SpringBoot로 간단한 이커머스 플랫폼 개발 - 1(개념정리)

간단한 개념부터 정리해 보자.

리액티브 프로그래밍의 필요성

리액티브 프로그래밍이 세상에 소개된지는 오래 되었지만 지금까지 왜 주류로 올라서지 못하였을까?

아마 리액티브 프로그래밍을 써야할 정도의 대규모 서비스가 많지 않았기 떄문이였던것 같다.

세상은 새로운 시대로 접어들면서 스타트업도 수백만명의 사용자에게 컨텐츠를 제공할 수 있어야 하고

전 세계의 고객을 상대해야 하므로 24시간 동안 끊임없이 운영되어야 한다.

또한 클라우드 환경에서 어플리케이션을 운영하는 것이 보편화 되고 있어서 문제가 생기면 서버를 더 투입하면 된다 라는 예전 방식은 이제 통하지 않게 되었다.

개발자들은 기존 자원을 더 효율적이고 일관성 있게 사용하는 방법을 찾고 있으며, 그 해법이 바로 리액티브 스트림이다.

 

---

Spring WebFlux의 등장

웹 어플리케이션을 개발할떄 가장 널리 사용돼온 도구는 Spring MVC 이지만 잠재적으로 수백만명의 사용자를 감당해야 하는 서비스에서는 웹 계층을 확장하는 것이 필수다. 이러한 확장 요구는 Spring WebFlux를 이용하여 웹 요청을 리액티브하게 처리하는 것이 좋은 선택이다.

Spring MVC는 Java Servlet을 기반으로 만들어졌다. Servlet API는 내부적으로 많은 가정에 의존하고 있는데 그중 대표적인 부분이 블로킹 방식으로 동작한다는 점이다. 물론 Servlet 3.1 이후에는 비동기방식을 일부 지원하기는 하였지만 완전히 reactive하다고 볼 수는 없다.

Netty의 등장으로 100% 논블로킹, 비동기 웹 컨테이너로 서블릿 스펙에 구속되지 않는다.

Spring WebFlux는 Netty와 궁합이 잘 맞는다. Spring WebFlux를 사용하면 Spring MVC에서 사용하던 프로그래밍 모델 그대로 작성한 코드를 서블릿 컨테이너가 아닌 Netty 위에서 실행할 수 있다.

 

---

리액티브 데이터 스토어 요건

데이터를 DB에 밀어 넣기 전에 리액티브 프로그래밍을 사용하려면 모든 과정이 리액티브여야 한다.

일부라도 리액티브하지 않고 블로킹된다면 애플리케이션은 제대로 동작하지 않는다.

웹컨트롤러나 서비스 계층을 리액티브 방식으로 동작하게 만들어 놨지만 블로킹 방식으로 연결되는 DB를 호출하면

리액티브는 무너진다. DB를 호출한 스레드는 응답을 받을떄까지 다른 작업을 하지 못하기 떄문이다.

리액티브 프로그래밍 기법은 빠르다 라는 편견이 있는데 이는 사실이 아니다. 단일 스레드 기준으로 보면 여러가지 오버헤드를 수반하므로 결론적으로 성능 저하가 발생한다. 예시로 화물을 나르는 소형차와 대형트럭을 비교하면 된다.

사용자 수가 작고 데이터가 많지 않다면(소형차) 불필요한 오버헤드를 감수하면서 까지 리액티브를 사용하는 것은 낭비이다. 그러나 대규모 트래빅이 발생하는 백엔드에서 대용량 데이터를 처리하는 환경에서는 리액티브 프로그래밍의 장점이 빛을 발하게 된다.

따라서 리액티브가 제대로 동작하려면 DB도 리액티브하게 동작해야만 한다.

아래 목록은 리액티브 패러다임을 지원하는 DB 리스트이다.

• MongoDB
• Redis
• Cassandra
• ElasticSearch
• Neo4j
• CouchBase

목록에서 확인할 수 있듯이 관계형 데이터베이스(RDB)는 없다. 자바에서 RDB를 사용할떄는 JDBC, JPA, JOOQ 등과 같은 기술이 사용되는데 거의다 블로킹 API이다. 모든 DB호출은 응답이 올떄까지 블로킹되어 기다려야 한다.

요즘 R2DBC(Reactive Realational Database Connectivity)와 같은 리액티브 스트림을 활용하여 RDB에 연결시킬수 있는 기술이 있지만 아직은 이르다고 한다.

 

---

 

출처 : 도서 스프링 부트 실전활용 마스터