Node.js의 이벤트 루프

노드를 사용하는 회사에 가게되어서, 노드를 배우고 있는데...

 

자바스크립트나 노드나 다 처음 배우고 있어서 어려운 것이 많은 거 같다. 특히 이해하기 어려운게 이벤트 루프(Event Loop)였고, 핵심적인 부분인 것 같다고 느꼈다. 노드와 관련된 모든 이야기가 이벤트 루프로 모이는듯한 느낌을 받았기 때문이다. 그래서 이걸 이해한다면 노드의 구성 요소와 동작 방식은 물론이고 우선순위가 나뉘어져있는 비동기작업들을 잘 구분하고 설정할 수 있다고 생각했다. 그런 이유로 이번 글에서 이벤트 루프를 중심으로 노드와 관련된 여러가지 지식들도 함께 정리하면서 공부해볼 생각이다.

 

공부를 하면서 글도 함께 작성하고 있기 때문에, 부정확한 정보가 있을 수도 있다! 그러한 부분들은 실무를 경험하며 차차 수정해나가보겠다.

 

Node.js

기본적으로 노드는 단일 스레드로 동작한다. 딱 하나의 메인 스레드가 모든 것을 처리하는 구조이다. 이는 자바스크립트 언어 자체가 단일 스레드로 동작하는 언어이기 때문인데, 하지만 웹 브라우저를 생각해보면 영상을 보면서 여러 웹 페이지를 열어 탐색할 수 있다. 노드로 이루어진 서버도 동시에 여러 요청을 처리할 수 있다.

 

이는 내부적으로 이벤트 루프라는 것이 동작하고 있기 때문이다. 하지만, 스프링에서처럼 요청부터 응답까지 모든 과정을 멀티 스레드로 동작하는 것이 아니라 노드는 I/O 작업에 대해서만 멀티 스레드로 동작한다는 차이가 있다. 이는 노드의 철학의 근간이 "I/O 작업이 물리적으로 느리고, 작업 완료까지 프로그램이 대기하는건 바보같은 일이다." 라는 말에 있기 때문이다. - Ryan Dahl: Node JS

 

그래서 나노초 단위로 끝나는 CPU 작업에 대해서는 메인 스레드가 처리하고, 이외의 I/O 작업은 모두 libuv 라이브러리를 통해 외부로 위임한다. 이때 libuv는 아주 영리하게 동작하는데, 네트워크 통신 같은 작업은 운영체제의 커널의 비동기 기능을 통해 스레드 낭비없이 처리하고, 파일 시스템 접근이나 무거운 암호화/압축 작업 등과 같이 OS가 비동기로 처리하기 어려운 작업만 내부의 스레드 풀에 있는 다른 스레드에게 맡겨서 메인 스레드가 차단되는 것을 막는다.

https://www.vskills.in/certification/tutorial/node-js-architecture-2/

 

기본적으로 이러한 구조를 가지고 있다. Worker Threads 부분을 제외하면 모든 영역이 메인 스레드 하나로 처리되는 셈이다. 근데 여기서 의문이 들었던건 보통 프로세스 하나에 여러 스레드를 컨텍스트 스위칭 하는데, 노드는 어떻게 메인 스레드 하나로 V8 엔진, Node API를 통한 V8 <-> libuv 바인딩, libuv 실행까지 수행하는지가 궁금했다.

 

이건 코드를 확인하는 것으로 해소했다. 노드에서는 기본적으로 v8 엔진으로 애플리케이션 코드를 수행하고, 애플리케이션 코드 실행이 끝나면 이벤트 루프 수행을 호출하고 libuv로 제어권이 넘어간다. 그럼 제어권을 가진 libuv가 이벤트 루프를 돌면서 작업들을 처리하고, 각 페이즈에 진입할 때 해당 페이즈의 큐에서 콜백을 꺼내 V8에게 실행을 위임한다.

 

이를 node 내 코드로 확인해보면 다음과 같은 순서로 이어진다. 실제 코드를 확인하면서, AI의 도움을 받아 핵심 호출 흐름을 정리해 보았으며 자세한 내용은 공식 node github에서 확인할 수 있다.

main()                                          # node_main.cc
└→ node::Start()                                # node.cc
    └→ StartInternal()
        ├→ InitializeOncePerProcessInternal()   # V8, libuv 초기화
        ├→ NodeMainInstance 생성                 # V8 + libuv 연결
        └→ NodeMainInstance::Run()              # node_main_instance.cc

NodeMainInstance::Run()
├→ LoadEnvironment()                            # app.js 실행 담당
│   └→ StartExecution(env, cb)
│       └→ StartExecution(env, "internal/main/run_main_module")
│           └→ ExecuteBootstrapper("internal/main/run_main_module")
│               └→ CompileAndCall()
│                   ├→ LoadBuiltinSource()      # JS 소스코드 읽기
│                   ├→ LookupAndCompile()       # V8으로 컴파일 (JS → 바이트코드)
│                   └→ fn->Call()               # ← 실제 JS 실행 (app.js)
│                       └→ process, require 등 주입
│
└→ SpinEventLoopInternal()                     # 이벤트 루프 시작
    └→ uv_run()                                # libuv/core.c
        └→ while(hasPendingTasks) {
               uv__run_timers()                # Phase 1: Timers
               uv__run_pending()              # Phase 2: Pending Callbacks
               uv__io_poll()                  # Phase 3: Poll
               uv__run_check()                # Phase 4: Check (setImmediate)
               uv__run_closing_handles()      # Phase 5: Close Callbacks
           }

 

