한빛출판네트워크

끊임없는 혼란과 과한 기대의 바다에서 간단한 리액티브 설계 원리에 안착하기

 

2013년 "리액티브 선언문"을 공동작성한 이후, 우리는 리액티브라는 주제가 가상의 인식되지 않은 기술에서 수 많은 미들웨어 분야의 회사들이 사용하는 전반적인 플랫폼 전략으로 변화하는 것을 지켜봐왔다. 이 기사는 리액티브 프로그래밍 스타일로 코드를 작성하는 것과 응집성있는 전체로서 리액티브 시스템을 설계하는 것의 차이점을 살펴봄으로써 리액티브의 다양한 관점을 명확히 하고 정의할 것이다.

 

리액티브는 일련의 설계원칙

 

성공에 대한 최근의 지표 중 하나는 "리액티브"가 과부하된 용어가 되어 "스트리밍", "경량" 그리고 "실시간"과 같은 단어를 사용하는 좋은 회사에서 여러 사람들과 여러 가지 다른 것들과 관련되어 있다는 것입니다.

 

이 기사의 관점에서 볼 때, 리액티브는 일련의 설계 원칙으로 구현 기법, 툴링 그리고 디자인 패턴이 전체 시스템의 구성 요소 인 분산 환경에서 시스템 아키텍처와 디자인에 대해 생각하는 방식입니다.

 

다음과 같은 비유를 생각해보십시오 : 운동 팀 (야구, 농구 등)을 생각할 때, 예외적인 개인으로 구성되는 것을 보는 것은 드문 일이 아니지만, 그들이 아직 함께 움직이지 않을때, 무언가가 클릭되지 않고 하나의 팀으로서 효과적으로 작동하기 위한 시너지가 부족하여 "열등한"팀에게 지고 맙니다.

 

이 비유는 개별적으로는 훌륭한 리액티브 시스템이라 할지라도 생각없이 결합된 일련의 리액티브 응용 프로그램들과 리액티브 시스템 간의 차이점을 보여줍니다. 리액티브 시스템에서는 모든 차이를 만드는 개별 부품 간의 상호 작용입니다. 이는 개별적으로 작동하면서도 그들의 의도된 결과를 성취하기 위해 움직이는 기능입니다.

 

리액티브 시스템은 여러 개의 개별 응용 프로그램이 하나의 단위로 통합되어 주변과 반응하면서 인식하면서 서로를 인식 할 수있게 해주는 아키텍처 스타일입니다 -이 기능은 규모확장/ 축소,로드 밸런싱 그리고 일부 이러한 단계를 사전에 처리하는 것을 가능하도록 명확하게 합니다.

 

단일 애플리케이션을 리액티브 스타일로 작성할 수 있습니다 (즉, 리액티브 프로그래밍 사용); 그러나 그것은 단지 퍼즐의 한 부분일 뿐입니다. 위에서 살펴본 각 측면은 "리액티브"로 간주 될 수 있지만 시스템 자체를 리액티브로 만들지는 않습니다.

 

사람들이 소프트웨어 개발 및 디자인의 맥락에서 "리액티브" 라고 말하면 일반적으로 다음 세 가지 중 하나를 의미합니다.

• 리액티브 시스템 (구조 및 설계)
• 리액티브 프로그래밍 (선언적 이벤트 기반)
• 함수형 리액티브 프로그래밍 (FRP)

처음 두 가지를 강조하면서 이러한 관행과 기법이 의미하는 바를 살펴 보겠습니다. 보다 구체적으로 말하자면, 언제 사용하는지, 어떻게 서로 관련되는지, 그리고 각각의 이점을 기대할 수 있는지에 대해 논의 할 것입니다-특히 멀티 코어, 클라우드  그리고 모바일 아키텍쳐 시스템 구축의 맥락에서.

 

함수형 리액티브 프로그래밍 그리고 이 기사에서 앞으로의 논의에서 함수형 리액티브 프로그래밍을 왜 제외하기로 선택했는지에 대해 이야기해 보겠습니다.

 

함수형 리액티브 프로그래밍(FRP)

 

