Spring Cloud GateWay를 사용한 프로젝트를 진행하면서 로깅을 통해 내부적으로 netty가 사용되는걸 확인했다. 하지만 netty가 무엇인지 정확한 개념이 없었다. 그래서 관련 내용을 공부했고 해당 내용을 공유하려한다.
공식문서에 따르면 Spring Cloud GateWay는 Spring WebFlux 위에서 동작한다.
This project provides a library for building an API Gateway on top of Spring WebFlux
Spring WebFlux의 중요한 특징 중 하나는 non-blocking server를 사용한다는 것이다. 여기서 궁금증이 생겼다. non-blocking server와 blocking server의 차이점은 무엇이고, spring cloud gateway 프로젝트는 왜 non-blocking server 위에서 동작하는지 궁금했다.
SpringBoot가 Spring WebFlux에서 사용할 수 있도록 지원하는 Server 종류
tomcat과 jetty는 Java Servlet API의 구현체이고 Servlet 3.1 이상부터 non-blocking을 지원한다.
blocking server vs non-blocking server
blocking server
blocking server는 보통 thread pool에 여러개의 thread를 가지고 있다. 그리고 request마다 thread를 할당하고 request 끝날때 까지 할당받은 thread에서 작업이 처리된다.
blocking server의 이런 특징 때문에 cpu를 효율적으로 사용하지 못하는 단점이있다. 첫 번째 이유는 I/O 연산이 자주 일어나면 cpu는 자주 cpu-idle 상태에 빠진다. 그리고 보통의 web application request는 socket I/O, db I/O등 I/O 연산이 자주 발생한다. 두 번째 이유는 context switching이 자주 발생한다. request가 증가하면 사용되는 thread 수가 증가하고 이는 잦은 context switching 유발한다. 추가적인 단점으로는 thread pool의 thread 개수가 정해져 있어 DOS 공격에 취약하다.
non-blocking server
non blocksing server는 여러 request를 하나의 thread에서 수행한다. 이게 가능한 이유는 non-blocking kernel I/O 기능을 이용하기 때문이다. 덕분에 socket I/O, db I/O 등의 연산이 일어날때 cpu가 다른 일을 할 수 있다.
non-blocking server는 주로 event-loop 또는 green-threads와 fibers 같은 추상화를 통해 구현한다. 여기서 한가지 중요한 부분이 있다. 바로 non-blocking server도 완전히 concurrently하게 request를 처리하지 않는다는 것이다. 하지만 blocking server보다 많은 request를 처리할 수 있다. 왜냐하면 메모리 소모량이 multi-thread model처럼 급격하게 증가하지 않기 때문이다. 하지만 단점도 존재한다. 코드가 훨씬 복잡해진다. 그리고 cpu-expensive request는 잘처리하지 못한다.
blocking server와 non-blocking server의 장단점
| Prob | Cons | |
| blocking server | - 코드가 간단하다. | - 동시에 처리할 수 있는 request 수가 제한적이다. - 많은 메모리를 사용한다. - cpu를 효율적으로 사용하지 못한다. - dos 공격에 취약하다. |
| non-blocking server | - cpu를 효율적으로 사용할 수 있다. - 동시에 처리할 수 있는 request가 훨씬 많다. |
- 코드가 복잡하다. - cpu-intensive request가 증가하면 성능이 떨어진다. |
Spring Cloud GateWay가 non-blocking server을 이용하는 이유
gateway의 특징을 생각보자. gateway는 많은 request을 받아 공통적인 작업을 처리하고 다른 service로 request을 전달한다. 다시 말하자면 동시에 처리할 수 있는 request는 많아야 하지만, 처리하는 작업이 대부분 간단하다.
이런 특징은 non-blocking server의 장점은 극대화할 수 있고, 단점은 최소화할 수 있다. 따라서 gateway에서는 non-blocking server를 사용하는게 합리적인 선택이다.
정리
spring cloud gateway를 사용하면서 netty에 대해 알게되었고, 이를 통해 non-blocking server에 대해 알게 되었다. 결국 server도 상황에 따라 적절한 선택이 중요하다는 깨달음을 얻었다.
글이 도움이 되었다면 공감 또는 댓글 부탁드립니다! 잘못된 내용이 있다면 언제든 피드백 부탁드려요. :)
참조
Spring webFlux differrences when Netty vs Tomcat is used under the hood
I am learninig spring webflux and I've read the following series of articles(first, second, third) In the third Article I faced the following text: Remember the same application code runs on To...
stackoverflow.com
https://spring.io/projects/spring-cloud-gateway
Spring Cloud Gateway
@SpringBootApplication public class DemogatewayApplication { @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("path_route", r -> r.path("/get") .uri("http://httpbin.org")) .route("host_route", r ->
spring.io
76. Embedded Web Servers
Each Spring Boot web application includes an embedded web server. This feature leads to a number of how-to questions, including how to change the embedded server and how to configure the embedded server. This section answers those questions. 76.2 Disablin
docs.spring.io
'Spring' 카테고리의 다른 글
| Spring's STOMP support 파헤치기 (0) | 2023.06.02 |
|---|---|
| Spring Websocket Trobleshooting!! (feat. Decorator Pattern) (0) | 2023.05.21 |
| @SpringBootTest의 비밀! (0) | 2022.12.11 |
| @RequestBody (0) | 2022.06.10 |
| @JdbcTest와 @DataJdbcTest (0) | 2022.05.21 |
