[Node.js] 스레드와 Event Loop

#Javascript

Node.js 환경에 대해서 이야기하거나 평가할 때 자주 거론되는 주제 중 하나가 스레드의 활용성이다.

흔히 Node 환경을 가리켜서 싱글스레드 환경의 런타임이라고 말하곤 한다.
근데 사실 또 멀티코어 환경을 아예 활용하지 못하는 것도 아니다. 정확히 말하면 I/O 동작에 대해서만 멀티스레드 활용을 보장할 수 있다.

싱글 스레드?

Node.js는 C/C++, Java, C# 같은 기성 언어들과 다르게 스레드를 직접 제어하지 못한다.
네이티브 스레드나 경량 스레드를 호출해서 직접 멀티코어를 쥐어짜 CPU 집약적인 연산을 효율적으로 해낼 수는 없다는 말이다.

Promise 같은 비동기 단위를 통해 동시성을 구현할 수는 있지만, 멀티스레드와 같은 병렬성을 담보하지는 못한다.
그냥 tick 기반으로 시분할 처리만을 수행하는 것이기 때문이다.

이런 부분에서는 파이썬, 루비와 비스무리한 싱글스레드 언어라고 할 수도 있다.

Event Loop!

하지만 Node.js는 이벤트 루프라는 매커니즘을 통해 I/O 작업을 효율화한다.
I/O 집약적인 환경에서는 멀티스레드를 충분히 활용한다고 할 수 있다.

https://www.geeksforgeeks.org/node-js-event-loop/
Node.js는 내부적으로 libuv라는 병렬처리 라이브러리를 사용하는데, 이걸 통해 스레드풀을 구성하고 I/O 작업을 다중화한다.
그리고 libuv는 또 내부적으로 epoll(Linux), kqueue(Mac), IOCP(Windows) 같은 커널 수준의 네트워킹 매커니즘을 사용해서 커널 스레드를 활용한다.

방식을 간략히 정리하면 이렇다.

File I/O나 Network I/O 같은 작업이 발생하면, 런타임은 그 요청을 이벤트 큐에 넣는다.
이벤트 루프는 이벤트 큐에 작업이 들어오면 스레드풀을 활용해 작업을 처리한다.
스레드상에서 작업이 완료되면 이벤트루프는 그 결과를 이벤트 큐를 통해 Javascript 측에 응답한다.

이런 구조 덕분에 서버 환경에서도 그럭저럭 나쁘지 않은 퍼포먼스를 보여줄 수 있는 것이다.
연산 성능이 구리긴 한데, 어차피 서버 구조는 네트워크 I/O가 대부분이고, 대부분의 무거운 일은 DB가 하기 때문이다.
좀 특수한 영역으로 가면 말이 달라질 수도 있지만, 대부분의 스타트업 수준에서 요구하는 기능 명세에서는 성능이 그다지 부족하진 않다.

조금 더 들어가보면, 이벤트루프의 각 루프 스텝은 이런 식으로 구성된다.

https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick

timer: 일단 타이머 관련 작업을 확인해서 먼저 처리한다. setTimeout이나 SetInterval로 예약한 함수가 이에 해당된다.
pending callbacks: 이전 루프에서 보류된 콜백을 실행한다.
idle, prepare: 이건 몰라도 된다. 내부적으로 GC를 위한 확인이나 잡다한 내부동작을 위해 존재한다.
poll: 새로운 I/O 이벤트를 받고 처리한다. readFile 같은 함수가 사용되면 그걸 받아주는 것이다. 사실 이게 점유율의 99% 정도는 된다.
check: 이벤트 큐에 추가된 모든 setImmediate() 콜백을 처리한다.
close callbacks: "소켓 연결 닫기" 같은 정리 작업에 대한 처리를 수행한다.

무한루프 뺑글뺑글 돌면서 저 스텝들을 계속 반복하는 것이다.
그리고 Event Loop 자체는 메인 스레드 위에서 돈다.

자바스크립트로 악질적인 문제를 낸다면 단골메뉴로 나오는 소재다.
원리를 잘 알면 더럽고 비직관적인 코드를 짜기 좋다.

이벤트 루프의 코드는 여기서 볼 수 있다.
https://github.com/nodejs/node/blob/main/deps/uv/src/unix/core.c#L378-#L417

최적화 포인트: setImmediate

setImmediate는 특수한 최적화 포인트가 필요할 때 사용되는 특수한 함수 중 하나다.

위에 언급했듯이 setImmediate는 이벤트 루프 스텝 중 poll 다음으로 처리된다.
거의 마지막 부분에 실행되는 셈인데, 이걸 이용해서 현재 자신이 처리하는 작업의 우선순위를 뒤로 미룰 수 있다는 것이다. 리소스를 양보하는 것이다.

그래서 뭔가 오랫동안 CPU를 잡아먹는 무거운 연산이 있는 경우에는 setImmediate로 띄워서 다른 더 중요한 I/O 작업이 우선으로 처리되게끔 유도하곤 한다.

최적화 포인트: Event Loop Lag

Event Loop은 위에서 언급했듯 주기적으로 메인 스레드를 점유하여 대기 중인 작업들을 처리한다.
이때, 메인 스레드가 다른 작업으로 인해 점유되어 Event Loop가 대기하는 시간이 길어지는 것을 Event Loop Lag이라고 한다.
I/O가 이벤트루프를 통해 비동기로 돈다고는 했지만, 이벤트루프 자체가 동기 코드에 의해서 블럭될 수 있는 구조로 되어있기 때문에 발생하는 문제다.

아무튼 Lag이 높다면 특정한 작업이 메인 스레드를 오래 잡고 있다는 것으로, Node.js의 Event Loop 구조를 이상적으로 활용하고 있지 못하다는 뜻이 된다.

1. Lag 측정법

Lag 측정용으로 제공되는 Node.js 전용 도구들이 존재한다.
돈내고 쓸거라면 New Relic, Appdynamics, Dynatrace 같은 옵션이 있고, 오픈소스 버전으로는 이런게 있다.
https://www.npmjs.com/package/nodejs-dashboard

2. Lag 개선

과도한 Lag을 개선하는 것에는 몇가지 옵션이 존재한다.

동기 코드를 최대한 다 비동기 코드로 전환한다.
worker_threads API 사용
C++로 네이티브 애드온 짜서 박기
child_process 사용

필요와 상황에 따라서 신중하게 선택하면 된다.

참조
https://medium.com/nodejsmadeeasy/nodejs-event-loop-lag-5d5928fd03c

최적화 포인트: Event Loop Utilization

Event Loop Utilization은 Event Loop가 얼마나 바쁘게 작업을 하고 있는지 나타내는 최적화용 수치다.

일반적으로 0과 1 사이의 값을 갖는데, 1에 가까울 수록 Event Loop가 쉬는 시간 없이 항상 어떤 작업을 처리하고 있다는 것이다.
만약 서버가 이미 Max RPS에 도달해서 더 이상의 트래픽을 받지 못하고 있는데, Event Loop Utilization이 1보다 낮다면 Loop를 충분히 활용하지 못하고 있다는 것이다.

Event Loop Utilization는 Node.js에서 제공하는 perf_hooks라는 API를 활용하면 측정할 수 있다.
https://nodejs.org/api/perf_hooks.html

참조
https://blog.platformatic.dev/the-nodejs-event-loop

참조
https://nodesource.com/blog/event-loop-utilization-nodejs/
https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick
https://github.com/libuv/libuv
https://stackoverflow.com/questions/63770952/nodejs-setimmediate-function-realtime-usecase-and-example
https://www.korecmblog.com/blog/node-js-event-loop