리액티브 프로그래밍과 WebFlux 예제의 정석! 스프링으로 시작하는 리액티브 프로그래밍: Spring WebFlux를 이용한 Non-Blocking 애플리케이션 구현

리액티브 프로그래밍과 WebFlux 예제의 정석! 스프링으로 시작하는 리액티브 프로그래밍

 

이제 우리도 리액티브 프로그래밍 시도해 볼까요?

 

웹 개발 패러다임의 대변혁 중 하나는 객체지향과 MVC 패턴을 적용한 모델 2 방식의 등장이죠. 화면 단위로 복잡하게 얽혀 있던 소스가 기능과 목적에 따라 깔끔하게 분리된 혁명적 사건이 일어났습니다.

 

몇 년 전부터 웹 개발자들 사이에서 ‘리액티브 시스템’이 이슈입니다. 비동기 메시지 통신을 기반으로 한 이 시스템은 현대 IT 시스템의 폭발적으로 증가하는 트래픽을 해결해 줍니다. 장애 발생 시에도 시스템이 온전하게 작동될 수 있게 하고요. 이미 네카라쿠배와 같은 IT 핵심 기업에서는 몇 년 전부터 리액티브 시스템을 이해하는 직원을 채용하고 있죠.

 

오늘은 리액티브 시스템을 구축하는 데 필요한 프로그래밍 모델인 리액티브 프로그래밍과 리액티브 프로그래밍의 핵심인 Non-Blocking I/O가 무엇인지 함께 알아보려고 해요. 자, 그러면 리액티브 시스템이 무엇인지부터 이야기해 봐요!

 

리액티브 시스템이란?

 

리액티브 시스템은 간단히 ‘반응을 잘하는 시스템’이라고 정의해 볼 수 있어요. 바로 클라이언트의 요청에 머뭇거리지 않고 즉시 응답해 주는 시스템이죠. 앞서 말했듯이 빠른 반응 속도를 바탕으로 기하급수적으로 증가하는 트래픽을 해결해 주기에 대규모 분산 시스템, 멀티 코어 기반의 클라우드 시스템, 모바일 시스템 등을 구축하는 데 적절합니다.

 

리액티브 프로그래밍과 Non-Blocking I/O

리액티브 프로그래밍과 WebFlux 예제의 정석! 스프링으로 시작하는 리액티브 프로그래밍

 

앞서 리액티브 프로그래밍은 리액티브 시스템을 구축하는데 핵심이 되는 모델이라고 했죠? 또한 리액티브 프로그래밍은 데이터를 비동기적인 방식으로 처리하는 데 Non-Blocking I/O를 사용한다고 했습니다. 지금부터는 Blocking I/O와 Non-Blocking I/O를 비교하면서 리액티브 프로그래밍에 대해 알아볼 거예요.

 

블로킹(Blocking)은 영어로 연상이 중단되는 현상을 말하고 I/O는 입출력, 즉 데이터를 주고받는 걸 말해요. 응용해서 생각해 보면 Blocking I/O는 데이터를 주고받는 과정에서 어떠한 중단 현상이 일어난다는 의미라는 걸 유추할 수 있겠죠?

 

위 그림과 아래 그림은 네트워크 통신의 입출력 과정에서 Blocking과 Non-Blocking I/O를 도식화한 거예요. 먼저 Blocking I/O부터 자세히 설명해 보겠습니다.

 

클라이언트 PC에서 도서 정보를 조회하기 위해 요청을 보냅니다. 그런데 클라이언트가 요청한 도서 정보를 가져오기 위해선 A 지점 서버와 B 지점 서버에 둘 다 접근해야 하는 상황이네요! 그래서 본사 API 서버는 A 지점 서버에 요청을 보냅니다.

 

