Reactive System에 대해 설명하고 Reactive Programming과의 차이를 설명합니다. 연계해서 event-driven과 message-driven에 대해서 설명합니다.

1. Reactive Programming vs
Reactive Systems

2. Key Takeaways
● 2015년 이후, 특히 ​​2016 년에 상업용 미들웨어 공급 업체와 그 사용자 단에서
Reactive에 대한 관심이 크게 증가함
● Reactive Programming은 구현 수준에서 Reactive System의 하위 집합임
● 성능/자원 효율성의 측면을 보면 Reactive Programming은 개발자에게 내부
논리/데이터 흐름 관리를 위한 구성 요소 수준에서의 생산성을 제공함
● 시스템 수준에서 복원력과 탄력성의 측면에서 Reactive System는 Cloud 기반
혹은 기타 대규모 분산 시스템 구축에 대한 Architects 및 DevOps의 생산성을
제공함
● Reactive System 구성 요소 내부에서 Reactive Programming을 사용하는 것이
매우 유용함

3. 관련 단어 - "스트리밍(streaming)", "경량의(lightweight)",
"실시간(real-time)
최근 Reactive가 인기있음

4. ● 응집력 있는 시스템을 만들기 위한 일련의 설계 원칙
○ 구현 기법, 관련된 도구 및 디자인 패턴을 이용해 분산 환경에서 시스템 아키텍처 및 디자인에
대해 생각하는 방법
● Reactive System
○ 차이를 만드는 것은 개별적으로 작동하면서 동시에 의도한 결과를 얻기 위해 함께 행동하는
것임, 즉 시스템!
○ 여러 개별 서비스를 하나의 단위로 통합하고 서로를 인식하면서 주변 환경에 대응할 수 있는
아키텍처 스타일을 기반으로 함
■ 서로 대칭적으로 확장/축소, 로드 균형 조정, 그 중 일부는 사전에 수행함
● Reactive Style(Reactive Programming)와의 차이
○ 단일 애플리케이션을 작성할 수 있지만 이는 퍼즐의 한 부분일뿐이고 시스템 자체를
reactive하게 만들지는 않음
Reactive - A Set of Design Principles

5. Reactive Manifesto
● 응답성(Responsiveness) - 현대 시스템의 핵심
○ 클라이언트 / 고객이 적시에 가치를 얻지 못하면 다른 곳으로 갈 것이라는 점을 인정함
○ 응답성이 없으면 근본적으로 고객이 가치를 얻지 못하고 이는 가치가 없을 때와 차이가 없음
● 응답성(Responsiveness)을 높이기 위해 필요한 두 가지
○ 탄력성(Resilience): 실패 상태에서 반응성
○ 유연성(Elasticity): 부하 상태에서 반응성
● 이를 달성하기 위해 시스템은 Message-Driven이어야 함

6. Functional Reactive Programming (FRP)
● FRP는 20년 전에 Conal Elliott에 의해 매우 정확하게 정의됨*
● 최근에 Elm, Bacon.js, Reactive Extensions (RxJava, Rx.NET, RxJS)와 같은
기술을 설명하기 위해 부정확하게 사용됨
● FRP를 지원한다고 주장하는 대부분의 라이브러리는 거의 Reactive
Programming만을 언급하고 있으므로 더 이상 논의하지 않을 것임
* FRP에 대한 자세한 내용은 여기서 다루지
않음

7. Reactive Programming
● 비동기 프로그래밍의 하위 집합
● 실행 흐름을 통해 제어 흐름을 제어하는 ​​대신 새로운 정보의 가용성이 논리
전달을 주도하는 패러다임
○ 문제를 여러 개별 단계로 분해해 비동기/논블로킹(non-blocking) 방식으로 각각 실행하고
Workflow를 생성하도록 구성할 수 있음
○ 비동기 - 메시지 또는 이벤트 처리는 임의의 시간에, 아마도 미래에 일어날 수 있음을
의미하고 이것은 non-blocking execution을 허용한다는 것임
○ 입력 또는 출력에 제한이 없음
● Amdahl‘s Law - 경쟁이 확장성의 가장 큰 적
○ 공유 리소스를 얻으려고 경쟁하는 쓰레드는 실행을 차단 당함 (현재 작업을 완료할 때까지
실행 쓰레드가 다른 작업을 수행하는 것을 방지할 필요는 없음)
○ 즉 자원이 점유되어 있는 동안 다른 유용한 작업을 수행할 수 없음

8. Reactive Programming

