Blocking-NonBlocking-Sync-Async

비동기 프로그래밍(Asynchronous)

비동기 프로그래밍(Asynchronous Programming)은 실행한 코드의 결과를 기다리지 않고 별도의 채널에 결과 처리를 맡긴 후 다음 작업을 바로 진행하는 방식의 프로그래밍을 뜻한다.

전통적인 절차 중심의 프로그래밍(Imperative Programming)에서는 코드를 실행 한 후 결과를 기다렸다 받아서 다음으로 진행하는 방식으로 코드를 실행한다.

비동기 프로그래밍은 이와 달리, 코드의 실행 결과 처리 및 활용을 별도의 채널에 맡겨둔 후 결과를 기다리지 않고 바로 다음 코드를 실행하는 방식으로 프로그램을 진행한다.

코드 실행의 결과가 다음 코드들에서 직접 연관이 없는 경우 실행의 결과를 기다릴 이유가 없기 때문에 자원을 더 효율적으로 사용할 수 있는 여지가 생긴다.

비동기 프로그래밍에서는 크게 두 가지 방식으로 결과를 처리한다.

• 함수 전달을 통해 처리(Callback)
• 언어에서 지원하는 방식(Future, Promise)

특정 함수를 호출하여 처리하는 방식은 함수를 값처럼 사용하기(First-class function)를 지원하는 언어에서 자연스럽게 사용하는 기법이다.

비동기 프로그래밍 방식으로 진행할 코드를 실행할 때 실행 하는실행하는 시점에 결과를 처리해 줄 함수를 일꾼에게 같이 넘기는 기법으로, 일꾼은 작업 후 실제 결과를 실행 시점에 받은 함수를 통해 처리한다. 이 방식은 직관적이고 일반적이지만, 실행하는 시점에 매번 함수를 넘겨주어야 하는 점에서 코드의 실행 흐름과 변수의 범위를 눈으로 좇기 힘들도록 만든다.

언어에서 지원하는 방식의 경우 비동기로 실행 한 코드의 결과를 언어에서 지원하는 방식으로 되돌려 받아 처리하는 방식이다. 이 방식을 이용하면 코드를 비동기로 실행할 때 해당 코드의 실제 결과가 아닌 언어에서 지정한 방식으로 결과를 즉시 되돌려 받는다.

언어적 방식을 통해 즉시 되돌려 받는 결과로는 Future, Promise 같은 객체 형태, Python의 코루틴(Coroutine)과 같은 언어의 문법을 이용하는 형태, 또는 Go와 같이 고 루틴(Goroutine) 또는 결과를 주고받을 별도의 채널을 사용하는 형태 등이 있다. 즉시 되돌려 받은 결과를 이용하여 각 방식에 알맞게 추후에 비동기로 실행 한 코드의 실제 결과를 꺼내어 사용하는 형태이다.

객체 형태로 돌려받는 경우는 실행 흐름을 프로그램으로 구현하여 마음껏 다를 수 있기 때문에 높은 자유를 누릴 수 있지만, 이를 위해 필요한 코드를 더 구현해야 하는 단점이 있다. 반면 언어의 문법을 이용하는 형태는 언어가 제공하는 제어문을 통해 비동기 프로그래밍의 실행 흐름을 언어의 실행 흐름으로 가져와 코드를 작성하게 하지만, 비동기 실행을 언어의 특정 문법에 제한해 버린다는 한계가 있다.

비동기 프로그래밍에서 가장 중요한 요소 중 하나는 비동기 기다리기(Asynchronous Wait 또는 줄여서 Await)이다.

프로그램을 만들다 보면, 비동기 프로그래밍으로 실행 했던 작업의 결과를 다시 최초의 실행 흐름으로 되가져와 사용해야 하는 경우가 생긴다.

이때 비동기 기다리기는, 기존의 실행 흐름에서 필요한 결과를 비동기 프로그래밍으로 실행한 작업에서 만들어낼 때까지 기다려 두 작업 간 타이밍을 맞추어 주는 역할을 한다. 또한 비동기 프로그래밍으로 실행 중인 작업이 있으니 함수를 끝내지 않고 기다리는 방식으로 사용할 수도 있다. 비동기 기다리기는 비동기 프로그래밍으로 실행한 작업과 원래 실행 흐름 묶어주는 중요한 기법이며, 대부분 비동기 프로그래밍 - 비동기 기다리기를 한 쌍으로 두고 당연히 따라오는 개념으로 생각한다.

