💻Node.js의 논 블로킹 IO, 싱글스레드, 이벤트 루프

💻Node.js의 논 블로킹 IO, 싱글스레드, 이벤트 루프

Block IO vs Non-Block IO & Sync vs Async에 대한 설명은 여기를 참고해주세요.

Node.js의 모든 I/O 메서드는 논블로킹인 비동기 방식을 제공하고 콜백 함수를 받는다. 일부 메서드는 같은 작업을 하는 블로킹 메서드도 가지는데 이름 마지막에 Sync가 붙는다.

Node.js의 non-blocking I/O

Node.js에서의 논블로킹 I/O 모델은 블로킹 작업(Input, Output과 관련된 작업 / http, Database CRUD, third party api, filesystem)들을 백그라운드(libuv의 스레드 풀)에서 수행하고, 이를 비동기 콜백함수로 이벤트 루프에 전달하는 것을 말한다.

Node.js는 싱글스레드인가요?

• 싱글 스레드 : 프로세스 내에서 하나의 스레드가 하나의 요청만을 수행한다. 해당 요청이 수행될 때 다른 요청을 함께 수행할 수 없다.
• 멀티스레드 : 스레드 풀에서 실행의 요청만큼 스레드를 매칭하여 작업을 수행한다.

Node.js는 싱글스레드 논블로킹 모델로 구성되어 있다. 하나의 스레드로 동작하지만, 비동기 I/O 작업을 통해 요청들을 서로 블로킹하지 않는다.

 

즉, 동시에 많은 요청들을 비동기로 수행함으로써 싱글스레드일지라도 논블로킹이 가능하다.

Node.js는 완전한 싱글스레드인가요?

• Node.js가 완전히 싱글스레드가 아닌 이유는 일부 Blocking 작업들은 libuv의 스레드 풀(Thread pool)에서 수행되는데, 이 스레드 풀이 멀티스레드이기 때문이다.

---

Node.js

흔히 Node.js를 싱글 스레드 논 블로킹이라고 한다. Node.js는 하나의 스레드로 동작하지만 I/O 작업이 발생한 경우 이를 비동기적으로 처리할 수 있다. 분명 하나의 스레드는 하나의 실행 흐름만을 가지고 있고 파일 읽기와 같이 기다려야 하는 작업을 실행하면 그 작업이 끝나기 전에는 아무것도 할 수 없어야만 한다. 그러나 Node.js는 하나의 스레드만으로 여러 비동기 작업들을 블로킹 없이 수행할 수 있고 그 기반에는 이벤트 루프가 존재한다.

 

Node.js의 내부 구조

노드의 구조는

• libuv란 C++로 작성된, Node.js가 사용하는 비동기 I/O 라이브러리
• libuv와 다른 저수준 기능들을 랩핑하고 표출시키기 위한 바인딩 세트(socket, http, ...)
• V8, 크롬 브라우저를 위한 구글이 개발한 JavaScript 엔진으로 Node.js가 매우 빠르고 효율적인 이유 중 하나이기도 합니다. V8은 혁신적인 설계와 속도 그리고 효율적인 메모리 관리로 높은 평가를 받고 있습니다.
• 고수준 Node.js API를 구현하고 있는 코어 JavaScript 라이브러리

 

위 4가지로 Node.js의 플랫폼을 구축하고 있습니다.

 

Libuv 탄생, Node.js의 I/O 엔진

각 운영체제는 API와 같은 이벤트 디멀티플렉서를 위한 자체 인터페이스를 가지고 있습니다. 게다가 I/O 작업은 동일한 OS 내에서도 리소스 유형에 따라 매우 다르게 동작할 수 있습니다.

예를 들어 Unix에서 일반 파일 시스템은 논 블로킹 작업을 지원하지 않기 때문에 논 블로킹 동작을 위해서는 이벤트 루프 외부에 별도의 스레드를 사용해야 합니다.

서로 다른 운영체제 간의 불일치성은 이벤트 디멀티플렉서를 위한 보다 높은 레벨의 추상화를 필요로 하게 되었습니다. 이런한 이유로 Node.js 코어 팀이 Node.js를 주요 운영체제에서 호환되게 해주며 서로 다른 리소스 유형의 논 블로킹 동작을 표준화하기 위해 libuv라고 불리는 C라이브러리를 만들었습니다. Node.js의 구성요소 중에서 가장 중요하다고 말할 수 있습니다.

Libuv는 기본 시스템 호출을 추상화하는 것 외에도 이벤트 루프의 생성, 이벤트 큐의 관리, 비동기 I/O 작업의 실행 및 다른 유형의 작업을 큐에 담기 위한 API들을 제공합니다.

Libuv 동작

libuv 에게 파일 읽기와 같은 비동기 작업을 요청하면 libuv는 이 작업을 커널이 지원하는지 확인한다. 만약 지원한다면 libuv가 대신 커널에게 비동기적으로 요청했다가 응답이 오면 그 응답을 우리에게 전달해준다.

만약 요청한 작업을 커널이 지원하지 않는다면 어떻게 할까? 바로 자신만의 워커 스레드가 담긴 스레드 풀을 사용한다.

 

libuv는 기본적으로 4개의 스레드를 가지는 스레드 풀을 생성한다. 환경 변수 설정으로 최대 128개까지 스레드 개수를 늘릴 수 있다. 그리고 스레드 풀에 있던 스레드가 작업을 완료하면 libuv가 우리에게 요청한 작업이 완료되었다고 친절하게 알려준다.

 

즉, 정리하면 다음과 같다.

