2025-09-03

배경

실시간 협업 환경에서 빈번한 I/O 작업 발생 (‘붙여넣기’, ‘변경 추적’)
짧은 시간 안에 MB 단위의 데이터 실시간 반영 필요 → 병목 현상 자주 발생
논블로킹 I/O 기반의 비동기 아키텍처 필수
기존의 Vert.x 기반 논블로킹 아키텍처는 내부 블로킹 로직이 다수 존재해 원활한 비동기 처리 X
Spring 생태계로 통합, 유지 보수 효율성을 살린 Spring WebFlux & Project Reactor 전환
- 리액티브 스트림 표준, 선언적/직관적 방식으로 고성능 논블로킹 I/O 처리 가능

Reactive System

소프트웨어가 가져야 하는 목표, 특징을 정의하는 아키텍처 패러다임
4가지의 핵심 원칙
1. 응답성 : 시스템은 항상 신속하고 일관된 응답을 제공
2. 회복탄력성 : 장애가 발생해도 시스템의 응답성은 유지
3. 탄력성 : 작업 부하가 변해도 시스템의 응답성은 유지
4. 메시지 주도 : 컴포넌트 간 비동기 메시지를 통해 통신하여 느슨한 결합과 격리 보장
메시지 큐, EDA와의 차이점
- 메시지 큐 : 비동기 통신을 위한 도구
- EDA(이벤트 주도 아키텍처) : ‘문단 삭제’ 등의 이벤트 중심으로 서비스 간 느슨한 결합 추구하는 설계 패턴
- 리액티브 시스템의 메시지 주도 원칙
  - 메시지를 유일한 통신 수단으로 하여 컴포넌트 간 명확한 경계 만들기
  - 장애 격리, 배압(Backpressure) 책임지는 것을 핵심으로 하는 아키텍처 원칙

Recative Programming

명령형 프로그램 : 어떻게 처리할 지 명시적으로 지시 (for loop, if, etc. 직접 제어)
선언형 프로그램 : 무엇을 원하는 지 목표 선언, 구체적 방법은 컴퓨터에 위임 (Stream API)

Recative Streams

Java의 Interface와 비슷한 역할
논블로킹 Backpressure를 표준화하여, Publisher가 Subscriber의 처리 속도를 넘지 않도록 데이터 흐름 제어
Project Reactor, RxJava, Akka Streams 등 여러 라이브러리들이 모두 해당 표준 인터페이스를 구현 → 높은 상호 운용성 확보
4가지의 핵심 인터페이스
1. Publisher : 데이터 스트림의 생성/발행 주체
  - subscribe(Subscriber s) : 데이터 스트림 생성
2. Subscriber : Publisher가 발행한 데이터의 소비 주체
  - onSubscribe(Subscription s) : 구독 시작 시 최초 1회 호출, 데이터 요청 개수 조절 준비
  - onNext(T t) : 새로운 데이터 수신 시 호출
  - onError(Throwable t) : 데이터 처리 중 에러 발생 시 호출
  - onComplete() : 모든 데이터 발행 성공적 완료 시 호출
3. Subscription : Publisher와 Subscriber 간 연결고리, 데이터 흐름 제어의 핵심 역할
  - request(long n) : 데이터 개수(n) 요청, Backpressure 구현 지점
  - cancel() : 구독 취소, Publisher에 데이터 수신 중지 알림
4. Processor : Publisher, Subscriber 역할 동시 수행 가능한 중간 처리자
  - Upstream Publisher로부터 데이터 구독 후, 가공하여 Downstream Subscriber에게 다시 발행

DP = 기억하며 풀기

results matching ""