[트래픽 핸들링] Blocking, Non-blocking, Sync, Async I/O가 뭘까?(Feat. IBM 논란)
프로젝트가 배포단계에 들어서면서 다음 단계로 시야를 돌려야 할 타이밍이 왔다. 운영단계를 공부할 때가 온것같다.
그래서 트래픽을 핸들링하는 방법들에 대해서 나름 조사하고 공부해 볼까한다.
내 프로젝트는 딱히 많은 트래픽이 몰리는 서비스는 아니지만 머신러닝작업도 보유하고있어서 서버 자체가 처리에 사용할 리소스가 많은 편이라
트래픽이 몰리는 상황엔 위험할수있다.
그래서 쉐도우 복싱 느낌이 있지만 대용량 트래픽을 대비해 어떤 노력을 해야하는지 알아보고자 한다.
때문에 지금 서버들이 어떤 방법으로 서버의 I/O를 핸들링 하고있는지 정리해볼것이다.
서버의 I/O는 서버로 오는 요청, 요청의 응답 과정 전반을 포괄한다.
즉, 트래픽이라고 볼수있을것같다.
I/O란?
input/output의 약자로 데이터의 입출력을 의미한다.
- 네트워크,파일,디바이스 등 다양한 영역의 입출력을 포괄한다.
다양한 영역에서 I/O라는 개념이 쓰이지만 나는 서버 개발을 담당하고있으니 서버의 I/O를 예로 설명할 것이다.
I/O 모델
I/O 를 다루는 4가지 방법이 있다. 이 방법들을 I/O 모델이라고 부른다.
아래 자료는 IBM에서 4가지 I/O 모델을 구분 해놓은 표이다.
I/O에는 4가지 프로그래밍 기법들이 사용된다.
- Blocking
- Non-blocking
- Synchronous
- Asynchronous
아래에서 이 기법들에 대해서 정리할것이다.
I/O 모델은 4가지 기법들의 조합으로 만들어진다.
- 동기 + 블록킹 모델: Synchronous Blocking I/O model
- 동기 + 논블록킹 모델: Synchronous Non-blocking I/O model
- 비동기 + 블록킹 모델: Asynchronous Blocking I/O model
- 비동기 + 논블록킹 모델: Asynchronous Non-blocking I/O model
결론부터 말하자면 현대 백엔드에서 I/O는 Asynchronous Non-blocking I/O 모델을 이용해서 서버의 I/O를 관리한다.
비동기 기법 + 논블록킹 기법 을 합해서 만들어진 I/O 모델
Blocking I/O 와 Non-blocking I/O의 차이
- Blocking 이나 Non-blocking이 어떤 기법인지는 OS에서 한번쯤 공부했을것이다.
OS는 Blocking 이나 Non-blocking를 이용해서 커널과 프로그램간 I/O를 관리한다.
- OS에서의 Blocking 와 Non-blocking이 뭔지 알면 서버에서의 I/O 관리도 쉽게 이해가 될것이다.
간단하게 말하면 Blocking 와 Non-blocking 의 차이는 호출된 함수가 호출한 함수에게 ''제어권'' 을 바로 주느냐 안주느냐 로 구분할수있다.
Blocking I/O
- I/O 작업을 요청한 프로세스/스레드는 요청이 완료될때까지 블락됨
- A는 B가 결과를 줄때까지 작업을 할수없다.
A가 작업을 하다가 B에게 요청을 보냈을때 B가 결과를 리턴할때까지 A는 작업을 멈추고 기다리고있다.
Non-blocking I/O
- 프로세스/스레드를 블락시키지 않고 요청에 대한 현재 상태를 즉시 리턴하는것
- A는 B에 상관없이 작업을 계속 할수있다.
- A가 작업을 하다가 B에게 요청을 보냈을때 B가 즉시 자신의 상태를 리턴해준다
결과가 바로 준비된다면 결과를 리턴하고 준비되지 않는다면 준비되지 않음을 리턴한다.
- A는 자신의 작업을 계속 수행한다.
- B도 자신의 작업을 수행한후 결과가 준비되면 결과를 준비해둔다.
- A가 자신의 작업을 하다가 B에게 다시 한번 요청(확인)을 보내면 B가 자신의 상태를 반환해준다. (준비됨)
글로 보면 이해가 힘들것이다. 아래 영상을 한번 보면 이해가 될것이다.
Blocking 와 Non-blocking 의 단점
Blocking은 A는 B가 결과를 줄때까지 작업을 멈추고있어야하기 때문에 누가봐도 비효율적으로 보인다.
Non-blocking은 어떤 단점이 있을까?
- 3,4 과정에서 time gap이 발생한다.
즉, 준비가 완료된 시점에 A가 바로 결과를 가지고 작업을 하는게 아니라 A가 다시한번 요청을 한 시점에 작업을 할수있다.
준비완료 시점과 A가 재요청을 하는 시점 사이만큼 작업이 딜레이 되었다고 해석할수있다.
- 반복적인 확인은 CPU 낭비가 발생한다.
주기적으로 A는 B에게 결과가 준비 되었는지 확인해야한다. 이 작업 또한 낭비가 심하다.
서버 입장에서 보면 무수히 많은 I/O가 존재할텐데
Blocking 을 이용하면 결과가 올때까지 작업이 멈춰지기 때문에 딜레이가 너무 심하고
Non-blocking을 이용해도 딜레이를 완전 해결할수없을 뿐 아니라 확인작업이 주기적으로 발생해서 서버 부하가 심해진다.
I/O multiplexing
이를 해결하기 위해 요즘 서버들은 Non-blocking에서 작업 확인을 할필요가 없도록 I/O multiplexing 이란 기법을 도입해 구현되어있다.
- 관심있는 I/O작업들을 모니터링하고 완료된 작업들을 한번에 알려줌.
- 작업이 완료되면 완료 여부를 이밴트 등으로 알려줌으로 Non-blocking의 주기적인 확인작업이 필요없어진다.
핵심은 이미 우리가 사용하는 서버들은 Non-blocking I/O를 통해 I/O 요청 완료 전에도 다른 작업을 계속 수행하고있을수있다는 것이다.
Synchronous I/O 와 Asynchronous I/O 의 차이
Synchronous I/O 와 Asynchronous I/O 를 이해하기 앞서, 먼저 Synchronous와 Asynchronous의 개념부터 이해해야한다.
- Synchronous(동기): 여러 작업을 차례차례 순차적으로 수행한다.
- Asynchronous(비동기): 여러 작업을 독립적으로 수행한다. (여러 작업을 동시에 실행)
비동기
동기는 작업 A가 끝나고 B,C를 순차적으로 수행한다면,
비동기는 여러가지 CASE가 존재한다.
- 한명의 사람이 작업 A와 B 와 C를 번갈아 가면서 동시에 작업
- 두명의 사람중 한사람이 A와 C를 번갈아가면서 작업, 다른 한사람은 C를 동시에 작업
- 세명의 사람이 A B C를 각각 도맡아 동시에 작업
여기서 각 사람이 의미하는 바는 바로 Thread이다.
예를 통해 알아보자
- 총 4개의 작업을 Thread 2개가 2개씩 도맡아서 작업을 수행한다.
- Thread를 보면 햇반을 데우면서 김치썰기도 수행하는것을 볼수있는데, 저 구간이 non - block I/O임을 확인할수있다.
꼭 이 영상을 한번 보자
그런데 의문점이 든다. 멀티 쓰래딩이 비동기 프로그래밍이랑 똑같은 말인가?
Asynchronous Programming == MultiThreading?
비동기와 멀티쓰래딩은 같은 개념일까? -아니다.
- Asynchronous Programming 는 여러 작업을 동시에 실행하는 프로그래밍 방법론
- MultiThreading은 Asynchronous Programming을 실현하는 방법중에 하나이다.
Asynchronous Programming을 가능하게 하는 것은 바로 multiThreads 와 non-block I/O이다.
- 멀티 쓰래드로 작업을 나눠 가져서 동시에 수행할수있고 각 작업은 non-block I/O로 동작하면서 block없이 계속해서 작업을 수행할수있다.
서버의 I/O모델 - Asynchronous non-blocking I/O 모델
그래서 요즘 서버들은 multiThreads 와 non-block를 이용해 적은 쓰래드로도 여러 작업을 효율적으로 처리해 , 전체 처리량을 향상시키는 방향으로 발전중이다.
쓰래드는 생성 비용이 높고 Context Switching이 발생함으로 적은 쓰래드로 효율적으로 작업을 처리할수있는것은 매우 중요하다.
- non-blocking 이기 때문에 다른 작업을 호출해도 계속 자신의 작업을 이어갈수있다.
- 또한, I/O multiplexing 덕분에 호출한 작업의 결과가 준비되었는지 주기적으로 확인할 필요도 없다.
- 비동기로 동작함으로 멀티 쓰래드를 이용해 작업을 동시수행할수있다.
+ IBM 논란
I/O multiplexing이 Asynchronous Blocking I/O 모델에 속한다고 구분했는데 Asynchronous Non-blocking이다는 논란이 있다.
- 나는 개인적으로 Asynchronous Non-blocking 인것같다..
Reference
Blocking, Non-blocking, Sync, Async 의 차이 (tistory.com)
'개발자 준비 > 트래픽 핸들링' 카테고리의 다른 글
| [트래픽 핸들링] Spring WebFlux(feat. I/O model, Thread) (0) | 2022.03.16 |
|---|---|
| [트래픽 핸들링] Thread pool 과 Queue (Feat.Tomcat WAS) (0) | 2022.03.16 |
| [트래픽 처리 이슈] CDN (0) | 2022.02.21 |
