네, 반갑습니다. 오늘 이 영상을 끝까지 보신 후엔 블락 I/O와 넌 블락 I/O의 개념을 이해하게 됩니다.

자, 그럼 오늘도 I/O에 대해서 한번 살펴볼게요.

I/O는 임프 드 아웃풋의 약자죠. 그래서 데이터의 입출력을 의미를 합니다.

이 I/O의 종류에는 여러 가지가 있는데요. 그중에서 대표적으로 네트워크 혹은 소켓 I/O가 있고요.

그다음에 일반적으로 우리가 알고 있는 파일 I/O가 있습니다.

그리고 파이프와 관련된 I/O가 있는데 여기서 파이 프는 프로세스가 통신을 할 때 사용되는 개념이에요.

그리고 일반적인 디바이스, 모니터라든지 키보드라든지 그런 디바이스에 대한 인풋 아웃풋 또 I/O의 한 경우가 되겠죠.

자, 그럼 여기서 네트워크 혹은 소켓 I/O를 좀 더 살펴볼게요.

소켓은 뭐냐면 네트워크 통신을 할 때는 소켓을 통해서 데이터가 입출력이 된다고 이해를 하시면 됩니다.

이게 무슨 말이냐? 이렇게 네트워크가 있고요. 여기 네트워크 공간에서 어딘가에 컴퓨터가 있고 또 다른 컴퓨터가 또 어딘가에 있습니다.

그럼 이 컴퓨터에 실행되는 각 프로세스가 서로 데이터를 주고받고 싶을 때는 반드시 이 프로세스의 아래에서 속해설, 열고 이렇게 속해설 열고 속해설 통해서 데이터를 주거나 받을 수 있습니다.

그러면 우리 채널은 백엔드 전문 채널이니까, 백엔드 서버는 어떻게 동작하는지 간단하게 설명하며, 네트워크 상에 여러 요청자, 혹은 클라이언트라고 하죠.

여러 요청자들과 백엔드 서버가 각각 소켓을 열고 통신을 하면서 요청에 대해서 처리를 하는 거예요.

그래서 그림으로 한번 살펴보면, 자 여기 이렇게 서버가 있고 네트워크 어딘가에 있는 각 클라이언트들이 이런 식으로 소켓을 열고 이 백엔드 서버를 요청을 하는 거죠.

이렇게 요청을 하게 되면 이 백엔드 서버에서도 마찬가지로 소켓을 이렇게 열고 요청을 준 각각의 클라이언트들과 서로 통신을 하게 되는 겁니다.

자, 그럼 이제 본격적으로 블락 I/O와 넌블락 I/O가 어떻게 동작하는지 OS 레벨에서 개념적으로 살펴보도록 하겠습니다.

여기서 특히 우리 백엔드 개발자는 네트워크 통신을 많이 하게 될 것이기 때문에 일반적인 개념을 설명한 이후에는 네트워크 I/O, 혹은 소켓 I/O를 예로 들어서 설명하도록 할게요.

블락 I/O는 I/O 작업을 요청한 프로세스 혹은 스레드가 요청에 완료 될 때까지 블락이 되는 I/O를 블록 I/O라고 합니다.

표를 통해서 한번 살펴보면 지금 이 쓰레드가 하나가 있고요.

그럼 이 스레드에서 우리가 작성한 코드가 쭉 실행이 되다가 `read`라는 이름의 시스템 콜 호출하는데 이 시스템 콜이 만약에 블라킹 시스템 콜이라고 한다면 이 `read` 시스템 콜을 호출하게 되는 순간, 일단 이 스레드, 이 `read` 시스템 콜을 호출한 이 스레드는 놀라게 됩니다.

블락 I/O에 대해서 아무것도 진행을 하지 못하고요.

그러니 시스템 콜을 통해서 이제 커널 모드로 전환이 되고 커널에서 이제 실행이 되면 이 커널에서는 리드 I/O를 실행을 시킵니다.

그럼 관련 있는 디바이스에 요청을 하겠죠.

그러고 난 뒤에 좀 시간이 지나서 그 디바이스에서 '아, 읽을 준비가 됐다'고 응답을 주면 커널이 그 응답을 받고 그 응답을 바탕으로 준비가 된 이 데이터를 커널 스페이스에서 유저 스페이스로 옮기게 됩니다.

그럼 그때에 이 블락이 됐던 스레드는 이 부분에서 다시 깨어나서 준비된 데이터를 읽어서 이어서 코드를 실행을 하게 되는 거죠.