그래서 정리하면 자바스크립트나 타입스크립트로 작성된 서버 코드를 실행하면, 노드는 서버 구성을 위해 필요한 코드들을 실행하고 제어권을 libuv에 넘겨 이벤트 루프를 수행하도록 한다. 사용자의 요청도 결국 네트워크 I/O 작업이기 때문에 이벤트 루프에서 이를 캐치해 v8 엔진에게 수행을 넘겨줄 수 있는 것이다. 즉, node가 서버 사이드 애플리케이션으로 사용될 수 있는 이유에 이벤트 루프가 핵심적인 것을 확인할 수 있었다.

 

하지만 이렇게 I/O를 비동기로 처리한다해도 메인 스레드 하나만으로 이벤트 루프를 수행하는 것은 여러 스레드를 이용하는 자바/스프링보다 요청 처리에 비효율적일 것 같다고 생각했다. 이에 대한 의견도 마찬가지로 Ryan Dahl: Node JS 영상에서 알 수 있었는데, 스레드의 실행이 작업 완료까지 대기하는 상황이 마음에 들지 않았고 컨텍스트 스위칭 비용과 스레드로 인한 메모리 비용이 비싸다고 생각했다고 한다. 또한, 다중 스레드 환경에서의 동시성 문제를 지적했다.

 

그래서 Ryan Dahl은 웹 서버인 Apache와 Nginx를 비교했는데, 영상 속 자료에서 커넥션마다 스레드를 생성하는 Apache 방식보다 Nginx의 이벤트 드리븐이 더 적은 메모리를 사용하면서도 같은 요청을 처리할 수 있는 것을 확인시켜줬다. 또한, 뭔가 그래프를 하나 더 보여줬는데 솔직히 말하면 영상의 화질 때문에 이해하진 못했다.

https://stackoverflow.com/questions/5598495/about-how-much-of-a-memory-footprint-reduction-does-nginx-give-over-apache2

 

그래서 Node.js의 요청 처리 방법으로 Nginx의 이벤트 드리븐 아키텍처에 채택했다. Nginx의 이벤트 드리븐 아키텍처는 Node.js와 유사하다. 마스터 프로세스가 설정 파일이나 워커 프로세스 생성 및 관리를 담당하고 그 아래 워커 프로세스들이 이벤트 루프를 돌면서 논블로킹 I/O 방식으로 동작한다. 워커 프로세스 하나가 정확히 Node.js의 동작 방법이다.

https://natnat1.medium.com/nginx-architecture-c9c93058e8a0

 

Nginx가 이벤트 드리븐으로 Apache를 압도한 것처럼, Node.js도 같은 원리로 동시 요청을 처리한다. 그렇다면 이 이벤트 루프는 정확히 어떻게 동작하는걸까?

 

이벤트 루프

앞서 이벤트 루프가 굉장히 중요한 구성요소 중 하나임을 알게되었다. 그래서 이벤트 루프가 정확히 무엇이고, 어떻게 동작하는지도 공부하면 좋을 것 같다고 생각했다.

 

이벤트 루프는 여러 비동기 작업들을 관리하기 위한 구현체이다. 비동기 작업 종류에 따라 완료된 콜백이 여러 페이즈에 나눠 저장되고, 이벤트 루프가 해당 페이즈에 진입할 때 실행된다. 저장한다는 말은 각 페이즈가 자신만의 큐를 하나씩 가지고 있다는 뜻이다.

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

 

위 그림에서 각 박스가 앞서 말한 '페이즈(phase)'이고, 이벤트 루프가 특정 페이즈에 진입하면 해당 페이즈의 큐에서 콜백을 실행하여 큐가 소진되거나 최대 콜백 수가 실행될 때까지 반복한다. 그 후, 큐가 소진되거나 콜백 한도에 도달하면 이벤트 루프는 다음 단계로 이동하면서 진행되는 방식이다.

 

그리고 이벤트 루프를 한 바퀴 돌았다면, 다시 이벤트 루프를 시작하기 전에 대기 중인 비동기 I/O나 타이머가 있는지 확인한다. 아무것도 남아있지 않다면 프로세스가 종료되고, 남아있다면 다시 pending callbacks 페이즈부터 순회를 시작한다. 실제로 노드 코드#core.c를 확인해보면 다음과 같이 페이즈를 진행하는 것을 확인할 수 있었다.

int uv_run(uv_loop_t* loop, uv_run_mode mode) {
  // 최초 타이머 실행
  if (mode == UV_RUN_DEFAULT && r != 0 && loop->stop_flag == 0) {
    uv__update_time(loop);
    uv__run_timers(loop);
  }
  
  // 이벤트 루프 페이즈 순회
  while (r != 0 && loop->stop_flag == 0) {
    uv__run_pending(loop);
    uv__run_idle(loop);
    uv__run_prepare(loop);

    uv__io_poll(loop, timeout);

    uv__run_check(loop);
    uv__run_closing_handles(loop);

    uv__update_time(loop);
    uv__run_timers(loop);

    r = uv__loop_alive(loop);
    if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)
      break;
  }

  /* The if statement lets gcc compile it to a conditional store. Avoids
   * dirtying a cache line.
   */
  if (loop->stop_flag != 0)
    loop->stop_flag = 0;

  return r;
}

 

