리액티브 프로그래밍 대 리액티브 시스템 (Reactive Programming vs Reactive Systems)

아래 글은 LightBend의 "Reactive Programming versus Reactive Systems"를 번역한 글입니다.

---

리액티브 프로그래밍 대 리액티브 시스템
Reactive Programming vs Reactive Systems

끊임없는 혼란과 과부하가 걸린 바다에서 단순한 반응 설계 원리 세트에 착수

Jonas Boner와 Viktor Klang, Lightbend Inc.

요약

2013년에 Reactive Manifesto를 공동 저작 한 이후, Reactive는 선택한 일부 기업 내에서 단지 프린지 프로젝트에서만 사용되는 애플리케이션 구축을위한 사실상 확인되지 않은 기술이 되었습니다. - 미들웨어 분야의 수많은 대기업에서 전반적인 플랫폼 전략의 일부가되었습니다.
 이 글의 목표는 Reactive Programming 스타일에서 코드를 작성하는 것과 Reactive Systems의 디자인을 응집력있는 전체로서 디자인하는 것의 차이를 살펴봄으로써 "Reactive"의 다양한 측면을 정의하고 명확히하는 것입니다.

주요 골자 (TL; DR)

• 2015년, 특히 ​​2016 년 이후로 상업용 미들웨어 공급 업체와 사용자 모두에서 Reactive에 대한 관심이 크게 증가했습니다.
• 리액티브 프로그래밍은 구현 수준에서 리액티브 시스템의 뚜렷한 하위 집합입니다.
• Reactive Programming은 내부 논리 및 데이터 흐름 관리를위한 구성 요소 수준에서 성능 및 자원 효율성을 통해 개발자에게 생산성을 제공합니다.
• Reactive Systems는 "Cloud Native"1 또는 기타 대규모 분산 시스템 구축을 위해 시스템 수준에서 복원력과 탄력성을 통해 Architects 및 DevOps의 생산성을 제공합니다.
• 리액티브 시스템 구성 요소 내에서 리액티브 프로그래밍을 사용하는 것이 매우 유용합니다.
• 리액티브 프로그래밍을 사용하여 작성된 컴포넌트로 만들어진 리액티브 시스템을 사용하는 것이 매우 유용합니다.

리액티브(Reactive) - 일련의 설계 원칙

성공의 최근 지표 중 하나는 리액티브가 과부하 된 용어가 되어 현재 "스트리밍(streaming)", "경량의(lightweight)" 및 "실시간(real-time)"과 같은 단어를 사용하는 좋은 회사에서 여러 사람들과 여러 가지 다른 것들과 연관되어 있다는 것입니다.

이 글의 관점에서 보면 "리액티브(Reactive)"는 응집력있는 시스템을 만들기위한 일련의 설계 원칙입니다. 구현 테크닉, 툴링 및 디자인 패턴이 더 큰 전체 구성 요소인 분산 환경에서 시스템 아키텍처 및 디자인에 대해 생각하는 방법입니다.

다음과 같은 비유를 생각해보십시오 :
운동 팀 (예 : 축구, 농구 등)은 특별한 개인으로 구성되는 경우가 많습니다. 그럼에도 불구하고 "열등한" 팀에 패배하는 것은 팀이한데 모여 무언가를 클릭하지 않을 때 흔히 볼 수 있습니다. 이처럼 시너지 효과가 부족하여 효과적으로 팀을 운영 할 수 없습니다.

이 유추는 개개인이 생각 나지 않고 자갈로 엮은 일련의 개별 리액티브 서비스 (Reactive Service)의 차이점을 보여줍니다.

리액티브 시스템에서 모든 차이를 만드는 것은 개별 부품 간의 상호 작용입니다. 이는 개별적으로 작동하면서 동시에 의도한 결과를 얻기 위해 함께 행동하는 기능입니다.

리액티브 시스템은 이러한 여러 개별 서비스를 하나의 단위로 통합하고 서로를 인식하면서 주변 환경에 대응할 수있는 아키텍처 스타일을 기반으로합니다.이 방식은 서로 대칭적으로 확장 / 축소,로드 균형 조정, 이러한 단계 중 일부는 사전에 수행합니다.

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