일반적으로 FRP라고 불리는 함수형 리액티브 프로그래밍 (Functional Reactive Programming)을 사람들이 가장 빈번하게 오해합니다. FRP는 20년 전에 Conal Elliott에 의해 매우 정확하게 정의되었습니다. 이 용어는 가장 최근에 Elm, Bacon.js, 리액티브 확장 (RxJava, Rx.NET, RxJS)과 같은 기술을 설명하는 데 잘못 사용되었습니다. FRP를 지원한다고 주장하는 대부분의 라이브러리들은 거의 오로지 리액티브 프로그래밍에 대해 이야기하고 있으므로 더 이상 논의하지 않을 것입니다.

 

리액티브 프로그래밍

 

리액티브 프로그래밍은 함수형 리액티브 프로그래밍과 혼동되어서는 안되며, 비동기 프로그래밍의 하위 집합과 새로운 정보의 가용성이 실행쓰레드에 의해 제어 흐름을 제어하는 대신 논리 전달을 이끌어가는 패러다임입니다.

 

문제를 여러 개별 단계로 분해하여 각각을 비동기식 및 비차단 방식으로 실행 한 다음 워크 플로우를 생성하도록 구성 할 수 있습니다-입력 또는 출력에 제한이 없음.

 

비동기는 옥스포드 사전에서 "존재하지 않거나 동시에 발생 함"으로 정의됩니다. 이 문맥에서 메시지 또는 이벤트 처리는 임의의 시간에, 아마도 미래에 일어날 수 있음을 의미합니다. 이것은 비치단 실행을 허용하기-공유리소스에 대해 경쟁하는 실행 쓰레드가 차단으로 인해 기다릴 필요없는 때문에 리액티브 프로그래밍에서 매우 중요한 기술입니다. 이것은 비차단 실행을 허용하기 때문에 리액티브 프로그래밍에서 매우 중요한 기술입니다. 공유 리소스에 대해 경쟁하는 실행 스레드가 차단에 의해 기다릴 필요가 없고(현재 작업이 완료 될 때까지 실행 스레드가 다른 작업을 수행하는 것을 방지), 자원이 점유되어 있는 동안에도 다른 유용한 작업을 수행할 수 있습니다. Amdahl's Law는 논쟁이 확장성의 가장 큰적임을 말해주기 때문에 리액티브 프로그램은 거의 차단해야 합니다.

 

리액티브 프로그래밍은 일반적으로 메시지중심의 리액티브 시스템과 달리 이벤트 중심형이며 이벤트중심형과 메시지중심형의 차이점은이 기사 뒷부분에서 설명합니다.

 

리액티브 프로그래밍 라이브러리 용 응용 프로그램 인터페이스(API)는 일반적으로 다음 중 하나입니다.

• 콜백 기반 : 익명의 부작용 콜백을 이벤트 소스에 첨부하고 이벤트가 데이터 흐름 체인을 통과할 때 호출됩니다.
• 선언적 : 일반적으로 맵, 필터, 폴드 (fold) 등과 같이 잘 확립 된 연결자를 사용하는 선언적 스루 기능 구성

대부분의 라이브러리는이 두 스타일을 혼합하여 제공합니다. 종종 윈도우 잉, 카운트, 트리거 등과 같은 스트림 기반 연산자가 추가되었습니다.

 

리액티브 프로그래밍은 데이터 흐름(dataflow) 프로그래밍과 관련이 있다고 주장하는 것이 타당합니다. 제어 흐름보다는 데이터 흐름에 중점을 둡니다.

 

이 프로그래밍 기법을 지원하는 프로그래밍 추상화의 예는 다음과 같습니다.

• Futures / Promises : 값의 비동기 변환을 아직 사용할 수 없는 경우에도 추가 할 수있는 단일 값, 많은 읽기 / 단일 쓰기 의미의 컨테이너.
  
• 반응 형 스트림에서와 마찬가지로 스트림(stream) : 데이터 처리의 제한되지 않은 흐름 - 여러 출처와 목적지에 비동기식, 비 차단, 역압력 변환 파이프 라인을 가능하게합니다.
  
• 데이터 흐름 변수(dataflow variables) : 입력, 프로시저 및 기타 셀에 의존 할 수 있는 단일 할당 변수(메모리 셀). 따라서 변경시 자동으로 업데이트됩니다. 실용적인 예는 스프레드 시트입니다. 셀에서 값의 변화가 모든 종속 함수를 통해 파급되어 새로운 값을 생성합니다.