보통 이벤트 루프에 대해서 구글 검색을 해보면, timers 페이즈부터 시작한다는 것으로 설명하는 경우가 많다. 이는 위 코드에서 보듯이 최초 타이머 페이즈를 먼저 수행하고 루프에 들어가기 때문에 편의상 timers 페이즈를 가장 상단에 두는 것이다. 하지만 정확히는 진입 전 timers 페이즈를 수행하고 루프에 들어간다.

 

이제 각 페이즈에서 어떤 비동기 작업의 결과를 보관하는지 알아보자.

 

timers phase

해당 페이즈는 setTimeout()과 setInterval()에 의해 예약된 콜백을 실행한다. 보통 타이머를 다음과 같이 원하는 딜레이 시간을 주어 실행하게 된다.

const timeoutScheduled = Date.now();

setTimeout(() => {
	const delay = Date.now() - timeoutScheduled;
	
	console.log(`${delay}ms have passed since I was scheduled`);
}, 100);

 

하지만 여기서 딜레이 시간은 정확한 그 시간이 아니라 제공된 콜백을 실행할 수 있는 임계값을 지정하는 것이다. 임계값은 정확한 실행 시간이 아니라 실행을 위한 최소 대기 시간을 의미한다. 즉, 100ms로 설정한 위 코드는 '적어도 100ms는 기다렸다가 실행해라'라는 의미가 된다.

 

그래서 이를 여러번 실행해보면 항상 같은 시간을 기다리고 실행되지는 않는다. 그래도 지정된 시간이 지나면 가능한 한 빨리 실행되도록 하지만, 운영체제 스케줄링이나 다른 콜백 실행으로 인해 지연될 수 있다. 예를 들어 1초의 임계값을 가진 타임아웃을 예약해두고, 메인 스레드를 강제로 3초간 바쁘게 만드는 다음 예제를 보자.

const start = Date.now();

// 1초(1000ms) 뒤에 실행하라고 예약!
setTimeout(() => {
    console.log(`타이머 실행됨! 지연 시간: ${Date.now() - start}ms`);
}, 1000);

// 메인 스레드를 강제로 3초 동안 바쁘게 만듦
const blockUntil = Date.now() + 3000;
while (Date.now() < blockUntil) {
    // 3초 동안 V8 엔진은 이 루프에 갇혀서 다른 일을 못 함
}

console.log("메인 스레드 작업 끝!");

 

 

결과를 확인해보면 3초가 지난 후에 타이머 콜백 함수가 실행된 것을 볼 수 있다. 또한, Node도 결국 운영체제 위에서 돌아가는 하나의 프로그램이다. 그래서 메인 스레드가 텅 비어있다고 해도 CPU의 컨텍스트 스위칭에 따라 Node에 늦게 할당된다면 그만큼 타이머 실행도 지연된다는 특징을 가진다.

 

좀 더 정확히 이해하기위해 내부 코드를 통해 분석해보자.

int uv_run(uv_loop_t* loop, uv_run_mode mode) {
	// ...
	uv__update_time(loop);
	uv__run_timers(loop);
	// ...
}

 

아까 이벤트 루프 코드에서 확인할 수 있는데, timers 페이즈는 항상 `uv__update_time`이라는 메서드와 함께 수행된다. `uv__update_time`은 이벤트 루프의 시간을 업데이트 하는 메서드로 timers 페이즈가 만료된 시간을 검증하는데 기준이 되는 시간으로 활용한다.

 

`uv__run_timers` 메서드 내부를 확인하면,

void uv__run_timers(uv_loop_t* loop) {
  struct heap_node* heap_node;
  uv_timer_t* handle;
  struct uv__queue* queue_node;
  struct uv__queue ready_queue;

  uv__queue_init(&ready_queue);

  for (;;) {
    heap_node = heap_min(timer_heap(loop));
    if (heap_node == NULL)
      break;

    handle = container_of(heap_node, uv_timer_t, node.heap);
    if (handle->timeout > loop->time)
      break;

    uv_timer_stop(handle);
    uv__queue_insert_tail(&ready_queue, &handle->node.queue);
  }

  while (!uv__queue_empty(&ready_queue)) {
    // ... 콜백 함수 실행
    handle->timer_cb(handle);
  }
}

 

먼저 heap_min을 통해 힙에서 데이터를 꺼내오는 것을 알 수 있다. 이는 timers 페이즈가 사실은 큐가 아니라 최소 힙(min heap) 을 통해 타임아웃 관련 정보를 보관하고 있기 때문이다. 이 정보들에는 만료 시간과 콜백 함수가 대표적으로 포함된다. 그래서 만료 시간을 기준으로 최소 힙에 저장하는 것이다.

 

만료 시간을 기준으로 최소 힙에 저장했기에 힙에서 데이터를 꺼냈을 때 해당 데이터의 만료 시간만으로 종료 조건을 판단할 수 있다.

