TIL 17 : 블로킹과 논블로킹

 

 

블로킹과 논블로킹에 대한 개념을 찾아서 학습해보고 알아야 하는 생각을 했다. 

 

오늘 MSA 아키텍처로 진행하고 있는 팀플젝에서 게이트웨이에서 다른 서비스 호출하려고 할 때 만난 트러뷸 슈팅도 한 몫을 했지만, 

 

프로그래밍을 하는데 있어서 블로킹과 논블로킹, 동기와 비동기 개념을 좀 알아둬야 하지 않을까 생각한다. 

 

 

이러한 블로킹과 논블로킹이란 개념이 나온 배경부터 알아보자

 

 

배경

---

 

이 블로킹과 논블로킹이란 개념이 어디서부터 나왔는지 알고싶었다. 

 

시작점은 입출력(I/O)로 부터 시작한다고 한다. 근데 모든 프로그래밍이 ..I/O부터 시작되지 않나..?

 

컴퓨터 프로그램은 보통 CPU와 I/O(입출력 장치)를 사용한다. 

예를 들어 서버가 DB에서 데이터 가져오기 같은 요청을 하면 CPU는 잠깐 멈추고 DB응답을 기다려야 한다. 

 

이런 걸 I/O 대기 시간이라고 한다. 

 

여기서 문제가 발생하는데 

CPU는 엄청 빠르고 I/O는 느리다는 것이다. 그런데 CPU가 I/O 기다리느라 멈춰 있으면 너무 낭비라는 생각이 든다. 

 

그래서 등장한 개념이 바로 블로킹과 논블로킹 그리고 동기와 비동기개념이다. 

 

 

"왜" 알아야 하나 ? 

---

 

1. 성능 차이를 만드는 핵심이기 때문이다. 

 

Blocking 방식은 요청마다 스레드 하나가 붙어서 기다려야 한다. 

많은 요청이 들어오면 스레드가 다 차버린다. 이 때 서버 과부하가 걸린다. 

Non-Blocking방식은 한 스레드가 여러 요청을 동시에 처리 가능해서 훨씬 효율적이다. 

 

블로킹	요청마다 기다림	요청 수 = 스레드 수	메모리 낭비, 느림
논블로킹	기다리지 않음	적은 스레드로 여러 요청	효율적, 빠름

 

2. Reactive Programming(리액티브)의 기반인 이유이다. 

 

Spring WebFlux, WebClient, Reactor 같은 리액티브 기술이 모두 이 Non-Blocking I/O(논블로킹 입출력) 개념 위에서 만들어졌다. 

 

Servlet 기반(Spring Mvc) -> 블로킹 (요청당 스레드 하나)

Netty 기반(Spring WebFlux) -> 논블로킹 (이벤트 루프 기반)

 

이 차이를 모르면 왜 WebClient를 써야하는지, 

왜 Gateway는 WebFlux기반인지 이해가 안간다고 한다. 

 

3. 시스템 설계의 기준이 되기 때문이다. 

 

대규모 트래픽 (수천~수만 요청)을 처리해야 하는 게이트웨이, API서버는 논블로킹 방식을 써야 한다고 한다. 

 

반면, 단순한 관리 콘솔, 백오피스는 블로킹으로도 충분하다고 한다. 

 

언제 어느 방식을 써야 하는가 판단할 때 필요한 개념이다. 

 

 

요약

---

 

 

CPU 상태	I/O 기다림 (멈춤)	I/O 기다리는 동안 다른 일 처리
스레드 사용	요청마다 하나	여러 요청을 하나로 처리
성능	단순하지만 비효율적	복잡하지만 고성능
대표 기술	Spring MVC, RestTemplate	Spring WebFlux, WebClient
기반	전통적인 Servlet	Netty + Reactor (비동기 이벤트 루프)