JVM에서 리액티브 프로그래밍 기술을 지원하는 인기있는 라이브러리로는 Akka Streams, Ratpack, Reactor, RxJava 및 Vert.x가 있습니다. 이러한 라이브러리는 JVM의 리액티브 프로그래밍 라이브러리 간의 상호 운용성을 위한 표준인 반응적인 스트림 사양을 구현하며 자체 설명에 따라 "비 차단 백압력으로 비동기 스트림 처리를 위한 표준을 제공하는 이니셔티브입니다. "

 

리액티브 프로그래밍의 주요 이점은 다음과 같습니다. 멀티 코어 및 멀티 CPU 하드웨어에서 컴퓨팅 리소스 사용 증가. Amdahl의 법칙과 확장성, Günther의 Universal Scalability Law에 따라 직렬화 지점을 줄임으로써 성능을 향상 시켰습니다.

 

전통적인 프로그래밍 패러다임이 모두 비동기 및 비 차단 컴퓨팅 및 I/O를 처리하기 위해 직접적이고 유지 보수가 쉬운 접근법을 제공하기 위해 애 쓰고 있기 때문에, 두번째 이익은 개발자 생산성 중 하나입니다. 리액티브 프로그래밍은 일반적으로 활성 구성 요소 간의 명시적 조정의 필요성을 제거하므로 대부분의 문제를 해결합니다.

 

리액티브 프로그래밍은 구성 요소 생성 및 작업흐름 구성에 도움이 됩니다. 비동기 실행을 최대한 활용하려면 과도한 사용 또는 자원의 무한한 소비를 피하기 위해 역압력을 포함하는 것이 중요합니다.

 

리액티브 프로그래밍은 최신 소프트웨어를 구축 할 때 매우 유용하지만, 시스템을 더 높은 수준으로 판단하려면 리액티브 시스템을 설계하는 프로세스 인 리액티브 아키텍처를 사용해야 합니다. 또한 많은 프로그래밍 패러다임과 리액티브 프로그래밍이 있지만 그 중 하나 인 점을 기억하는 것이 중요합니다. 따라서 모든 도구와 마찬가지로 모든 유스 케이스를 대상으로 하지 않습니다.

 

이벤트중심 vs 메세지 중심

 

앞서 언급했듯이, 일시적인 데이터 흐름 체인을 통한 계산에 중점을 둔 리액티브 프로그래밍은 이벤트중심인 반면, 분산 시스템의 통신 및 조정을 통한 회복성과 탄력성에 중점을 둔 리액티브시스템은 메시지중심입니다.

 

오랫동안 주소 지정이 가능한 구성 요소가 있는 메시지중심 시스템과 이벤트중심의 데이터 흐름 기반 모델의 주요 차이점은 메시지가 본질적으로 전달되고 이벤트가 전달되지 않는다는 것입니다. 메시지는 명확한 (단일) 대상을 가지며 이벤트는 다른 사람들이 관찰 할 사실입니다. 또한, 메시징은 보내는 것과 받는 것이 각각 보내는곳과 받는곳으로 부터 분리되는 비동기식 인 것이 바람직하다.

 

리액티브 선언문의 용어는 개념상의 차이점을 다음과 같이 정의합니다.

 

메시지는 특정 대상으로 보내지는 데이터 항목입니다. 이벤트는 주어진 상태에 도달했을 때 구성 요소가 내보낸 신호입니다. 메시지중심 시스템에서는 주소지정이 가능한 수신자는 메시지 도착을 기다리고 메시지에 응답합니다. 그렇지 않으면 휴면합니다. 이벤트 중심 시스템 알림에서 리스너는 이벤트 소스가 첨부되어 이벤트가 발생할 때 호출됩니다. 즉, 이벤트 중심 시스템은 주소지정이 가능한 이벤트 소스에 초점을 맞추고 메시지 중심 시스템은 주소지정이 가능한 수신자에 집중합니다.

 

 

메시지는 네트워크를 통해 통신하고 분산 시스템에서 통신을 위한 기반을 형성하는 반면, 이벤트는 로컬에서 방출됩니다. 일반적으로 메시지 내부에서 이벤트를 보내 네트워크를 통해 이벤트 중심 시스템을 연결하기 위해 메시징을 사용합니다. 이를 통해 분산 환경에서 이벤트 중심 프로그래밍 모델의 상대적 단순성을 유지할 수 있으며, 전문적이고 범위가 잘 정의된 유스케이스에서 잘 작동한다(AWS Lambda, Spark Streaming, Flink, Kafka 및 Akka와 같은 분산 스트림 처리 제품, Gearpump를 통한 스트림, Kafka 및 Kinesis와 같은 Publish Subscribe 제품).

 