int uv_timer_stop(uv_timer_t* handle) {
  if (uv__is_active(handle)) {
    heap_remove(timer_heap(handle->loop),
                (struct heap_node*) &handle->node.heap,
                timer_less_than);
    uv__handle_stop(handle);
  } else {
    uv__queue_remove(&handle->node.queue);
  }

  // ...
  return 0;
}

 

만약 최소 힙에서 꺼낸 데이터의 만료 시간이 아직 도달하지 않았다면, 이후 존재하는 데이터들도 아직 도달하지 않았을테니 타이머 페이즈를 종료한다. 하지만, 만료 시간에 도달했다면 해당 데이터를 힙에서 제거하고 콜백 함수를 실행한다. 그 후 다시 최소 힙에서 데이터를 꺼내 만료 시간이 적절하지 않거나, 힙이 빌 때까지 반복하는 것이다. 하지만 timers 페이즈도 콜백 한도에 영향을 받으므로 다음 데이터가 만료 시간이 지났다해도 다음 루프까지 지연될 수 있다.

 

정리하면,

• 노드에서 타이머는 임계값을 설정하는 것이며, 정확한 시간을 보장하지 않는다.
• 타이머 콜백 함수는 큐가 아닌 최소 힙에 저장하여 관리한다.

 

pending callbacks

이 페이즈는 애플리케이션 레벨의 일반적인 I/O 콜백보다는 시스템 레벨의 동작 완료 콜백이 실행되는 곳이다. 예를 들어, TCP 소켓이 연결을 시도하다가 ECONNREFUSED를 받았을 때, 일부 리눅스 시스템에서는 이 에러를 즉시 보고하지 않고 연기(pending)했다가 이 페이즈에서 처리한다.

 

일반적인 웹 서버 로직을 작성할 때는 직접 마주칠 일이 거의 없는 내부적인 큐이므로, "운영체제 시스템 레벨의 에러나 연기된 콜백들을 처리하는 단계" 정도로 알고있으면 될 것 같다.

 

idle, prepare phase

Node의 내부적으로만 사용된다. 공식 문서에도 딱히 설명이 없다.

 

poll phase

poll phase에서 메인 스레드는 두 가지 임무를 수행한다.

1. 계산: 새로운 I/O 이벤트를 위해 운영체제 커널에게 얼만큼 대기를 요청할(Timeout) 것인가?
2. 실행: poll 큐에 있는 이벤트 실행

 

계산

이는 poll phase의 큐가 비어있을 때 발생한다. 비어있으면 할 일이 없다는 뜻이므로 두 가지로 분기하게 되는데, setImmediate()로 예약된 코드가 있다면 더 이상 기다리지 않고 poll phase를 종료 후 다음 단계인 check phase로 넘어간다. 하지만, 예약된 코드가 없다면 새로운 I/O 이벤트가 올 때까지 무한히 대기한다.

 

그렇다고 마냥 무작정 대기하지는 않는다. 왜냐하면 예약된 타이머의 만료 시간이 되었을 수 있기 때문이다. 그래서 poll 큐가 비어서 대기해야 할 때, timers phase의 최소 힙을 먼저 확인하고 타이머가 있다면 해당 만료 시간을 기준으로 wait timeout을 설정한다.

 

그러면 poll phase는 운영체제 커널에게 새로운 I/O 요청이 오거나, 설정한 타임아웃 시간이 지나면 깨워달라고 위임한다. 만약 여기서 타이머가 만료되면 커널은 다시 메인 스레드를 깨우고, poll phase 종료 후 나머지 phase를 마저 수행한 후에 timers phase에서 타이머 콜백 함수를 수행한다.

int uv_run(uv_loop_t* loop, uv_run_mode mode) {
  // ...

  while (r != 0 && loop->stop_flag == 0) {
    // ...

    timeout = 0;
    if ((mode == UV_RUN_ONCE && can_sleep) || mode == UV_RUN_DEFAULT)
      timeout = uv__backend_timeout(loop);

	// ...

    uv__io_poll(loop, timeout);
    
    // ...
  }
}

static int uv__backend_timeout(const uv_loop_t* loop) {
  if (loop->stop_flag == 0 // 루프 종료 요청 없음 
	  && (uv__has_active_handles(loop) || uv__has_active_reqs(loop)) // 처리할 작업이 남아있음 
	  && uv__queue_empty(&loop->pending_queue) // pending 큐가 비어있음 
	  && uv__queue_empty(&loop->idle_handles) // idle 핸들 없음 
	  && (loop->flags & UV_LOOP_REAP_CHILDREN) == 0 // 종료된 자식 프로세스 없음 
	  && loop->closing_handles == NULL // 닫을 핸들 없음
	  )
    return uv__next_timeout(loop);
  return 0;
}

int uv__next_timeout(const uv_loop_t* loop) {
  const struct heap_node* heap_node;
  const uv_timer_t* handle;
  uint64_t diff;

  heap_node = heap_min(timer_heap(loop));
  if (heap_node == NULL)
    return -1; /* block indefinitely */

  handle = container_of(heap_node, uv_timer_t, node.heap);
  if (handle->timeout <= loop->time)
    return 0;

  diff = handle->timeout - loop->time;
  if (diff > INT_MAX)
    diff = INT_MAX;

  return (int) diff;
}

 