9. Reactive Programming
● 이벤트 주도형
● 컨트롤 흐름보다는 데이터 흐름에 중점을 둠
● 리액티브 프로그래밍 라이브러리용 API (Application Program Interface)
○ 두 가지 스타일을 혼합해서 제공함
■ Callback-based: 익명의 부작용 콜백이 이벤트 소스에 첨부되며 이벤트가 데이터 흐름
체인을 통과할 때 호출됨
■ Declarative: 기능 조합을 통해 일반적으로 map, filter, fold 등과 같이 잘 확립된 연결자를
사용함
○ 종종 windowing, count, trigger 등과 같은 스트림 기반 연산자를 제공함

10. Reactive Programming
● Reactive Programming 추상화의 예
○ Future/Promise - 값의 비동기 변환을 지원하지 않는 경우에도 추가할 수 있는 single-value,
multi-read/single-write 의미의 컨테이너
○ Stream - 무한한 데이터 처리 흐름으로 다수의 출처와 목적지 간 asynchronous, non-blocking,
back-pressure 파이프라인을 가능하게 함
○ Dataflow Variable - 입력, 절차 및 기타 셀에 따라 변경 사항이 자동으로 업데이트되는 단일
할당 변수(메모리 셀)
■ 실용적인 예는 스프레드시트임 셀에서 값의 변화가 모든 종속 함수를 통해 파급되어
새로운 값 "다운 스트림"을 생성함

11. Reactive Programming
● JVM 계열 Reactive Programming 기술을 지원하는 인기있는 라이브러리
○ Akka Streams, Ratpack, Reactor, RxJava 및 Vert.x
○ JVM의 Reactive Programming 라이브러리 간의 상호 운용성을 위한 표준인 리액티브 스트림
스펙(Reactive Streams specification, non-blocking back pressure 을 가진 asynchronous
stream 처리 표준을 제공하기 위한 발의)을 구현함

12. The Benefits
● 멀티 코어 및 멀티 CPU 하드웨어에서 컴퓨팅 리소스 사용 증대
○ Amdahl's law과 확장성(extension), Günther의 USL(Universal Scalability Law)에 따라 직렬화
지점을 줄임으로써 성능을 향상시킴
● 활성 구성 요소 간의 명시적 조정의 필요성을 제거함으로 인한 개발자
생산성을 증대함
○ 전통적인 프로그래밍 패러다임은 모두 asynchronous/non-blocking과 IO를 처리하기 위해
직접적이고 유지 보수 가능한 접근법을 제공하기 위해 고군분투하고 있음
○ Lock, Semaphore ...
● 구성 요소의 생성과 워크 플로우의 구성
○ Asynchronous 실행을 최대한 활용하려면 과도한 사용 또는 자원의 무한한 소비를 피하기
위해 배압(back-pressure)을 포함하는 것이 중요함

13. Event-Driven vs Message-Driven
● Reactive Programming - 일시적인 데이터 흐름 체인을 통한 계산에 중점을 둠
● Reactive System - 이벤트 주도형(분산 시스템의 통신 및 조정을 통한
탄력성과 유연성에 중점을 둠)은 메시지 기반임

14. Event-Driven vs Message-Driven
Event-Driven Message-Driven
● Event
○ 주어진 상태에 도달했을 때 구성
요소가 내보낸 신호
○ 다른 사람이 관찰하는 사실임
○ 지역적으로 사용함
● 주소 지정이 가능한 이벤트 소스에
초점을 맞춤
● 이벤트 기반 시스템 알림에서 Listener는
Event-Source에 종속되어 이벤트가
발생할 때 호출됨
● Message
○ 특정 대상으로 보내지는 데이터
항목
○ 확실하고 단일이며 목적지가 있음
○ 메시지는 분산 시스템에서의
통신이나 네트워크 통신을 필요로
할 때 사용함
○ 각각 송신자와 수신자가 분리되기
때문에 송신 및 수신이 비동기임
● 주소 지정이 가능한 수신자에 집중함
● 주소 지정 가능한 수신자는 Message
도착을 기다리고 메시지에 응답하고
그렇지 않으면 휴면함

15. Event-Driven vs Message-Driven
● 분산 환경에서 Message를 이용해서 Event-driven 프로그래밍 모델의 상대적
단순성을 유지할 수 있음
○ 메시지에 이벤트를 첨부해서 보냄으로써 네트워크를 통해 이벤트 중심 시스템을 연결함
○ 전문화되고 잘 정의된 용례
■ AWS Lambda, Spark Streaming, Flink, Kafka 및 Akka Streams와 같은 분산 스트림 처리
제품
■ Gearpump 및 Kafka 및 Kinesis와 같은 Distributed Publish/Subscribe 제품