특히 절차 중심의 언어에서는 비동기 기다리기를 통해 실행 흐름을 제어하는 것은 자연스러운 방식이다.

언어적 방식인 Future 객체, Promise 객체, 코루틴(Coroutine)문법, 고 루틴(Goroutine) 문법 등을 이용하여 비동기 프로그래밍을 지원하는 언어들은 비동기 기다리기를 제공한다.

오로지 Java만 절차 중심의 프로그래밍이면서도 아직까지 비동기 기다리기가 없다.

비동기 기다리기는 교착 상태(Deadlock) 문제가 발생할 여지가 있고, 추상화의 수준을 절차 중심의 프로그래밍 언어 수준으로 낮추는 주된 요인이다.

비동기 프로그래밍을 지원하는 거의 모든 언어에서 비동기 기다리기가 필수인 것은 이견이 없는 사안이며 아주 중요한 핵심 요소 중 하나이다.

하지만 이는 사용하기에 따라 비동기 프로그래밍을 절차 중심의 프로그래밍 관점으로 되돌려 와서 실행 흐름 제어의 늪에 빠지게 만들기도 한다.

비동기 프로그래밍의 기능을 절차 중심의 프로그래밍이 가지는 추상화 수준에 맞추어 사용할 수 밖에 없게 되는 문제 이외에도 사용자의 역량에 따라 자원을 효율적으로 사용할 수 있는 여지가 크게 달라진다는 문제가 있다. 비동기 프로그래밍의 추상화 수준을 높이는 계산 모델 또는 프로그래밍 모델을 사용하면 실행 흐름을 직접 제어하는 일 절차 중심의 프로그래밍 관점 에서 벗어나 비동기 프로그래밍의 장점만을 온전히 누릴 수 있다.

높은 수준의 추상화를 제공하는 기법을 이용하여 실행 흐름을 직접 제어하는 고통에서 벗어나면 교착 상태에 빠질 상황을 피할 수 있으며, 사용자의 역량과 상관없이 비동기 프로그래밍이 제공하는 효율적 자원 사용을 온전히 누릴 수 있다.

Haskell, Scala, 또는 OCaml 같은 함수 중심의 프로그래밍 언어에서는 비동기 프로그래밍의 흐름 제어를 모나드(Monad)를 이용하여 함수를 엮어나가는 방식으로 추상화 수준을 높여 사용할 수 있다.

또는 반응하는 프로그래밍(Reactive Programming)을 이용하여 프로그래밍의 관점을 절차 중심이 아니라 데이터의 흐름으로 바꾸어서 실행 흐름을 데이터 흐름에 맞추어 따라가도록 하는 방식으로 추상화 수준을 높여 사용할 수 있다.

비동기 프로그래밍은 동시성(Concurrency), 멈추지 않고 기다리기(Non-Blocking I/O)와 매우 흡사한 개념 같아 보이지만 독립된 정의로 다루어야 한다.

비동기 프로그래밍은 ‘결과를 기다리지 않고 다음 코드를 실행하는 흐름’을 대표하는 개념이다.

이를 구현하기 위해 여러 일꾼을 사용하여 실행하도록 하든 일꾼 하나에 작업의 순서를 조절하여 실행하도록 하든, 어떻게 구현할지는 비동기 프로그래밍과 연관이 있을지언정 정의의 구성 요소라고 볼 수는 없다.

물론 일반적으로 비동기 프로그래밍은 병렬성(Parallelism)과 동시성 모두를 확보한 구현체를 통해 코드를 진행하지만 그렇지 않고도 비동기 프로그래밍을 제공하는 것은 여전히 가능하다.

한 가지 예로, 이벤트 루프(Event Loop)를 사용하여 병렬성을 확보하지 않고 오직 동시성만 으로 비동기 프로그래밍을 제공하는 방식이 있다.

또는, 함수를 전달하여 처리하기(Callback) 방식을 사용하여 동시성 없이 비동기 프로그래밍을 제공할 수도 있다.

하지만 그것은 비동기 프로그래밍의 코드 진행을 구현하는 구현 방식들 중 하나일 뿐이지 비동기 프로그래밍이 병렬성, 동시성 또는 멈추지 않고 기다리기에 종속된 개념은 아니다.

입출력을 기다리는 방식 (Blocking & Non-Blocking)

입출력을 기다리는 방식은 크게 멈추고 기다리는 방식(Blocking I/O)과 멈추지 않고 기다리는 방식(Non-Blocking I/O)이 있다. 프로그램이 외부와 데이터를 주고받을 때, 데이터를 처리하는 동안 가만히 기다리는 것을 Blocking I/O, 다른 일을 하며 기다리는 것을 Non-Blocking I/O이라고 한다.