코드를 보면, 여러 조건을 검사하고 타이머의 최소 힙을 기준으로 timeout 값을 설정한 후에 poll phase를 호출하는 것을 알 수 있다.

 

실행

실행은 단순히 큐가 비어있지 않은 경우이므로 메인 스레드는 큐에 쌓인 작업들을 순서대로 꺼내 처리한다. 이때 처리되는 작업들에는 흔히 아는 'HTTP 요청 접수', 'DB 쿼리 결과 반환', '파일 읽기 완료' 등 백엔드 서버가 처리하는 대부분의 비동기 I/O 결과물들이다.

 

그러한 비동기 I/O 중 파일 I/O처럼 OS가 비동기로 처리하기 어려운 작업은 worker thread(libuv Thread Pool)가 처리하고, 완료되면 메인 스레드에 신호를 보내 콜백을 실행한다.

 

Linux 기준으로 좀 더 살펴보기

• 코드를 분석하긴 했으나, 부정확한 정보일 수 있음.
• 코드를 먼저 정리한 결과는 다음과 같다.

[파일 I/O 흐름]

1. JS 코드 실행
   fs.readFile('file.txt', callback)
       └→ uv__work_submit()
            └→ 글로벌 wq에 uv__work 삽입
            └→ uv_cond_signal() → idle worker thread 깨움
            # deps/uv/src/threadpool.c > uv__work_submit()

2. worker thread
   while (uv__queue_empty(&wq)) uv_cond_wait()  // 글로벌 wq 대기
       └→ q = uv__queue_head(&wq)               // 작업 꺼냄
       └→ w = uv__queue_data(q, struct uv__work, wq)
       └→ w->work(w)                            // 파일 읽기 실행 (blocking)
       └→ uv__queue_insert_tail(&w->loop->wq, &w->wq)  // loop->wq에 결과 삽입
       └→ uv_async_send(&w->loop->wq_async)     // 메인 스레드에 신호
       # deps/uv/src/threadpool.c > worker()

3. uv_async_send()
       └→ uv__async_send()
            └→ Linux:  write(eventfd, &val, 8)  // eventfd에 write
            └→ 그 외:  write(async_wfd, "", 1)  // pipe에 write
                └→ 메인 스레드 epoll_wait 깨어남
       # deps/uv/src/unix/async.c > uv_async_send(), uv__async_send()

4. 메인 스레드
   wq_async 핸들러 호출
       └→ uv__queue_move(&loop->wq, &wq)        // loop->wq를 로컬로 이동
       └→ while (!uv__queue_empty(&wq))
            └→ w->done(w, err)                  // JS 콜백 실행
       # deps/uv/src/threadpool.c > uv__work_done()


[네트워크 I/O 흐름]

1. JS 코드 실행
   http.createServer().listen(3000)
       └→ watcher_queue에 FD + 콜백 등록
       # deps/uv/src/unix/core.c

2. poll phase 진입
       └→ watcher_queue 순회
            └→ epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ...)  // 커널에 FD 감시 등록
       └→ epoll_wait(epfd, events, timeout)             // 대기
       # deps/uv/src/unix/linux/epoll.c > uv__io_poll()

3. 커널: FD 이벤트 감지
       └→ epoll_wait 반환
       └→ pe->fd로 loop->watchers[fd] 찾기
       └→ w->cb(loop, w, pe->events)                   // JS 콜백 실행
       # deps/uv/src/unix/linux/epoll.c > uv__io_poll()


[초기화]

heap_init(&loop->timer_heap)         // timers 최소 힙
uv__queue_init(&loop->wq)            // 파일 I/O 완료 큐
uv__queue_init(&loop->watcher_queue) // 네트워크 I/O 감시 큐
uv__queue_init(&loop->pending_queue) // pending callbacks 큐
uv_async_init(loop, &loop->wq_async, uv__work_done)  // worker 완료 핸들러 등록
# deps/uv/src/unix/core.c > uv_loop_init()

 

여기서 poll phase는 wq(work queue)와 watcher_queue를 활용한다. 여기서 네트워크를 타느냐 타지 않느냐에 따라서 사용되는 큐와 메커니즘이 다르다. wq의 경우에는 worker thread(libuv Thread Pool)를 이용한 작업의 결과가 담기는 큐이다. 그래서 파일 읽기처럼 소켓의 감시(epoll_ctl)로 처리되지 않는 작업의 경우에 worker thread가 이를 처리하고 해당 큐에 콜백 함수를 삽입한다.

 

watcher_queue는 소켓을 통해 네트워크를 타고 '어떤 파일 디스크립터(File Descriptor)의 이벤트를 감시해야 하는지'에 대한 등록 요청이 담긴다. poll phase 진입 시 이 큐를 순회하며 커널에 감시 등록(epoll_ctl)을 요청하고, 이후 epoll_wait으로 대기하다가 커널이 이벤트를 감지하면 콜백을 실행한다.

 

실제로 큐가 비어있지 않은 경우란 wq에 있는 작업과 watcher_queue로 감시를 요청한 epoll이 이벤트를 감지했을 때를 의미하는 것이다.

 

네트워크 I/O와 watcher_queue

