Non-Blocking

Overview

Spring Webflux를 적용한 애플리케이션은 비동기 논블러킹(Asynchronous Non-Blocking) 하다고 합니다. 과연 논블러킹하다는 말은 어떤 의미일까요? 논블러킹을 이해하기에 앞서 Blocking I/O, Synchronous Non-Blocking I/O를 순차적으로 보고 최종적으로 논블로킹(Asynchronous Non-Blocking I/O)을 알아보겠습니다.

Blocking I/O

Blocking I/O 모델에서 애플리케이션은 커널에 I/O 요청을 보내고 응답이 오기 전까지는 Block 상태가 되어 다른 작업을 수행할 수 없습니다. 일반적인 Spring MVC(서블릿 기반)와 RDBMS를 사용하고 있으면 대부분 이 Blocking I/O 모델을 따릅니다.

대부분 시스템이 Blocking 방식임에도 불구하고 실제 애플리케이션이 Block되고 있다는 것을 느끼기는 어렵습니다. 왜냐하면 기본적으로 서블릿이 Multi Thread 기반으로 동작하며 Block이 되는 순간 다른 Thread로 Context Switching하기 때문입니다. Context Switching 덕분에 CPU 자원을 효율적으로 사용하게 되지만, Context Switching에 드는 고정비용이 있기 때문에 다수의 I/O를 처리하는 경우에는 비효율적인 면이 있습니다.

Synchronous Non-Blocking I/O

Synchronous Non-Blocking I/O 모델은 애플리케이션에서 I/O를 요청을 하면 보내고 바로 다른 작업을 수행하게 됩니다. 다른 작업을 처리하면서 결과 I/O 데이터가 준비 되었는지 주기적으로 확인하고 준비가 완료되면 결과 데이터에 대한 후처리를 합니다. 이렇듯 주기적으로 확인하는 방식을 폴링(Polling) 방식이라고 합니다. 폴링방식은 주기적으로 I/O 작업이 완료되었는지 하기때문에 추가 자원을 사용하게 됩니다.

앞에서 본 Blocking과 Non-Blocking의 차이는 요청 이후 프로세스 제어권을 즉시 요청 측에 넘길 것인지 말것인지 여부에 달려 있습니다. 즉 Non-Blocking은 요청 측에 제어권을 넘겨주고, 요청 측에서 즉시 다른 작업을 할 수 있는 기회를 줍니다. 반대로 Blocking은 요청 수신측이 작업을 온전히 마칠때 까지 요청 측에 제어권을 넘겨주지 않습니다.

Asynchronous Non-Blocking I/O

Asynchronous Non-Blocking I/O 모델은 앞서 설명한 Synchronous Non-Blocking 모델과 마찬가지로 I/O 요청이후 즉시 다른 작업을 수행합니다. (둘다 Non-Blocking 모델) 두 모델의 결정적인 차이는 Synchronous과 Asynchronous에서 옵니다.

Synchronous인지 Asynchronous인지 판단하는 기준은 수신측의 작업완료를 요청측에서 확인하는지 여부에 있습니다.
Synchronous의 경우는 요청측에서 수신측 작업완료 여부를 지속적으로 확인합니다.(polling) 요청측에서 수신측 작업완료를 신경쓰지 않는 경우를 Asynchronous라 합니다. Asynchronous 방식에서는 요청측에서 callback 명령을 추가전달하여 수신측 작업이 완료되면 해당 callback을 실행하도록 하는게 가장 일반적인 방법입니다.

Asynchronous Non-Blocking I/O은 Blocking I/O, Synchronous Non-Blocking I/O 보다 효율적입니다. (Context Switching, Polling 관점에서)