Spring Webflux

Spring Webflux

• Spring5에서 새롭게 추가된 모듈
• 비동기적인 웹 애플리케이션 개발을 지원
• Reactor 라이브러리를 이용하여 리액티브 프로그래밍을 지원
• 적은 스레드로 많은 요청을 처리할 수 있음
• HTTP 클라이언트도 제공
• 함수형 프로그래밍을 지원
• Java와 Kotlin 모두에서 사용할 수 있음
• Spring Boot와 함께 사용하여 웹 애플리케이션을 구축 가능

webmvc

• Spring MVC는 기본적으로 blocking이고 동기방식을 사용한다.
• 사용자의 요청이 들어올 때마다 Thread를 생성하여 처리한다.
• 보통은 요청 시마다 스레드를 생성, 삭제해 주면 일정한 리소스가 지속적으로 소모되므로 Thread를 미리 생성해 저장해 두는 Thread Pool 을  생성해 사용한다.
• spring mvc 같은 경우 요청이 들어오면  Queue에 쌓고 순서에 따라서 Thread를 하나 점유해 요청을 처리한다.
• 스레드 수를 초과하는 요청이 발생한다면 계속해서 요청이 큐에 대기하게 되는 Thread Pool Hell 현상이 발생할 수 있다.

 

webflux

• webflux는 이 요청을 처리하는 방식이 Event-Driven 방식이고 비동기 non-blocking 방식이다.
• webflux는 이벤트 루프가 돌아서 요청이 발생할 경우 그것에 맞는 핸들러에게 처리를 위임하고 처리가 완료되면 callback 메서드 등을 통해 응답을 반환한다.
• 이 방식의 경우 요청이 처리될 때까지 기다리지 않기 때문에 Spring MVC에 비해 사용자의 요청을 대량으로 받아낼 수 있다는 장점이 있다.

WebFlux를 사용하는 이유

• 비동기 non-blocking 방식의 리액티브 개발에 사용됩니다.
• 서버 프로그램이 효율적으로 동작해서, cpu, thread, memory에 자원을 낭비하지않고 효율적으로 동작하는 고성능 웹 어플리케이션을 개발하는 걸 목적으로 합니다.
• 서비스간 호출이 많은 마이크로 서비스 아키텍처에 적합하다

"적은 양의 스레드" 와 "최소한의 하드웨어 자원" 으로 동시성을 핸들링하기 위해 Webflux가 탄생하였다. 
함수형 프로그래밍이 webflux의 기반이 되었다

 

WebFlux 함수형 스타일의 특징

1. 모든 웹 요청 처리 작업을 명시적인 코드로 작성하게 되어있다.
   • 기존의 Spring MVC는 어노테이션에 의한 흐름 관례를 사실상 외워야 코드의 해석이 가능하다.
   • (어노테이션의 명시적인 분석이 힘들다.)
   • 함수형 타입의 WebFlux는 명시적인 코드로 작성하기 때문에 메소드 시그니처 관례와 타입체크가 불가능한 어노테이션에 의존하는 MVC 스타일보다는 명확하다.
   • 정확한 타입 체크 가능
2. 함수 조합을 통한 편리한 구성, 추상화에 유리하다.
   • 함수형 스타일이기 때문에 추상화와 모듈화에 유리하다.
   • MVC 보다 확장에 유리하다.
3. 테스트 작성이 편리하다.
   • Spring MVC 는 Controller 나 Service 단위를 테스트하기위해서는 사실상 WebTest 를 진행해야하지만
   • WebFlux는 핸들러 로직과 요청 매핑, 리턴 값 처리까지 단위테스트로 작성 가능

 

Reactor Library

• Java 8+에서 작동하는 Reactor 라이브러리를 통해 구현되는 Reactive Programming 라이브러리
• Reactor는 Spring Framework 5에서 사용되는 기반 라이브러리 중 하나이다.
• Spring WebFlux와 같은 Spring 프로젝트에서 Reactive Programming을 지원하기 위해 사용된다.
• Reactor는 Reactor Core, Reactor Addons 및 Reactor Netty로 구성된다.

 

Reactor Core