16. Event-Driven vs Message-Driven
● Tradeoff
○ 장점 - 프로그래밍 모델의 추상화와 단순화
○ 단점 - 제어의 관점에서 손실됨
● Message는 분산 시스템의 현실과 제약을 포용하도록 강제함
○ 분산 시스템의 현실과 제약 - 부분적인 장애, 장애 감지, 삭제 / 중복 / 재정렬된 메시지,
이벤트의 견고함, 다양한 동시성의 관리 등
○ 과거에서 자주 반복된 것과 같은(예 : EJB, RPC, CORBA 및 XA) 네트워크가 존재하지 않는
것처럼 가장해서 빈 틈이 있는 추상화 뒤에 숨기는 대신 정면으로 맞붙음
○ 이 의미 및 적용 가능성의 차이는 복원성, 탄력성, 이동성, 위치 투명성과 분산 시스템의
복잡성 관리 등에 있어서 응용 프로그램 설계에 중대한 영향을 미침

17. Reactive Systems/Architecture
● 전혀 새로운 것이 아니고 70년대와 80년대에 나온 개념 - Erlang
○ Jim Grey, Pat Helland, Tandem System, Joe Armstrong, Robert Virding이 제안한 개념
○ 당시 너무 앞선 기술이었지만 지난 5 ~ 10년 동안 기술 산업계는 기업 시스템 개발을 위한
현재 "모범 사례"를 재고해야 했음
○ 오늘날의 멀티 코어, 클라우드 컴퓨팅 및 사물의 세계에 대한 반응 원칙에 대한 지식을
적용하는 법을 배우는 시간이었음
● Reactive System의 토대 - Message-Passing
○ 구성 요소 간 시간적 경계가 생겨 구성 요소가 시간에 따라 분리될 수 있음
○ 이는 동시성(Concurrency)과 공간(space)을 허용하여 배포(distribution)와 이동성(mobility)을
허용함
○ 이 분리(De-coupling)는 구성 요소 간의 완전한 격리에 대한 요구 사항이며 탄력성(Resilience)
과 유연성(Elasticity)의 기초를 형성함

18. From Programs To Systems
● 종단 간 논리(end-to-end logic)를 구축하지 않음
● 상호 연결성과 시스템 복잡성의 증대
○ 각 구성 요소는 여러 구성 요소로 구성되며 각 구성 요소 자체가 시스템이 될 수 있음
○ 소프트웨어가 제대로 작동하려면 점점 다른 소프트웨어에 의존하게 됨
○ 오늘날 우리가 만들어내는 시스템은 크고 작은 컴퓨터, 서로 가까이 있거나 거의 반으로
떨어진 컴퓨터에서 작동해야 함
● 어려워진 사용자 요구사항
○ 동시에 일상 생활이 원활하게 기능할 수 있는 시스템의 가용성에 점점 더 의존하고 있기
때문에 사용자의 기대 수준은 점점 더 어려워지고 있음
○ 사용자 및 비즈니스가 의존할 수 있는 시스템을 제공하려면 응답이 필요할 때 사용할 수 없는
경우 올바른 응답을 제공하는지 여부는 중요하지 않으므로 응답해야 함
○ 이를 달성하기 위해 우리는 실패에서의 반응성(탄력성)와 동적으로 변화하는 부하에서
반응성(유연성)을 유지할 수 있어야 함

19. 탄력성(Resilience)
● 실패의 대응성
○ 시스템의 고유한 기능적 특성 - 소급해서 추가 할 수 있는 것이 아니라 설계해야 함
○ 내결함성(fault-tolerance)을 뛰어넘음
○ 정상적인 성능 저하가 아니라 장애로부터 완전히 복구할 수 있는 것임 (자가 치유)
● 복원력 있고 자가 치유적인 시스템을 구축하는 열쇠
○ 인접한 구성 요소로 전파되는 오류를 피하기 위해 구성 요소 격리 및 오류 억제가 필요함
■ 대개의 경우 치명적인 계단식 오류 시나리오가 발생함
○ 해당 문맥이 포함된 구체화된 메시지로 다른 구성 요소 (감독자의 역할을 담당)로 전송되고
실패한 구성 요소 외부의 안전한 문맥에서 관리되도록 하는 것임
○ 여기에서 Message-Driving이 가능함
■ 모두가 겪어보거나 무시하는, 강하게 결합되고 부서지기 쉽고 깊게 중첩된 동기식 호출
체인에서 벗어나게 해줌
○ 이 아이디어는 호출 체인에서 실패 관리를 분리해 클라이언트가 서버의 오류를 처리할 책임을
없애는 것임

