[Spring WebFlux] 0. 리액티브 프로그래밍의 소개

 

 

🤔 1. 리액터(Reactor)는 무엇인가요?

 

 

간단 용어 정리

- Reactive Stream : JVM 위에서 실행될 수 있는 리액티브 프로그래밍 라이브러리를 표준화시킨 것으로 이해할 수 있습니다. 인터페이스의 형태로 스펙이 정의되어 있습니다.

- Reactor3 : Reactive Stream 스펙을 구현한 구현체 라이브러리입니다. JVM 위에서 리액티브 프로그래밍이라는 새로운 패러다임을 적용시키기 위한 라이브러리입니다. 

- TCK(Reactive Streams Technology Compatibility Kit) : Reactive Streams 구현자가 사양에 정의된 규칙에 대해 구현을 확인하기 위한 지침으로, TestNG라는 Java의 테스트 프레임 워크로 개발이 되었습니다.

 

 

 

리액티브 스트림의 스펙은 JVM 위에서 실행될 수 있도록 리액티브 프로그래밍 라이브러리를 산업에서 주도적으로 개발되어 표준화 된 것을 의미합니다. 

 

4가지의 매우 단순한 인터페이스를 포함한 형태로 구성이 되어있으며, 해당 인터페이스를 구현함과 동시에 TCK(Reactive Streams Technology Compatibility Kit) 규칙을 통과해야 Reactor Streams를 구축한 것이라고 볼 수 있습니다. 

 

우리는 리액티브 프로그래밍을 하기 위해 이렇게 Reactive Stream 인터페이스를 모두 구현하고, TCK를 통과한 구현체를 사용하게 됩니다. 그 구현체의 종류 중 하나가 바로 Reactor3에 해당합니다. 리액터들은 Reactor3, RxJava2, Akka Streams 등 다양한 구현체들이 존재합니다. 또한 Reacitve Streams는 리액터 간의 상호 운용(호환 가능하도록)이 가능하도록 동작하는 방법을 설계했습니다.

 

Reactive Streams는 여전히 사용자 입장에서는 Low-Level의 기술입니다. 그래서 우리는 구현체인 Reactor3를 사용합니다.

Reactor3는 Reactive Streams Publisher 위에 빌드함으로써 다양한 상황에서 영향력을 미칠 수 있도록 High Level API를 제공하는 것을 목적으로 개발되었습니다.

 

 

 

🤔 2. 그럼 리액티브 프로그래밍이 뭔가요? / 왜 사용하나요?

 

리액티브 프로그래밍(Reactive Programming)은 비동기적인 프로세싱 파이프라인을 만들기 위한 목적으로 개발되었고, 함수형 프로그래밍과 유사한 "선언적 코드"를 사용한 새로운 패러다임입니다. 

 

백기선님도 이 "선언적 코드"의 의미에 대해 굉장히 의아해 하셔서 다양한 글을 서치해보셨지만, 명확한 답은 얻지 못했습니다.

그래서 추가적으로 찾아본 결과,

 

기존의 명령형 프로그래밍 : 
원하는 결과를 달성해 나아가는 과정에만 관심을 두는 방식의 프로그래밍 스타일. URL에서 공백을 허용하지 않고 하이픈으로 바꾸는 과정을 그대로 코딩하는 방식.

var string = 'THis is the midday show with Cheryl Waters';    
var urlFriendly = "";    

for(var i=0; i<string.length; i++){    
    if(string[i] === " "){    
        urlFriendly += "-";    
    }else{    
        urlFriendly += string[i];    
    }    
}    
    
console.log(urlFriendly);​

새로운 패러다임, 선언적 프로그래밍 : 

const string = 'This is the midday show with Cheryl Waters';    
const urlFriendly = string.replace(/ /g, '-');    

console.log(urlFriendly);

선언적 프로그래밍에서는 구체적인 절차 대신에 replace라는 함수를 사용해 추상적인 개념을 표현했습니다.
선언적 프로그래밍의 코드 구문에서는 어떤 일이 발생해야 하는지 기술하고, 실제로 그 작업을 처리하는 방법은 추상화로 아랫단에 감추어집니다.

