Reactive Programming ‐ Reactive System & Reactive Programming - thought-corner/Backend-PlayGround GitHub Wiki

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 드라이버를 결합해야만 진정한 리액티브 시스템의 성능을 끌어낼 수 있다.

트래픽이 폭주하더라도 시스템의 어느 한쪽이 OOM 등으로 무너지는 것을 막고 자신의 처리 능력(Capacity) 안에서 가장 안전하고 효율적으로 동작하도록 보장하는 방어 메커니즘이다.
Consumer-Driven : 데이터를 만들어내는 쪽(Publisher)이 일방적으로 데이터를 밀어 넣는(Push) 것이 아니라, 데이터를 소비하는 쪽(Subscriber)이 철저하게 트래픽의 주도권을 쥐게 된다.
Dynamic Adjustment : 실시간으로 데이터 수신량을 조절한다.
Graceful Completion : 모든 데이터를 동적으로 보내고 지체 없이 onComplete()를 호출하여 자원 낭비 없이 안전하게 통신을 종료한다.

1. 쓰레드 할당 및 필터 단계

클라이언트 요청 → 쓰레드 풀로부터 쓰레드를 할당
사용자의 HTTP 요청이 WAS에 도달하면 WAS가 관리하는 쓰레드 풀에서 유휴 쓰레드 하나를 꺼내 해당 요청에 할당한다.
서블릿 필터 : 할당된 쓰레드는 Spring 컨텍스트에 진입하기 전 톰캣과 같은 서블릿 컨테이너 레벨에서 공통 관심사를 처리하는 필터 영역을 거치게 된다.

2. Spring MVC 핵심 컨트롤러

디스패처 서블릿(Dispatcher Servlet) : 필터를 통과한 요청은 디스패처 서블릿으로 들어온다. 모든 요청을 중앙에서 받아 적절한 곳으로 위임하는 프론트 컨트롤러 패턴이다.
HandlerMapping + Controller : 해당 URI 요청을 처리할 수 있는 컨트롤러 메서드가 있는지를 조회 후 매핑된 Controller로 요청을 전달, 컨트롤러는 사용자가 보낸 파라미터를 검증 및 바인딩한 뒤 비즈니스 로직으로 넘긴다.

3. 비즈니스 로직 및 데이터 접근 단계

Service 레이어에서 핵심 비즈니스 로직이 실행된다.
데이터를 조회하거나 저장하기 위해 Repository를 호출하여 데이터베이스와 통신한다.
핵심 포인트 : 전통적인 JDBC나 비동기를 지원하지 않는 드라이버를 사용할 경우, DB에 쿼리를 날리고 결과를 받아올 때까지 해당 쓰레드는 블로킹 상태가 된다. 이 구간이 시스템 전체의 처리량(Throughput)을 제약하는 주요 병목 구간이 된다.

4. 응답 및 스레드 반납

DB 조회가 완료되면 Dispatcher Servlet으로 결과가 리턴된다.
쓰레드 반납 : 클라이언트에게 최종 HTTP 응답이 전송되면 해당 요청을 처리하기 위해 사용했던 쓰레드는 파괴되지 않고, 다시 WAS의 쓰레드 풀에 반납되어 다음 요청을 대기한다.

1. 이벤트 루프

2. 요청 1 유입 및 작업 위임

요청 1이 들어오는데 만약 이 요청이 CPU만 쓰는 단순 계산이라면 이벤트 루프가 바로 처리해서 응답한다.
하지만 DB 조회, 외부 API 호출, 파일 읽기 등 오래 걸리는 I/O 작업이라면 이벤트 루프는 자기가 직접 기다리지 않고 운영체제나 백그라운드 쓰레드 풀에 해당 작업을 처리해달라고 요청을 등록한다.

3. 막힘없는 동시 처리

요청 1의 I/O를 던져버린 이벤트 루프는 블로킹되지 않는다.
즉시 다음으로 들어온 요청 2, 요청 3을 받아서 똑같이 처리하거나 위임한다. 하나의 쓰레드로 수천, 수만 개의 동시 커넥션을 맺을 수 있는 이유가 바로 Non-Blocking 기반이기 때문이다.

4. 완료 이벤트

5. 응답 처리