[Spring] Spring MVC & Spring WebFlux

1. Spring MVC (전통적인 블로킹 방식)

• 기반 기술: 서블릿 API (Tomcat, Jetty 등 서블릿 컨테이너 위에서 동작)
• 동작 방식
  • 요청당 스레드(Thread-per-request) 모델을 기본으로 합니다.
  • 각 HTTP 요청마다 별도의 스레드가 할당되어, 해당 요청이 완료될 때까지 그 스레드가 블로킹(대기)됩니다.
• I/O 처리
  • JDBC, RestTemplate등 전통적인 블로킹 I/O를 사용합니다. DB 쿼리나 외부 API 호출 시, I/O 작업이 완료될 때까지 스레드가 대기합니다.
• 장점
  • 익숙함: 대부분의 자바 개발자에게 익숙한 순차적인 코드 작성 방식
  • 쉬운 디버깅: 코드 흐름이 예측 가능하여 디버깅이 비교적 용이함.
  • 다양한 라이브러리: 블로킹 기반의 풍부한 라이브러리 생태계.
• 단점
  • 스레드 고갈: 동시 요청이 많아지면 할당할 스레드가 부족해져 성능 병목이 발생할 수 있음.
  • 비효율적인 리소스 사용: I/O 작업 대기 시간 동안 스레드가 비활성 상태로 리소스를 점유.
• 주요 사용처: CPU 집약적인 작업, 트랜잭션이 복잡한 백오피스 시스템, 동시성보다 코드의 직관성과 빠른 개발이 중요한 시스템.

2. Spring WebFlux (반응형 논블로킹 방식)

• 기반 기술: 리액터 프레임워크 (Netty등 논블로킹 서버 위에서 동작)
• 동작 방식
  • 이벤트 루프 모델을 기본으로 합니다.
  • 소수의 스레드가 여러 요청을 동시에 처리하며, I/O 작업 시 스레드를 블로킹하지 않고 다른 요청을 처리하다가 I/O가 완료되면 콜백을 통해 다음 작업을 이어갑니다.
• I/O처리
  • WebClient, R2DBC, Reactive Redis등 논블로킹 I/O를 사용합니다.
  • I/O 작업이 진행되는 동안 스레드가 유휴 상태로 다른 작업을 수행합니다.
• 주요 타입
  • Mono (0-1개의 데이터를 발행)
  • Flux (0-N개의 데이터를 발행)
• 장점
  • 높은 확장성/동시성: 적은 스레드로 많은 동시 요청을 효율적으로 처리할 수 있어 고성능, 고동시성 환경에 유리
  • 리소스 효율성: I/O 대기시간 동안 스레드가 점유되지 않아 리소스 사용이 효율적.
  • 백프레셔: 발행자가 소비자의 처리 속도에 맞춰 데이터 발행량을 조절하는 메커니즘 제공
• 단점
  • 높은 학습 곡선: 반응형 프로그래밍 패러다임과 Mono/Flux 체인 방식에 익숙해지는 데 시간과 노력이 필요.
  • 복잡한 코드: 순차적이지 않은 비동기 코드 흐름으로 디버깅이나 에러 핸들링이 복잡할 수 있음.
  • 제한된 라이브러리: 모든 라이브러리가 논블로킹을 지원하지 않아 선택의 폭이 좁을 수 있음.
• 주요 사용처: I/O 집약적인 작업, 실시간 스트리밍, 대량의 요청 처리, 마이크로서비스 간 논블로킹 통신.

3. 하이브리드 사용시 주의사항

• 문제점
  • 하나의 프로젝트에서 MVC와 WebFlux 스타터를 함께 사용할 수 있지만, 반응형 코드 경로에서 블로킹 I/O 작업이 수행되면 심각한 성능 저하와 스레드 고갈 문제를 야기합니다.
  • WebFlux의 이벤트 루프 스레드가 블로킹되면 그 스레드가 다른 작업을 처리할 수 없게 되기 때문입니다.
• 현 프로젝트에서의 문제 - 프로젝트 리팩토링 중
  • KisTokenService에서 WebClient를 사용하면서 Mono를 반환하지만, 내부적으로 블로킹 방식의 RedisService를 호출하는 것.
• 해결방안
  • WebFlux를 제대로 활용하려면 모든 I/O작업(DB, Redis, 외부 API)을 논블로킹 드라이버로 전환해야 합니다.
  • 만약 불가피하게 블로킹 작업을 해야 한다면, Schedulers.boundedElastic()과 같은 별도의 블로킹 스레드 풀로 작업을 오프로드해야 합니다.
  • 혹은 모든 통신을 명시적인 블로킹 방식으로 통일하는 전략도 있습니다.