Reactive Programming

fireFox·2022년 5월 2일

reactive

Reactive Programming

목록 보기

1/3

개요

리액티브 프로그래밍은 데이터의 흐름과 변화의 전파에 중점을 둔 프로그래밍 패러다임이다.

Reactive Programming 이라는 단어를 사전적으로 해석해보면 반응형 프로그래밍이다.
어떤 데이터의 변화가 있을때 변화를 중심으로 데이터흐름을 처리하겠다는 것이다.

또한 리액리브 프로그래밍은 선언적 프로그래밍이다.
선언적 프로그래밍은 코드가 과정을 표현하는 것이 아니라 행위를 선언만 하는 프로그래밍 패러다임을 말한다.

명령형 VS 선언형(리액티브)

1. 명령형 프로그래밍

명령형 프로그래밍은 실행할 동작을 구체적으로 명시하고 이를 실행하는 프로그램이다.

int Data1 = 10;
int Data2 = 10;
int Data3 = 10;
int Total = Data1 + Data2 + Data3;
// Total = 30

명령형 프로그래밍은 위의 java 코드처럼 변경이 발생하면, 변경이 발생했다는 요청을 받아서 Total값을 새로 계산하여 당겨오는 방식이다. (Pull 방식)
만약 위의 코드가 이미 실행된 경우라면 Data2의 값이 10->30으로 바뀐다고 해도 Total값이 30이라는 점은 변하지 않는다.

2. 리액티브 프로그래밍

리액티브 프로그래밍을 이해하기 좋은 예시에는 엑셀이 있다.

Total셀은 Data1, 2, 3 셀의 값을 합산한다는 선언(SUM(A2:C2)만 했을뿐 어떻게 값을 꺼내오고 어떻게 더해서 결과를 나타낼지 표현되어있지 않다.

만약 Data2 의 값이 10->30으로 변화가 있으면 Data2셀의 변경사항은 자동으로 전파되어 미리 정해둔 수식으로 처리되고 Total값에 반영된다.

리액티브 프로그래밍은 Data값의 변화가 있을때마다 감지하여 변경된 Total값만을 밀어주는 방식이다. (Push 방식)

리액티브 프로그래밍을 사용하는 이유

사용자들은 항상 빠르고 안정적인 서비스를 기대한다. 기존 MVC같은 아키텍처에서는 동기-Blocking 방식을 사용하여 요청을 처리했다. 하나의 쓰레드에서 하나의 요청을 처리하고, 요청이 다 끝날때까지 해당 쓰레드는 다른 요청을 처리하지 못한다.

그러다보니 트래픽이 증가하여 서버가 더 이상 사용할 쓰레드가 없는경우, 서버는 다른 쓰레드가 요청을 처리할때까지 대기상태에 놓이게 되고 사용자는 응답을 받지 못한다.

문제는 사용자는 계속해서 증가하고 어플리케이션에서 처리해야할 데이터는 계속 늘어나고 있다는 점이다.
그래서 적은 수의 쓰레드를 가지고 데이터 생산자가 소비자에게 감당하지 못할 요청을 주지않도록 Backpresure로 조절하며, 비동기 방식으로 데이터를 처리하는 리액티브 프로그래밍의 필요성이 증가하고 있다.

(생산자, 소비자와 Backpresure 부분은 다음 내용인 Reactive Stream에서 더 자세하게 설명하겠습니다.)

리액티브 선언문

재미있게도 리액티브 선언문이라는것이 존재한다. 리액티브 선언문은 리액티브 프로그래밍의 정의, 필요성, 프로그래밍 방법을 서술하고있다.

리액티브한 프로그래밍을 위해 아래 4가지 원칙이 필요하다.

응답성 : 시스템은 가능한 한 즉각적으로 응답해야한다.
탄력성 : 어떤 시스템에 장애가 발생했을때 다른시스템에 문제를 전파시키지않고 복구가 잘되는것.
유연성 : 사용량에 대해 유연하게 대비할 수 있어야한다.
메시지 기반(Message Driven) : 메시지를 전달하는 방식으로 프로그래밍이 구성된다. 메시지를 보내고 받을때는 보내고 잊는(fire-and-forget) 방식을 이용한다. 즉 메시지를 누가 보냈는지, 누가 처리하는지는 신경쓰지않는다.

한글 번역도 잘 되어있고 심지어 진짜 독립선언문마냥 서명도 받으니 한번 확인해보자 https://www.reactivemanifesto.org/ko