사람들이 소프트웨어 개발 및 디자인의 맥락에서 리액티브에 대해 이야기 할 때 일반적으로 다음 세 가지 중 하나를 의미합니다.

• 리액티브 시스템 (아키텍처 및 디자인)
• 리액티브 프로그래밍 (선언적 이벤트 기반)
• Functional Reactive Programming (FRP)

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

2013년 Akka 기반 시스템의 생성, 유지 및 운영에 대한 오랜 경험을 쌓은 후 동시성 및 배포 문제를 해결하는 전통적인 접근 방식에 비해 엄청난 이점을 보았던 경험과 교훈을 형식화하는 아이디어는 리액티브 선언서(Reactive manifesto)의 우산 아래에서 촉발되었습니다 

현대 시스템의 핵심은 응답성(Responsiveness)입니다. 클라이언트 / 고객이 적시에 가치를 얻지 못하면 다른 곳으로 갈 것이라는 점을 인정합니다. 근본적으로 가치를 얻지 못하고 가치가 없을 때 차이가 없다.

응답성(Responsiveness)을 높이기 위해서는 두 가지가 필요합니다. :

• 탄력성 (Resilience) : 실패 상태에서 반응성
• 유연성 (Elasticity) : 부하 상태에서 반응성

Reactive Manifesto는 이를 달성하기 위해 시스템이 Message-Driven이어야한다고 규정합니다.

Reactive Manifesto의 네 가지 교리.

2016년 JVM 분야의 주요 벤더 중 일부는 리액티브 프로그래밍 (Reactive Programming)을 수용하기위한 핵심 계획(initiative)을 발표했습니다. 이는 오늘날 기업이 직면 한 문제를 엄청나게 검증 한 것입니다.

전통적인 프로그래밍 기법에서 이러한 변화를 시도하는 것은 크고 도전적인 작업입니다. 기존 기술과의 호환성을 유지하고 사용자 기반을 다른 사고 방식으로 유도하는 동시에 내부 개발자 및 운영 경험을 구축해야합니다. 따라서 이들 회사의 투자는 결코 쉬운 일이 아니며 이것이 엔지니어링에 대한 큰 도전이라고 언급 할 필요가 없습니다.

리액티브 프로그래밍 공간에는 많은 활동이 있는 것처럼 보이지만 시스템 아키텍처 레벨에서는 아키텍처 및 운영 경험을 구축하는 데 시간이 걸릴 것입니다. 이는 다른 프로그래밍 패러다임을 채택하여 자동으로 해결되지는 않습니다. 리액티브 시스템을 구축 할 필요가있는 리액티브 선언(Reactive Manifesto)의 배경이되면서 앞으로 무엇이 부상 할 것인지를 보는 것이 흥미로울 것입니다.

함수형 리액티브 프로그래밍 (Functional Reactive Programming)에 대해 이야기하고, 왜 이 글에서 더 이상 논의하지 않기로 결정했는지 알아 보겠습니다.

Functional Reactive Programming (FRP)

Functional Reactive Programming (일반적으로 "FRP"라고 함)은 자주 오해됩니다. FRP는 20 년 전에 Conal Elliott에 의해 매우 정확하게 정의되었습니다. 이 용어는 가장 최근에 Elm, Bacon.js, Reactive Extensions (RxJava, Rx.NET, RxJS)와 같은 기술을 설명하기 위해 부정확하게 사용되었습니다.[2] FRP를 지원한다고 주장하는 대부분의 라이브러리는 거의 독점적으로 리액티브 프로그래밍에 대해 이야기하고 있으므로 더 이상 논의하지 않을 것입니다.

리액티브 프로그래밍

리액티브 프로그래밍은 함수형 리액티브 프로그래밍(Functional Reactive Programming)과 혼동하지 않고 비동기 프로그래밍의 하위 집합이며 새로운 정보의 가용성이 실행 흐름에 의해 제어 흐름을 제어하는 ​​대신 논리 전달을 주도하는 패러다임입니다.

