Project Reactor 1.리액티브 프로그래밍
1. 리액티브 프로그래밍
스프링 5 버전 이후로, 스프링 기반의 "리액티브 프로그래밍"이 많이 도입되고 있지만, 아쉽게도 해당 주제에 대한 국내 레퍼런스가 많지 않은 상황이다. 필자는 2019년 상반기에 "Reactive Spring"이라는 큰 주제로 글을 작성할 예정이다. "Reactive Spring" 의 하위 주제로 "Reactor", "Spring Webflux", "Spring Reactive Data" 의 세 번의 주제로 글을 작성할 예정이며, 상반기 완료하는 목표로 시작하였다. 쉽지 않은 주제라서, 잘못된 내용이 포함될 수 있다. 이 글을 읽는 개발자 중에서, "Reactive Spring" 개발 경험이 있다면 그냥 지나치지 말고 피드백을 꼭 해주길 바란다.
전체 목차
Reactive Spring
첫 번째 주제는, Project Reactor
1. 리액티브 프로그래밍 (현재 글)
2. Async VS Non-Blocking
3. Reactive Streams
4. Project Reactor Flux, Mono Basic
5. Project Reactor Subscriber
6. Project Reactor Data Processing
7. Project Reactor Create, Generator
8. 미정
두 번째 주제는, Spring Webflux
목차 미정
세 번째 주제는, Spring Reactive Data
목차 미정
추후에 목차는 변경될 수 있습니다.
Overview
스프링 5 버전이 도입되면서, 스프링 프레임워크는 새로운 도전에 직면하게 되는데 바로 "리액티브 프로그래밍"이다. 스프링 프레임워크 오픈소스를 리딩하고 있는 "Pivotal"에서는 오래전부터 "리액티브 프로그래밍"을 준비하고 있었는데, 프로젝트 이름은 "Reactor" 이다. "Reactor" 는 "Reactive Streams"의 구현체로서, 스프링 5 리액티브 프로그래밍의 핵심 라이브러리이다. 많은 개발자들이 Reactor 를 이해하지 않고, Webflux 를 성급하게 도입하려는 시도를 많이 하는데, 바람직하지 않다고 생각한다. "Reactor"를 먼저 이해하고 Webflux 를 도입해야 한다는 점을 반드시 명심하길 바란다. by Eddy.Kim
사실, 필자도 아직은 잘 모른다. 이제 막 공부를 시작하였다.
1. Reactive Programming(리액티브 프로그래밍)
1.1 Reactive(리액티브)
2015년부터 상업용 미들웨어 업체에서 "리액티브"에 대한 관심이 크게 증가해 왔다. 보통 일반적으로 소프트웨어 개발에서 "리액티브"라는 용어는 아래와 같은 3가지 의미로 주로 사용된다. [1]
Reactive Systems (architecture and design)
Reactive Programming (declarative event-based)
Functional Reactive Programming (FRP)
또한, "리액티브"의 3가지 의미와 함께 자주 사용되는 단어는 streaming, lightweight, real-time이다. [1]
streaming, lightweight, real-time
필자는, "리액티브" 라는 단어는 한 문장으로 표현하기는 어렵고, "Reactive"라는 단어는 너무 추상적이고 명확하지 않은 단어라고 생각한다. "뉴욕의 프로그래머" 저자인 "임백준"님은, ZDnet 기사에서 "리액티브"라는 의미를 아래와 같이 정의하였다.
사용자가 해당 소프트웨어를 사용하기 위해서 어떤 입력을 발생시켰을 때 꾸물거리지 않고 최대한 빠른 시간 내에 응답을 한다는 의미다.[3]
필자가 생각하는 "리액티브"의 가장 심플한 예는 MS엑셀의 스프레드시트 이다. 엑셀의 나열된 셀에 데이터가 있다고 가정하자. 만약, 특정 셀의 데이터를 변경하게 되면 해당 셀과 관련된 모든 셀들이 동시에 변경이 된다. 어쨌든 "리액티브"는 일련의 설계 원칙이다.
혹시, 이 글을 읽는 개발자 분 중에서, "리액티브"에 대해서 명확하게 정의를 내릴 수 있는 개발자가 있다면 피드백을 해주길 바란다.
1.2 리액티브 선언문
리액티브라는 용어의 의미를 정의하려고 노력하는 "리액티브 선언문"에 따르면 리액티브는 4가지 속성으로 이루어진다. 참고로, 임백준 님의 기사에서는 Resilient 를 유연성[3]으로 번역하였으나, 리액티브 선언문의 한글 번역 버전에서는 Resilient 를 탄력성으로 번역하였고, Elastic 를 유연성으로 번역하였다. 필자는, 선언문의 번역을 기준으로 글을 작성하겠다. 선언문에서 정의한 리액티브의 4가지 속성은 아래와 같다.
응답성(responsive)
탄력성(resilient)
유연성(elastic)
메시지 주도(message driven)
https://www.reactivemanifesto.org/ko응답성(responsive)
시스템이 가능한 한 즉각적으로 응답하는 것을 응답성이 있다고 한다. 문제를 신속하게 탐지하고 효과적으로 대처할 수 있는 것을 의미한다. 응답성이 있는 시스템은 신속하고 일관성 있는 응답 시간을 제공하고, 신뢰할 수 있는 상한선을 설정하여 일관된 서비스 품질을 제공한다. 이러한 일관된 동작은 오류 처리를 단순화하고, 일반 사용자에게 신뢰를 조성하고, 새로운 상호 작용을 촉진한다. [4]
탄력성(Resilient)
시스템이 장애에 직면하더라도 응답성을 유지하는 것을 탄력성이 있다고 한다. 탄력성이 없는 시스템은 장애가 발생하면, 장애가 전파되고 응답성을 잃게 된다.
유연성(Elastic)
시스템이 작업량이 변화하더라도 응답성을 유지하는 것을 유연성이라고 한다. 리액티브 시스템은 입력 속도의 변화에 따라 이러한 입력에 할당된 자원을 증가시키거나 감소시키면서 변화에 대응한다. 시스템에서 경쟁하는 지점이나 중앙 집중적인 병목 현상이 존재하지 않도록 설계하여, 구성 요소를 샤딩하거나 복제하여 입력을 분산시키는 것을 의미한다. 실시간 성능을 측정하는 도구를 제공하여 응답성 있고 예측 가능한 규모 확장 알고리즘을 지원한다. 이 시스템은 하드웨어 상품 및 소프트웨어 플랫폼에 비용 효율이 높은 방식으로 유연성을 제공한다. [4]
메시지 기반(Message Driven)
비동기 프로토콜을 기반으로, 메시지 기반으로 느슨하게 결합한 시스템 아키텍처를 구성한다. 명시적인 메시지 전달은 시스템에 메시지큐를 생성하고, 모니터링하며 필요시 BackPressure 를 적용하여 유연성을 부여한다. 이런 메시지 기반 시스템은 큐 분산 시스템으로 시스템 부하를 막고 안정적인 시스템을 운영할 수 있다.
[레퍼런스] 리액티브 선언문
http://www.reactivemanifesto.org/
1.3 리액티브 프로그래밍 vs 리액티브 시스템
"리액티브 시스템"은 클라우드 환경 및 분산 시스템을 구축하기 위해 시스템 레벨에서 아키텍트와 DevOps를 위한 생산성을 제공한다. "리액티브 시스템"으로 구축된 시스템은 보다 유연하고, 느슨한 결합을 갖고, 확장성이 있다. 이로 인해 개발이 더 쉬워지고 변경 사항을 적용하기 쉬워진다. 리액티브 시스템은 장애에 대해 더 강한 내성을 지니며, 비록 장애가 발생하더라도, 장애 전파가 발생하지 않고, 간결한 방식으로 장애를 해결한다. 리액티브 시스템은 높은 응답성을 가지며 사용자에게 효과적으로 피드백을 제공한다.[1][2]
반면에, "리액티브 프로그래밍"은 "리액티브 시스템"의 구현 수준의 하위 집합으로, 내부 로직 및 데이터 흐름 관리를 위한 구성요소 단계에서 성능 및 리소스 효율성을 높이는 등 높은 생산성을 제공해준다. "리액티브 시스템" 의 구성 요소로서 "리액티브 프로그래밍"을 사용하는 것은 매우 유익할 것이다. [1][2]
필자는 이 글에서는 더 이상 "리액티브 시스템"에 대해서는 자세히 다루지 않을 예정이다.
Event-Driven vs Message-Driven
https://www.lightbend.com/reactive-programming-versus-reactive-systems
1.4 JDK 환경에서의 리액티브 프로그래밍
JDK 위에서 "리액티브 프로그래밍"을 제공하는 기술은 아래와 같다.
RxJava
Project Reactor
Spring Framework 5.0
Ratpack
Akka
필자는 Reactor에 대해서만 공부할 예정이다.
1.5 정리
Composing asynchronous & event-based sequences, using non-blocking operators.
"리액티브 스프링" 시리즈의 첫 번째 주제로 작성한 이 글에서는, "리액티브 프로그래밍"에 대해서 간략하게 정리를 하였다. 필자가 작년에 "스프링 리캡 데이"라는 세미나에서 스프링 웹 플럭스에 대해서 강연을 들은 적이 있다. 해당 세미나를 듣고 나오면서 팀원과 나눴던 대화가 정확히 기억난다.
"Webflux(웹플럭스)를 언제 사용하는지 모르겠다..."
필자가 당시에, "리액티브 프로그래밍" 에 대해서 이해가 전혀 없었다. 만약, 필자가 당시 "리액티브 프로그래밍"에 대한 이해가 사전에 있었다면, 웹플럭스를 언제 사용하면 좋을지에 대해서 좀 더 명확하게 이해할 수 있었을 것이다. 스프링 기반 환경에서, "리액티브" 프로그래밍을 구현하기 위해서, 반드시 Reactor 를 정복해야 할 것이다. 필자는 당분간 Reactor 를 집중해서 공부할 예정이다.
1.6 필자의 의견
혹시라도, "Project Reactor" 에 대한 내용이 전혀 없어서 실망을 하셨다면 죄송합니다. "Project Reactor"에 대해서는 3장 이후에 작성할 예정입니다. 마음이 급하신 분들은, 공식 레퍼런스를 참고하시길 바랍니다.
https://projectreactor.io/docs/core/release/reference/
[레퍼런스]
[1] https://www.lightbend.com/reactive-programming-versus-reactive-systems
[2] https://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscape
[3] http://www.zdnet.co.kr/view/?no=20161010104628 : ZDNet Korea, 임백준 님
[4] https://www.reactivemanifesto.org/ko
[5] https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems
