리액티브 마이크로 서비스 패턴은 다음과 같은 문제점, 솔루션, 해결책의 필요 조건이 있다.
문제점
관례적으로 자바 개발자는 HTTP 기반의 RESTful JSON API와 같은 블로킹 I/O 모델을 사용해 동기식 통신을 구현해 왔다. 블로킹 I/O를 사용하면 요청을 처리하는 동안 운영체제의 스레드를 점유하게 된다. 동시 요청 수가 증가하거나 요청과 관련된 컴포넌트가 증가하면 운영체제의 가용 스레드가 부족해 응답 시간이 늦어지거나 서버가 중단되는 문제가 발생 할 수 있다.
또한 앞에서 언급했듯이 블로킹 I/O를 과도하게 사용하면 마이크로서비스 시스템에 오류가 발생하기 쉽다. 예를 들어, 어떤 서비스의 지연 시간이 증가하면 가용 스레드가 부족해져서 클라이언트가 실패 할 수 있다. 이런 상황은 결국 클라이언트의 클라이언트에게도 동일한 유형의 문제를 유발하게 되며, 이것을 연쇄 장애라고 한다. 연쇄 장애와 관련된 문제의 처리는 '서킷 브레이커' 절을 참고한다.
해결책
논블로킹 I/O를 사용해 데이터베이스나 다른 마이크로서비스가 처리하길 기다리는 동안 스레드가 할당되지 않게 한다.
해결책의 필요 조건
해결책의 필요 조건은 다음과 같다.
- 가능하다면 비동기(asynchronous) 프로그래밍 모델을 사용한다. 즉 메시지를 보낸 후 수신자가 메시지를 처리하길 기다리지 않는다.
- 동기식 프로그래밍 모델을 선호한다면 논블로킹 I/O를 사용해 응답을 기다리는 동안에도 스레드 할당 없이 동기식 요청을 실행하는 리액티브 프레임워크를 사용한다.
- 마이크로서비스는 의존하는 서비스가 중단되더라도 응답할 수 있도록 탄력성 있게 설계돼야 하며, 중단된 서비스가 재개되면 클라이언트가 서비스를 다시 사용할 수 있어야 한다. 이것을 자가 치유(self-healing)라고 한다.
Reactive Manifesto
2013년에 이런 방식의 시스템 설계 주요 원칙이 리액티브 선언문(https://www.reactivemanifesto.org/)로 발표되었다. 선언문에 따르면 리액티브 시스템은 메시지 기반의 비동기 통신을 사용해 탄력성, 확장성, 유연성을 가져서 장애에 강하다. 탄력성과 유연성을 갖춘 리액티브 시스템은 응답성이 높으며 즉각적으로 반응한다.
The Reactive Manifesto
Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems
www.reactivemanifesto.org
'MicroService Architecture > Microservice Design Pattern' 카테고리의 다른 글
| 분산 추적 (0) | 2021.03.06 |
|---|---|
| 로그 분석 중앙화 (0) | 2021.03.05 |
| 구성 중앙화 (0) | 2021.03.05 |
| 에지 서버 패턴 (0) | 2021.03.05 |
| 서비스 검색(Service Discovery) 패턴 (0) | 2021.03.05 |