그러나 프로그래밍 모델의 추상화와 단순화로 인해 얻는 것과, 제어 측면에서 잃는 것은  하나의 트레이드오프입니다. 메시징은 부분적 오류, 오류 감지, 삭제 / 중복 / 재정렬 된 메시지, 궁극적인 일관성, 다양한 동시성 현실의 관리와 같은 현실과 제약을 포용하고

과거에 수 없이 처리했던(e.g. EJB, RPC, CORBA, and XA) 네트워크가 존재하지 않는 것처럼 약한 추상화 뒤에 그것들을 숨기는 대신 그것들에게 달려들기를 강요합니다.

 

이러한 의미 및 적용 가능성의 차이는 회복성, 탄력성, 이동성, 위치 투명성 및 분산 시스템의 복잡성 관리와 같은 응용 프로그램 설계에 중대한 영향을 미칩니다. 자세한 내용은 이기사에서 설명합니다.

 

리액티브 시스템, 특히 리액티브 프로그래밍을 사용하는 시스템에서는 한가지가 커뮤니케이션(메시지)을 위한 훌륭한 도구이고 다른 하나가 사실(이벤트)을 표현하기 위한 훌륭한 방법이기 때문에 이벤트와 메시지가 모두 존재합니다.

 

리액티브 시스템과 아키텍쳐

 

리액티브 시스템은 "리액티브 선언문"에 정의된 바와 같이 오늘날 응용프로그램들이 마주한 증가하는 요구사항들을 충족할 수 있도록 잘 준비된 현대적 시스템을 구축하기 위한 일련의 아키텍쳐 설계 원칙들입니다.

 

리액티브 시스템의 원리는 전혀 새로운 것이 아니며, '70 년대와 '80 년대 그리고 Tandem System의 Jim Grey와 Pat Helland, Erlang의 Joe Armstrong과 Robert Virding의 중대한 작업까지 거슬러 올라가 추적 할 수 있습니다. 그러나 이러한 사람들은 시대를 앞서 있었고, 불과 5-10 년 전까지만 해도 기술산업은 현재의 기업 시스템개발과 어렵게 얻은 오늘날의 멀티코어, 클라우드 컴퓨팅 및 사물인터넷 상의 리액티브 원리에 대한 지식을 적용하기 위해 배우는 것을 재고하도록 강요되어 왔습니다.

 

리액티브 시스템의 기반은 메시지전달 입니다. 컴포넌트 간의 시간적 경계를 만들어서 시간에 분리 될 수 있습니다. 이는 동시성 및 공간을 허용하여 분산 및 이동성을 허용합니다. 이 디커플링은 구성 요소 간의 완벽한 분리에 대한 요구사항이며 복원력과 탄력성의 기초를 형성합니다.

 

프로그램에서 시스템으로

 

세계는 점점 더 상호 연결되어 가고 있습니다. 우리는 더 이상 시스템을 구축하는 것 만큼 한 사람의 운영자를 위해 무엇인가를 계산하는 종단간 논리 프로그램들을 만들지 않습니다.

 

시스템은 정의에 의해 복잡합니다. 각 구성 요소는 여러 구성 요소로 구성되며 시스템 자체가 시스템이 될 수 있습니다. 이것은 소프트웨어가 제대로 작동하려면 점점 다른 소프트웨어에 의존성을 가지게 된다는 것을 의미합니다.

 

오늘날 우리가 만들어내는 시스템은 크고 작은 컴퓨터, 많거나 적거나, 서로 가까이 있거나 거의 지구 반대편에 떨어진 컴퓨터에서 작동해야합니다. 동시에 사람들의 일상생활이 부드럽게 기능하는 시스템의 가용성에 점점 의존함에 따라 이용자들의 기대는 점점 더 힘들어지고 있습니다.

 

사용자와 비즈니스가 의존 할 수있는 시스템을 제공하려면 응답이 필요할 때 응답을 사용할 수없는 경우 올바른 응답을 제공하는지 여부는 중요하지 않으므로 응답해야합니다. 이를 달성하기 위해서는 실패(탄력성) 및 부하(탄력성) 하에서 응답성을 유지할 수 있어야합니다. 그렇게하기 위해 우리는 이러한 시스템을 메시지 중심으로 만들고 리액티브 시스템이라고 부릅니다.

 