watcher_queue에는 소켓을 통해 네트워크를 타고 '어떤 파일 디스크립터(File Descriptor)의 이벤트를 감시해야 하는지'에 대한 등록 요청이 임시로 담긴다.

 

간단하게 예를 들어 DB에 쿼리를 수행하는 비동기 요청을 보냈다고 하자. 그러면 해당 DB와 통신을 담당하는 네트워크 소켓(파일 디스크립터)의 이벤트를 감시하기 위해 이와 관련된 정보들이 watcher_queue에 등록된다.

 

그 후 poll phase에 진입하여 poll 큐가 비어있을 때, 메인 스레드는 대기 직전에 watcher_queue에 담긴 정보들을 꺼내 운영체제에게 해당 소켓들의 상태 변화를 감지(epoll_ctl)해달라고 요청한다. 이후 앞서 계산 단계에서 설정한 timeout만큼 대기하다가 커널이 DB로부터 데이터가 도착했다는 신호를 주면, 메인 스레드는 해당 이벤트와 매핑된 콜백 함수를 V8 엔진으로 곧장 실행하는 흐름이다.

 

파일 I/O와 wq(work queue)

반면에 파일 읽기와 같이 운영체제의 소켓으로 비동기 처리가 어려운 작업은 worker thread(libuv Thread Pool)를 이용한다. 다음 예시를 보자.

const fs = require('fs');

fs.readFile('any-file.txt', () => {
  setTimeout(() => {
    console.log('timeout');
  }, 0);

  setImmediate(() => {
    console.log('immediate');
  });
});
// 해당 코드의 실행 결과는
/*
immediate
timeout
*/


/*
setTimeout(() => {
  console.log('timeout');
}, 0);

setImmediate(() => {
  console.log('immediate');
});

해당 코드의 실행결과는
timeout
immediate

immediate
timeout

둘 중 어느 것이 나올지 확신할 수 없다.
setTimeout(..., 0);은 사실 0ms가 아니라 노드에서 정한 최소값인 1ms로 설정되기 때문이다.
그래서 노드가 시작되면서 두 메서드를 실행하고 이벤트 루프에 들어간다. 하지만 가장 처음 timers phase를 검사했을 때 1ms가 지나지 않은 상황이면 빠르게 다음 phase로 넘어가는 과정을 거쳐 check phase에 도달하여 immediate가 먼저 출력될 수도 있고,
혹은 지연으로 인해 timers phase에서 1ms가 지난 상황이라 timeout이 먼저 출력될 수도 있다.
*/

 

해당 코드를 실행하면 fs.readFile 구문을 읽고 worker thread(libuv Thread Pool)에게 해당 작업을 위임한다. 그리고 poll phase에 진입하면 파일 읽기가 끝나는 동안 대기 상태에 들어간다. (만약 예약된 타이머가 있었다면 타이머 만료 시간까지만 대기한다.)

 

이때 노드는 내부적으로 이벤트 루프와 worker thread끼리 통신할 수 있는 파이프(async_wfd)를 열어두고 감시하고 있다. 시간이 지나고 worker thread에서 해당 작업을 모두 처리하고, 작업 결과와 콜백 함수를 wq에 삽입하고 내부 파이프를 통해 메인 스레드에게 신호를 보낸다. 그러면 비로소 메인 스레드는 해당 큐(wq)에서 작업을 꺼내 콜백 함수를 수행하는 흐름이다.

uv__queue_insert_tail(&w->loop->wq, &w->wq);
uv_async_send(&w->loop->wq_async);

 

이렇게 다른 큐로 동작하는 이유는 리눅스 자체에서 파일에 대한 epoll을 지원하고 있지 않기 때문이다. 그래서 wq라는 큐를 통해 작업을 처리한다. 하지만, 윈도우의 경우에는 리눅스처럼 watcher_queue, wq 같은 개념이 없다. 이는 IOCP(I/O completion Port)라는 비동기 I/O 커널 모델을 제공하고 있기 때문이다. 그냥 간단히 운영체제 자체에서 다 처리해주는 흐름이다. 대부분 리눅스, 맥 기반으로 개발, 운영하게 되니 윈도우는 따로 코드를 파보거나 하진 않았다.

 

정리하면,

• 큐에 데이터가 있을 때는 콜백 함수를 순서대로 꺼내 메인 스레드에서 처리한다.
• 큐가 비어있을 때는
  • watcher_queue에 쌓여있던 파일 디스크립터를 꺼내 커널에 감시를 등록한다.
  • 다음 phase에서 처리할 작업이 없다면, timer phase의 타이머 기준으로 timeout을 설정하여 대기를 요청한다.
  • 다음 phase에서 처리할 작업이 있다면 바로 다음 phase로 넘어간다.
  • 둘 다 없다면 새로운 I/O 이벤트가 들어올 때까지 무한정 대기한다.

 

check phase

해당 페이즈에서는 다른 작업은 일절 없이, 오직 setImmediate()로 등록한 콜백 함수들만 처리하는 전용 공간이다. 딱히 설명할 내용이 없다.

 

close callbacks phase

socket.on('close', cb)와 같이 close, destory 이벤트 타입 콜백 처리

 

여기까지가 사실상 이벤트 루프 페이즈의 끝이다. 하지만 이벤트 루프의 일부는 아니지만 노드의 루프 과정에서 중요한 역할을 하는 친구가 있는데 바로 nextTickQueue, microTaskQueue이다.

 