• Reactor의 핵심 라이브러리
• Flux와 Mono와 같은 Reactive Stream 기반 타입
• Flux와 Mono에 대한 변환 작업을 수행하는 연산자
• Hot Sequence를 생성하는 Hot Stream에 대한 도구가 포함되어 있다.

Reactor Addons

• Reactor Core에 추가적인 기능을 제공하는 라이브러리
• Retry 및 Circuit Breaker와 같은 더 나은 오류 처리, 로깅 및 성능 모니터링과 같은 기능을 제공한다.

Reactor Netty

• Reactor Netty는 Netty의 일부분으로 Reactor에서 사용하는 Reactor Netty HTTP 및 TCP 서버를 지원한다.

 

Mono,  Flux

리액터는 리액티브 스트림을 구현하는 라이브러리로 Mono 와 Flux 2가지 데이터 타입으로 스트림을 정의한다.
spring WebFlux를 사용하여 비동기적인 데이터 스트림의 처리를 리액터 라이브러리가 제공하는 데이터 타입인 Mono 와 Flux로 다뤄야 한다
"그렇기 때문에 WebFlux에서는 모든 응답을 Mono 혹은 Flux에 담아서 반환해 주어야 한다."

 

Mono 와 Flux 의 차이점

• Mono는 0-1개의 결과만을 처리하기 위한 객체
• Flux는 0-N개인 여러 개의 결과를 처리하는 객체

Reactor를 사용해 일련의 스트림을 코드로 작성하다 보면 보통 여러 스트림을 하나의 결과를 모아줄 때 Mono를 쓰고, 각각의 Mono를 합쳐서 여러 개의 값을 여러 개의 값을 처리하는 Flux로 표현할 수도 있다.

 

Mono <>

• Mono 는 0 또는 하나의 데이터 항목과 에러를 가진다.

Flux <>

• Flux 는 0 또는 하나 이상의 데이터 항목과 에러를 가진다.

 

Netty

• 프로토콜 서버 및 클라이언트와 같은 네트워크 응용 프로그램을 빠르고 쉽게 개발할 수 있는
• NIO (Non-Blocking Input / output) 클라이언트 서버 프레임 워크
• TCP 및 UDP 소켓 서버와 같은 네트워크 프로그래밍을 크게 단순화하고 간소화한다.

Netty 의 장점

• NIO 네트워크 기반 Netty 프레임워크는 비동기식 이벤트 기반 네트워킹 (Event Driven) 을 지원한다.
• Tomcat서버가 10,000건의 커넥션을 처리한다면, netty는 NIO 방식으로 이벤트를 처리하기 때문에 자원이 스레드를 계속 점유하며 Block 상태를 유지 하지 않는다. => 10배~100배의 커넥션을 처리할 수 있다.
• 네티의 경우에는 이벤트 기반 방식으로 동작하기 때문에 스레드 개수는 머신 Core 개수의 2배이다.

 

Netty 의 구조 : 핵심 컴포넌트

Channel

• 하나 이상의 입출력 작업을 수행할 수 있는 하드웨어 장치, 파일, 네트워크 소켓이나 프로그램 컴포넌트와 같은 Open된 Connection

CallBack

• 자신에 대한 참조를 제공하는 메서드
• 이벤트를 처리할 때 Netty 내부적으로 콜백을 이용하는데, 이때 ChannelHandler 인터페이스를 통해 이벤트를 처리

Future

• 작업이 완료가 될 경우 애플리케이션에 알린다.
• Future 객체는 비동기 작업의 결과를 담는 Plachloder의 역할을 한다.
• 이때 ChannelFuture 인터페이스를 이용해 결과값을 활용한다.

Event와 Handler

• Netty는 작업 상태의 변화를 알리기 위해 이벤트를 이용하고, 발생한 이벤트를 기준으로 Handler를 통해 트리거한다.

Event Loop

• 유저가 입출력을 요구할 경우의 흐름

PipeLine

• 이벤트 루프에서 이벤트를 받아 핸들러에 전달하는 역할을 한다.

 

Reactor는 Reactor Core의 Flux와 Mono와 같은 타입을 사용하여 비동기 및 이벤트 기반 시스템에서 처리 작업을 처리한다. Reactive Programming은 비동기 이벤트 처리 및 병렬 처리를 구현하기 위한 패러다임이며
비동기성, 일관성, 이벤트 기반 처리, 비동기 오류 처리 및 높은 가용성과 같은 이점을 제공한다.

 