문제를 여러 개별 단계로 분해하여 비동기 및 논블로킹(non-blocking) 방식으로 각각 실행하고 워크 플로우를 생성하도록 구성 할 수 있습니다. 입력 또는 출력에 제한이 없습니다. 비동기는 Oxford Dictionary에 의해 "존재하지 않거나 동시에 발생 함"으로 정의됩니다.이 문맥에서 메시지 또는 이벤트 처리는 임의의 시간에, 아마도 미래에 일어날 수 있음을 의미합니다.

이것은 논블로킹 실행 (non-blocking execution)을 허용하기 때문에 리액티브 프로그래밍 (Reactive Programming)에서 매우 중요한 기술입니다. 공유 리소스에 대해 경쟁하는 실행 스레드가 차단 (현재 작업이 완료 될 때까지 실행 스레드가 다른 작업을 수행하는 것을 방지 할 필요는 없습니다. ), 자원이 가득 차있는 동안 다른 유용한 작업을 수행 할 수 있습니다. 암달의 법칙(Amdahl 's Law[3])은 얘기합니다. 논쟁이 확장성의 가장 큰 적임을, 따라서 리액티브 프로그램은 거의 블로킹(blocking)하지 않아야 합니다.

동기식, 통신 차단 (왼쪽)은 자원이 비효율적이며 병목 현상이 발생하기 쉽습니다.
리액티브 접근법 (오른쪽)은 위험을 줄이고 귀중한 자원을 보존하며 하드웨어 / 인프라를 덜 필요로합니다.

리액티브 프로그래밍은 일반적으로 메시지 기반의 리액티브 시스템과는 달리 이벤트 주도형입니다. 이벤트 주도형과 메시지 구동 형의 차이점은 다음 섹션에서 명확히 설명됩니다.

리액티브 프로그래밍 라이브러리용 API (Application Program Interface)는 일반적으로 다음 중 하나입니다.

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

대부분의 라이브러리는이 두 스타일을 혼합하여 제공합니다. 종종 윈도우 잉, 카운트, 트리거 등과 같은 스트림 기반 연산자가 추가되었습니다.
리액티브 프로그래밍은 데이터 흐름 프로그래밍과 관련이 있다고 주장하는 것이 타당합니다. 컨트롤 흐름보다는 데이터 흐름에 중점을 둡니다.
이 프로그래밍 기법을 지원하는 프로그래밍 추상화의 예는 다음과 같습니다.

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

JVM에서 Reactive Programming 기술을 지원하는 인기있는 라이브러리로는 Akka Streams, Ratpack, Reactor, RxJava 및 Vert.x가 있습니다. 이러한 라이브러리는 JVM의 리 액티브 프로그래밍 라이브러리 간의 상호 운용성을 위한 표준인 리액티브 스트림 스펙(Reactive Streams specification, 논블로킹 백프레셔로 비동기 스트림 처리 표준을 제공하기위한 계획)을 구현합니다.

리액티브 프로그래밍의 이점 (그리고 한계)

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

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

Reactive Programming이 빛나는 곳은 구성 요소를 만들고 워크 플로를 구성하는 것입니다. 비동기 실행을 최대한 활용하려면 과도한 사용 또는 자원의 무한한 소비를 피하기 위해 백 프레셔(back-pressure)을 포함하는 것이 중요합니다.

데이터 흐름 측면에서 안정적인 상태를 유지하기 위해 끌어 오기 기반 백 프레셔(back-pressure)는 업스트림으로 이동하고 다운 스트림으로 메시지를 수신하므로 생산자가 소비자를 압도하지 않습니다. 이미지 Kevin Webber (@ kvnwbbr).

그러나 Reactive Programming은 최신 소프트웨어를 구축 할 때 매우 유용하지만, 시스템을 더 높은 수준으로 판단하기 위해서는 Reactive Systems를 설계하는 프로세스인 Reactive Architecture를 사용해야합니다. 또한, 많은 프로그래밍 패러다임과 Reactive Programming이 있다는 것을 기억하는 것이 중요합니다. 그 중 하나는 툴과 마찬가지로 모든 유스케이스를 위한 것이 아닙니다.

이벤트 중심 VS 메시지 기반

이전에 언급했듯이, 일시적인 데이터 흐름 체인을 통한 계산에 중점을 둔 리액티브 프로그래밍은 이벤트 주도형인 반면, 리액티브 시스템(분산 시스템의 통신 및 조정을 통한 탄력성과 유연성에 중점을 둠)은 메시지 기반입니다.

오랫동안 지속되는 주소 지정 가능 구성 요소가 있는 메시지 기반 시스템과 이벤트 중심 데이터 흐름 기반 모델의 주요 차이점은 메시지는 본질적으로 전달되고 이벤트는 그렇지 않다는 것입니다. 메시지에는 깨끗한 단일 대상이 있습니다. 이벤트는 다른 사람들이 관찰하는 사실입니다. 또한, 메시징은 송신자와 수신자가 각각 분리 된 송신 및 수신과 함께 비동기인 것이 바람직하다.

이벤트 중심의 커뮤니케이션은 "비누 상자"방식을 사용하지만 다른 사람들이 관찰하는 사실 (이벤트)을 듣는 경우 메시지 중심의 커뮤니케이션은 수신자와 단일 목적을 가지고 있습니다.

리액티브 선언(Reactive Manifesto)의 용어집은 개념상의 차이점을 다음과 같이 정의합니다.

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

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

그러나, 프로그래밍 모델의 추상화와 단순화에서 무엇이 이득을 얻는 지, 통제면에서 손실되는 것이 트레이드 오프입니다.

메시징은 부분적 실패, 실패 감지, 삭제 / 중복 / 재정렬 된 메시지, 궁극적 인 일관성, 여러 동시 현실의 관리 등과 같은 분산 시스템의 현실과 제약을 포용하도록 강요합니다. 과거에 너무 많은 시간 (예 : EJB, RPC, CORBA 및 XA)이 수행 된 것처럼 네트워크가 존재하지 않는 것처럼 보이는 새는 추상화.

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

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

리액티브 시스템 및 아키텍처

리액티브 시스템(Reactive System)은 리액티브 선언(Reactive Manifesto)에서 정의한대로 현대적인 시스템을 구축하기위한 아키텍처 설계 원칙으로, 오늘날 애플리케이션이 직면하는 증가하는 요구 사항을 충족 할 수 있도록 잘 준비되어 있습니다.

리액티브 시스템의 원칙은 전혀 새로운 것이 아니며, 70년대와 80년대까지 거슬러 올라갈 수 있습니다. Jim Grey와 Pat Helland는 Tandem System, Joe Armstrong과 Robert Virding의 Erlang입니다. 그러나 이 사람들은 시간을 앞섰고 기술 산업계는 기업 시스템 개발을위한 현재 "모범 사례"를 다시 생각해야만했던 지난 5 ~ 10년 동안만 있었습니다. 이는 오늘날의 멀티 코어, 클라우드 컴퓨팅 및 사물의 세계에 대한 반응 원칙에 대한 지식을 적용하는 법을 배우는 것을 의미합니다.

리액티브(Reactive System)의 토대는 Message-Passing입니다. 구성 요소간에 시간적 경계가 생겨 구성 요소가 제 시간에 분리 될 수 있습니다. 이는 동시성(Concurrency) 및 공간(space)을 허용하여 배포(distribution) 및 이동성(mobility)을 허용합니다. 이 디커플링은 구성 요소 간의 완전한 격리에 대한 요구 사항이며 탄력성(Resilience)과 유연성(Elasticity)의 기초를 형성합니다.

프로그램에서 시스템으로

우리는 더 이상 시스템을 구축하는 것만 큼 단일 운영자를 위해 무언가를 계산하기위한 종단 간 논리 (end-to-end logic)를 구축하지 않습니다.

세계는 점점 더 상호 연결되어 가고 있습니다. 시스템은 정의에 의해 복잡합니다. 각 구성 요소는 여러 구성 요소로 구성되며 각 구성요소 자체가 시스템이 될 수 있습니다. 소프트웨어가 제대로 작동하려면 점점 다른 소프트웨어에 의존하게됩니다.

오늘날 우리가 만들어내는 시스템은 크고 작은 컴퓨터, 서로 가까이 있거나 거의 반으로 떨어진 컴퓨터에서 작동해야합니다. 동시에 일상 생활이 원활하게 기능할 수있는 시스템의 가용성에 점점 더 의존하고 있기 때문에 사용자의 기대는 점점 더 어려워지고 있습니다.

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

리액티브 시스템의 탄력성(Resilience)

탄력성은 실패시의 대응성에 대한 것이며, 시스템의 고유 한 기능적 특성이며, 소급하여 추가 할 수있는 것이 아니라 설계해야 할 것입니다.

복원력은 내결함성을 뛰어 넘습니다.
이는 시스템의 매우 유용한 특성이지만 정상적인 성능 저하가 아니라 장애로부터 완전히 복구 할 수있는 것입니다 :자가 치유합니다.

이를 위해서는 인접한 구성 요소로 전파되는 오류를 피하기 위해 구성 요소 격리 및 오류 억제가 필요합니다. 결과적으로 대개의 경우 치명적인 계단식 오류 시나리오가 발생합니다.

복원력 있고자가 치유적인 시스템을 구축하는 열쇠는 포함되어 메시지로 구체화되고 다른 구성 요소 (감독자의 역할을 담당)로 전송되고 실패한 구성 요소 외부의 안전한 컨텍스트에서 관리되도록하는 것입니다. 여기에서 Message-Driving이 가능합니다 : 강하게 결합되고 부서지기 쉽고 깊게 중첩 된 동기식 호출 체인에서 벗어나 모두가 겪어 보거나 묵살하는 것을 배웠습니다. 이 아이디어는 호출 체인에서 실패 관리를 분리하여 클라이언트가 서버의 오류를 처리 할 책임을 없애는 것입니다.

리액티브 시스템의 유연성(Elasticity)

탄력성은 부하에서의 응답 성입니다. 즉, 시스템의 처리량이 자동으로 증가하거나 감소하여 (즉, 단일 시스템에서 코어 추가 또는 제거) 데이터 센터의 노드 / 머신 추가 또는 제거와 같이 자동으로 리소스가 비례 적으로 추가되거나 제거 될 때 다양한 요구를 충족시킵니다. 이는 클라우드 컴퓨팅의 약속을 활용하는 데 필요한 필수 요소입니다. 시스템을 자원 효율적, 비용 효율적, 환경 친화적 및 사용량 당 지불 할 수 있습니다.

시스템은 적응성이 있어야합니다. 시스템을 다시 작성하거나 심지어 재구성하지 않고도 자동 조정, 상태 및 동작 복제, 통신로드 밸런싱, 장애 조치 및 업그레이드 등의 개입이 가능합니다. 이에 대한 실현 요인은 위치 투명성입니다. CPU 코어에서 데이터 센터에 이르는 모든 규모의 규모에서 동일한 프로그래밍 추상화를 사용하여 같은 의미로 동일한 방식으로 시스템을 확장 할 수있는 기능입니다.

Reactive Manifesto는 다음과 같이 말합니다.

이 문제를 대단히 단순화하는 핵심 통찰력은 우리 모두가 분산 컴퓨팅을 수행하고 있다는 것을 깨닫는 것입니다. 이는 단일 노드 (QPI 링크를 통해 통신하는 여러 독립 CPU 포함) 또는 노드 클러스터 (네트워크를 통해 통신하는 독립 시스템)에서 시스템을 실행하든 상관 없습니다. 이 사실을 받아들이면 멀티 코어에서 수직으로 스케일링하거나 클러스터에서 수평으로 스케일링하는 것과 개념적으로 차이가 없다는 것을 의미합니다.

비동기 메시지 전달을 통해 활성화 된 공간에서의 이러한 분리 (decoupling) [...]와 런타임 인스턴스의 참조에서의 분리는 Location Transparency라고합니다.

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

리액티브 시스템의 생산성(Productivity)

대부분의 시스템은 기본적으로 본질적으로 복잡하기 때문에 가장 중요한 측면 중 하나는 시스템 아키텍처가 구성 요소의 개발 및 유지 보수에서 최소한의 생산성 감소를 보장하면서 동시에 실수로 인한 복잡성을 줄이는 것입니다. 최저한의.

이는 시스템의 수명주기 동안 (제대로 설계되지 않은 경우) 유지 관리가 더 어려워지고 어려워지고 문제를 지역화하고 해결하기 위해 이해해야 할 시간과 노력이 계속 증가해야하기 때문에 중요합니다.

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

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

타이타닉에서 제대로 수행되지는 않았지만 배수 시설 건설 업계에서는 다른 작업에 영향을주는 계단식 실패를 방지하기 위해 오랫동안 벌크 헤드가 사용되었습니다.

따라서 Reactive Systems는 시간이 지남에 따라 낮은 소유 비용을 제공하면서 장애 발생시에도 부하 및 변화의 변화에 효과적으로 대처할 수있는 생성 시스템을 지원합니다.

리액티브 프로그래밍은 리액티브 시스템과 어떤 관련이 있습니까?

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

리액티브 프로그래밍을 활용할 때 가장 많이 발생하는 문제 중 하나는 이벤트 기반 콜백 기반 또는 선언적 프로그램에서 계산 단계 간의 긴밀한 연결로 인해 탄력성 체인이 종종 일시적이며 콜백 또는 결합자인 익명임을 나타내는 Resilience를 달성하기가 더 어려워집니다. 즉, 주소 지정이 불가능합니다.

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

리액티브 시스템 접근법과는 달리 순수 리 액티브 프로그래밍을 사용하면 시간에 따라 디커플링이 가능하지만 공간에서는 사용할 수 없습니다 (앞에서 설명한대로 Message-passing을 사용하여 데이터 흐름 그래프를 네트워크 전체에 배포하지 않는 한).

디커플링은 동시성을 가능하게하지만 공간에 디커플링을 적용하여 배포 및 이동성을 허용하므로 탄력성에 필수적인 정적 토폴로지뿐만 아니라 동적 토폴로지를 고려할 수 있습니다.

위치 투명성이 부족하여 Reactive Programming 기술을 기반으로하는 프로그램을 탄력적으로 적응 적으로 확장 할 수 없으므로 메시지 버스, 데이터 그리드 또는 맞춤형 네트워크 프로토콜과 같은 상단에 추가 도구를 레이어해야합니다. 여기서 Reactive Systems의 Message-Driven 방식은 모든 차원의 스케일에서 프로그래밍 모델과 의미를 유지하는 통신 추상화이므로 시스템 복잡성과인지 오버 헤드를 줄입니다.

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

예를 들어, 익명 콜백을 기반으로하는 시스템은 사용자가 추론해야 할 때 통찰력을 유지하거나 유지해야하며, 무엇보다도 생산 중단 및 오작동이 발생하는 위치와 이유를 파악해야합니다.

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

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

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

리액티브 프로그래밍은 단일 노드 또는 서비스 간의 비동기식 비 블로킹 데이터 흐름 관리에 중점을 두지 만 복잡한 리 액티브 시스템 아키텍처는 노드 및 클러스터에 여러 서비스를 성공적으로 배포하는 데 훨씬 더 많은 것을 필요로합니다.

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

리액티브 프로그래밍 및 시스템은 빠른 데이터 스트리밍과 어떤 관련이 있습니까?

빠른 데이터 스트리밍 (분산 스트림 처리) 6은 사용자 관점에서 일반적으로 로컬 및 스트림 기반 추상화를 사용하여 이벤트 중심으로 기능적 결합 자 및 콜백과 같은 리 액티브 프로그래밍 구조에 의존하는 최종 사용자 API를 노출합니다.

그런 다음 최종 사용자 API 아래에서 일반적으로 Message-passing 및 스트림 처리 단계의 분산 시스템, 내구성 이벤트 로그, 복제 프로토콜을 지원하는 노드 사이의 Reactive Systems의 원칙을 사용합니다. 이러한 부분은 일반적으로 개발자. 이는 사용자 수준에서 리 액티브 프로그래밍을 사용하고 시스템 수준에서 리 액티브 시스템을 사용하는 좋은 예입니다.

리액티브 프로그래밍 및 시스템은 마이크로 서비스와 어떤 관련이 있습니까?

마이크로 서비스 기반 아키텍처 - Cloud를 지정된 배포 플랫폼으로 사용하는 자율적 인 분산 서비스 시스템을 설계하는 것은 Reactive를 수용하여 제공되는 가치에서 많은 이점을 얻습니다.

지금까지 살펴본 바와 같이, 리액티브 프로그래밍과 리액티브 시스템 설계는 서로 다른 상황에서 서로 다른 이유로 중요합니다.

• 리액티브 프로그래밍은 단일 마이크로 서비스 내에서 서비스 내부 로직 및 데이터 흐름 관리를 구현하는 데 사용됩니다.
• 리액티브 시스템 디자인은 마이크로 서비스 사이에서 사용되며 분산 시스템의 규칙에 따라 재생되는 마이크로 서비스 시스템을 만들 수 있습니다.
  메시지 주도로 가능해진 탄력성과 탄력성을 통한 반응성.

리액티브 프로그래밍 및 시스템은 모바일 애플리케이션 및 IoT (Internet of Things)와 어떤 관련이 있습니까?

Internet of Things (IoT) - 연결된 센서, 장치 및 가전 제품의 폭발로 인해 검색, 집계, 분석 및 푸시 아웃해야하는 많은 양의 데이터를 생성하는 동시에 연결된 모든 장치를 처리하는 방법에 문제가 발생합니다. 전체적인 시스템 응답을 유지하면서 모든 장치를 지원합니다. 이러한 과제에는 센서 데이터 수신, 대량 프로세스 (일괄 프로세스 또는 실시간) 처리, 실제 사용 패턴에 대한 값 비싼 시뮬레이션을 통해 트래픽 급증을 관리하는 것이 포함됩니다. 일부 IoT 배포에서는 장치에서 보낸 데이터를 소비하는 것이 아니라 장치를 관리하는 백 엔드 서비스가 필요합니다.

잠재적으로 수백만 개의 연결된 장치가 사용할 수있는 서비스를 구축 할 때 대규모의 정보 흐름에 대처할 수있는 모델이 필요합니다. 장치 고장을 처리하기위한 전략, 정보가 손실되었을 때, 서비스가 실패 할 때를 대비하여 전략이 필요합니다. 이 모든 것을 관리하는 백엔드 시스템은 수요에 맞게 확장하고 완전히 복원력이 있어야합니다. 즉, 리 액티브 시스템이 필요합니다.

많은 양의 센서가 데이터를 생성하고이 데이터가 도착하는 속도를 처리 할 수 ​​없기 때문에 IoT의 백엔드에서 흔히 볼 수있는 문제는 장치 및 센서에 역 압력을 구현할 필요가 있음을 나타냅니다. IoT 시스템의 엔드 투 엔드 데이터 흐름 (수많은 장치) : 서비스를 중단하지 않고도 데이터를 저장하고 정리하고 처리하고 분석을 실행해야하는 필요성 - 비동기식, 비 차단식 역 압력의 흐름이 중요 해지면 리 액티브 프로그래밍 (Reactive Programming)이 실제로 빛을 발합니다.

리액티브 프로그래밍 및 시스템은 전통적인 웹 응용 프로그램과 어떤 관련이 있습니까?

웹 응용 프로그램은 Reactive Programming 스타일 개발의 이점을 크게 누릴 수 있으므로 서비스 호출을 분기하고 비동기 적으로 리소스를 가져 오며 응답을 작성한 후 클라이언트에 마샬링하는 등 요청 / 응답 워크 플로를 구성 할 수 있습니다. 가장 최근에는 Server-Sent 이벤트와 WebSocket이 점점 더 많이 사용되어 왔으며이를 대규모로 수행하면 열려있는 많은 연결을 유지하는 효율적인 방법이 필요합니다. IO가 차단되지 않는 경우 Reactive Programming은 이에 대한 도구를보다 구체적으로 제공합니다 Streams and Futures를 사용하면 비 차단 및 비동기 변환을 수행하고이를 클라이언트에 전달할 수 있습니다. 리 액티브 프로그래밍은 데이터 액세스 계층에서 중요한 역할을합니다. 비효율적 인 드라이버가있는 SQL 또는 NoSQL 데이터베이스를 사용하는 것이 리소스 효율적인 방식으로 데이터를 업데이트하고 쿼리합니다.

또한 웹 애플리케이션은 리액티브 시스템 디자인의 이점을 활용하여 분산 캐싱, 데이터 일관성 및 노드 간 알림을 제공합니다. 전통적인 웹 응용 프로그램은 일반적으로 상태 비 저장 노드를 사용합니다. 그러나 SSE (Server-Sent-Events) 및 웹 소켓을 사용하자 마자 노드는 클라이언트 연결 상태를 유지하고 있으므로 푸시 알림을 그에 따라 라우팅해야하므로 상태가 유지됩니다. 이렇게하려면 효과적으로 반응 형 시스템 디자인이 필요합니다. 메시징을 통해받는 사람을 직접 주소 지정하는 것이 중요한 영역이기 때문입니다.

요약

기업 및 미들웨어 업체는 모두 리액티브를 채택하기 시작했으며 2016 년에는 Reactive 채택에 대한 기업의 관심이 크게 증가했습니다. 이 글에서는 리액티브 시스템을 중요요한 툴 중 하나 인 Reactive Programming과 함께 기업용 멀티 코어, 클라우드 및 모바일 아키텍처의 컨텍스트를 가정하는 최종 목표로 설명했습니다.

Reactive Systems는 내부 논리 및 데이터 흐름 변환을위한 구성 요소 수준에서 성능 및 자원 효율성을 통해 개발자를 위한 생산성을 제공하며 Reactive Systems는 "Cloud Native"를 구축하고 시스템 수준에서 복원력과 탄력성을 통해 Architects 및 DevOps에 생산성을 제공합니다. 다른 대규모 분산 시스템. Reactive Programming의 기술을 Reactive Systems의 설계 원칙에 결합하는 것이 좋습니다.

---

1 일반적으로 파일 시스템과 같은 기본 OS 기능에 의존하지 않는 대신 일반적으로 구성 가능한 끝점을 사용하여 클라우드와 같은 가상화 된 환경에서 실행할 수 있도록 해주는 응용 프로그램을 가리키는 다소 정의되지 않은 용어입니다.

2 이 프레젠테이션에서 FRP의 발명가 인 Conal Elliott에 따르면.

3 Amdahl의 법칙에 따르면 시스템의 이론적 인 속도 향상은 일련의 부품에 의해 제한되므로 새로운 자원이 추가 될 때 시스템의 수익이 줄어들 수 있습니다.

4 Neil Günter의 범용 확장 성법은 동시 및 분산 시스템에서 경합 및 조정의 효과를 이해하는 데 필수적인 도구이며 새로운 자원이 시스템에 추가 될 때 시스템의 일관성 비용이 부정적인 결과를 초래할 수 있음을 보여줍니다.

5 메시징은 동기식 (발신자와 수신자가 동시에 사용 가능해야 함) 또는 비동기식 (시간 내에 분리 될 수 있음) 중 하나 일 수 있습니다. 의미 론적 차이에 대해 논의하는 것이이 백서의 범위를 벗어납니다.

6 예를 들어 Spark Streaming, Flink, Kafka Streams, Beam 또는 Gearpump를 사용합니다.

7 autonomous라는 단어는 자동을 뜻하는 auto라는 단어에서 비롯된 것이며 law는 법을 의미합니다. 나. 자신의 법에 따라 사는 요원 : 자치와 독립.

Original text

[1] Reactive Programming versus Reactive Systems, LightBend