Reactive Programming ‐ Reactive System & Reactive Programming

Reactive Programming - Reactive System & Reactive Programming

MVC 기반 아키텍처 흐름

1. Blocking I/O와 스레드 풀 고갈

• 200개의 스레드가 모두 DB 조회(200ms)나 외부 API 호출(500ms) 결과를 기다리며 대기(Block) 상태에 빠지게 된다.
• 리소스 낭비 : 이 대기 시간 동안 스레드들은 CPU 연산을 전혀 수행하지 않으면서도, 단지 응답이 오기를 기다린다는 이유만으로 시스템 리소스(스레드)를 점유하고 있다.
• 스레드 풀 고갈(Thread Pool Exhaustion) : 기본 Tomcat 설정인 200개의 스레드가 모두 이런 I/O 대기 상태에 묶여버리면, 이후에 들어오는 201번째 요청은 처리할 여유 스레드가 없어 큐에서 대기하게 되고, 결국 타임아웃이나 Connection Refused 에러와 함께 요청이 유실된다.

2. 스레드를 늘리는 것의 물리적 한계

• 쓰레드라는 자원은 공짜가 아니라는 것을 명심해야 한다.
• 메모리 오버헤드 : 스레드는 생성될 때마다 독립적인 스택 메모리(일반적으로 1MB)를 할당받는다. 스레드가 기하급수적으로 늘어나면 애플리케이션의 메모리 점유율도 감당할 수 없이 커지게 된다.
• 컨텍스트 스위칭(Context Switching) 비용 : CPU 코어 수는 제한적인데 동작해야 할 스레드만 많아지면, CPU가 여러 스레드를 번갈아 실행하기 위해 현재 상태를 저장하고 다른 상태를 복원하는 작업에 과도한 연산 능력을 낭비하게 되어 오히려 전체 처리량(Throughput)이 저하된다.

3. 패러다임의 전환: 리액티브 프로그래밍과 Non-Blocking I/O

• Event Loop 기반 비동기 처리 : 요청이 들어오면 대규모 스레드 풀 대신, 소수의 스레드(보통 CPU 코어 수와 동일하거나 2배)로 동작하는 이벤트 루프가 이를 수신한다.
• 작업 위임과 즉시 반환 : 스레드가 DB나 외부 API에 데이터를 요청한 뒤, 결과를 그 자리에서 기다리지 않고 즉시 스레드 풀로 돌아가 대기 중인 다른 클라이언트의 요청을 처리한다.
• 이벤트 콜백 : DB나 API로부터 응답 데이터가 준비되어 도착하면 시스템에 이벤트를 발생시키고, 여유가 있는 스레드가 해당 결과값을 받아 나머지 비즈니스 로직을 마저 처리한 뒤 클라이언트에게 응답한다.

4. 진정한 리액티브 아키텍처를 위한 조건

• 리액티브 스택의 높은 동시성 처리 이점을 극대화하려면 웹 계층만 비동기로 동작해서는 안 되며, 데이터베이스 접근 계층까지 모두 Non-Blocking으로 구성해야한다.
• 웹 계층을 WebFlux로 구현했더라도 DB 연결에 기존의 동기식 JDBC를 사용한다면 스레드는 결국 DB 응답을 기다리며 블로킹된다.
• 따라서 다수의 외부 API를 호출하여 시세 데이터를 병합하는 크롤러나, 높은 트래픽의 금융 데이터를 다루는 아키텍처에서는 기존 패러다임을 깨고 R2DBC와 같은 비동기 논블로킹 DB 드라이버를 결합해야만 진정한 리액티브 시스템의 성능을 끌어낼 수 있다.

Reactive
Spring WebFlux
우아한 기술 블로그 (배민)
OKKY 실제 테스트 결과
과연 매번 WebFlux는 옳을까?? reddit의 토론글