이거를 소켓 I/O를 통해서 한번 살펴볼게요. 소켓 I/O에서 블락 I/O가 무슨 의미냐 하면, 자, 여기 예가 있습니다.

소켓 A가 있고 소켓 B가 있는데, 소켓 A에서 소켓 B로 데이터를 보내려고 해요.

그러면 소켓 A는 일단 기다려야 됩니다.

여기서 기다린다는 말은 무슨 말이냐면 이 소켓마다 2개의 버퍼가 있는데, 하나는 샌드 버퍼, 또 하나는 리시브 버퍼요.

그럼 여기서 리드 시스템 콜을 소켓 3 되고 호출하게 되면 리시브 버퍼에 데이터가 들어올 때까지 이 리드 시스템 콜을 호출한 스레드는 블락이 된다는 말인 거죠.

계속 블락이 됩니다. 언제까지?

리시브 버퍼에 데이터가 들어올 때까지 말이죠.

그러면 이번에는 샌드 소켓 입장에서 한번 살펴보죠.

이 소켓 입장에서 이제 소켓에 쓰기를 하게 되면 샌드 버퍼에 전송하려고 하는 데이터를 쓰게 됩니다.

그런데 이때도 라이트가 블락이 되는데, 어떤 경우에 블락이 되냐면, 자, 샌드 버퍼가 가득 찰 수가 있어요.

그러면 더 이상 데이터를 밀어 넣을 수 없기 때문에 그때 이 라이트 시스템 콜은 블락이 돼요.

언제까지 이 샌드 버퍼가 비어서 공간이 생길 때까지 블락이 되는 거죠.

이런 식으로 소켓에서는 리드할 때 또 라이트 할 때 각각 리시브 버퍼와 샌드 버퍼의 상태가 어떤지에 따라서 블락이 되는 거죠.

자, 그럼 이제 넌 블락 I/O에 대해서 한번 살펴볼게요. 넌 블라 키 I/O는 아까 앞에서 봤던 블락 I/O와 다르게 프로세스 혹은 스레드를 블락시키지 않고 요청에 대한 현재 상태를 즉시 리턴 한다는 게 특징입니다.

이 도식으로 살펴보면 유저 스레드 에서 리드라는 이름의 시스템 콜 호출 하는데 이번에는 넌 블라킹 모드로 실행을 했어요.

그러면은 시스템 콜 호출 하는 순간 커널 모드로 컨텍스트 스위칭이 되고 그때의 커널 모드에서는 리드 I/O 작업을 실행시킵니다.

그리고 나서 이 커널에서 바로 리턴을 시켜요.

아직 요청한 데이터가 준비되지 않았기 때문에 리눅스 기준으로는 - 1이라는 값을 리턴을 하고요.

그러면서 동시에 E, again이나 EWOULDBLOCK이라는 에러 코드도 함께 리턴을 합니다.

그러면 이때 이 스레드는 아까 블락 I/O와 다르게 넌 블라킹 I/O로 호출 했기 때문에 블락이 되지 않고 이어서 다른 코드를 실행할 수 있게 돼요.

그렇게 실행을 하는 동안에 이 I/O 디바이스로부터 읽을 준비가 됐다 라는 응답이 커널로 오게 되고 커널은 이제 데이터를 준비를 해, 뭐, 좋아요.

한편 이 스레드는 쭉 실행을 하다가 I/O에 대해서 다시 한번 read 시스템 콜 호출 하는데 마찬가지로 넌 블라킹 모드로 호출합니다.

그럼 다시 커널로 컨텍스트 스위칭이 되고 이때는 이제 데이터가 준비되어 있는 상태기 때문에 이 커널이 다시 유저 스페이스에 있는 스레드 쪽으로 요청했던 데이터를 전송을 하게 돼요.

그러면 그 데이터를 이제 유저 스레드에서 다시 읽게 되고 이어서 작업을 처리를 하게 되는 거죠.

이런 식으로 넌 블라킹 I/O는 스레드를 블록 시키지 않고 즉시 리턴하기 때문에 스레드가 다른 작업을 이어서 수행할 수 있는 그런 장점이 있습니다.

그럼 이 넌블로킹 I/O를 소켓에서 한번 살펴볼게요.

소켓에는 샌드 버퍼와 리시브 버퍼가 있다고 했습니다.