리액티브 시스템의 회복성

 

회복성은 실패시 대응성에 관한 것이며, 시스템의 고유한 기능적 특성, 소급하여 추가 할 수있는 것이 아니라 설계되어야 하는 것입니다. 복원력은 내결함성을 뛰어 넘습니다. 이는 시스템의 매우 유용한 특성이지만 정상적인 성능 저하가 아니라 장애로부터 완전히 복구 할 수있는 것입니다 :자가 치유. 이를 위해서는 인접한 구성 요소로 전파되는 오류를 피하기 위해 구성 요소 격리 및 오류 억제가 필요합니다. 그 결과, 대개의 경우 치명적이고 연속적인 오류 시나리오가 발생합니다.

 

따라서 회복성을 가진 자가치유 시스템을 구축하기 위한 핵심은 오류를 포함하고, 메시지로 구체화하고, 다른 구성 요소 (감독자의 역할을 담당)로 전송하고, 오류가 발생한 구성 요소 외부의 안전한 컨텍스트에서 관리 할 수 있도록하는 것입니다. 여기에서 메시지 중심적으로 작동하는 것이 가능합니다. 강하게 결합되고 부서지기 쉽고 깊게 중첩 된 동기식 호출 체인에서 벗어나 모두가 고생을 하거나 무시하는 방법을 배우게됩니다. 이 아이디어는 호출 체인에서 실패 관리를 분리하여 클라이언트가 서버의 오류처리에 대한 책임으로부터 자유롭게하는 것입니다.

 

리액티브 시스템의 탄력성

 

탄력성은 부하에서의 응답성을 의미합니다. 즉, 다양한 요구를 충족시키기 위해 자원이 추가되거나 제거될 때 그에 비례하여 시스템의 처리량이 자동으로 확대 또는 축소됩니다. 이것은 클라우드 컴퓨팅의의 약속을의 이점을 활용하는데 필수적 요소입니다. 시스템을 자원 효율적이고 비용 효율적이며 환경 친화적이며 사용에 대해서만 지불이 가능하게 합니다.

 

시스템은 적응성이 있어야합니다. 자동 재구성, 상태 및 동작 복제, 통신에 대한 로드밸런싱, 시스템 대체작동 및 업그레이드를 시스템의 재작성 또는 재구성 없이 수행할 수 있습니다. 이를 가능케하는 요소는 위치 투명성입니다. 이는 CPU 코어에서 데이터 센터에 이르는 모든 규모의 스케일에서 동일한 의미로 동일한 프로그래밍 추상화를 사용하여 동일한 방식으로 시스템을 확장 할 수있는 기능입니다.

 

리액티브선언문은 다음과 같이 말합니다.

 

이 문제를 대단히 단순화하는 핵심 통찰력은 우리 모두가 분산 컴퓨팅을 수행하고 있다는 것을 깨닫는 것입니다. 이는 단일 노드(QPI링크를 통해 통신하는 여러 독립적인 CPU와 함께) 또는 여러 노드로 이루어진 클러스터(네트워크를 통해 통신하는 독립된 시스템과 함께)에서 시스템을 실행하든 상관 없습니다. 이 사실을 받아들이면 멀티 코어에서 수직으로 스케일링하거나 클러스터에서 수평으로 스케일링하는 것과 개념적으로 차이가 없다는 것을 의미합니다. 비동기 메시지 전달을 통해 활성화 된 공간[...]에서의 이러한 분리와 런타임 인스턴스의 참조에서의 분리는 위치 투명성이라고 부릅니다.

 

 

수신자가 어디에 있든 상관없이 우리는 같은 방식으로 메시지를 교환합니다. 의미 상 동등하게 수행할 수있는 유일한 방법은 메시징을 통하는 것입니다.

 

리액티브 시스템의 생산성

 

대부분의 시스템은 선천적으로 본질적으로 복잡하기 때문에 가장 중요한 측면 중 하나는 시스템 아키텍처가 구성 요소의 개발 및 유지 보수에서 생산성의 감소를 최소화하면서 동시에 운영상의 우발적인 사고 복잡성을 최소화하는 것을 분명히 하는 것이다.

 

이는 시스템의 수명주기 동안 (적절하게 설계되지 않은 경우) 점점 더 유지보수하기 어려워지고 문제를 지역화하고 수정하기 위해 이해하는 데 점점 더 많은 시간과 노력을 요구하기 때문에 중요합니다.

 