Blocking I/O 경우, 외부에서 작업을 진행하는 동안 프로그램 자원을 외부 작업이 끝나기를 기다리는데에 소비한다.

반면에 Non-Blocking 경우, 외부에서 필요한 작업을 하는 동안 프로그램은 다른 일을 할 수 있다.

따라서 Non-Blocking 방식을 이용하면 개발자의 역량에 따라 프로그램의 자원을 훨씬 효율적으로 사용할 수 있는 여지가 있다. 다만, Blocking 방식을 사용할 경우 프로그램과 외부 작업 사이에 데이터를 주고받기 위한 약속이 필요하다.

Blocking 방식은 외부 작업의 결과를 멈추어서 기다리기 때문에 그 자리에서 바로 받을 수 있다. 반면에 Non-Blocking 방식은 결과를 얻어 오기 까지 멈추어 있는 것이 아니라 다른 일을 하다 나중에 결과를 사용하는 것이 가능해졌을 때 결과를 받아서 사용하는 방식이다. 다만, Non-Blocking을 사용하는 경우 프로그램은 자신의 현재 맥락과 상관없이 외부 작업과 데이터를 공유할 방법이 필요하고 이를 위한 추가 구현이 필요하다.

이때 결과를 가져오는 방식에 따라 Non-Blocking을 다시 두 분류로 나누기도 한다. 입출력을 멈추지 않고 기다리는 방식 중, 주도적으로 데이터를 가져오는 방식(Pull Base)을 사용하는 경우를 멈추지 않고 기다리기(Non-Blocking I/O)라 부른다. 반대로 수동적으로 받아오는 방식(Push Base)을 사용하는 경우를 비동기 방식으로 입출력 기다리기(Asynchronous I/O)라 부른다. 일반적으로 수동적으로 받아오는 방식이 자원을 훨씬 효율적으로 사용할 수 지만, 주도적으로 가져오는 방식에 비해 구현해야 하는 코드가 많고 복잡한 단점이 있다.

결과를 가져오는 방식에 따라 다시 두 분류로 나누더라도, 본질은 여전히 입출력 결과를 수행하는 과정 동안 일하기를 멈추지 않고 기다린 다는 점이다. 따라서 이 글에서는 논의를 단순하게 하기 위해 입출력을 다루는 방식에 대한 논의는 처음과 마찬가지로 오로지 멈추고 기다리기와 멈추지 않고 기다리는 두 분류로만 나눌 것이다. 이는 이후 등장할 개념인 비동기 프로그래밍(Asynchronous Programming)의 비동기 기다리기(Asynchronous Wait)가 비동기 방식으로 입출력 기다리기 사이에 혼동을 줄이기 위한 것이기도 하다.

I/O 모델

시작하기 전에 아래의 뜻을 알고 넘어가자.

사용자 단계의 프로세스는 I/O 작업을 직접 수행할 수 없으며 커널에게 요청해야 한다.

운영체제가 제공하는 서비스 호출 함수를 시스템 호출이라고 한다.

아래는 관련 내용으로 유명한 IBM DeveloperWorks 2x2 매트릭스 이미지이다.

동기와 비동기는 프로세스의 수행 순서 보장에 대한 매커니즘이고 블록킹과 논 블록킹은프로세스의 유휴 상태에 대한 개념으로 완전한 별개의 개념이다.

Blocking&Non-Blocking

Blocking&Non-Blocking의 관심사는 호출되는 함수가 반환되는지에 대한 여부이다.

• Blocking : 사용자 프로세스가 시스템 호출을 하고 난 뒤에 결과가 반환되기까지 다음 처리로 넘어가지 않고 대기하는 상태이다. (A 가 B를 호출하였을 때, B 가 완료되기 전까지 대기 상태 후 완료 시에 반환)
• Non-Blocking : 사용자 프로세스가 시스템 호출을 하고 난 뒤에 제어권을 돌려받아 응답을 기다리지 않고 다음 일을 진행한다. (A 가 B를 호출하였을 때, B 가 완료되지 않더라도 반환)

Synchronous&Asynchronous

Synchronous&Asynchronous 관심사는 어떠한 순서를 가지고 실행되는지에 대한 여부이다. 더불어, 현재 작업의 응답과 다음 작업의 요청이 일치하느냐가 될 것이다.