자, 그러면 이제 넌블로킹 I/O로 동작을 하게 되면 지금 소켓 통해서 소켓 내에, 예를 들어 데이터를 보낸다고 했을 때, 소켓 내에 되고 리시브 버퍼에 데이터가 있는지 리드로 확인을 해요.

아까 블로킹 I/O 같은 경우에는 이 상황에서 데이터가 아직 없다면 이 리드 시스템 콜 호출 하 쓰레드가 풀리게 되지만 지금은 넌블로킹 I/O이기 때문에 이 리시브 버퍼에 데이터가 없다면 그냥 없다고 알려주고 이 리드 시스템 콜에 대한 호출은 바로 종료가 돼요.

그러니까 블락이 안 되는 거죠.

마찬가지로 소켓 S에서 라이트를 할 때도 만약에 이 샌드 버퍼에 데이터가 다 차 있었으면 더 이상 라이트를 할 수 없기 때문에 아까 앞에서 봤던 블락 I/O 같은 경우에는 I/O 시스템 콜 호출 시 쓰레드가 샌드 버퍼의 공간이 생길 때까지 블락이 되지만, 넌 블락 I/O기 때문에 만약에 샌드 버퍼가 가득 차 있더라도 이 라이트를 호출한 스레드를 블락시키지 않고 적절한 에러 코드와 함께 바로 이 라이트 시스템 콜은 리턴이 되는 거죠.

이런 식으로 넌 블락 I/O가 소켓에서도 동작을 한다고 이해하시면 되겠습니다.

그러면 넌 블락 I/O에는 한 가지 이슈가 있는데 그게 뭐냐면 I/O 작업 완료를 어떻게 확인할 것인가, 이 이슈가 있습니다.

그래서 지금부터 넌 블락 I/O 결과를 처리하는 방식을 몇 가지 설명드릴게요.

먼저 첫 번째로는 완료되었는지 반복적으로 확인하는 거예요.

이건 아까 앞에서 봤던 그 예와 동일하죠.

가령 리드 시스템 콜을 넌 블락 모드로 호출을 했다면, 일단은 데이터가 아직 준비되지 않았기 때문에 리눅스라면 E-AGAIN이라는 에러 코드를 반환을 할 겁니다.

그러고 나면 이 스레드에서는 일단 다른 코드를 실행을 시켜, 다른 코드를 실행을 시키다가 오는 순간에 다시 한번 리드, 논 블라킹 시스템 콜을 호출해서 데이터가 준비됐는지 확인을 하는 거죠.

이런 식으로 내가 읽으려는 데이터가 준비될 때까지 확인하는 방식, 이 방식이 하나가 있습니다.

근데 이 방식에는 문제가 있죠.

먼저 완료된 시간과 완료를 확인한 시간 사이의 갭으로 인해서 처리 속도가 올라가는 데에 비해서 느려질 수가 있어요.

무슨 말이냐면 지금 보시면은 디바이스로부터 읽을 준비가 됐다라는 리스폰스를 이 타이밍에서 받아서 요 타이밍에 이제 준비가 됐는데 실제로 이 시스템 콜을 통해서 이 스레드가 준비했는지 다시 확인한 타이밍은 지금 요 타이밍이잖아요.

그래서 242만큼의 타임 갭이 발생을 하는 거죠.

그 말은 이 처리가 이 시간만큼의 딜레이가 생겼다는 의미로도 해석할 수 있겠죠?

요런 문제가 하나 있고요. 어떤 문제가 있냐면, 논블록 I/O 작업이 완료되었는지 반복적으로 확인을 해야 하기 때문에 CPU를 낭비하는 일이 발생을 하죠.

가령 예를 들어서 소켓 I/O 같은 경우에 지금 이 그림이 네트워크 상에서 데이터를 주고 받으려고 소켓 2개가 연결이 된 거잖아요.

근데 데이터를 보내는 쪽에서 언제 데이터를 보낼 줄 모르니까 데이터를 기다리는 쪽 입장에서는 계속 기다려야 되는 거죠.

언제 올지 모르는 데이터를. 그러면 주기적으로 계속 확인을 해야 되니까 그렇게 주기적으로 확인할 때마다 1번, 2번, 3번, 그렇게 확인할 때마다 CPU 사이클을 사용하게 되니까 낭비가 되는 거죠.

이게 지금 이 한 종류의 소켓 연결만 놓고 봐도 이런데 서버 입장에서 보면 지금이 얘만 놓고 봐도 총 8개의 소켓 연결이 있거든요.