리액티브 시스템은 우리가 알고있는 (멀티 코어, 클라우드 및 모바일 아키텍처의 맥락에서) 가장 생산적인 시스템 아키텍처입니다.

• 장애 격리는 구성 요소 사이에 격벽을 제공하여 단계적으로 장애가 발생하는 것을 방지하여 장애의 범위와 심각성을 제한합니다.
  
• 감독자 계층 구조는 자체 복구 기능과 함께 자기치유력을 포함하여 여러 수준의 방어 기능을 제공함으로써 운영상의 조사 비용을 발생시킬 수 있는 일시적인 오류를 많이 제거 할 수 있습니다.
  
• 메시지 전달 및 위치 투명성을 통해 구성 요소를 오프라인으로 전환하고 최종 사용자 환경에 영향을 미치지 않고 교체하거나 경로를 변경함으로써 중단 비용, 상대적 긴급성 및 진단 및 수정에 필요한 리소스를 줄일 수 있습니다.
  
• 복제는 데이터 손실에 대한 위험을 줄이고 장애가 정보의 검색 및 저장의 가용성에 미치는 영향을 줄여줍니다.
  
• 탄력성은 사용량이 변동함에 따라 리소스를 절약 할 수 있으므로 부하가 적을 때 운영 비용을 최소화하고 부하가 증가 할 때 정전 또는 확장성에 대한 긴급한 투자의 위험을 최소화합니다.

따라서 반응 시스템은 시간이 지남에 따라 낮은 소유 비용을 제공하는 동시에 장애 발생시 다양한 부하와 변화에 잘 대응하는 생성 시스템을 허용합니다.

 

리액티브 프로그래밍은 리액티브 시스템과 어떻게 관련이 있는가?

 

리액티브 프로그래밍은 코드 명확성, 성능 및 리소스 효율성을 최적화하는 방법으로 구성 요소 내에서 로컬로 내부 논리 및 데이터 흐름 변환을 관리하는 훌륭한 기술입니다. 일련의 아키텍처 원칙인 리액티브 시스템은 분산된 커뮤니케이션에 중점을 두고 분산시스템에서 회복성과 탄력성을 발휘할 수 있는 도구를 제공합니다.

 

리액티브 프로그래밍을 활용할 때 빈번한 문제 중 하나는 콜백기반의 이벤트중심 또는 선언적 프로그램에서 계산 단계 간의 긴밀한 결합으로 인해 회복력을 이루기 힘들게 변형체인이 종종 일시적 또는 콜백이나 연결자와 같은 그 단계가 주소를 지정할 수 없는 무명이 되어버립니다.

 

즉, 대개 외부 세계에 알리지 않고 성공 또는 실패를 직접 처리합니다. 이러한 주소 지정 기능의 부족은 예외가 전파되어야하는 곳이 일반적으로 불분명하기 때문에 개별 단계의 복구를 어렵게 만듭니다. 결과적으로 오류는 구성 요소의 전반적인 상태가 아닌 일시적인 클라이언트 요청에 연결됩니다. 데이터 흐름 체인의 단계 중 하나에서 오류가 발생하면 전체 체인을 다시 시작해야하며 클라이언트에서 이를 알립니다. 이는 클라이언트에 알릴 필요 없이 자가치유 할 수 있는 메시지중심의 리액티브시스템과는 대조적입니다.

 

리액티브 시스템의 접근 방식과는 달리 순수한 리액티브 프로그래밍을 사용하면 시간에 따라 디커플링을 할 수 있지만 공간에 따라 사용할 수 없습니다 (앞에서 설명한대로 메시지 전달을 사용하여 데이터 흐름 그래프를 네트워크를 통해 배포하지 않는 한). 앞서 언급했듯이 시간의 분리는 동시성을 가능하게하지만, 공간적으로 분리되어 분산 및 이동성을 허용하여 탄력성에 필수적인 정적이지만 동적 인 토폴로지를 허용합니다.

 

위치 투명성이 부족하여 리액티브 프로그래밍 기술을 기반으로 하는 프로그램을 탄력적으로 적응 적으로 확장 할 수 없으므로 메시지 버스, 데이터 그리드 또는 주문형 네트워크 프로토콜을 레이어 위에 추가해야합니다. 이것은 응답 시스템의 메시지 중심 프로그래밍이 모든 차원의 규모에서 프로그래밍 모델과 의미를 유지하는 통신 추상화이므로 시스템 복잡성과 인지오버 헤드를 줄이는 부분입니다.

 