nextTickQueue, microTaskQueue

process.nextTick() 의 콜백들이 저장되는 nextTickQueue와 Promise, queueMicrotask() 등의 콜백이 저장되는 microTaskQueue는 이벤트 루프의 일부는 아니다. 하지만, 이벤트 루프의 페이즈에서 현재 실행 중인 작업(자바스크립트 코드)이 끝난 직후에 가장 우선적으로 확인되고 실행되는 큐이다.

 

그래서 두 큐는 libuv가 아니라 Node.js에 포함되는 부분이다. 두 개의 큐 모두 작업 후 실행된다는 특징을 가지고 있지만, 둘 사이에도 우선순위가 존재한다. 1순위는 nextTickQueue이고 2순위는 microTaskQueue이다.

 

좀 더, 자세하게 말하자면 페이즈에서 콜백 함수를 실행할 때마다 두 큐에 들어있는 작업이 실행되고 원래 페이즈의 다음 작업을 수행한다.

 

해당 그림으로 요약이 가능할 거 같다. Node.js 내부인 C/C++에서 자바스크립트 콜백을 수행하고, 그 콜백이 끝나서 다시 Node.js인 C/C++로 돌아가는 경계에서 nextTick을 확인하고 두 큐가 모두 비어질때까지 남은 콜백을 실행한다.

 

node v11 이전에는 페이즈 사이에 있는 저 '틱(Tick)' 즉, 각 페이즈를 넘어가는 그 사이에 nextTick을 확인하고 두 큐가 빌때까지 수행하는 방식으로 동작했지만 브라우저와의 호환성을 위해 node v11부터는 콜백 실행 직후로 변경되었다고 한다. - New Changes to the Timers and Microtasks in Node v11.0.0 ( and above), MacroTask and MicroTask execution order

 

여기서 주의할 점은 nextTickQueue, microTaskQueue 모두 빌 때까지 수행을 하기 때문에 재귀적인 process.nextTick() 호출로 인해 I/O 기아상태에 빠질 수 있어 poll phase로 도달하지 못할 수 있다.

 

왜 필요한걸까?

공식 문서에서 해당 기능이 Node.js에 포함되어야 하는 이유를 설명해주었다. 이는 일부 API가 반드시 비동기적이어야 한다는 설계 철학 때문이라고 한다. 이게 잠재적인 문제를 초래하는 상황으로 다음 코드를 제시했다.

let bar = null;

// this has an asynchronous signature, but calls callback synchronously
function someAsyncApiCall(callback) {
  callback();
}

// the callback is called before `someAsyncApiCall` completes.
someAsyncApiCall(() => {
  // since someAsyncApiCall hasn't completed, bar hasn't been assigned any value
  console.log('bar', bar); // null
});

bar = 1;

 

해당 코드에서 사용자가 someAsyncApiCall() 메서드를 호출할 때 비동기를 기대하지만, 실제로는 동기적으로 호출된다. 왜냐하면 someAsyncApiCall()메서드 호출 구문에서 콜백을 등록하지만, 내부에서 그대로 callback()을 호출하기 때문에 콜스택 자체가 someAsyncApiCall() - callback() 순으로 등록되고 호출된다. 그래서 bar = 1; 코드에 접근하기 전에 이미 bar를 참조하여 콘솔에 출력하기에 예측하지 못한 예외 상황이 발생한다.

 

이러한 상황을 방지하기 위해서 다음과 같이 코드를 작성해야 한다.

let bar = null;

function someAsyncApiCall(callback) {
  process.nextTick(callback);
}

someAsyncApiCall(() => {
  console.log('bar', bar); // 1
});

bar = 1;

 

process.nextTick()에 콜백을 넣어, 해당 자바 스크립트의 실행이 모두 끝난 후에 callback이 실행되는 것을 보장할 수 있고, 출력 결과 또한 bar = 1; 이후이기에 1이 출력됨을 확인할 수 있다.

 

근데 솔직히 이 예제만으로는 왜 사용해야 하는지 이해하기 어려웠다. 더군다나 노드로 개발을 해보지도 않아서 더 그랬던 거 같다. 그래서 AI를 활용하여 해당 기능이 필요한 실무적인 이유에 대해서 물어봤다. 그러자 2개의 예제를 통해 해당 기능의 존재 이유에 대해서 설명해주었다.

 

캐시 사용에 대한 문제

유저의 정보를 가져오는 getUser()라는 함수를 만들었다고 가정해보자.

function getUser(id, callback) {
  if (cache[id]) {
    callback(cache[id]);
  } else {
    fetchFromDB(id, callback);
  }
}

 

처음 요청에는 데이터베이스에서 유저 정보를 가져와야 하니 비동기 처리로 시간이 걸린다. 하지만 한 번 가져온 유저 정보에 대해서는 메모리(캐시)에 저장해두고, 다음번 요청 때는 DB 접근없이 캐시에서 동기적으로 즉시 꺼낸다.

 

그리고나서 클라이언트 코드에서 데이터를 가져오는 동안 로딩 상태를 표현하기 위해 isLoading이라는 상태 변수로 이를 사용한다고 해보자.

