I/O의 Sync와 Blocking 그리고 Multiplexing

해당 글은 네이버 클라우드 플랫폼의 글을 참고하였습니다. 참고로 I/O는 파일 입출력 (Input/Output)을 의미합니다.

 

Everything is a FIle

Server 내에서 읽고 쓰는 것도 파일 I/O 이고

Server-Client 간 네트워크 통신을 할 때 쓰는 것도 파일 I/O입니다.
무슨 헛소린가 싶지만, 리눅스에서 네트워크 통신에 사용하는 socket 도 결국에는 File Descriptor로 관리되는 하나의 파일입니다. Low-Level의 파일 핸들링을 기반으로 socket 기반 데이터 송수신이 가능합니다. 즉, 소켓 통신을 하는 네트워크 I/O도 결국 운영체제에서 파일을 다루는 것과 개념은 다르지 않습니다. 모든 것은 파일입니다.

---

# 파일 I/O의 종류

파일 입출력은 user 영역에서 직접 수행 할 수 없기때문에 user process가 운영체제 커널에 I/O 작업을 '요청'하고 '응답'을 받는 구조입니다. 여기에서 응답을 어떤 순서로 받는지 (synchronous/asynchronous), 어떤 타이밍에 받는지(blocking/non-blocking)에 따라 파일을 다루는 여러 모델로 분류가 됩니다.

 

작업의 순서를 보장한다는게 무슨말이죠?

작업의 순서를 보장한다는 것은 '현재 작업의 응답'을 받는 시점과 '다음 작업을 요청'하는 시점을 맞추는 일입니다. 아래 그림을 보면 이해가 쉽습니다. 다음 작업이 있다는 것 자체가 순서가 있다는 것을 의미하며 이전 작업이 완료되기 전까진 다음 작업이 수행되지 않습니다.

 아예 상관없는 작업이더라 하더라도 순서를 기다려야 하기 때문에 작업 별 지연이 발생합니다.

 

@ Synchronous, 동기

작업에 순서가 있으며, 한 작업이 끝난 후 다음 작업을 실행합니다.

• 모든 I/O 요청-응답 작업이 일련의 순서를 따릅니다. 즉 작업의 순서가 보장됩니다.
• 작업 완료를 user 영역에서 판단하고, 다음 작업을 언제 요청할지 결정하게 됩니다.
• 일련의 파이프라인을 준수하는 구조에서 효율적입니다.

제일 일반적인 구조입니다. 한 작업이 끝나는 동시에 다음 작업이 시작됩니다.

 

@Asynchronous, 비동기

작업 순서를 고려안하고 여러 작업을 동시에 합니다. (* 각 작업이 독립적이라 동시실행이 가능한 경우)

• 커널에 I/O 작업을 요청한뒤 바로 다른 작업을 할 수 있습니다. 허나 작업의 순서는 보장되지 않습니다.
• 작업이 완료되면 커널 영역에서 통보를 해줍니다. 제어권이 없어 user 영역에서 판단 불가능합니다.
• 각 작업들은 독립적으로 동시에 실행가능합니다. 작업 별 지연이 큰 경우 효율적입니다.

물론 작업 순서가 중요한 경우 비동기를 사용할 수 없을 수도 있습니다.

 

---

@Blocking, 블로킹

해당 작업의 반환 값을 기다립니다. 제어권은 반환값을 주는 작업이 가지고 있기에 계속 기다려야 합니다.

• 요청한 작업이 모두 완료될 때까지 기다렸다가, 완료될 때 응답과 결과를 받습니다. ( 대기 有 )
• 요청한 작업 결과를 기다립니다.

 

@Non-Blocking 넌-블로킹

해당 작업의 반환 값을 기다리지않고 다른 일을 합니다. 요청하자말자 바로 제어권을 돌려받아 기다리지 않고 다른작업을 할 수 있습니다. 다만 중간에 상태확인(polling)을 계속하여 반환 값이 나왔는지 확인해야 합니다.