20. 유연성(Elasticity)
● 부하에서의 응답성임
○ 시스템의 처리량이 자동으로 증가하거나 감소해 데이터 센터의 노드/머신 추가 또는 제거와
같이 자동으로 리소스가 비례적으로 추가되거나 제거되는 다양한 요구를 충족시킴
○ 이는 사용량 당 지불할 수 있는 클라우드 컴퓨팅의 이점을 활용하는 데 필요한 필수 요소임
○ 자원 효율적, 비용 효율적으로 만들고 환경 친화적임
● 위치 투명성(Location Transparency)
○ CPU 코어에서 데이터 센터에 이르는 모든 규모에서 동일한 프로그래밍 추상화를 사용하여
같은 의미로 동일한 방식으로 시스템을 확장할 수 있는 기능임
○ 공간에서의 이러한 분리(decoupling) 와 실행 인스턴스의 참조에서의 분리가 비동기 메시지
전달을 통해 가능해짐

21. 생산성(Productivity)
● 시스템 구조가 생산성 저하에 최소한으로 영향을 미쳐야 함
○ 이것은 컴포넌트를 개발하는 것과 유지 보수하는 시점에 모두 적용되어야 함
○ 동시에 우발적 복잡성(accidental complexity) 을 최소화해야 함
○ 제대로 설계되지 않은 시스템은 생명 주기 내 유지보수성이 점점 떨어지고 문제를 찾아내고
수정하기 위한 시간과 노력의 양이 증가하기 때문에 중요함

22. 생산성(Productivity)
● 멀티 코어, 클라우드 및 모바일 아키텍처에서 가장 생산적인 시스템 아키텍처
○ 장애 격리 - 구성 요소간에 격벽을 제공하여 장애의 범위를 제한하여 장애가 전파되는 것을
막을 수 있음
○ 감독자 계층 구조 - 자체 복구 기능과 함께 다양한 단계의 방어 체계를 제공하므로 조사
비용을 들이지 않고 대부분의 일시적 장애를 많이 제거함
○ 메시지 전달 및 위치 투명성 - 최종 사용자 환경에 영향을 주지 않고 구성 요소를
오프라인으로 전환하고 교체하거나 경로를 변경할 수 있고 이를 통해 중단 비용, 상대적
긴급성 및 진단 및 수정에 필요한 리소스를 줄일 수 있음
○ 복제 - 데이터 손실 위험을 줄이고 장애가 정보 검색 및 저장의 가용성에 미치는 영향을 줄임
○ 탄력성 - 사용량이 변동함에 따라 리소스를 절약할 수 있으므로 부하가 적을 때 운영 비용을
최소화하고 부하가 증가할 때 정전 또는 확장성에 대한 긴급한 투자의 위험을 최소화함

23. Reactive System에서의 Reactive Programming의
역할● 컴포넌트 안에서 내부 로직과 데이터 흐름의 변경을 관리하기 위한 훌륭한
기법이자 또한 코드를 명확하게 하고 성능과 자원 효율성을 최적화할 방법을
제공함
● 문제 1. 탄력성 부재
○ 이벤트 기반 콜백 혹은 선언적 프로그램에서 연산 단계가 긴밀하게 연결되어 복원성을 얻기
힘들게 만듦
■ 데이터를 변형하는 체인의 수명이 짧고 콜백이나 결합자(combinator)가 익명 즉 주소로
지정할 수 없기 때문임
■ 예외를 전파해야 하는 위치가 분명하지 않고 일반적으로 전파될 수 없기 때문에 개별
단계의 복구가 어려워짐
○ 대개 외부 세계에 알리지 않고 성공 또는 실패를 직접 처리하기 때문에 클라이언트에게
오류가 전달됨
○ 데이터 흐름 체인의 단계 중 하나에서 오류가 발생하면 전체 체인을 다시 시작해야 함
○ 자가 치료할 수 있는 메시지 기반 대응 시스템과는 대조적임

24. Reactive System에서의 Reactive Programming의
역할● 문제 2. 유연성의 부재
○ 공간 분리가 아닌 시간 분리만 제공함 - 시간으로부터 분리되는 것은 동시성을 제공하지만
공간에서 분리되는 것은 정적인 상황뿐만 아니라 동적인 토폴러지에서 분산성과 이동성을
제공함
○ 위치 투명성의 부재
○ 이를 해결하기 위해 Message Bus, Data Grid, bespoke network protocols와 같은 추가적인
계층이 필요함