• Synchronous : 작업을 요청한 후 결과가 나올 때까지 기다린 후 처리한다. 그렇기 때문에, 결과 시간과 반환되는 시간이 동일하다.
• Asynchronous : 요청한 작업에 대한 완료 여부를 신경 쓰지 않고, 다음 작업을 진행한다. 그렇기 때문에, 결과 시간과 반환 시간이 다르다.

Synchronous blocking I/O

가장 기본적인 I/O 모델이다.

파일을 읽고 쓰는 일반적인 read(), write()와 같은 I/O 시스템 호출을 의미한다. (특별한 설정이 없으면 blocking으로 동작한다)

사용자 프로세스가 read()를 호출한 후 운영체제(커널)는 데이터가 사용자 버퍼에 복사되기 전까지 반환하지 않으며, 사용자 프로세스는 자신의 작업을 중단한 채 대기한다.

이러한 부분에서 여러 클라이언트가 하나의 프로세스(또는 스레드)를 진행하기 위해서는 하나의 작업이 끝날 때까지 대기해야하므로, 클라이언트 별로 프로세스(또는 쓰레드)를 만들어 연결시켜야 한다.

그러므로, 클라이언트 별로 프로세스(또는 쓰레드) 수가 증가하면서 CPU 등의 자원 낭비가 된다. (ex. 접속자 수가 많아질 경우)

호출 응용 프로그램은 CPU를 소비하지 않고 단순히 응답을 기다리는 상태이므로 처리 관점에서 효율적이다.

그러나 실제로는 응용 프로그램이 실제로 blocking 되고, 읽기는 커널의 다른 작업과 다중화된다.

Synchronous non-blocking I/O

운영체제(커널)는 data를 읽은 후 버퍼에 저장하고 그 내용을 사용자에게 복사해준다.

버퍼는 커널이 가지고 있는 메모리에 적재되므로 메모리 간에 복사가 일어나 I/O 보다 빠른 속도로 받아올 수 있다.

그러나 버퍼가 비어있다면 커널은 즉시 에러 코드(EAGAIN 또는 EWOULDBLOCK)를 반환하여, 사용자 프로세스가 지속적으로 read()를 호출하여 I/O 준비사항을 체크하도록 한다.(polling 방식)

이에 반복적으로 시스템 호출이 일어나므로 CPU 등의 자원이 낭비된다.

Non-blocking 의미는 I/O 명령이 즉시 충족되지 않을 수 있으므로 응용 프로그램이 완료를 대기하기 위해 수많은 호출을 수행해야 한다는 것이다.
응용 프로그램이 데이터를 사용할 수 있을 때까지 대기 중이거나 명령이 커널에서 수행되는 동안 다른 작업을 시도해야 하기 때문에 이는 매우 비효율적 일 수 있다.

Asynchronous blocking I/O

select와 poll과 같은 시스템 호출을 이용하여 I/O Multiplexing 하기 위한 목적으로 사용된다.

즉, 하나의 통신 채널을 통해서 둘 이상의 데이터(시그널)를 전송하며, 물리적 장치의 효율성을 높이기 위해 최소한의 요소만 사용하여 최대한의 데이터를 전달한다. (여러 파일 descriptor를 하나의 프로세스로 관리)

select와 poll은 여러 개의 descriptor에서 데이터가 준비되었는지 검사를 수행하여 준비가 된 descriptor 가 발견될 경우 반환하여 여러 개의 I/O 를 처리할 수 있다.

다만, select는 관리 file descriptor 수에 제한이 있고, poll 은 제한은 없으나 file descriptor 당 체크 마스크의 크기가 커서 접속자 수가 늘어나면 성능이 떨어진다.

select call의 주요 문제는 효율적이지 않다는 것이다.
asynchronous notification에 편리한 모델이지만 고성능 I/O에 사용하는 것은 권장하지 않는다.

추가적으로, 아래와 같은 이유 때문에 IBM 블로그의 내용이 잘못되어 있다 라는 의견도 있으니 참고하면 좋겠다.

I/O Multiplexing이 IBM의 그림에서 Blocking-Async로 분류되어 있는 것에 동의하지 않는 이유

Asynchronous non-blocking I/O (AIO)

마지막으로 Asynchronous non-blocking I/O 는 I/O와의 중복 처리 중 하나이다.
읽기 요청이 즉시 반환되어 읽기가 성공적으로 시작되었음을 나타낸다.
그런 다음 application 은 백그라운드 읽기 조작이 완료되는 동안 다른 처리를 수행할 수 있다.
읽기 응답에 도달하면 신호 또는 스레드 기반 콜백을 생성하여 I/O 트랜잭션을 완료할 수 있다.

