Reactor execution model 1
리액터의 동작 모델&원리에 관한 탐구
Last updated
리액터의 동작 모델&원리에 관한 탐구
Last updated
다른 공식 문서나 강의 같은 것들을 보아도 execution model 보다 operator 들을 먼저 소개 및 학습한다. 나도 그렇게 공부를 했지만 점점 execution model 자체에 대한 깊은 이해가 없이는 단지 얄팍한 기술만 알게 되는 느낌이고 공부하면 할 수록 원리에 대한 이해의 필요성이 커지는 것 같다. 그래서 학습을 하다가 뒤에 나온 execution model에 대한 내용을 맨 앞으로 옮겨서 정리하게 되었다.
최근에 회사 프로젝트에서 flatMapSequential()을 사용할 일이 있었다. 더 정확히 표현하자면 flatMapSequential()을 쓰지 않아도 되는 부분이었는데 내가 생각하기엔 속도를 위해서 쓰면 좋겠다고 생각해서 썼던 적이 있다. 그 때 팀원분께서 오버헤드가 발생하니 map으로 쓰는게 좋겠다고 피드백을 주셨는데, 그 부분에 대해서 이야기를 나누다가 보니 내가 지금까지 flatMap 자체에 대해서 이해도가 부족했다는 것을 알게 되었다. 덕분에 완전히 오해하고 있었던 개념을 인지할 수 있었다.
팀원분의 피드백 덕분에 내가 마주한 나의 리액터에 대한 오해와 이번 executioni model은 매우 밀접하게 맞닿아 있다. 결국 정리하자면 나는 리액터의 execution model 에 대해서 이해가 부족한 사람이었던 것이다.
이에 관해 공부를 해보니 어떤 operator 들이 있고, 각 operator 들은 어떤 기능을 하는지에 대한 이해보다 훨씬 더 중요하다는 생각이 들어서 페이지상 순서를 앞으로 배치하게 되었다.
지금 내가 듣는 udemy 강의에서도 이 주제에 대해서 초반에 다루긴 했지만 이 강의가 나에겐 더 도움이 많이 되었다. 결론적으로 요약하자면 Spring WebFlux 가 Spring MVC 에 비해서 더 높은 처리량과 빠른 응답속도를 보여줬다. 하지만 조금 더 디테일하게 들여다 보면 이렇게 단편적으로만 말할 수는 없다는 것을 알 수 있다.
다시 말해, 단순하게 'WebFlux가 MVC보다 무조건 빠릅니다' 라는 말을 하는 것은 틀린 말이라는 것이다. 위 영상에서 그래프와 숫자로 비교해주고 있지만 상황에 따라, 또 작성된 코드에 따라 속도차이는 발생하며 가장 이상적으로 처리를 잘 한 상태에서 트래픽이 일정량 이상일때만 WebFlux가 MVC보다 평균적으로 더 빠른 응답속도를 보여준다고 말할 수 있다.
또 한 가지를 덧붙이자면 그렇다고 WebFlux가 무조건 더 좋은 것도 아닌것이 코드 가독성도 떨어지고 디버깅도 MVC 에 비해서 상대적으로 더 어렵다.
아래에 나오는 모든 이미지의 출처는 위 유투브 영상이다.
Spring MVC는 request per thread 가 원칙이다. 즉, 각 요청에 대해서 스레드풀 내에 있는 하나의 스레드가 이를 전적으로 책임지고 끝까지 로직을 처리하여 응답을 주는 것이다. 위 그림은 이에 대한 설명이다. 브라우저의 요청에 대해서 스레드풀의 6번째 스레드가 이를 받아 처리하는 모습이다. (일반적으로 톰캣의 기본 스레드 설정은 200개 이다.)
위 그림은 첫번째 그림의 Spring MVC Application 내부에서 스레드가 일하는 모습이다. 양쪽으로 검정색 선의 네모가 보이는데 둘은 서버이다. 즉, 좌측의 서버가 우측의 서버에 REST API를 호출하여 응답을 받아 처리하는 모습이다.
그림의 예시는 1번 스레드가 이를 처리하는 중에 어떠한 외부 서버(우측 네모)로 REST API를 요청한 뒤, 응답이 올 때까지 block 상태에 있다가 외부 서버에서 응답이 오자마자 다시 Task3이 실행되는 모습이다.
reactor의 execution model을 이해하기 위해 이 부분에서 유의하여 봐야할 부분은 아래와 같다.
1번 스레드가 외부 서버로 REAT API를 호출한 뒤 block 상태로 '일하지 않고 그냥 대기' 하고 있다는 것이다. 스레드가 block 되어 I/O가 끝날 때 까지 waiting 한다는 것이다. (외부의 응답이 늦는 것은 어쩔 수가 없기에 응답이 올때까지는 마냥 기다릴 것이 아니라 할 수 있는 일을 하면 되는데 그렇게 하지 않고 기다리는 것이 문제인 것이다. 즉, 하드웨어 성능을 더 쥐어짤 수 있는데 자원을 할당받고 로직을 처리하는 실행 단위인 스레드가 다 소진될 여지가 커지니까 이게 문제인 것이다)
thread의 상태가 runnable, waiting, runnable로 자주 바뀐다는 것이 곧 context switching의 발생을 의미한다.
톰캣 기본값 기준 200개의 스레드가 CPU를 할당 받기 위해 경합하면서 오버헤드가 발생한다.(아무래도 CPU의 스케줄링 방식이 무엇이든 받고자하는 주체의 수가 많을 수록 스케줄링 계산을 모두 해줘야하니까 자원을 할당해줄 후보가 많을 수록 확실히 오버헤드가 많을 수 밖에 없는 것 같음)
Spring WebFlux는 Event Loop 방식으로 동작한다. 즉, 사용자들의 요청 및 어플리케이션 내에서 처리해야할 과정들은 모두 event 라는 단위로 event queue에 적재되어 처리된다. Event Loop는 이렇게 적재된 event를 순차적으로 꺼내서 처리하게 된다.
Spring WebFlux는 reactor 와 netty를 기반으로 동작하는데 위 장표에도 나와있다시피 netty의 스레드 풀의 스레드 개수는 코어 * 2 이다.
여기서 위 MVC 방식과 비교하면 두 가지 차이를 인지할 수 있다.
스레드의 수 자체가 적어서 CPU 경합시 발생하는 오버헤드가 상대적으로 적다.
스레드가 블로킹되지 않아서 context switching 으로 인한 오버헤드 비용이 줄어든다.
결국 위 그림과 같이 스레드들이 블로킹 되지 않는 시간적 구간에 다른 일을 처리할 수 있어서 성능을 쥐어 짤 수 있다. 위 MVC 때와 비교하자면 1번 스레드가 Task 1 을 수행하고 블로킹이 된 상태로 무의미하게 대기를 했었는데 WebFlux의 경우에는 그 시간에 다른 일을 처리할 수 있는 것이다.
결국 WebFlux가 MVC에 비해서 일을 할 수 있는 Free한 스레드가 더 많을 가능성이 다고 말할 수 있다. 단순히 스레드 풀의 개수자체는 MVC가 200개이고 WebFlux가 그보다 훨씬 적지만 WebFlux는 위 그림과 같이 논블로킹 방식으로 동작하므로 트래픽이 많아질 수록 이벤트 루프의 메인 스레드가 '이거 처리할 사람?' 하고 물어봤을때 '저요'라고 손들 수 있는 스레드가 많을 가능성이 크다는 것을 의미한다.
반대로 MVC에서는 이때 외부 서버의 응답을 기다리거나, DB로부터 응답을 기다리는 등의 이유로 블로킹에 걸린 스레드들이 많으면 당장 그 순간에는 일을 안하고 있는데 일을 하고 있긴한 상태의 스레드가 많을 수 있고, 결론적으로 요청이 들어온 그 순간에는 정작 일을 처리할 스레드가 없어서 요청이 대기할 가능성이 크다고 할 수 있다.
CPU 코어가 4개라는 가정에서 MVC와 WebFlux를 극단적인 비유를 통해 비교해보자.
상황은 사무실에 직원이 MVC(200명), WebFlux(8명) 이 일하고 있고 프린터가 4대가 있다고 하자. 직원들은 문서를 출력하거나 전화를 받거나 문서를 작성하는 등의 업무를 수행한다.
현재 200명은 놀고 있는 상태다.
문서를 출력하는 업무가 200건이 동시에 들어왔다.
200명 모두에게 1건씩 할당된다.
200명이 모두 동시에 프린터 출력을 시도했다.
아직 한장의 프린트도 완료되기 전에 갑자기 전화 업무가 50건이 들어왔다.
프린터 출력을 기다리는 직원들은 전화를 받을 수 있지만 받지 않는다. 프린트기가 출력해줄 프린트물을 기다리고 있기 때문이다.
전화를 건 사람은 누가 받기를 기다리며 계속 대기한다.
먼저 출력시도 한 순서로 프린트 물이 출력된다. 프린트 물을 받아든 사람은 그제서야 전화를 받기 시작한다.
순차적으로 프린트가 완료된 직원들이 차례차례 대기중인 전화를 받는다.
현재 8명은 놀고 있는 상태다.
문서를 출력하는 업무가 200건이 동시에 들어왔다.
1명이 1건의 문서출력업무를 할당받고 프린트 출력 버튼을 누른다. 그리고 그 프린트물이 아직 프린트되어 나오기 전이지만 작업을 끝낸 작업자는 곧 바로 또 다른 문서출력 업무 1건을 가져가서 출력 버튼을 누른다. 이런 방식으로 200건이 모두 프린터기에 출력 명령이 들어갈때 까지 8명 모두가 이를 순차적으로 1건씩 받아 처리한다.
갑자기 전화 업무가 50건이 들어왔다.
200건의 문서에 대해서 프린트 출력 버튼이 모두 눌러진 상태라면 아직 프린트물이 나오지 않았어도 가장 먼저 여유가 있어서 작업을 할당 받을 수 있는 작업자가 전화를 받는다.
하지만 위 글에서 '동기'에 관해 예시를 들어둔 것중 instant messaging은 개인적으로 '동기'에 넣으면 안된다고 본다. 그 외에 비유는 매우 적절한 것 같아서 링크를 달아둔다.
비유들만 옮기자면 화상채팅, 직접 대면, 전화통화가 '동기'적 cummunication 방식이고 '비동기'적 communication 방식으로는 이메일, Video recording(이걸 누가 요즘..?), Cloud collaboration(매우 좋은 예시인 것 같다), Project management software(이것도 매우 좋은 예시라고 생각한다)와 같은 것들이 있다.
여기서 확실히 짚어야 할 부분은 '비동기'와 '논블로킹'은 다른 개념이라는 것이다. 극단적인 예시로 요청자가 '비동기'통신을 하지만 통신 직후에 아무것도 못하게 하면 '블로킹'이 되는 것이긴 하다는 것을 생각해보면 다른 개념임을 확실히 할 수 있다.
응답이 얼마나 걸리든 요청자 입장에서 응답을 요청한 시점부터 바로 이어서 받느냐, 응답의 시점이 뚝 끊겨서 나중에 받느냐에 따라서 '동기'와 '비동기'가 갈린다.
극단적으로 응답을 하기 위해서 1시간이 걸리는 작업이 있다고 한다면 요청자가 요청 직후에 '그래 준비되면 알려줘' 라고 하고 '나중에 알아서 준비되면 연락이 온다'는 것을 인지하고 있다면 '비동기'라고 볼 수 있고(=callBack), 1시간 내내 응답을 받기까지 대기한다면 결국 요청과 응답이 동기적으로 이뤄진다고 봐야하기 때문에 '동기' 방식으로 봐야한다.
시간이 얼마나 걸리는지가 중요한 것이 아니라 의사소통의 형태가 '동기'와 '비동기'를 가른다.
IBM의 글에서 '비동기', '논블로킹' 모델 하나만 가져오자면 아래와 같다.
블로킹과 논블로킹을 가르는 핵심은 요청자 측에서 요청 직후 '다른 일을 할 수 있는가'의 기준이다. 스레드 입장에서 보면 요청 직후 결과가 어찌되었건 상태가 waiting이 되는 것이 아니라 runnable을 그대로 유지할 수 있어야만 '논블로킹'하다고 할 수 있다.
위 그림은 Spring WebFlux가 동작하는 모습을 보여준다. Task1, Task3 모두 Event로 만들어져서 이벤트 큐에 들어가게 된다. NIO() 를 이용하여 작업처리를 하기 때문에 논블로킹 방식으로 동작이 가능하다.
project reactor는 Reactive Streams() 명세를 따른 라이브러리이기 때문에 비동기, 논블로킹이 특징이다. reactor의 공식 홈페이지()에 가면 대표 특징으로 'fully non-blocking'이라고 잘 써놨다. 각각의 특징에 대해서 다시 한번 의미를 짚어보자.
국어사전을 찾아보면 여기서 '동'은 '같을 동' 을 사용하며 '기'는 '기약할 기'를 사용한다. 잘 정리된 것이 있나 찾아보던 중 동기와 비동기 개념을 프로그래밍에 접목하지 않고, 실제로 협업하는 협업과정에 적용해서 설명한 글()을 찾았는데 매우 흥미롭다. 동기와 비동기라는 개념 자체가 태생이 프로그래밍인 것으로 알고 있었는데, 이걸 보니 그게 아니라 원래 존재했던 개념이었나 싶기도 하다.
이 이슈에 관해서는 잘 정리된 글이 너무 많은데, 개인적으로 이 글()이 시각화해서 개념을 정리를 잘 해둔 것 같아서 링크를 달아둔다. 이 포스팅은 IBM의 글() 을 한글화 해서 정리해둔 것 같은데, 원문이 아무래도 이해하기엔 더 좋을 것 같다.