25. Reactive System에서의 Reactive Programming의
역할● Reactive System을 위해 설계된 라이브러리와 플랫폼
○ 예. Akka 프로젝트나 Erlang 플랫폼
○ 오랜 시간이 지나도 알기 쉬운 수명이 길고 주소가 지정 가능한 구성 요소를 사용함
○ 장애가 발생했을 때 장애를 발생시킨 메시지와 함께 컴포넌트를 고유하게 식별할 수 있음
○ 모니터링 솔루션은 컴포넌트 모델의 핵심인 주소 지정 가능성이라는 개념을 통해 전파되는
ID를 활용해 수집된 데이터를 제공하는 의미 있는 방법을 제공함
○ 주소지정 가능성과 장애 관리와 같은 기능을 수행하는 좋은 프로그래밍 패러다임을 선택하는
것은 운영에 도움이 된다는 것이 증명됨
■ 이것은 현실의 가혹함을 염두에 두고 설계되었고 장애를 막으려고 시도하는 과정에서
원인을 찾지 못하는 것보다는 장애를 예상하고 받아들일 수 있도록 하는 것임

26. Fast Data Streaming에서의 역할
● 함수형 결합자나 콜백과 같은 리액티브 프로그래밍의 구조를 사용하는 API를
제공함
● 사용자 관점에서 보면 일반적으로 지역적으로 사용할 때는 Event 기반/Stream
기반 추상화로 볼 수 있음
○ 대체로 최종 사용자 API 하부에서 Message-passing을 사용하며 노드 간의 스트림 처리
단계의 분산 시스템, 내구성 있는 이벤트 로그, 복제 프로토콜(replication protocols)을
지원하는 리액티브 시스템의 원칙을 사용함 이러한 부분은 보통 개발자에게 드러나 있지 않음
● 사용자 수준에서 Reactive Programming을 사용하고 시스템 수준에서
Reactive System을 사용하는 좋은 예임

27. Microservice에서의 역할
● Cloud를 지정된 배포 플랫폼으로 사용하는 자율적인 분산 서비스 시스템을
설계하는 것은 Reactive를 수용하면 제공되는 가치에서 많은 이점을 얻을 수
있음
○ Reactive Programming - 단일 Microservice 내에서 서비스 내부 로직 및 데이터 흐름 관리를
구현하는 데 사용됨
○ Reactive System - Microservice 사이에서 사용되며 메시지 주도로 가능해진 탄력성과
탄력성을 통한 반응성을 가진 재생되는 Microservice 시스템을 만들 수 있음

28. Mobile Application과 IoT에서의 역할
● 대규모의 정보 흐름
○ 연결된 센서, 장치 및 가전 제품의 폭발
○ 검색, 집계, 분석 및 푸시 아웃해야 하는 많은 양의 데이터를 생성함
○ 동시에 연결된 모든 장치를 처리하는 방법에 문제가 발생함
● 장치를 관리하는 백엔드 서비스
○ 장치 고장을 처리하기 위한 전략, 정보가 손실되었을 때, 서비스가 실패할 때를 대비하여
전략이 필요함
○ 모든 것을 관리하는 백엔드 시스템은 수요에 맞게 확장하고 완전히 복원력이 있어야 함
● Back-pressure
○ 많은 양의 센서가 데이터를 생성하고 데이터가 도착하는 속도를 처리 할 수 ​​없음
○ Back-pressure을 구현할 필요가 있음

29. Traditional Web Application에서의 역할
● 서비스 호출을 분기하고 비동기적으로 리소스를 가져오며 응답을 만든 후
클라이언트에 마샬링하는 등 요청/응답 워크 플로우를 구성할 수 있음
● Server-Sent Event/WebSocket
○ 대규모로 수행하면 열려있는 많은 연결을 유지하는 효율적인 방법이 필요함
○ IO가 차단되지 않는 경우 Reactive Programming은 이에 대한 도구를 보다 구체적으로 제공함
○ Streams/Futures를 사용하면 비 차단 및 비동기 변환을 수행하고 이를 클라이언트에 전달할
수 있음
○ 메시징을 받는 사람을 직접 주소 지정하는 것이 중요한 영역이기 때문에 상태가 유지됨
● 데이터 액세스 계층에서 중요한 역할을 함
○ 비효율적인 드라이버가 있는 SQL 또는 NoSQL 데이터베이스를 사용하는 것이 리소스
효율적인 방식으로 데이터를 갱신하고 쿼리함
○ 분산 캐싱, 데이터 일관성 및 노드 간 알림을 제공함

30. Reference
● Reactive Programming versus Reactive Systems: Landing on a set of simple
Reactive design principles in a sea of constant confusion and overloaded
expectations
● 리액티브 프로그래밍 대 리액티브 시스템
● 리액티브 선언문