[링크 : https://velog.io/@hyun_sang/%EB%AA%85%EB%A0%B9%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EA%B3%BC-%EC%84%A0%EC%96%B8%EC%A0%81-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EB%B9%84%EA%B5%90 ]

 

이러한 글을 찾아 볼 수 있었습니다. 사실 명확하게 정의된 규칙 같은게 존재하지 않기 때문에 와닿지 않고 추상적이다라고 느낄 수 있을 것 같습니다.

 

제가 이해한 바로는, 각각의 작은 함수에 그 함수가 하는 일을 잘 설명하는 이름을 붙여 더 읽기 쉽고, 추론하기 쉽게 개발하며, 내부 구현은 감추어 드러나지 않도록 하는 것으로 이해했습니다.

 

리액티브 프로그래밍은 이벤트 기반의 모델으로, 데이터를 사용할 준비가 되면 소비자에게 push하는 방식으로 동작합니다.

이로써 우리는 비동기적으로 이벤트의 시퀀스를 다룰 수 있습니다. 

 

리액티브 프로그래밍은 이러한 구조를 통해 가지고 있는 자원을 더욱 더 효율적으로 사용할 수 있고, 더 많은 사용자들을 수용할 수 있는 어플리케이션을 만들도록 도와줍니다. 

또한 Runnable, Thread와 같은 Low-Level의 직접적인 기술 사용으로 인해 스트레스를 받지 않고도 병행 / 병렬 코드를 작성할 수 있도록 도와주는 것이 큰 메리트에 해당합니다.

 

리액티브 프로그래밍은 두 가지 핵심 키워드를 기반으로 설계 되었습니다. 바로 "비동기(Asynchronous)"와 "논블로킹(Non-Blocking)"이죠.

즉, 리액티브 프로그래밍은 Callback 기반 API 혹은 Future 키워드를 대체하여 비동기 코드를 작성할 수 있는 훌륭한 대안이 된다는 것입니다.

또한 리액티브 프로그래밍을 사용하면 비동기 방식의 코드를 좀 더 readable하고 maintainable하도록 만들어 준다는 장점이 있습니다.

 

 

 

 

💡 3. 여기까지 중간 정리!

 

리액티브 프로그래밍 : 비동기적인 프로세싱 파이프라인을 개발할 수 있으며, 이벤트 기반의 모델입니다. 비동기 / 논블로킹 방식을 통해 자원의 효율적 사용과 다수의 사용자 수용을 가능케 합니다.

Reactors Streams : 이러한 리액티브 프로그래밍을 가능케 하도록 만든 표준화된 라이브러리로 인테페이스의 형태로 스펙이 정의되어 있습니다.

Reactors3 : Reactors Streams 구현한 구현체, TCK를 통과한 구현체에 해당하며, 이를 통해 우리는 쉽게 리액티브 프로그래밍을 할 수 있도록 만들어줍니다. 

 

 

 

🤔 4.  Reactive Streams Interface 명세

간단 요약!
아래 4개의 API Components로 구성되어 있습니다.

1. Publisher
2. Subscriber
3. Subscription
4. Processor

 

자세한 명세는 아래의 깃허브 Readme에서 확인할 수 있습니다.

GitHub - reactive-streams/reactive-streams-jvm: Reactive Streams Specification for the JVM

 

추가적인 공부를 통해 나중에 자세히 공부해보도록 하겠습니다 :)

 

 

 

🤔 5.  Reactive Stream Sequence의 상호작용

https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/Intro

 

Reactive Stream의 시퀀스는 Publisher가 데이터를 생산해냅니다.

하지만, 기본적으로 Subscriber가 등록되기(구독하기)전까지 아무런 일도 하지 않습니다.

즉, Publisher는 Subscriber가 등록되는 시점부터 데이터를 push 하게 됩니다.

 

그림을 자세히 보시면, Subscriber는 Publisher에게 피드백을 줍니다.

