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

코드3-5 Non-Blocking I/O 지점 API 서버(SpringReactiveBranchOfficeController.java)

 

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

 

[그림 3-3]에서는 A, B 두 개의 지점으로 설명 했지만 코드상으로는 편의상 A 지점에 해당하는 하나의 지점 API 서버 코드로만 설명한다.

 

Non-Blocking I/O 방식의 지점 API 서버 역시 Blocking I/O 지점 API 서버와 마찬가지로 애플리케이션이 실행될 때 내부적으로 Map에 샘플 도서 정보를 미리 저장해둔다.

 

Spring WebFlux 기반 애플리케이션에서도 스레드의 차단 여부를 확안하기 위해서 Thread.sleep(5000)을 추가해 작업 스레드의 실행을 5초 지연시켰다. (16번 라인)

 

이제 클라이언트 PC 에서 본사 API를 호출했을 때, 지점 API 쪽에서 Thread.sleep(5000)이라는 지연 시간이 응답 시간에 그대로 반영되는지 확인해 보면 된다.

 

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

 

코드 3-6은 Non-Blocking I/O 기반의 본사 API 서버에 도서 정보를 요청하는 클라이언트 PC 역할을 하는 코드이다. 여기서도 본사 API 서버 애플리케이션이 실행 될 때 본사 API를 호출하도록 했다.

 

Non-Blocking I/O 방식의 클라이언트 코드에서 주목해야 할 부분은 역시 본사 API를 반복적으로 호출하는 부분(21 ~ 30번 라인)이다. for문에서 loop를 돌면서 본사 API 서버의 API를 5회 호출한다.

 

그런데 Blocking I/O 예제와는 다른 부분이 보인다. Blocking I/O 예제에서는 this.getBook(i)만 호출해서 전달받은 응답 데이터를 처리하면 되는데, 여기서는 subscribe()에서 응답 데이터를 전달받은 후에 처리하는 것을 볼 수 있다.

 

이렇게 처리하는 이유는 본사 API로부터 전달받은 응답이 Mono 타입이고, Mono는 Reactor에서 지원하는 Publisher 타입 중 하나이기 때문이다.

 

Publisher 인터페이스는 subscribe()를 호출해서 전달받은 데이터를 처리하도록 정의되어 있는데, Mono 역시 Publisher이므로 subscribe()를 호출해서 전달받은 데이터를 처리하는 것이다.

 

이번에도 애플리케이션을 실행해서 응답 결과를 확인해보자. 지점 API 서버 애플리케이션을 먼저 실행한 후, 본사 API 서버 애플리케이션을 실행한다.

 

실행 결과

 

조회 시간이 5~5.5 정도밖에 걸리지 않았다.

 

Spring MVC 기반 애플리케이션의 경우 Blocking I/O 방식이기 때문에 스레드가 차단되지만, Spring WebFlux 기반 애플리케이션의 경우 스레드가 차단되지 않기 때문에 위와 같은 결과가 나올 수 있는 것이다.

 

물론 실무에서 애플리케이션 성능을 확인하기 위해 이런 단순한 방식으로 테스트를 진행하지 않는다. 하지만 Blocking, Non-Blocking 관점에서 Spring MVC 기반 애플리케이션과 Spring WebFlux 기반 애플리케이션이 I/O를 어떻게 처리하는지에 대한 개념을 이해하는 데는 위와 같은 방식의 테스트만으로도 충분하다.