여기서부터 핵심이에요! 그림에서 알 수 있듯이 본사 API 서버는 지점 API 서버가 데이터를 읽어오는 동안 멈춰 있어야(Blocking) 합니다. 그래서 본사 스레드가 쉴 수밖에 없는 시간이 생기는 거죠. 만약 이 시간에 본사 스레드가 일하게 한다면 조금 더 효율적일 텐데요!

 

물론 멀티스레딩 기법으로 추가 스레드를 할당하며 Blocking I/O 방식의 문제점을 해결할 수는 있는데요. 멀티스레딩 기법에는 컨텍스트 스위칭(Context Switching)이 발생하게 됩니다. 컨텍스트 스위칭은 스레드를 자꾸 번갈아 실행하면서 스레드 정보를 읽어오고 저장하고 하느라 낭비되는 에너지를 말합니다. 오늘은 멀티 스레딩에 대해 간단하게 이해하셔도 될 것 같아요.

 

리액티브 프로그래밍과 WebFlux 예제의 정석! 스프링으로 시작하는 리액티브 프로그래밍

 

그럼 Non-Blocking I/O는 어떻게 이 문제를 해결했을까요? 애초에 스레드를 차단하지 않아도 되도록 시스템을 설계했어요. 그래서 하나의 스레드로 많은 수의 요청을 처리할 수 있게 된 거예요! 위 그림처럼 한 개의 스레드가 실행되는 동안 A 지점에 도서를 요청하고 동시에 B 지점에도 도서를 요청합니다. 훨씬 효율적이죠? 이렇게 효율적이니 성능이 뛰어날 수밖에 없습니다.

 

물론 Non-Blocking 방식에도 단점이 존재합니다. 스레드 내부에 CPU를 많이 사용하는 작업이 포함되었을 때는 이 방식을 지양하는 편이 좋습니다. 성능에 악영향을 줄 수 있거든요.

 

또한 요청에서 응답까지 과정에서 한 번이라도 Blocking I/O가 포함되어 있으면 스레드가 차단되면서 병목 구간이 발생해 Non-Blocking I/O의 장점을 살릴 수 없게 됩니다. DB I/O부터 네트워크 I/O까지 전체 과정이 Non-Blocking I/O로 설계되어 있어야 뛰어난 성능을 자랑하는 시스템을 만들 수 있는 것이죠!

 

오늘은 이렇게 리액티브 시스템에 대해 간단히 알아보고 Non-Blocking I/O에 대해 설명해 봤어요. 오늘 소개한 모든 내용은 황정식 개발자의 스프링으로 시작하는 리액티브 프로그래밍을 참고해 작성했습니다. 다른 책과 비교해 리액티브 시스템, Non-Blocking I/O, 선언형 프로그래밍 등에 굉장히 많은 비중을 할애했습니다.

 

그리고 리액티브 프로그래밍을 위해 꼭 알아야 하는 리액터(Reactor)에 대해서도 자세히 소개하죠.

 

단순히 소스 코드만 제시하는 게 아니라 왜 이런 시스템이 필요한지 어떤 점이 장점인지 원리를 자세히 설명했기 때문에 리액티브 시스템의 A to Z를 확실히 이해할 수 있는 첫 번째 책이 될 거라고 자신합니다.

 

또한 웹 어플리케이션 개발에서 가장 많이 쓰는 스프링 프레임워크의 리액티브 버전인 WebFlux에 대해서도 스프링 MVC와 꼼꼼하게 비교 설명하기 때문에 웹 개발자라면 이 책을 통해 많은 지식과 인사이트를 얻으실 수 있을 거예요.

 

이제 우리 시스템에도 Spring WebFlux와 Netty 같은 비동기 서버 엔진을 적용해 볼까요? 황정식 개발자의 《스프링으로 시작하는 리액티브 프로그래밍》과 함께 시작해 보세요!

 

▼책 구매하러 가기▼

리액티브 프로그래밍과 WebFlux 예제의 정석! 스프링으로 시작하는 리액티브 프로그래밍