그런데 그러면 이것을 다 하나하나 돌아가면서 데이터가 왔는지 안 왔는지 데이터가 왔는지 안 왔는지 데이터가 왔는지 안 왔는지 서버 입장에서 계속 확인을 하는 게 되게 비효율적이고 CPU를 낭비하게 되는 거죠.

그러면 어떤 분은 이렇게 생각하실지도 모르겠습니다.

음, 블록으로 동작하지 말고, 논블로킹으로 그렇게 하면 되는 것 아니냐, 이렇게 생각하실 수도 있는데, 만약 그러면 지금 이 상황에서 불러, 친구들, 굉장, 합격, 해볼게요.

그러면 이 계속해서 이 클라이언트로부터 데이터 요청이 오는 것을 이드 하면서 블로킹 돼서 기다린다고 해볼게요.

그러면 얘는 여기서 계속 기다려요. 여기서 블로킹, 계속 기다린다는 말은 스레드가 여기서 멈춰 서서 더 이상 진행을 못 한다는 거죠.

그런데 공교롭게도 이 친구가 데이터를 계속 안 보내고 있어요.

데이터를 계속 안 보내고 있는 상태에서 나머지 친구들이 나머지 클라이언트들은 이 서버에 요청을 한 거예요.

서버에 다 막 데이터를 보내는 네 지금 스레드는 여기에다가 지금 계속해 블로킹에 대해서 아무것도 처리를 못 하고 묶여 있는 상태기 때문에 다른 쪽 소켓에 데이터들이 다 들어갔다고 할지라도 처리를 못 해 주는 거죠.

그러면 다른 쪽 소켓과 연결된 클라이언트들 입장에서는, 어, 내 데이터가 아직도 처리가 되고 있지 않는 거지?

이렇게 불만이 생길 수 있는 거죠.

그래서 이 소켓을 블로킹 모드로 리드를 할 수는 없고요.

그러면 좀 눈치 빠른 분들은 이렇게 생각하실 수도 있습니다.

그러면은 이 모든 소켓에 대해서 얘네들이 클라이언트로부터 데이터가 들어오길 기다리고 있으니까, 그중에 하나라도 데이터가 들어오면 여기 지금 데이터가 들어왔다고 OS 에서 혹은 커널에서 알려 주면 되는 거 아니야?

이렇게 생각하시는 분들도 있을 거예요.

그런 방법이 있어요. 실제로 그런 방법이 있습니다. 그 방법이 바로 이 I/O 멀티플렉싱이라는 방법인데요.

이 I/O 멀티플렉싱 형벌로는 다중 입출력 사용인데요, I/O 멀티플렉싱은 관심 있는 I/O 작업들을 동시에 모니터링을 하고 그중에 완료된 I/O 작업들을 한 번에 알려주는 방식이에요.

이 그래프를 다시 보면 이번에는 I/O 멀티플렉싱을 사용해서 시스템 콜을 커널에 요청합니다.

이때 어떻게 요청을 하냐면 두 개의 소켓 3에 대해서 넌 블로킹 모드로 읽으려고 하니까 새로 들어오는 데이터가 있는지 알려주세요.

이런 시스템 콜이라고 이해를 하시면 돼요.

그러면 이 커널에서는 두 개의 소켓 3에 대해서 리드 I/O 요청을 네트워크 디바이스 쪽에 보내게 되고요.

그럼 이 시스템 콜을 호출한 쓰레드는 어떻게 되느냐?

여러 형태가 될 수가 있어요. 블락이 될 수도 있고, 이 시스템 콜을 어떻게 호출하느냐에 따라서는 블락이 안 되고 또 다른 코드를 실행할 수 있게도 만들 수 있습니다.

block I/O vs non-block I/O 개념을 설명합니다! 소켓 I/O를 예제로 주로 설명해요! I/O multiplexing(다중 입출력) 설명도 빠질 수 없겠죠? ;)

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널


block I/O vs non-block I/O 개념을 설명합니다! 소켓 I/O를 예제로 주로 설명해요! I/O multiplexing(다중 입출력) 설명도 빠질 수 없겠죠? ;)

block I/O vs non-block I/O 개념을 설명합니다! 소켓 I/O를 예제로 주로 설명해요! I/O multiplexing(다중 입출력) 설명도 빠질 수 없겠죠? ;)

Scripts