[Springboot] spring Web tomcat 서버로 구현된 프로젝트 spring WebFlux Netty 서버 사용으로 바꾸기 - 1

 

1. 현재 프로젝트

 

1) spring-boot-starter-web 과spring-boot-starter-webflux 둘 다 의존하여 사용

• spring-boot-starter-web과 spring-boot-starter-webflux 두 가지 의존성이 함께 설정되어 있기 때문에 Tomcat 서버가 우선 적용
• Tomcat은 기본적으로 블로킹 I/O 모델을 사용하는 서블릿 컨테이너로 전통적인 Spring MVC 방식에서는 동기 블로킹 I/O 처리 하지만WebFlux는 Servlet 3.1 이상을 지원하는 Tomcat에서 비동기 논블로킹 방식으로도 작동할 수 있음(Servlet 3.1 이상부터는 비동기 요청을 처리할 수 있는 기능이 도입)

 

2) 주요 비즈니스 로직

WebClient를 통해 여러 외부 API 호출을 비동기적으로 처리하며, 1개 요청에 n개의 WebClient 호출 수행

 

 

2. Netty 서버를 사용하는 것이 적합한 이유

 

1) 비동기 논블로킹 처리의 중요성

• 현재 코드를 보면 WebClient가 n개의 요청을 비동기적으로 처리되고 있음. 각 요청이 독립적으로 실행되고 결과를 비동기적으로 결합하는 흐름
• Netty는 기본적으로 논블로킹 I/O를 기반으로 동작하며 많은 수의 병렬 요청을 처리하는데 최적화 되어 있음
• tomcat도 비동기 처리를 지원하지만 기본적으로 블로킹 모델에서 동작되도록 설계되어 있어 대량의 비동기 요청을 효율적으로 처리하는 데 Netty보다 성능 저하가 발생할 수 있음

 

2) 성능과 확장성

• 한 번의 요청에서 WebCleint가 n개의 호출을 생성하는데, 이러한 대규모 비동기 요청 패턴에서는 논블로킹 I/O 모델이 성능과 확장성 면에서 훨씬 더 유리함
• Netty는 적은 리소스를 사용해 동시에 많은 요청을 처리할 수 있는 높은 동시성을 제공하는데, 이는 현재 비즈니스로직에서 매우 중요한 요소임
• Tomcat이 동일한 작업을 처리하려면 상대적으로 더 많은 시스템 리소스(스레드 및 메모리)가 필요할 수 있음

 

3) Reactor Netty와 WebClient의 자연스러운 통합

• WebClient는 내부적으로 Reactor Netty를 기본 HTTP 클라이언트로 사용함
• 만약 서버도 Netty를 사용하게 된다면 전반적인 네트워크 처리 성능과 응답 시간이 개선될 수 있음

 

4) 대량 요청에 대한 안정성

• Netty는 이벤트 기반으로 동작하기 때문에 대량의 요청을 처리할 때 대기 상태 없이 이벤트 루프를 통해 처리할 수 있음 
• Tomcat의 경우 대량의 비동기 요청을 처리할 때 스레드 풀을 활용하는데 스레드 풀 크기를 조정하지 않으면 스레드 경합이 발생하거나 리소스 소모가 커질 수 있음

 

3. 결론 

• 비동기 논블로킹 방식으로 대량의 WebClient 호출을 처리하는 코드가 비즈니스 로직의 주요한 부분이라면 Netty로 전환 하는 것이 더 나은 선택
• Netty는 비동기 처리에 최적화된 서버이며 WebFlux와 함께 사용할 때 성능과 확정성에서 큰 이점을 제공
• Tomcat은 블로킹 I/O 모델을 기본으로 하므로 대규모 비동기 처리에서 성능 저하가 발생할 수 있음