• 작업 요청 이후 결과는 나중에 필요할 때 전달받습니다. ( 대기 無 )
• 요청한 작업 결과를 따로 기다리지 않습니다.
• 중간중간 필요할 때 상태 확인을 하여 결과를 확인합니다. (polling) 

 

---

@ Non-Blocking 과 asynchronous의 차이

요청된 I/O 작업순서가 보장(synchronous) 되고, 각 작업마다 결과를 받아(blocking) 보는 방식이 가장 흔합니다. 그래서 sync와 blocking 개념을 혼동하기 쉬운데, 이 두개는 아예 독립적인 개념입니다.

비동기(async) 작업이 결국 non-blocking을 의미하는게 아니냐고 잘못 이해하는 경우가 많습니다.

예를 들어 결과를 기다리며 block된 동안 아예 다른 작업이 시작할 수 있냐 없냐는 순서의 문제이므로 sync/async와 관련됩니다. 보통은 순서 없이 여러 작업을 처리하는 상황(async)에서 한 작업을 시작한 뒤 결과를 기다리지 않고 다른 것도 처리(non-blocking)해야 효율적이기 때문에 [각 작업들이 서로 상관이 없어 독립적인 경우] 가 많았습니다. 때문에 보통 non-blocking 작업의 경우에 작업순서, 즉 종료시점이 달라도(async) 상관 없는게 대부분이었을 뿐입니다.

 

즉 non-blocking(작업의 결과를 기다리지 않는 것)과 asynchronous(작업의 순서가 없는 것)은 서로 비교되는 개념이 아닙니다.

 

---

# 여러가지 I/O 처리 방식( I/O Model )

sync/async와 block/non-block은 서로 다른 개념임을 다시 한번 상기하며, 해당 특징을에 조합에 따른 I/O Model을 알아봅시다. 참고로 이 4가지 개념을 애매하게 작성하는 곳이 많다보니 같은 모델을 설명하더라도 명칭이 헷갈릴 때가 있습니다. 따라서 모델의 의미와 부합하다고 생각하는 정의를 이용해 model을 분류하고, 각 모델을 구분지어 알아보겠습니다.

 

모델은 O.S의 구현방법에 따라 세부적인 차이가 있습니다. 지금은 가장 많이 사용하는 리눅스 기반의 I/O 모델을 기준으로 알아보겠습니다. 아래의 그림은 가장 흔하고 유명한 IBM Developer의 I/O 모델 분류 표입니다.

4가지 모델의 호칭에 대하여

사실 I/O Multiplexing 이 async + blocking 방식인지에 대해 다양한 의견이 있습니다. 구현 방식에 따라 차이가 있지만, 어디에 관점을 두냐에 따라 blocking, non-blocking으로 갈리기도하며 실제 I/O 동작은 sync 방식으로 동작합니다. 

심지어 각 기법에 따라 세부적인 로직과 결과 알림방식이 달라 Multiplexing을 단순하 async + blocking 방식이라고 설명하는건 애매합니다. 따라서 기본 개념만 숙지한 채, 해당 모델이 어떤기법을 사용하는지 위주로 이해하는걸 추천합니다.

전체로 봤을 때는 동기인데, 관점 주체를 바꿔 안에서 보면 달라질 수있다.

 

•  Synchronous Blocking I/O → [ Blocking I/O ]
•  Synchronous Non-Blocking I/O → [ Non-Blocking I/O ]
•  Asynchronous Blocking I/O → [ I/O Multiplexing ]
•  Asynchronous Non-Blocking I/O → [ Asynchronous I/O ]

---

@1. Blocking I/O (sync + blocking)

가장 흔하게 사용하는 I/O 모델로 user 공간에 존재하는 process는 운영체제 커널에게 I/O를 요청하는 함수를 호출합니다. (system call) 그리고 커널이 작업결과를 반환하기까지 중단된 채 대기(block)합니다. 이때 user process는 CPU를 점유하지 않으며 커널의 응답을 기다립니다.