Spring R2DBC

(Reactive Relational DataBase Connectivity)

Reactive Programming을 하는 과정에서 Database 사용이 필요한 경우에 사용한다.

많은 예제로 Project Reactor 기반의 Spring Webflux를 사용하며 Database를 사용해야할 때 R2DBC를 많이 사용한다.

 

"Spring에서 많이 사용하는 JPA를 사용할 수는 없나?"

 "사용할 수 있다. 하지만 사용하는 것이 좋진 않다."

 

JPA는 기본적으로 비동기를 제공하지 않는다.

즉, Webflux 기반에서 JPA를 사용하면 Database 부분에서 block되고, 그동안 thread가 기다리게 된다.

Webflux 같은 적은 양의 thread를 계속해서 사용하는 framework에서 이러한 작업은 비효율적이며 전체 시스템에 영향이 갈 수 있다. 이러한 문제를 해결하기 위해 나온 것이 R2DBC이다.

 

R2DBC는 Reactive programming 기반이다보니 Reactive programming이 가지는 장점을 그대로 갖는다.

즉, Blocking programming일 때보다 높은 동시성(High Concurrency)이 요구되는 상황에서 더 좋은 성능을 낼 수 있다.

Spring: Blocking vs non-blocking: R2DBC vs JDBC and WebFlux vs Web MVC

동시성(Concurrency)이 높아짐에 따라 MVC-JDBC를 사용하는 것보다 Latency는 더 줄었고, Throughput은 더 증가한다.

 

그러나 아직!

• 기술측면에서 숙련도가 높지 않다. Blocking 방식에 비해 사용자도 많지 않고, 커뮤니티의 부재, 노하우 및 자료의 적음, 피드백을 받기 어려움 등 이슈가 있다.
• 구현체 측면에서도 아직 제공되지 않는 데이터베이스 벤더가 있다. 또한, 공식적으로 벤더사에서 제공하지 않는 경우도 있다. 이런 경우에 추후 관리 측면에서 문제가 발생할 수 있으므로 도입하는데 고려해봐야할 점이 많다.
• Spring 진영에서는 R2DBC를 위한 Spring Data R2DBC 를 지원하지만 아직 부족한 점이 많다.

 

API 예제

Controller

@Controller
public class UserController {

    private final UserService userService;

    @GetMapping("/users")
    public Flux<User> getAllUsers() {
        return userService.getAllUsers();
    }

    @PostMapping("/users")
    public Mono<User> createUser(@RequestBody User user) {
        return userService.createUser(user);
    }

    @PutMapping("/users/{id}")
    public Mono<ResponseEntity<User>> updateUser(@PathVariable("id") String id, @RequestBody User user) {
        return userService.updateUser(id, user)
                .map(updatedUser -> ResponseEntity.ok().body(updatedUser))
                .defaultIfEmpty(ResponseEntity.notFound().build());
    }

    @DeleteMapping("/users/{id}")
    public Mono<ResponseEntity<Void>> deleteUser(@PathVariable("id") String id) {
        return userService.deleteUser(id)
                .map(user -> ResponseEntity.ok().<Void>build())
                .defaultIfEmpty(ResponseEntity.notFound().build());
    }
}

 

Service

public interface UserService {
    Mono<User> getUserById(String id);
    Flux<User> getAllUsers();
    Mono<User> createUser(User user);
    Mono<User> updateUser(String id, User user);
    Mono<Void> deleteUser(String id);
}

 

@Service
public class UserServiceImpl implements UserService {

    private final UserRepository userRepository;

    @Override
    public Flux<User> getAllUsers() {
        return userRepository.findAll();
    }

    @Override
    public Mono<User> createUser(User user) {
        return userRepository.save(user);
    }

    @Override
    public Mono<User> updateUser(String id, User user) {
        return userRepository.findById(id)
                .flatMap(existingUser -> {
                    existingUser.setName(user.getName());
                    existingUser.setEmail(user.getEmail());
                    return userRepository.save(existingUser);
                });
    }

    @Override
    public Mono<Void> deleteUser(String id) {
        return userRepository.deleteById(id);
    }
}