Hae-Riri
commented
3 years ago Spring WebFlux, Armeria로 Reactive+RPC 구현하기
모놀리식 아키텍처는 하나의 커다란 서비스와 저장소로 구성된 아키텍처로, 하나의 모듈이 변경되어도 전체 서버를 배포해야 하고 작은 기능의 문제점도 곧 서버 전체의 문제점이 되었다. 그리고 많은 코드가 엮여 있어서 비즈니스 요구 변화에 유연하게 대처하지 못했다.
MSA 등장
커다란 서비스는 작은 단위의 독립된 모듈로 쪼개지고 추가 기능이나 확장이 필요하면 해당 모듈만 변경하면 된다.
MSA에서의 문제
- 단일 애플리케이션 내부의 메소드 콜을 통한 정보 교환 -> 네트워크를 타고 모듈 간의 정보 교환 스레드 풀을 이용한 동기식 호출 방식은 코드가 간결하고 순차적으로 동작하기 때문에 개발자가 코드를 직관적이고 빠르게 작성할 수 있지만 상대방 응답이 올 때까지 블로킹된다. 만약 응답이 늦어지면 이 응답을 기다리는 데 스레드를 모두 소진해서 추가 요청을 처리할 수 없는 상태가 될 수도 있다. MSA에서는 타임아웃이 발생할 정도의 지연이 생기면 순식간에 다른 모듈로 전파되어 전체 시스템이 마비된다.
그래서, 스레드가 응답을 기다리지 않고 다른 일을 처리하다가 응답이 왔을 때 해당 일을 처리하게 해서 불필요하게 응답만을 기다리며 리소스를 점유하는 일이 없도록 하자는, '이벤트루프를 이용한 비동기 프로그래밍'이 등장한다.
이벤트 루프를 활용하면 요청을 보내고 응답이 올 때까지 무작정 기다리는 대신 자신에게 할당된 다른 여러 소켓의 요청을 순차적으로 처리한다. 더 이상 blocking되지 않도록 Spring 5부터 webFlux가 도입되면서 비동기 프로그래밍이 가능해졌다.
Spring WebFlux
Spring MVC
xml 기반의 환경 설정, dispatcher servlet 기반의 코드를 war로 패키징하고 이걸 톰캣과 같은 was의 docRoot에 배포한 뒤 was를 별도로 가동시켜야 애플리케이션이 동작한다.
- 관리의 이원화
- 애플리케이션 설정과 WAS 설정을 별도 관리
- 배포 및 설정 불편
- was 중지 -> war 배포 -> was 가동 등의 단계 필요
- xml 기반 설정은 애플리케이션 가동 전까지는 설정이 맞는지 틀린건지 알 수 없다.
- WAS 의존적.
MSA 시대에서의 극복
- 버전 3에서는 JavaConfig, 애너테이션 기반 설정 도입 -> 기존 xml 기반 설정의 불편함을 개선
- 버전 4에서는 spring boot의 AutoConfig -> 설정 간소화, WAS 내장을 통해 단일 JAR로 패키징 배포 가능
그럼에도 불구하고 비동기 논블로킹에 대한 지원이 없는 것이 문제가 된다.
Spring WebFlux
- 더 이상 WAS가 필요하지 않음. 기본 설정은 Netty(reactor-netty) 기반이다. 특정 WAS도 사용할 수는 있긴 함.
- Projector Reactor를 통해 리액티브 프로그래밍을 지원
Reactive Stream의 구현체. 단순히 JVM 기반에서 비동기 논블로킹 처리를 위한 스펙을 명시한 것으로, 다른 구현체로는 RxJava, Akka Streams 등이 있다. Armeria도 이 스펙을 직접 구현했다.
차이는 진입점 설정 애너테이션 기반 라우팅도 가능하고 함수 기반 라우팅도 가능하다.
// 애너테이션 기반 라우팅
@GetMapping("/hello")
@ResponseBody
public Mono<String> getHello() {
return demoService.getHello();
}
// 함수 기반 라우팅
@Bean
public RouterFunction<ServerResponse> routes(DemoHandler demoHandler) {
return RouterFunctions
.route(RequestPredicates.GET("/hello"), demoHandler::getHello);
}** webFlux는 mvc와 코드 생김새는 같으나 반환형이 다르다. MVC에서 일반적으로 사용하던 String,List 같은 plain object를 사용할 수 없고 반드시 Publisher Object로 감싸서 반환해야 한다.
-
DemoHandler.java
@Slf4j @Component @RequiredArgsConstructor public class DemoHandler { private final Validator validator; private final DemoService demoService; public Mono<ServerResponse> post(ServerRequest serverRequest) { Flux<DemoResponse> ret = demoService.post( serverRequest.bodyToFlux(DemoModel.class) .filter(demoModel -> { Set<ConstraintViolation<DemoModel>> validationResult = validator.validate(demoModel); if (validationResult.isEmpty()) { return true; } else { return false; } }) ); return ServerResponse.ok().body(ret, DemoResponse.class); }
}
- DemoService.java@Slf4j @Service public class DemoService {
public Flux<DemoResponse> post(Flux<DemoModel> demoModelFlux) {
return demoModelFlux.
flatMap(demoModel -> {
log.debug("demoModel : {}", demoModel);
return Flux.just(new DemoResponse(demoModel, true));
});
}}
#### Publiser Object
publisher object는 Mono와 Flux가 있다.
- Mono는 0 또는 1개의 아이템이 나올 수 있음을 의미
- Flux는 0또는 n개의 아이템이 나올 수 있음을 의미
> Mono<List<String>> 과 Flux<String> 비교
>
> 둘 다 여러개의 요소가 포함될 수 있음을 의미하지만 용도가 다름.
> Mono는 0또는 1개 이므로 List<String> 1개가 반환되기 때문에, 여러 개의 요소가 "한번에" 반환된다.
> Flux는 0또는 n개가 반환되므로 여러 개의 String 요소가 Stream 형태로 반환된다.
## Armeria 소개
java8, netty, http/2, thrift, gRPC 기반의 비동기 RPC/REST 라이브러리
애플리케이션의 성능 향상을 위해 http 대신 rpc를 도입하려다 보니 spring 에서는 rpc를 사용하는 게 제한적이다.
#### Armeria와 MSA
armeria를 통해 reactive streams 를 활용하면 많은 양의 데이터와 트래픽을 유연하게 처리할 수 있다. 또한 rpc를 통해서 마이크로 서비스 간 통신도 쉽게 처리할 수 있다.
RPC는 서버와 클라이언트 구조를 기반으로 작동하며, 각각의 클라이언트와 서버는 리모트 콜을 하기 위한 프로시저에 대한 인터페이스를 통해 서로의 요청에 대해 이해한다.
Pub/Sub 구조
비동기식 메시징 패턴으로, 메시지 기반의 미들웨어 시스템을 말한다. 주로 서버리스/마이크로 서비스 아키텍쳐에서 사용된다.
일반적으로 메시지를 전송할 때는 publisher(sender)가 subscriber(receiver)에게 직접 메시지를 전송한다. 하지만 pub/sub 모델에서는 publisher는 어떤 subscriber가 있는지 모르는 상태에서 메시지를 전송하고, subscriber는 publisher에 대한 정보 없이 자신의 interest에 맞는 메시지만을 전송 받는다.
pub/sub 구조는 비동기식으로 어떻게 작동하는가?
pub/sub 구조는 낮은 결합도로 인해 안정적이고 확장에 용이하지만 아무래도 브로커(채컬)을 통해 메시지를 전달하기 때문에 부하가 있어서 좀 느리다.