이 과정에서 singal을 이용해 system call이 중지될 순 있으나, 보통 커널의 응답이 되돌아옴과 동시에 반환된 결과가 user 공간의 buffer로 돌아오게 되고(sync) 그제서야 user process는 마침내 unblocking되어 반환받은 데이터를 처리할 수 있게 됩니다.  

 

호출할 때마다 I/O 요청 스레드를 생성하므로 I/O 접근이 많아지게 된다면 한 작업당 하나의 context-switching이 발생하게 됩니다. 또한 block 된 user process 는 커널의 결과응답이 오기전까지 CPU를 사용하지 않고 놀고있기 때문에 리소스 사용 효율도 나쁩니다. 

---

@2. Non-Blocking I/O (sync + non-blocking)

@1에서 Non-block하게 동작하게 만들고 싶다면 socket 생성 시 O_NONBLOCK 옵션을 주면 됩니다. 해당 socket으로 커널에 I/O 요청, 즉 [ I/O system call ]을 하게되면 block 없이 요청 즉시 결과를 반환받습니다.

 

block과 다르게 반환할 데이터가 준비되지 않았더라도 기다리지 않고 -1 을 대신 반환합니다. 그리고 왜 반환이 불가능한지에 대한 오류 코드(errno)를 같이 제공합니다. 보통 오류코드로 EAGAIN 또는 EWOULDBLOCK을 반환 받게 됩니다.

요청 결과와 errno를 즉시 받아보고 커널에 더 물어볼지 말지를 결정하기 때문에 I/O 작업이 완료되지 않아도 user process는 block 되지 않습니다. 요청한 [ I/O system call ] 에 대해 커널이 user process를 기다리게 하는게 아니라 아직 덜됐으면 덜됐다고 물어볼 때 마다 알려주는 방식이라고 생각하면 됩니다.

 

이렇게 user process가 제어권을 반환받고 나면 다른 작업을 처리할 수 있으니 Blocking I/O보다 더 좋은 모델이라고 생각할 수 있습니다. 하지만 non-blocking을 사용하는 경우 user process는 원하는 결과를 반환받을 때까지 계속해서 커널에 상태를 체크해야합니다. (이를 보통 busy-wait이라 표현합니다.)

 

동기식(sync)으로 동작하기에 user process는 block만 안되었을 뿐, 현재 작업이 완료 될 때까지 다른 일을 할 수 없습니다. 그래서 I/O 완료만 기다리며 계속 context-switching를 일으키는 구조인거죠. 또한 계속해서 커널 상태를 체크해야하니 적절한 polling 주기가 필요한데 주기가 너무 길 경우 준비가 완료되었음에도 늦게 요청하여 지연이 생길 수 있고 반대로 주기가 너무 짧으면 커널에서 의미없는 요청 반환을 계속해줘야하니 I/O 작업의 지연을 초래할 수 있습니다.

 

앞서 살펴본 Syncronous 모델은 Block이던 Non-Block 이던 결국 요청한 순서대로 작업을 완료시킵니다. 이런 방식은 작업의 흐름이 직관적이지만 2개 이상의 파일을 동시에 다룰 때에는 multi-process 또는 multi-thread로 구현해야 합니다. 하지만 멀티쓰레드, 멀티프로세스로 구성하게되면 IPC나 동기화(Semaphore, Mutex) 작업을 추가로 고려해야하기 때문에 프로그램 설계가 복잡해집니다. 그 때문에 다음에 나올 @3 Multiplexing, 다중화 기법이 주목받게 됩니다.

---

@3. I/O Multiplexing (async + blocking)

멀티플렉싱은 마지막에 정리해서 쉽게 설명할거니, 일단 @4 까지 쭉 읽어주세요.

이 모델은 비동기블럭보다는 Multiplexing 라는 이름이 어울립니다. '다중화', 사실 Multiplexing은 구현 방법이나 사용자 관점, 서버 프로세스 관점, 운영체제 관점에 따라 비동기, 동기가 바뀔 수도 있습니다. 정확하게는 특정 기법을 사용하여 여러 I/O 작업을 독립적으로 관리하는 방법이라고 이해하면 됩니다.

 