• libuv는 운영체제의 커널을 추상화해서 비동기 API를 지원한다.
• libuv는 커널이 어떤 비동기 API를 지원하고 있는지 알고 있다.
• 만약 커널이 지원하는 비동기 작업을 libuv에게 요청하면 libuv는 대신 커널에게 이 작업을 비동기적으로 요청해준다.
• 만약 커널이 지원하지 않는 비동기 작업을 libuv에게 요청하면 livuv는 내부에 가지고있는 스레드 풀에게 이 작업을 요청해준다.

 

Node.js는 I/O 작업을 자신의 메인 스레드가 아닌 다른 스레드에 위임함으로써 싱글 스레드로 논 블로킹 I/O를 지원한다. 다르게 말하면 Node.js는 I/O 작업을 libuv에게 위임함으로써 논 블로킹 I/O를 지원하고 그 기반에는 이벤트 루프가 있다.

 

Node.js에서의 이벤트 루프

• 이벤트 루프는 Node.js가 여러 비동기 작업을 관리하기 위한 구현체다.
• 동기 작업이 아니라 file.readFile('test.txt', callback)과 같은 비동기 작업들을 모아서 관리하고 순서대로 실행할 수 있게 해주는 도구이다.

이벤트 루프는 6개의 페이즈를 가지고 있으며, 페이즈를 라운드 로빈(RR) 방식으로 순회한다. 페이즈는 각자마다 큐를 가지고 있고, FIFO(First In First Out) 순서로 콜백 함수들을 처리한다.

라운드 로빈 스케줄링

• 시분할 시스템을 위해 설계된 선점형 스케줄링의 하나로서, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘입니다.
• 즉, 6개의 페이즈에 모두 일정한 시간을 할당하고 차례대로 순회하는 스케줄링 방식입니다.

---

이벤트 루프의 "단계" 설명

각 단계는 실행할 콜백의 FIFO 큐를 가집니다. 이 큐에는 이벤트 루프가 실행해야 하는 작업들이 순서대로 담겨있다. 각 단계는 자신만의 방법에 제한적이므로 보통 이벤트 루프가 해당 단계에 진입하면 해당 단계에 한정된 작업을 수행하고 큐를 모두 소진하거나 콜백의 최대 개수를 실행할 때까지 해당 단계의 큐에서 콜백을 실행합니다. 큐를 모두 소진하거나 콜백 제한에 이르면 이벤트 루프는 다음 단계로 이동합니다.

 

1. timers Phase

• setTimeout()과 setInterval() 같은 함수가 만들어 내는 타이머들을 다룬다.
• Timer Phase는 min-heap을 이용해서 타이머를 관리한다. 이 덕분에 실행 시간이 가장 이른 타이머를 효율적으로 찾을 수 있다.

 

2. pending callbacks Phase

• I/O 작업 블록 내의 콜백함수들을 poll단계의 큐로 넘겨준다.
• 이 페이즈는 pending_queue에 담기는 콜백들을 관리한다. 이 큐에 담기는 콜백들은 이전 이벤트 루프 반복에서 수행되지 못했던 I/O 콜백들이다.
• 시스템의 실행 한도 제한에 의해 큐에 쌓인 모든 작업을 실행하지 못하고 다음 페이즈로 넘어갈 수도 있다. 이때 처리하지 못하고 넘어간 작업들을 쌓아놓고 실행하는 페이즈다.

 

3. Idle, Prepare Phase

• 이 페이즈들은 Node.js의 내부적인 관리를 위한 페이즈로 자바스크립트를 실행하지 않는다. 공식 문서에서도 별다른 설명이 없고 코드의 직접적인 실행에 영향을 미치지 않는다.

 

4. poll Phase

• 이 페이즈는 새로운 I/O 이벤트를 다루며 watcher_queue의 콜백들을 실행한다. watcher_queue에는 I/O에 대한 거의 모든 콜백들이 담긴다. 쉽게 말하면 setTimeout, setImmediate, close 콜백 등을 제외한 모든 콜백이 여기서 실행된다고 생각하면 된다. 예를 들면 아래와 같은 콜백들이 실행된다.
  • 데이터베이스에 쿼리를 보낸 후 결과가 왔을 때 실행되는 콜백
  • HTTP 요청을 보낸 후 응답이 왔을 때 실행되는 콜백
  • 파일을 비동기로 읽고 다 읽었을 때 실행되는 콜백
• 이벤트 루프가 종료되었다면 바로 다음 페이즈로 넘어간다.
  • 만약 Close Callbacks Phase, Pending Callbacks Phase에서 실행할 작업이 있다면 바로 다음 페이즈로 넘어간다.
  • 만약 Timer Phase에서 즉시 실행할 수 있는 타이머가 있다면 바로 다음 페이즈로 넘어간다.
  • 만약 Timer Phase에서 즉시 실행할 수 있는 타이머는 없지만 n초 후에 실행할 수 있는 타이머가 있다면 n초 기다린 후 다음 페이즈로 넘어간다.

 

5. check Phase

• 이 페이즈는 오직 setImmediate의 콜백만을 위한 페이즈다. setImmediate가 호출되면 Check Phase의 큐에 담기고 Node.js가 Check Phase에 진입하면 차례대로 실행된다.
• 공식 문서에서 setImmediate와 process.nextTick의 차이에 주목하고 있다. 정리하면 아래와 같다.
  • process.nextTick은 같은 페이즈에서 호출한 즉시 실행된다.
  • setImmediate는 다음 틱에서 실행된다. 정확히는 Node.js가 틱을 거쳐 Check Phase에 진입하면 실행된다.
• 따라서 동작만 보면 process.nextTick은 즉시 실행되고 setImmediate는 다음 틱에 실행된다.

 

6. close callbacks Phase

• socket.on('close', () => {});과 같은 close 이벤트 타입의 핸들러를 처리하는 페이즈다. 정확하게는 uv_close()를 부르면서 종료된 핸들러의 콜백들을 처리하는 페이즈다.