let isLoading = true; // 1. 로딩 시작

getUser(1, (data) => {
  console.log('데이터 도착:', data);
  isLoading = false; // 3. 데이터가 오면 로딩 끝!
});

// 2. (개발자의 의도: 함수 호출 직후에 로딩 상태를 확실히 켜둠)
isLoading = true;

 

첫 번째 호출 시에는 DB에서 데이터를 가져오는데 시간이 걸리므로 코드는 아래로 쭉 내려가서 isLoading = true; 구문이 먼저 실행된다. 나중에 DB에서 데이터가 오면 콜백이 실행되어 isLoading = false; 구문이 실행되면서 로딩 끝나며 예상대로 흘러간다.

 

하지만 두 번째 호출부터는 조금 이상하게 동작하는데, 두 번째 호출부터는 캐시에 데이터가 존재하니 곧바로 콜백 함수를 호출한다. 그래서 isLoading = false; 구문이 실행되면서 로딩이 끝난다. 하지만 곧바로 getUser() 메서드 이후 isLoading = true;가 실행되면서 다시 로딩 상태로 들어가는 문제가 생긴다.

 

그래서 위의 코드에서 캐시를 통해 데이터를 가져오더라도 콜백의 실행을 뒤로 미루어야 한다. 이때 process.nextTick()을 활용하여 다음과 같이 해결할 수 있다.

function getUser(id, callback) {
  if (cache[id]) {
    process.nextTick(() => callback(cache[id]));
  } else {
    fetchFromDB(id, callback);
  }
}

 

이벤트 리스너 문제

두 번째 예제는 8080 포트로 서버를 열고(listen), 서버가 준비되었다는 이벤트(listening)를 감지하는 코드이다.

const server = net.createServer(() => {}).listen(8080);

server.on('listening', () => {});

 

listen(8080)을 호출하면 Node.js 내부적으로 포트 바인딩 작업이 즉시, 동기적으로 완료된다. 만약 포트가 바인딩되자마자 서버가 준비되었다라는 'listening' 이벤트를 그 즉시(동기적으로) 터뜨려 버린다면 어떻게 될까?

 

컴퓨터는 아직 다음 줄인 server.on(...) 코드를 읽기도 전이다. 즉, 이벤트를 받을 리스너가 아직 장착되지도 않았는데 이벤트가 먼저 발사되어 허공으로 증발해 무시되는 문제가 발생한다.

 

이를 해결하기 위해 Node.js 개발자들은 내부적으로 포트 바인딩은 즉시 수행하되, "이벤트를 터뜨리는 작업(emit)"만 process.nextTick()으로 감싸서 뒤로 미뤄두었다. 덕분에 사용자가 작성한 스크립트가 끝까지 모두 실행되어 수신기(.on)가 무사히 장착될 수 있는 시간을 벌어주며, 이후에 안전하게 이벤트 리스너가 동작할 수 있도록 보장해 준다.

 

이외에도 많은 예제가 있겠지만, 노드로 직접 개발까지 해본 상태는 아니라서 다른 예제를 담기엔 어려웠다. 실무 경험이 쌓이면 이 또한 추가해볼 수 있을 것 같다.

 

그리고 노드 공식문서에서는 웬만하면 모든 상황에서 setImmediate()를 사용하는 것을 권장한다고 한다. 그게 개발자들이 이해하기 더 쉽기 때문이라고 한다. 또한, 재밌는건 process.nextTick()는 콜백 함수 이후 곧장 실행되고, setImmediate()는 check phase에 이르러서야 실행되므로 둘의 이름을 바꿔야 하는게 맞지만 바꾸는 순간 수백만개의 npm 패키지가 장애를 일으키니 그대로 두는 것이라고 한다.

 

결론

 

노드의 전체 흐름을 정리하면 그림과 같다.

 

Node.js는 V8이 앱 코드를 실행한 뒤 제어권을 libuv에 넘겨 이벤트 루프를 시작한다. 루프는 timers → pending callbacks → idle/prepare → poll → check → close callbacks 순으로 페이즈를 순회하며, 각 콜백 실행 직후마다 nextTickQueue와 microTaskQueue를 우선 소진한다. I/O는 네트워크의 경우 OS 커널(epoll)이, 파일 시스템은 libuv Thread Pool이 담당하고, 완료 신호를 메인 스레드에 보내 poll 페이즈에서 콜백을 실행한다.

 

여기까지가 Node.js의 이벤트 루프를 공부하며 정리한 내용이다. 비동기 I/O에 강력한 이유는 위의 이벤트 루프가 기반을 확실히 잡고 있기 때문이다. 그래서 Node.js 특성상 I/O 작업만 비동기로 처리하므로 CPU Bound한 로직에 대해서는 비효율적으로 동작한다.

 

내부 C/C++ 구조까지 파고들다 보니 Node.js가 왜 이렇게 설계되었는지, 그 철학적 이유를 직접 확인할 수 있었다. 단순히 "노드는 싱글 스레드다.", "비동기라서 빠르다"는 말이 libuv의 epoll, Thread Pool, 이벤트 루프 페이즈 설계 전반에 걸쳐 어떻게 구현되어 있는지 이해하고 나니 더 명확하게 보인다. 이제는 경험으로 좀 채워볼 차례인 것 같다.