99클럽 16일차 TIL: Spring Webflux

#1. 오늘의 학습 키워드

Spring Webflux 에 대해서

• 기존에 많이 사용했던 Spring MVC 패턴은 blocking I/O 방식이다.
  • 요청을 하고 응답이 올 때까지 대기.
• 그런데 몇몇 요건에 따르면 요청을 보내고 다른 일을 할 수 있도록 대기하지 않길 원한다.
  • 예를 들면 시스템 알람과 같은 것.
    • 실시간 어플리케이션
  • 그러면 Non-blocking I/O 방식을 지원해주는 프레임워크는 무엇일까

---

#2. 공부한 내용

• Spring Webflux
  • 반응형 및 비동기적 웹 앱 개발을 지원하는 모듈
    • 비동기 Non-Blocking I/O 방식을 제공
    • Reactive Streams 의 구현체 중 하나인 Reactor 에 의존하여 비동기 로직을 구성.
      • 비동기적인 이벤트 지향 프로그래밍을 통해 얻을 수 있는 이점
        • 높은 확장성
        • 높은 성능(처리량)
    • 데이터를 비동기적으로 처리하기 위한 반응형 Type을 제공
      • Mono
        • Reactive Stream의 Publisher에 해당하는 객체
      • Flux
        • Reactive Stream의 Publisher에 해당하는 객체
• 반응형 프로그래밍(Reactive Programming)
  • 비동기적인 프로세싱 파이프라인을 만들기 위한 목적으로 개발 되었다.
    • 이벤트 기반의 비동기식 어플리케이션 구축
  • 대량의 동시 요청을 처리하는 어플리케이션의 확장성과 응답성을 향상시키는 데에 효과적.
• Reactor
  • Reactive Stream
    • JVM 위에서 실행될 수 있는 반응형 프로그래밍 라이브러리를 표준화 시킨 것.
    • 인터페이스 형태
      • 따라서 Reactor는 Reactive Stream 스펙을 구현한 구현체.
  • 비동기 이벤트 기반 서버인 Netty 서버를 통해 환경 제공.
    • 비동기, Non-Blocking 방식으로, 이벤트 기반 반응형 스트림으로 데이터 주고 받는다.
• Netty
  • 비동기 Non-Blocking 을 지원하는 Spring Reactive Stack 의 기본 서버 엔진

---

• 참조:
  • https://adjh54.tistory.com/232
  • https://velog.io/@shdrnrhd113/Spring-MVC-Vs.-Spring-WebFlux
  • https://blog.naver.com/seek316/223311717538
  • https://hoons-dev.tistory.com/117

---

#3. 오늘의 회고

• Spring Webflux 는 비동기 Non-Blocking i/o 방식을 사용함으로써 Blocking i/o 방식으로 처리하는데 한계가 있는 대량 트래픽이 발생하는 곳에서 유리하다.
  • 또한 아래 같은 시스템에서도 적합하다.
    • 응답성과 리소스 효율성이 중요한 MSA (Microservice Architecture)
    • 스트리밍, 메시징, 채팅 등 실시간 시스템
    • 높은 부하를 처리해야하는 API 서버
  • 높은 확장성과 성능을 제공하는 반응형 웹 프레임워크다
• 물론 단점 또한 있다.
  • 기존 MVC 와의 다른 패러다임을 따르기에 학습 곡선이 다소 높다
    • 반응형 프로그래밍과 명령형 프로그래밍의 차이도 다른 사고 방식을 요구한다.
  • 디버깅과 오류 처리가 다소 복잡하다.
• 정리를 하면 진입장벽이 높고 어렵다는 단점 이외에는 장점이 많다는 것이다.
  • 조금이라도 적합할 경우 적용을 시도해봐서 나쁠 게 없어 보인다.