Reactive Programmming

Reactive Manifesto?

재심 2025. 1. 1. 12:21

 

Reactive Manifesto?

 

Reactive Manifesto (리액티브 선언문) 리액티브 시스템 설계 원칙을 정의한 문서
"리액티브 시스템을 만들기위해 어떤 조건을 갖춰야 하는지를 명세해놓은 가이드라인"
2013년에 처음 발표되었으며 4가지의 특성을 정의하고 있다.

 

공식 웹사이트: https://www.reactivemanifesto.org/

 

 

1. Responsive (응답성, 반응성)

  • 시스템은 사용자의 요청에 빠르고 일관되게 응답해야 한다.
  • 낮은 응답 시간과 고가용성을 유지하며, 시스템이 느리거나 장애가 발생한 경우에도 이를 적절히 처리해야 한다.
  • Responsive를 준수했을 때 오류처리도 단순화 할 수 있고, 신뢰성 있는 시스템을 구축할 수 있다.

2. Resilient (복원성)

  • 복제, 봉쇄, 격리, 위임에 의해 실현될 수 있음
    • 복제(Replication): 데이터를 여러 인스턴스에 복제하거나 서비스 인스턴스를 다수 실행하여 장애가 발생해도 다른 인스턴스가 이를 대체할 수 있도록 보장하는 방법.
      • 분산 데이터베이스에서 데이터를 여러 노드에 복제하여 한 노드가 장애를 겪더라도 다른 노드가 요청을 처리할 수 있음
    • 봉쇄(Containment):  장애를 국소화하여 전체 시스템으로 전파되지 않도록 막는 방법
      • Circuit Breaker 패턴: 서비스 간 호출에서 문제가 발생하면 요청을 차단하여 장애 전파를 방지
      • 프로세스 격리: 서비스가 별도의 프로세스나 컨테이너에서 실행되어 메모리나 리소스를 공유하지 않음
    • 격리(Isolation): 시스템의 각 구성 요소를 독립적으로 운영하여 장애 시 다른 요소가 영향을 받지 않도록 함
      • eg: 마이크로서비스에서 각 서비스가 독립된 데이터베이스와 리소스를 사용
    • 위임(Delegation): 작업을 다른 구성 요소나 프로세스로 위임하여 시스템의 복원력을 높이는 방법.
      • 메시지 큐를 사용하여 작업을 위임하고 비동기적으로 처리함으로써 장애 발생 시 작업 재시도를 보장
  • 시스템은 장애가 발생하더라도 지속적으로 작동할 수 있어야 한다.
  • 장애를 격리하고, 복구 메커니즘을 통해 전체 시스템의 안정성을 유지한다.
  • Resilient를 준수했을 때 장애가 나더라도 응답성이 유지될 수 있다. (장애가 전파되지 않으며 장애가 격리되고 복구되는 형태로 운영)

3. Elastic (탄력성, 유연성)

  • 시스템은 부하가 증가하거나 감소함에 따라 자원을 동적으로 조정할 수 있어야 한다.
  • 경쟁 지점이나 중앙 집중적인 병목이 없어야 한다. (샤딩 같은 것을 통해 입력을 분산할 수 있어야 함)
  • Elastic을 준수했을 때 유입량이 늘어도 응답성을 유지할 수 있다.

4. Message-Driven (메시지 기반)

  • 비동기 메시징 처리에 의존: 구성요소 간에는 비동기적으로 메시지를 주고받고 독립적으로 수행되어야 한다.
  • 메시지 큐: 비동기 통신을 하는 방법 중 하나로 메시지 큐를 이용하는 것이며, 메시지 큐를 통해 느슨한 결합이 가능하며 부하분산, 흐름제어를 지원 한다.
  • 복원

 

 

요약

 

4가지 원칙을 보았을 때 모두 응답성에 초점을 맞추고 있는 모습이다.

정리해보면 리액티브 시스템은 "가능한 즉각 응답"하고, "장애가 나도 응답성을 유지"하고 "작업량이 변해도 응답성이 유지"되어야 한다.

이를 어떻게 달성하냐면 그게 메시지 기반으로 비동기 논블로킹처리를 하면 된다는 것이다.

 

 

v1 manifesto

 

앞서 요약한 내용은 v2 manifesto이고 최초 발표된 v1도 존재한다.

 

interative는 responsive라는 좀 더 명확한 의미로 변했고, scalable도 뭔가 확장 개념이다보니 자원을 줄이고 늘리는 의미는 적절치 않아서 elastic으로 변경되었다고 한다.

 

근데 event-driven은 message-driven으로 바뀌었다. 둘의 개념은 다른데 왜 message-driven으로 변경되었을까?

 

Event-Driven, Message-Driven

  • Message: 이벤트, 커맨드, 쿼리 등 다양한 형태를 모두 수용.
  • Event: Message의 범주 중 이벤트만을 일컬음.

위의 정의를 바탕으로 생각해보았을때 메시지는 어떠한 형태이든 모두 수용하고, reactive system 에서는 형태에 관계 없이 단지 '비동기적이며 배압이 가능한' 형태로 데이터가 전달된다는 조건을 전제로 하고 있다.

 

그렇기 때문에 Reactive Manifesto V2에서는 Message-Driven으로 정의를 변경한 것..!

 

 

저작자표시 비영리