다중화란 간단하게 '하나'를 '여러 개'처럼 보이게 동작한다는 뜻입니다. 이를 I/O 관점에서 말하면 한 프로세스가 여러 파일(file)을 관리하는 기법이라고 합니다. [파일과 파일I/O]는 프로세스가 커널에 진입할 수 있도록 다리역할을 하는 일종의 인터페이스입니다. 만약 한 컴퓨터가 아닌 server-client 네트워크 환경이라면, 하나의 server에서 여러 socket, 즉 파일을 관리하여 여러 client가 접속 할 수있게 구성됩니다. 처음에 말했지만 socket 또한 IP/Port 정보를 가진 일종의 파일이니까요.

 

프로세스에서 운영체제를 통해 특정 파일에 접근 할 때에는 File Descriptor(FD,파일 핸들러)라는 추상적인 값을 이용하게 됩니다. 이 FD들을 어떻게 감시하냐는게 I/O Multiplexing의 핵심입니다. 여기에서 어떤 상태로 대기하느냐에 따라 정말 다양한 기법들 (select, poll, linux_epoll, bsd_kqueue, window_iocp)등 다양한 기법들이 등장하죠.

각각의 요청은 blocking 되지만, 비동기적으로 여러 소켓이 동시에 동작합니다. 소켓 작업이 완료되면 event처럼 callback을 전달하는데, 서버에서는 전체 callback을 하나로 관리하고 완료된 소켓을 찾아 후속 작업을 처리합니다.

우선 @1, @2와 동일하게 IBM 에서 제시된 분류기준으로 Async block I/O로 구현한 Multiplexing 모델을 살펴봅시다. 아래의 그림에서 커널의 I/O 요청을 받으며 처리를 시작함과 동시에 user porcess에게 미완료 상태를 반환합니다. 위에서 설명한 non-blocking이랑 크게 다른게 없죠. 그래서 보통 blocking인지 non-blocking인지 많이 헷갈려합니다.

 

명확히 구분하자면 user process에서 read, write같은 I/O 작업 자체가 block되는건 아닙니다. select, poll 같은 Mutilplexing 관련 [ system call ]에 대한 커널의 응답이 block 된다고 봐야합니다.

 

여기선 첫 read 요청에 대해 즉각 미완료 상태를 반환받는 non-blocking socket의 동작을 보여주는데, select의 결과에 따라 read/write system call을 수행하게끔 구현하면 위 그림에서 Non-blocking 요소를 없애는건 가능합니다. 하지만 특수한 상황들, 예를 들어 데이터 유효성 검사(checksum) 실패로 폐기가 된다면 select()가 어떤 FD에 데이터가 있으니, 읽으라고 알려와서 읽었다가 socket이 block되는 경우가 나올 수 있습니다. (물론 이럴 땐 데이터를 받는 socket을 non-blocking으로 구성하여 EWOULDBLOCK errno 만 반환하게끔 설계하는게 안전성을 더 높일 수 있습니다.)  

 

이어서 커널의 응답을 기다리다보면, 커널에서 결과 값이 준비되었다는 callback 신호가 오게됩니다. 그럼 user process는 자신의 buffer로 데이터를 복사해옵니다. 사실 select 방식의 실제 구현으로 들어가면 select 호출 결과가 유의미한 값으로 나올 때 까지 user process에서 루프를 돌며 대기하고 있습니다. 결국 select를 요청한 user process가 반환 값을 보고 후속 작업 유무를 판단하는 것이죠. 예측할 수 없는 여러 I/O 요청을 한 번에 관리하는 측면서는 비동기이지만, 결국 실제 내부 I/O동작은 동기적인 루프문을 돌고있습니다.

 

멀티플렉스를 구현하는 여러가지 방법

[네이버클라우드 기술&경험] IO Multiplexing (IO 멀티플렉싱) 기본 개념부터 심화까지 -1부-

 

---

@4. Asynchronous I/O (AIO, async + non-blocking)

