Reactive Manifesto (Reactive System Guide)

 

이번 포스팅의 주제는 Reactive Manifesto - Published on September 16 2014. (v2.0) 이다.

 

https://www.reactivemanifesto.org/

The Reactive Manifesto

 

리액티브 선언문에서는...

리액티브 시스템의 특성을 정의하고..

이에 따라 리액티브 시스템의 구축 가이드라인을 제공한다고 볼 수 있다.

 

리액티브 시스템의 특성 4가지

1. Responsive (응답성)

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 focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.

 

요약

- 즉각적인 응답을 할 수 있어야한다.

- 사용자에게 신속한 응답 속도가 일관되게 제공되어야한다.

 

 

2. Resilient (복원력)

Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission-critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.

 

요약

- 장애가 발생해도 응답성(Responsive) 을 유지할 수 있어야한다.

- Resilient 는 복제(replication), 봉쇄(containment), 격리(isolation), 위임(delegation) 으로 실현 될 수 있다.

- 복제

동일한 인스턴스로 복제하여 고가용성(High Availability)이 보장되도록 함.

- 봉쇄

장애는 각 component 에 포함되도록 한다. (A 의 장애인데 B 의 장애로 만들지 말라는 듯..)

- 격리

각 component 들 간에 장애와 복구는 격리되어야 한다.

즉, 장애가 발생하면 전파되면 안된다. 부분적 장애가 시스템 전체 장애로 전파되지 않음

- 위임

각 component 의 장애 복구는 외부 component 에 위임한다.

(여기서의 외부 componet 는 Client 가 아니다.)

 

 

3. Elastic (유연성)

Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.

 

요약

- 작업량이 많거나 적거나 간에 응답성(Responsive) 를 유지할 수 있어야한다.

- input rate 에 따라 시스템 자원도 반응성있게 증가시키거나 감소시킬수 있어야한다.

- 또한, contention points(경쟁 지점), central bottlenecks(중앙 병목현상) 등을 없애야한다.

- components 의 input 을 샤딩이나 복제를 통하여 분산시킴으로서 경쟁, 병목을 사라지게 할 수 있다.

 

참고

Resilient 에서는 복제가 장애를 대응하기 위한 수단이었지만,

Elastic 에서의 복제는 트래픽(작업량)을 분산시키기 위함이다.

 

 

4. Message Driven (메시지 기반)

Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.

 

요약

- 각 component 는 비동기 메시지 전달을 사용하여,

각 component 간의 loose coupling, isolation 과 location transparency 를 보장하도록 한다.

즉, 비동기(결과에 관심 없음) 메시지 전달로 각 component 간 독립적인 실행이 보장되도록 하며,

이러한 독립적 실행 경계간 메시지 전달은 장애를 전파하지 않게 하고 장애 복구를 외부 compenent 로 위임할 수 있도록 한다.

따라서, 비동기 메시지 전달로 Resilient (복원력) 를 달성할 수 있는 것이다.

- Message queues 에 back-pressure (배압) 를 적용하여 부하를 관리하고 흐름을 제어한다.

즉, 서로 다른 component 는 처리 속도가 다를텐데 중앙에 버퍼(메시지 큐)를 두고

component 스스로 배압을 조절하여 Elastic (탄력성) 을 유지한다.

- Non-blocking 통신을 하여 시스템 자원이 active 상태일 때만 소비되어 시스템 오버헤드를 낮출 수 있다.

 

 

결론

장애가 발생해도 Responsive(응답성) 를 유지해야하며.. -> Resilient(복원력)

작업량이 갑자기 많아져도 Responsive(응답성) 를 유지해야하며.. -> Elastic(유연성)

이를 실현하려면 Message Driven(메시지 기반) 방법을 사용할 수 있다.

 

즉, Reactive System 을 만들기 위해서는...

"Resilient 와 Elastic 을 가지는 Responsive 가 필요한데, 이를 위해 Message Driven 방법을 써야한다"

라고 말하는 것이다.