비동기 서버 도입에 대한 고찰
본 문서는 Spring Reactive Web (WebFlux)를 도입하면서 고찰한 내용을 기록한 문서입니다.
기존에 사용하던 "Spring Web MVC"의 동작방식으로 인한 서버 Latency에 대한 고민을 하기 시작했습니다.
직접 쓴 링크에서 학습한 내용과 같이 기존의 서버는 다음과 같은 문제가 있습니다.
- Context Switching
- Sync(Blocking)
위의 두 가지 이유로 인하여 기존의 Spring 서버에 대한 문제를 고민하게 되었습니다.
비동기 서버를 선택한 이유는 본 서버가 cpu 1core, ram 1gb인 프리티어 환경에서 구성될 예정이기 때문입니다.
1 core 상황에서 서버가 구성되었으면 많은 쓰레드를 감당하기 힘든 구조라고 판단하였습니다.
Network I/O, Disk I/O가 비동기적으로 처리되기때문에 많은 Request가 할당되었을 때 더욱 유리한 상황이라고 판단이 되었습니다.
아래의 사진과 같이 WebClient에서 Network I/O가 발생했을 시, 대기할 쓰레드를 따로 사용하고 Callback 처리를 한 것을 볼 수 있습니다. Main 쓰레드는 Request를 계속해서 수행한다고 판단이 되었습니다.
-
"Mono", "Flux" 구조에 따른 Stack Trace가 파악하기 힘들다고 판단이 되었습니다. 그에 따른 디버깅도 힘들다고 파악하였습니다.
-
에러나 예외시 연쇄적 효과가 발생한다고 파악하였습니다.
-
관련된 라이브러리가 아직 부족하다고 판단이 되었습니다.
본 프로젝트에서는 서버가 3종류가 존재합니다.
- Book 서버
- Auth(Member) 서버
- Board 서버
Book 서버는 외부 API(책 정보 제공)에 연동하여 서비스를 제공합니다.
- 외부 Network I/O가 많이 발생할 것이라고 판단하였습니다.
- 본 서버는 단순한 외부 API 통신을 하는 서버이므로 서버가 다중화되고 분산화될 시, 본 서버에 많은 요청이 들어올 것으로 판단이되어서 비동기 서버가 유리하다고 생각하였습니다.
그리하여 기존의 Tomcat 구조로 진행한다면 서버에 Latency가 발생한다고 판단하게 되었고, 비동기 서버 Netty를 선택하였습니다.
Auth 서버 또한 API 인증에 관한 기능을 수행하는 서비스입니다.
- Book 서버와 마찬가지로 외부 APi 요청이 많이 들어올 것으로 판단이 되었습니다. 그리하여 비동기 이벤트 처리가 필요하다고 판단되어 비동기 서버를 선택하였습니다.