@4 Async I/O 환경에서 user process는 커널 I/O system call 이후 처리에 아예 신경쓰고 있지 않다가, 작업이 완료되면 커널로부터 신호(singal)을 받는 방법입니다. 그렇기에 응답이 오기 전까지 user process는 I/O를 신경쓰지않고 다른 작업을 동시에 할 수 있습니다. (* 단, 독립적으로 실행가능한 다른작업인 경우)

하지만 안타깝게도 Linux AIO(Asyn Non-blocking)에서는 개시만 되었을 뿐 아직까지도 완전한 형태의 API로 해당 기능을 제공하지 않습니다. 그래서 리눅스에서 이와 같이 사용하려면 커널이 아닌 user 영역에서 POSIX AIO라는걸 사용합니다.

 

POSXI AIO는 커널에서 제공하는 AIO를 사용 하는것이 아니라 user 공간에 한정된 구현체입니다. 이는 I/O 작업을 위한 여러 쓰레드 관리하는데 비용이 많이 들고 확장성이 떨어진다는 문제점을 유발합니다.

 

이미 수년에 걸쳐 AIO 시스템에 많은 개선 시도가 이루어지고 있습니다. 물론 현재(2021) libaio라는 이름으로 커널 영역에서 제공하는 Linux AIO가 있긴하지만 구현이 어려워 사용하기에 완전한 수준은 아닙니다.

---

# I/O 멀티플렉싱에 대하여

각각의 요청은 blocking 되지만, 비동기적으로 여러 소켓이 동시에 동작합니다. 소켓 작업이 완료되면 event처럼 callback을 전달하는데, 서버에서는 전체 callback을 하나로 관리하고 완료된 소켓을 찾아 후속 작업을 처리합니다.

1. 멀티플렉싱은 딱 뭐에 속한다고 말하기 애매하다. 넓게보냐 좁게보냐에 따라 다르다.
2. 노드는 사용자 요청을 단일 스레드로 받는다
3.  I/O는 이벤트 루프(callback)기반으로 Sync하게 동작.
4.  순서를 예측 할수없는 여러 커널 I/O요청들을 select등의 기법으로 한번에 모아 관리하는 측면에서 Async하다고도 볼수있다.
5. 하지만 커널의 응답들을 받는 select의 이벤트 루프는 단일스레드/동기로 돌고있는건 변함없다.
6. 즉  I/O 멀티플랙싱은 프로세스에서 하나의 스레드로 Sync하게 동작된다. -> 즉 코어는 하나만 돈다.
7. Node는 동시성은 가능하지만 병렬성은 불가능하다.

Node-MySQL로 예를 들어보면, 멀티플렉싱의 다중파일 이벤트기반 처리는 어차피 Node에서 비동기/논블럭 멀티스레드로 select를 구현 한들  MySQL에서 블록당하기에 이벤트처리 루프가 대기하게된다. 그래서 싱글스레드/동기로 처리하는 것과 성능이 크게 다르지않다.이렇게 노드처럼 싱글 스레드로 사용자 요청과 I/O callback을 받는 방법을 사용하면 스레드 장애에 대응하게 설계하기 어렵다. 해당 작업을 대체해줄 다른 스레드가 없으니까실제로 node는 각각의 작업이 거대한경우 적합하지 않은 선택이다. (=내부적인 작업큐에 대기하는 요청이 많아진다. 참고로 노드의 V8엔진은 멀티스레드 API를 지원하지않는다)

 

---

# 멀티플렉싱에 대한 세줄 요약

1. 운영체제 커널은 비동기/블럭으로 놀고있는데 그걸 callback으로 받아쓰는 [멀티플렉싱 I/O 서버]는 동기/블럭이다.
2. 하지만 사용자 입장에서는 콜백함수로 비동기/논블로킹처럼 쓸 수 있다. (* 블로킹이 필요한 작업이 아닌경우)

3. 즉 사용자, 서버, 운영체제의 관점에 따라 블로킹, 논블로킹, 동기, 비동기가 달라진다.

전체로 봤을 때는 동기인데, 관점 주체를 바꿔 내부를 보면 달라질 수있다.