Spring Webflux - 배경, 개념 Cpu bound vs I/O Bound, block vs non-block, mvc vs webflux

Cpu bound vs I/O Bound

스프링 웹플럭스는 대량의 트래픽을 처리하는데 특화되어 있고 I/O 바운드에 가깝다.

CPU Bound

CPU를 중점적으로 다루는 작업들
암호화 압축화
주로 CPU 계산 능력에 따라 성능이 좌우되는 것들

단일 CPU 코어에 두 개의 작업을한다면 어떨까? 동시간 대에 하나의 명령만 실행하기 때문에 실제로는 app1과 app2가 번갈아가면서 실행하게 된다. 이렇게 실행되는 과정에서 Context Switing이 일어나고 성능 저하가 발생.

메모리 -> CPU : register

컨텍스트 스위칭은 Register 과정을 초기화한다. 즉, 2번 앱 정보를 가져와서 실행.

-> 성능상 오버헤드 발생

해결 방법은 ?


multi core를 활용 -> 병렬 처리를 한다.

IO Bound

Input, Output -> 입출력 장치의 중점이 된 Bound

네트워크 주고 받는 행위도 포함

Client <----> Server: "Hello" 전달

-> 패킷을 주고 받음

어플리케이션 관점에서는 패킷의 수신 완료까지 대기 하기 때문에 CPU를 중점적으로 사용하는 관점이 아님

-> Http 프로토콜
-> 비즈니스 로직 처리 후 DB 연결
-> 외부 API 연결

하나의 웹서비스에 IO 작업이 여러 군데 산재되어 있음


만약 클라이언트로부터 많은 요청이 동시적으로 처리해야 한다면?

전통적인 해결 방법은 Thread를 늘리는 것 -> THREAD per Reqeuest

-> 쓰레드를 만들려면 메모리 필요 -> 10만 요청을 필요로 한다면 ? -> OOM

가용 가능한 다수의 thread pool을 만들어서 사용 -> 사용하고 반납하는 방식 -> 오버헤드를 줄일 수 있다.
-> 스프링 MVC에서는 톰캣을 통해 트래픽을 처리하도록 설계

Synca sync와 block non-block

Sync와 Async

말 그대로 동기적 비동기적 -> 순차적 vs 비 순차적

block과 non block

요청 이후 대기를 할 것인지, 바로 응답을 받을 것인지 -> 주로 I/O와 관련된 작업들
대기를 하면 Block, 안하면 Nonblock

block ->


8080 포트 서버에서 다음과 같이 데이터까지 받게 되면 연결을 종료할 때, 서버 시작 이후 클라이언트 연결이 되면, 이후 readline에서 대기하다가 hello blocking을 전달 받으면 그 다음 코드를 진행함

non block ->

blocking configure false로 non blocking 설정

요청을 대기하지 않음

하나의 쓰레드에서 io 요청을 대기하지 않기 때문에 여러 IO 작업을 번갈아가면서 할 수 있음 -> 여러 소켓 연결을 하나의 thread에서 처리도 가능 -> 메모리 효율적

I/O multiplexing

기존 보다 적은 쓰레드로 많은 트래픽

연결을 하나의 Thread가 담당하고, 여러 worker thread로 분산

MVC vs Webflux

• boot 2부터 지원
• reactive 스택에서는 reactor를 필수로 사용 -> 비동기 처리의 기반
• servlet 스택에서는 웹 요청부터 응답까지 하나의 쓰레드가 처리

mvc with tomcat

쓰레드 풀 전략을 사용 -> 요청에 대해 풀에서 만들어놓은 쓰레드로 활용

하나의 쓰레드, blocking io로 실행하기 때문에 문제 파악이나 직관적으로 이해할 수 있음

대량의 요청시 ? 쓰레드가 많이 필요하므로 효율적이지 못함

reactor 스택

netty 사용 -> non blocking event 기반 네트워크 프레임 워크, io multiplex 기반, 다양한 프로토콜 지원

이벤트 루프를 통해 동시적 요청을 단일 큐에 적재, 이벤트 루프가 해당 요청을 처리

netty는 여러 개의 이벤트 루프를 운영하면서 처리 -> Boss Event loop group - 보통 한 개의 이벤트 루프를 운영 , work thread-> 여러개

각 채널에는 채널 핸들러를 파이프라인으로 추가, 필터링, 프로토콜 처리 등을 단계적으로 처리

서버를 시작하면 acceptor로 받고 http 코덱을 거쳐 handler를 통해 처리

클라이언트, 이벤트 통신 -> netty
그 이후 -> reactor가 담당

Reactor 이론

reactive stream

비동기 처리를 위한 스펙

publisher <-> subscriber

표준을 보면 다음과 같다.

처리 속도 불균형 발생시 -> back pressure 를 통한 해결

처리할 수 없는 수준으로 데이터를 보내면 지연 등 문제
subscriber가 역으로 필요한 데이터를 요청하는 것으로 backpressure를 통해 데이터 흐름을 제어

subscriber가 request를 요청할 때 데이터를 받을 때까지 blocking을 하지 않는다는 점이 중요

---

reference: fastcampus 시그니처 백엔드 path 초격차 패키지 course 7