콜백 기반 프로그래밍의 일반적으로 언급 된 문제는 그러한 프로그램을 작성하는 것이 비교적 쉽지만 장기적으로 실제 결과를 가져올 수 있다는 것입니다.

 

예를 들어, 익명의 콜백을 기반으로하는 시스템은 사용자가 추론 할 필요가 있거나 이를 유지 관리해야 할 때 또는 무엇이, 어디서, 왜 생산 중단 및 오작동을 발생시키는지 파악해야 할 때 아주 적은 통찰력을 제공합니다.

 

리액티브 시스템 용으로 설계된 라이브러리 및 플랫폼 (예 : Akka 프로젝트 및 Erlang 플랫폼)은 오랫동안이 교훈을 얻었으며 장기적으로 추론하기 쉬운 수명이 긴 주소 지정 가능 구성 요소에 의존합니다. 오류가 발생하면 구성 요소는 오류의 원인이 된 메시지와 함께 고유하게 식별 할 수 있습니다. 모니터링 솔루션은 구성 요소 모델의 핵심 부분 인 주소 지정 가능성이라는 개념을 통해 전파되는 ID를 활용하여 수집된 데이터를 제공하는 의미있는 방법을 제공합니다.

 

주소 지정 기능 및 오류 관리와 같은 기능을 수행하는 좋은 프로그래밍 패러다임의 선택은 실재의 혹독함을 마음에 두고 설계되었기 때문에 운영환경에서 매우 귀중한 것으로 입증되었습니다. 장애를 막기 위해 장애의 원인보다는 장애를 예상하고 받아 들일 수 있습니다.

 

대체로 리액티브 프로그래밍은 리액티브 아키텍처에서 사용할 수있는 매우 유용한 구현 기술입니다. 스토리의 한 부분만을 관리하는 데 도움이된다는 점을 기억하십시오. 비동기 및 비 차단 실행을 통한 데이터 흐름 관리 - 대개 단일 노드 또는 서비스 내에서만 가능합니다. 여러 개의 노드가 있으면 데이터 일관성, 노드 간 통신, 조정, 버전 관리, 오케스트레이션, 오류 관리, 관심과 책임 분리 등과 같은 시스템 아키텍쳐와 같은 일에 대해 열심히 생각을 시작해 볼 필요가 있습니다.

 

따라서, 리액티브  프로그래밍의 가치를 극대화하려면, 리액티브 프로그래밍을 리액티브 시스템을 구성하는 도구 중 하나로 사용하십시오. 리액티브 시스템을 구축하려면 OS 관련 리소스를 추출하고 기존의 소프트웨어 스택 위에 비동기 API와 순회차단장치를 뿌려주는 것 이상을 필요로합니다. 당신은 여러 서비스로 구성된 분산 시스템을 구축하는 것을 도입하려는 중텐데, 모든 서비스는 예상대로 작동 할 때뿐만 아니라 예측할 수없는 부하와 장애 상황에서도 일관적이고 빠른 반응 경험을 제공해야합니다.

 

요약

 

2016년 리액티브를 적용하는 것에 대한 기업의 관심이 크게 성장하는 것을 목격하며 기업과 미들웨어 벤더 모두 리액티브를 채택하기 시작했습니다. 이 기사에서 우리는 리액티브 시스템을 기업의 최종 목표로 서술하였습니다-멀티코어, 클라우드, 모바일 아키텍쳐의 맥락을 가정함-기업에 있어서 리액티브 프로그래밍은 중요한 도구중 하나가 됩니다.

 

리액티브 프로그래밍은 내부 로직 및 데이터흐름 변환을 위한 컴포넌트 수준에서 성능 및 리소스 효율성을 통해 개발자에게 생산성을 제공합니다. 리액티브 시스템은 클라우드기반과 다른 대규모의 분산 시스템을 구축하기 위한 시스템 수준의 복원력과 탄력성을 통해 아키텍쳐 및 개발운영 전문가에게 생산성을 제공합니다. 리액티브 프로그래밍 기법을 리액티브 시스템 설계원칙내에 결합하기를 추천합니다.

 

*****

원문 : Reactive programming vs. Reactive systems

번역 : 전성종