여러 I/O 요청에 대해 단일 프로세스에서 계산 및 I/O 처리를 겹치는 기능은 처리 속도와 I/O 속도 간의 격차를 이용한다.
하나 이상의 느린 I/O 요청이 보류 중인 동안 CPU는 다른 작업을 수행하는 것보단 일반적으로 다른 I/O 가 시작되는 동안 이미 완료된 I/O 에서 작동할 수 있다.

비동기 입출력

AIO의 기본 개념은 프로세스가 완료될 때까지 기다리거나 기다릴 필요 없이 프로세스가 많은 I/O 작업을 시작할 수 있도록 하는 것이다. 나중에 또는 I/O 완료 통지를 받은 후 프로세스는 I/O 결과를 검색할 수 있다.

컴퓨터 과학에서 비동기 입출력(Asynchronous I/O) 또는 비순차 입출력(non-sequential I/O)은 데이터 전송을 마치기 전에 기타 프로세스가 계속하도록 허가하는 입출력 처리의 한 형태이다.

컴퓨터에서의 입출력 기능은 데이터 처리 시 보다 상당히 느릴 수 있다. 모든 입출력 장치는 읽기나 쓰기를 위해 트랙을 찾는 하드 드라이브와 같이 물리적으로 움직여야 하는 기계 장치를 포함할 수 있다. 즉, 전기 회로를 전환하는 것보다 종종 더 느리다. 이를테면, 디스크 작업 수행에 10 ms가 소요되는 동안 1 기가헤르츠 클럭의 프로세서는 10,000,000 명령 처리 사이클을 수행할 수 있다.

입출력에 대한 단순 접근은 액세스를 시작하고 끝날 때까지 기다리는 것이다. 그러나 이러한 접근(동기 입출력)은 통신 중에 프로그램의 진행을 가로막아, 시스템 자원을 유휴 상태로 만들어버린다. 프로그램이 수많은 입출력 동작을 취할 때, 프로세서는 입출력 동작이 끝날 때까지 기다리는 유휴 시간 대부분을 소모할 수 있다.

한편, 통신을 시작한 다음 입출력이 끝날 것을 요구하지 않는 처리를 수행할 수 있다. 이러한 접근은 비동기 입출력으로 부른다.

비동기 입출력을 사용하면 스루풋, 레이턴시, 반응 속도를 개선할 수 있다.

Concurrency(동시성) vs Parallelism(병렬성)

Concurrency(동시성) 은 많은 것들을 한 번에 처리하는 것이며,
Parallelism(병렬성) 처리는 한 번에 많은 작업을 수행하는 것이다.

병렬 처리는 동시에 여러 계산을 수행하여 프로그램을 더 빠르게 만드는 기술을 나타낸다.
여러 처리 장치가 있는 하드웨어가 필요하며, 많은 경우 하위 계산의 구조는 동일하지만 반드시 그럴 필요는 없다.
GPU에서의 그래픽 계산은 병렬 처리이다.
병렬 처리의 주요 문제점은 최소한의 통신으로 독립 계산 단위에서 계산을 수행할 수 있도록 데이터 종속성을 줄이는 것이다.
이를 위해 서로 다른 단위로 동일한 계산을 두 번 수행하는 것이 유리할 수도 있다.

동시성은 프로그램을 보다 유용하게 만드는 기술을 말한다.
동시성은 구현될 수 있고 단일 처리 장치에서 많이 사용되지만, 속도와 관련하여 여러 처리 장치의 이점을 얻을 수 있다.
운영 체제를 멀티 태스킹 운영 체제라 고하는 경우 동시성을 지원하는 동의어이다.
브라우저의 탭에서 동시에 여러 문서를 로드할 수 있고 메뉴를 열고 다른 작업을 수행할 수 있는 경우 이는 동시성이다.

포 그라운드에서 대화식 응용 프로그램으로 작업하는 동안 백그라운드에서 분산 네트워크 계산을 실행하면 동시성이 된다.
반면, 분산 네트워크 클라이언트를 통해 계산할 수있는 패킷으로 작업을 나누는 것은 병렬 처리이다.

참고

Boost application performance using asynchronous I/O

Blocking-NonBlocking-Synchronous-Asynchronous

동기는 정확히 무엇을 의미하는 걸까?

비동기 입출력

비동기 프로그래밍과 웹 프레임워크

Parallelism vs. Concurrency