Reactive System(리액티브 시스템)

응답이 잘 되고, 탄력적이며 유연하고 메시지 기반으로 동작하는 시스템을 말한다. 리액티브 시스템으로 구축된 시스템은 보다 유연하고, 느슨한 결합을 갖고, 확장성이 있다. 이로 인해 개발이 더 쉬워지고 변경 사항을 적용하기 쉬워집니다. 이 시스템은 장애 에 대해 더 강한 내성을 지니며, 비록 장애가 발생 하더라도 재난이 일어나기 보다는 간결한 방식으로 문제를 해결한다. 리액티브 시스템은 높은 응답성을 가지며 사용자 에게 효과적인 상호적 피드백을 제공한다.

[리액티브 시스템]

리액티브 선언문

4가지 핵심

응답성(Responsive) : 시스템이 가능한 한 즉각적으로 응답하는 것을 말한다. 응답성은 사용자의 편의성과 유용성의 기초가 되지만, 그것뿐만 아니라 문제를 신속하게 탐지하고 효과적으로 대처할 수 있는 것을 의미합니다. 응답성 있는 시스템은 신속하고 일관성 있는 응답 시간을 제공하고, 신뢰할 수 있는 상한선을 설정하여 일관된 서비스 품질을 제공한다. 이러한 일관된 동작은 오류 처리를 단순화하고, 일반 사용자에게 신뢰를 조성하고, 새로운 상호작용을 촉진한다.
탄력성(Resilient) : 시스템이 장애를 직면하더라도 응답성을 유지 하는 것을 말한다. 탄력성은 고가용성 시스템, 미션 크리티컬 시스템에만 적용되지 않는다. 탄력성이 없는 시스템은 장애가 발생할 경우 응답성을 잃게 된다. 탄력성은 복제, 봉쇄, 격리, 위임에 의해 실현된다. 장애는 각각의 구성 요소 에 포함되며 구성 요소들은 서로 분리되어 있기 때문에 이는 시스템이 부분적으로 고장이 나더라도, 전체 시스템을 위험하게 하지 않고 복구 할 수 있도록 보장한다. 각 구성 요소의 복구 프로세스는 다른(외부의) 구성 요소에 위임되며 필요한 경우 복제를 통해 고가용성이 보장된다. 구성 요소의 클라이언트는 장애를 처리하는데에 압박을 받지 않는다.
유연성(Elastic) : 시스템이 작업량이 변화하더라도 응답성을 유지하는 것을 말한다. 리액티브 시스템은 입력 속도의 변화에 따라 이러한 입력에 할당된 자원을 증가시키거나 감소키면서 변화에 대응한다. 이것은 시스템에서 경쟁하는 지점이나 중앙 집중적인 병목 현상이 존재하지 않도록 설계하여, 구성 요소를 샤딩하거나 복제하여 입력을 분산시키는 것을 의미한다. 리액티브 시스템은 실시간 성능을 측정하는 도구를 제공하여 응답성 있고 예측 가능한 규모 확장 알고리즘을 지원하고, 하드웨어 상품 및 소프트웨어 플랫폼에 비용 효율이 높은 방식으로 유연성을 제공합니다.
메시지 구동(Message Driven): 리액티브 시스템은 비동기 메시지 전달 에 의존하여 구성 요소 사이에서 느슨한 결합, 격리, 위치 투명성 을 보장하는 경계를 형성한다. 이 경계는 장애 를 메시지로 지정하는 수단을 제공공하고, 명시적인 메시지 전달은 시스템에 메시지 큐를 생성하고, 모니터링하며 필요시 배압 을 적용함으로써 유연성을 부여하고, 부하 관리와 흐름제어를 가능하게 한다. 위치 투명 메시징을 통신 수단으로 사용하면 단일 호스트든 클러스터를 가로지르든 동일한 구성과 의미를 갖고 장애를 관리할 수 있다. 논블로킹 통신은 수신자가 활성화가 되어 있을 때만 자원 을 소비할 수 있기 때문에 시스템 부하를 억제할 수 있다.

참조

https://www.reactivemanifesto.org

주문 처리 서비스에 적용하면

네 성질은 체크리스트의 독립 항목이라기보다 서로 연결된 설계 판단이다. 주문 API가 결제 시스템에 동기 호출을 보냈는데 결제 응답이 늦어지면 요청 스레드와 연결이 쌓여 새 주문까지 지연될 수 있다. 요청을 큐에 무제한 넣는 방식은 일시적으로 응답하는 것처럼 보여도 대기 시간과 메모리가 계속 늘어난다. 큐 길이의 상한과 요청 제한 시간을 정하고, 처리할 수 없는 입력에는 명확한 실패 응답을 반환해야 응답성의 상한을 관리할 수 있다.

flowchart LR
  고객[주문 요청] --> 게이트[요청 수 제한]
  게이트 --> 주문[주문 서비스]
  주문 --> 큐[용량이 정해진 메시지 큐]
  큐 --> 결제[결제 작업자]
  결제 --> 결과[성공 또는 실패 결과]
  결과 --> 주문

그림에서 요청 제한과 용량이 정해진 큐는 부하가 몰려도 대기 작업 수가 끝없이 커지지 않도록 하는 경계다. 결제 작업자를 늘리는 것은 탄력성에 해당하지만 결제 시스템의 허용 동시 요청 수를 넘기면 오히려 장애가 커질 수 있다. 결제 작업자가 실패했을 때 다른 주문 처리까지 멈추지 않게 격리하고, 실패한 메시지의 재시도 횟수와 중복 결제 방지 키를 정하는 것이 회복성의 구체적인 예다.

메시지 구동 방식은 송신자와 수신자가 같은 호출 스택을 공유하지 않게 해 준다. 하지만 고객에게 즉시 결제 성공을 약속하는 계약인지, ‘주문 접수’만 먼저 응답하고 결제 결과를 나중에 알리는 계약인지 결정해야 한다. 후자라면 클라이언트가 결과를 조회하거나 알림을 받을 경로가 필요하다. 이 선택 없이 큐만 넣으면 화면의 성공 표시와 실제 결제 상태가 어긋날 수 있다.

응답성은 평균 지연 하나로 판단하지 않는다. p95·p99 응답 시간과 타임아웃 비율, 큐의 대기 건수·체류 시간, 작업자 처리율, 외부 서비스 실패율을 함께 본다. 입력률이 처리율을 계속 초과하면 작업자를 늘릴지, 요청을 제한할지, 비필수 작업을 미룰지를 정해야 한다. Flowable 같은 스트림 라이브러리는 한 프로세스 안의 데이터 흐름을 조절하는 도구이고, 이 운영 경계들을 자동으로 만들어 주지는 않는다.

참고: Reactive Manifesto 원문.