리액티브. (2024-07-09)

코드 3-3 Blocking I/O 클라이언트(SpringMvcHeadOfficeApplication.java)

 

코드 3-3은 Blocking I/O 기반의 본사 API 서버에 도서 정보를 요청하는 클라이언트 PC 역할을 하는 코드이다.

 

이 예제 코드에서는 클라이언트 PC 역할을 하는 별도의 애플리케이션을 만든 것이 아니라, 편의상 본사 API 서버 애플리케이션이 실행될 때 본사 API를 호출하도록 간단하게 구현했다.

 

대부분의 코드가 본사 API를 호출하기 위한 코드이고, 실제로 주목해서 봐야 되는 부분은 26 ~ 29번 라인이다. for문을 이용해 본사 API 서버의 API를 5회 호출한다.

 

호출 결과를 예상하면, 코드 3-2 지점 API 서버의 코드상에서 Thread.sleep(5000)을 통해 호출당 5초 지연시켰기 때문에 전체 응답 시간은 대략 25초 정도가 되어야 할 것이다.

 

본사 API 서버가 지점 API 서버의 API를 호출할 수 있도록 지점 API 서버 애플리케이션을 먼저 실행한 후, 그다음에 본사 API 서버 애플리케이션을 실행한다.

 

실행 결과

 

실행 결과를 보면 전체 조회 시간이 약 25초 정도 걸렸다. 이제 Spring MVC 기반의 애플리케이션은 Blocking I/O 방식이기 때문에 스레드가 차단된다는 사실을 확실히 알 수 있다.

 

그렇다면 이번에는 Non-Blocking I/O 방식을 사용하는 Spring WebFlux 기반의 애플리케이션에서는 정말로 스레드가 차단되지 않는지 확인해보자

---

코드 3-4 Non-Blocking I/O 본사 API 서버(SpringReactiveHeadOfficeController.java)

 

코드  3-4는 [그림3-3] Non-Blocking I/O 예시에서 본사 API 서버에 해당되는 코드이다.

 

코드 3-1에서는 Spring MVC에서 사용하는 RestTemplate을 사용해 요청 전송 후, 응답으로 전달받은 도서 정보를 ResponseEntity 클래스를 사용해서 반환했다.

 

반면에 코드 3-4에서는 WebClient를 사용해서 요청을 전송한 후, 응답으로 전달받은 도서 정보를 포함한 Mono 타입으로 바꾸는 과정(29번 라인)을 거친 후에 최정적으로 Mono 타입의 객체를 반환한다.

 

WebClient에 대해서는 'Spring WebFlux' 장에서 자세히 설명한다.

 

지금은 WebClient가 Non-Blocking I/O 방식으로 리액티브 타입을 전송하고 수신하는 역할을 한다고 이해하면 된다.

 

어쨌든 코드3-4에서는 Non-Blocking I/O 방식을 지원하는 WebClient를 사용해서 지점 API 서버로 요청을 보내기 때문에 이 부분에서는 Non-Blocking I/O가 발생하여 현재 스레드가 차단되지 않을 것이라고 예상할 수 있다.

---

Mono

Mono는 Reactor에서 지원하는 Publisher 타입 중 하나로, 단 하나의 데이터만 emit하는 Publisher 타입이다.

 

일반적으로 HTTP 요청에 대한 응답으로 JSON 형식의 응답을 많이 사용하는데, JSON 형식으로 전달되는 응답 내부에는 여러 가지 결과 값이 포함될 수 있지만 JSON 형식의 응답 자체는 하나의 문자열로 구성된 단 하나의 데이터이기 때문에 Mono를 사용하기 가장 적합하다고 볼 수 있다.