읽을말한 글

• https://mygumi.tistory.com/154

• 동기 / 비동기 ?

  • 동기 : Node A , Node B 의 작업이 있다고 가정해보자. 동기작업의 경우는 Node A 의 작업을 마친 뒤, Node B의 작업을 처리하는 방식으로, 하나의 노드 프로세스간 점유하고 있는 상태가 되어, 다른 작업을 할 수 없게 된다. 동기방식은 요청과 동시에 그 결과가 일어나는 프로세스로 상당히 신뢰도가 높은 작업 방식이다. 단점으로는 멀티스레딩 방식으로 주로 서버의 요구사항을 처리하는데, 이 경우 스레드가 계속해서 증가할 경우 로드 밸런서 혹은 서버 증설을 통해서 서버의 요구사항을 처리해주어야 한다.
  • 비동기 : Node A, Node B가 있다고 가정해보자, 비동기 작업의 경우 Node A 가 작업하고 있는 동안 Node B가 수행되는 방식이다. 요청한 결과가 그 자리에서 보여주지 않음, 노드 사이의 작업 처리 단위를 동시에 맞추지 않아도 된다. 하지만 동기에 비해 코드가 상당히 복잡해질 수 있는 단점이 있다. 이러한 비동기 방식을 처리하는 이유는 아래와 같다. 서버로 HTTP 통신을 해서 DB data 를 받아오는 과정일 경우 생각보다 많은 시간을 요구하는 경우가 있다. 동기 방식의 경우 해당 프로세스를 진행할 경우, 작업을 할 경우 다른 작업을 진행할 수 없게된다. 그래서 비동기 방식은 이러한 요구 사항이 높은 과정은 비동기처리로 진행하여, 다른 작업을 진행할 수 있도록 한다.

  자 그럼 NodeJS 가 왜 싱글 쓰레드 / 비동기 IO 방식을 채택했는지 이야기 해보자. 싱글 쓰레드의 경우 문맥교환으로 인한 오버헤드가 발생하지 않으며 근데 알아둬야 할 점은 EventLoop 가 싱글 스레드인거지, 뒤에서 일하는 워커들은 멀티스레딩 방식이다. 비동기 IO 방식은 위에서 설명했듯이 최대한 효율적으로 작업을 진행하려고 하므로, CPU time loss 가 최소화된다. 비동기로 처리해야되는 IO 요청이 있으면, 워커한테 던져놓고 스레드는 계속 다른일을 받는다. (이처리과정은 그림으로 설명할예정)

  EventLoop 는 자바스크립트 엔진 내부에 있다. 대표적인 잘못된 개념들 중 하나는 바로 이벤트 루프가 자바스크립트 엔진의 일부라는 것이다.

  Event Loop Phase

  • Timers!

    • setTimeout() 과 setInterval() 과 같은 타이머 콜백들이 처리된다.
    • 코드를 보면 이벤트 루프가 uv__run_timers() 호출할때 타이머 콜백들을 받고, 실제 유저로직은 timer_cv인데, 이걸 poll Queue 에 등록해 버린다.
    • 따라서 타이머 콜백 내부 로직들은 poll큐에 먼저 등록된 콜백들이 처리되고, 나중에 처리될 수도 있으므로, 파라미터로 지정한 시간에 딱 실행됨을 보장하지 못한다. 즉, 파라미터는 일정 시간 이후에 실행된다는 기준 시간 같은 셈이다.
    • setTimeOut 은 100ms 이후 언제 실행될지 모름. (poll Queue 가 비어있다면 100ms 후 딱 실행되겠지만..)

  • I/O Callbacks : Close Call back , Callback Scheduling with Timers, setImmediate()를 제외한 거의 모든 콜백들을 집행

    • http, apiCall, DBread 등등..
    • 이것 역시 작업 완료는 이벤트 루프가 I/O CallBack 영역을 호출 (uv__run_pending()) 할때 체크할 수 있지만, 이후에 콜백이 poll큐에 등록되므로, 이벤트루프가 poll 영역을 처리할때 콜백 내부로직이 실행된다.

  • idle, prepare : 내부용으로만 사용 (모든 큐가 비어있으면 idle이 되면서 tick frequency가 떨어짐 = 할일도 없으니 이벤트 루프가 천천히 돈다고한다.. 확인안해봄)

  • poll

    • 이벤트 루프가 uv__io_poll() 를 호출했을때, poll 큐에 있는 이벤트, 콜백들을 처리
    • 만약 CPU를 할당받았을때
      • poll 큐가 비어있음 : setImmediate() 가 있으면 check 로 넘어감, 없으면 이벤트 루프가 phase 를 돌며 callback을 무한히 기다림 ⇒ poll 이 끝나면 uv__run_check() 가 호출된다.
      • poll 큐에 뭐가 있음 : 이벤트가 큐를 순회하며 처리함.
    • check : setImmediate() 콜백은 여기서 호출되고 집행
    • close callbacks: .on('close', ... ) 같은 것들이 여기서 처리됨.

    fs.readFile(__filename, ()=>{
    	setTimeout(() => {
    		console.log("A");
    	}, 0);
    	setImmediate(() => {
    		console.log("B");
    	}, 0);
    }); 
    

    위 코드를 실행하면 이벤트 루프에서는 아래와 같은 순서로 동작한다.

    1. fs.readFile 이라는 (I/O 작업!) ⇒ 블로킹 작업이므로 이벤트루프는 워커쓰레드에게 작업을 넘긴다.
    2. 워크쓰레드가 작업을 완료한 뒤 I/O callBack 영역의 큐에 콜백을 등록
    3. 이벤트루프가 I/O callbacks 영역을 실행할 때, 콜백을 poll 영역의 큐에 등록
    4. 이벤트루프가 poll 영역을 실행할 때, 큐에 1개가 있으므로 이걸 실행함!
    5. (콜백내부) 2라인에서 setTimeout() 이므로 다시 timers 영역에 넣고 5라인으로 간다.
    6. (콜백내부) 5라인에서 setImmediate() 이므로 다시 check 영역에 넣는다.
    7. 이벤트루프가 poll 큐를 비우고, 다음 실행영역인 check 영역으로 간다. check 영역의 큐에는 들어있는 'B' 를 콘솔에 찍는다. check 영역의 큐를 비우고 다시 while 문의 시작지점으로 간다.
    8. 이벤트루프가 timers 영역을 호출한다. uv__run_timers() 는 setTimeout() 의 콜백을 poll큐에 등록한다.
    9. 이벤트루프가 2번째로 poll 영역을 실행한다. 큐에 1개가 있으므로 이걸 실행하고 'A' 를 찍는다.
    10. node 프로세스가 반환되고 끝

    예제 2.

    setTimeout(() => {
    	console.log("A");
    }, 0};
    setImmediate(() => {
    	console.log("B");
    }, 0};
    

    위 코드를 실행하면 이벤트 루프에서는 아래와 같은 순서로 동작한다.

    1. setTimeout() 를 만나면 timers 영역에 넣고 4라인으로 간다.
    2. setImmediate() 를 만나면 check 영역에 넣는다.
    3. 프로세서의 상황에 따라 랜덤하지만, timers 영역을 먼져 수행한다면 setTimeout() 이 poll큐에 들어가고 먼져 "A" 가 콘솔에 찍힐 것이다. 하지만 timers 영역을 지나칠 경우 check 영역에 있는 "B"가 호출될 것이다.