간단하게 설명하자면, 이 피드백은 혼잡을 제어할 수 있는 도구로 "모든 이벤트를 다 push하지 말고, N개만 보내줘"와 같은 요구에 해당한다고 합니다. 이로써 Subscriber에 데이터가 지나치게 쌓여서 감당할 수 없는 현상을 제거하기 위해 이 피드백은 굉장히 중요한 역할을 합니다.

 

이러한 피드백을 관장하는 요소가 바로 Back-Pressure 입니다. 한국어로는 '배압'이라고 한답니다.

백기선님의 유튜브에서 이 Back-Pressure는 굉장히 중요한 키워드라고 했지만, 자료에서 Back-Pressure을 설명하지 않은 것이 굉장히 부실하다고 말씀을 하셨네요. 그래서 추가적인 자료를 찾아 정리를 했습니다.

 

배압은 사전적 의미로 파이프를 통한 유체 흐름에 반하는 저항, 힘을 의미하며 유체가 흐르는 방향과 반대 방향으로 작용하는 저항 압력을 의미합니다.

 

도대체 이게 소프트웨어 얘기를 하다가 왜 나오느냐? 라는 의문이 있을 수 있지만, Reactive Streams는 실제 세상에 있는 파이프와 그 흐름을 빗대어 설계된 것입니다. 단지 그 내용물이 액체와 기체가 아닌 데이터로 바뀐 것 뿐이죠. 그렇기 때문에 이 Reactive Streams에서도 배압이 존재합니다.

 

배압의 필요성은 아래 그림으로 쉽게 알아볼 수 있습니다.

 

배압이 정상적으로 동작한다면, 모두가 일정한 처리량을 유지하면서 진행합니다.

Fast Producer가 Slow Consumer에게 적절한 속도로 벽돌을 제공하기 때문에 일이 잘 진행될 수 있습니다.

반면에 배압이 없다면, Fast Producer는 Slow Consumer를 고려하지 않고 무지성 벽돌 전송하는 모습을 볼 수 있습니다.

Slow Consumer는 감당하지 못하고 도망쳐버립니다. 

 

 

소프트웨어 환경에서는 CPU와 메모리, Data Drop 현상을 겪을 수 있습니다. Network I/O, Disk I/O, Out of Memory 등의 현상을 겪을 수도 있고요.

 

그렇기 때문에 이러한 현상을 막기 위한 노력이 필요할 것입니다.

 

 

Reactor는 어떤 데이터가 대해서 각각의 단계를 적용하기 위한 처리에 대한 내용을 기술하기 위해 서로 묶여있는, 오퍼레이터라는 개념을 추가했습니다.

오퍼레이터를 적용하면, 중간 퍼블리셔(upstream에 대한 subscriber, downstream에 대한 publisher)를 리턴하게 됩니다. 

Flux<String> flux = Flux.just("A");
flux.map(s -> "foo" + s); // 새로운 Publisher 생성, 걔를 구독해야 fooA가 찍힘.
flux.subscribe(System.out::println); // 얘는 1번 라인의 flux를 구독, 따라서 "A"가 나온다.

Flux<String> flux = Flux.just("A");
Flux<String> flux2 = flux.map(s -> "foo" + s);
flux2.subscribe(System.out::println); // fooA

두 번째 줄의 코드를 보면, flux.map()을 통해서 새로운 중간 publisher가 생성되게 됩니다.

하지만 셋째 줄에서 첫째 줄의 flux를 subscribe 했기 때문에 "fooA"가 아닌 "A"가 나오게 되죠.

 

그 아래의 코드대로 사용하면, 기존의 의도대로 코드가 나오게 됩니다. 물론 flux2를 생성하지 않고 이어서 선언할 수도 있습니다.

 

 

 

🏝 출처

[링크] https://www.youtube.com/watch?v=VeSHa_Xsd2U&list=LL&index=2 (백기선님 유튜브)
[링크] https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/Intro (Introduction to Reactive Programming)
[링크] https://doublem.org/stream-backpressure-basic/ (back-pressure에 대한 이해)
[링크] https://www.oreilly.com/library/view/spring-50-projects/9781788390415/fd86b987-d9dd-465e-837f-ab4534e9d337.xhtml (TCK)