[Programming] Reactive (리액티브)

웹 서비스에서 흔히 발생하는 일이 있습니다. 하나의 API 결과 뿐만 아니라 n개의 API 결과를 받아보고 싶습니다. 흔히 우리가 SPA를 가지고 웹 애플리케이션을 만들다보면 여러 API를 호출하는 일이 있는데, 이와 비슷한 이야기입니다.

 

Reactive Programming이 나오기 이전, 우리가 생각하는 대규모 애플리케이션은 그냥 수십대 서버를 가지고 GB 정도의 데이터, 몇 초 걸리는 응답 시간, 유지보수는 몇 시간 걸리는 정도가 당연하다. 라고 보고 운영을 해왔습니다. 하지만 지금은 어떨까요? 다양한 서비스가 있고, 특히 한국에서는 인터넷 속도가 굉장히 빠르기 때문에 페이지 로딩 시간이 수 초라도 걸리면 그냥 닫아버리는 게 관습이 되어버렸죠.

 

이렇게 변화가 된 이유는 무엇일까요?

 

• 늘어난 데이터
  
  시간이 갈수록 데이터량은 늘어나는데, 그에 따라 성능이 따라가지 못함.
  
  
• 사용 패턴의 변화
  
  사용자는 1년 내내 언제 어디서든 ms 단위의 응답 시간을 요구함.

 

요구 사항이 늘어나고 사용자가 늘어나면 그만큼 데이터는 늘어나게 됩니다. 그렇다면 그에 따라서 성능도 변화가 생기는데, 사용자는 그로 인한 성능 변화에 되게 민감하다는 것이죠. 따라서 Reactive Programming은 이러한 성능 변화에 대처하기 위한 기술이라고 할 수 있습니다.

 

 

 

Reactive

이런 의문을 가질 수 있습니다. 그럼 도대체 Reactive가 뭐야? 제가 생각하는 Reactive 란, 마우스 이벤트나 Network I/O 등의 입력 이벤트를 발생시켰을 때 즉각 반응하여 처리하는 것을 Reactive라 합니다.

 

음 이것만 가지고는 설명이 부족한데? 그러면 이런 건 어떨까요. 우리가 데이터베이스에서 원하는 정보를 검색하고자 할 때 그 검색 결과를 보려면 Enter를 눌러야 합니다. 하지만 Reactive는 사용자가 입력한 데이터를 바로 읽어서 그 결과를 보여주는 것이죠. 이것을 우리는 Reactive라 합니다.

 

 

 

Reactive Manifesto

Reactive Manifesto는 "Reactive"라는 용어를 정의하기 위해 만들어진 선언문으로 이 선언문에는 Reactive의 4가지 속성을 이야기 합니다.

 

The Reactive Manifesto

 

• 반응성 (Responsive)
  
  Reactive 시스템은 일정하고 예상 가능한 반응 시간을 제공해야 함.
  
  
• 회복성 (Resilient)
  
  장애가 발생해도 시스템의 운영은 지속되어야 함. 
  
  
• 탄력성 (Elastic)
  
  대용량 트래픽과 같은 거대한 부하 내에서도 버틸 수 있도록 컴포넌트 자원 수를 동적으로 확장할 수 있어야 함.
  
  
• 메시지 주도 (message-driven)
  
  회복성과 탄력성 원칙을 지키기 위해선 느슨한 결합, 고립, 위치 투명성 등을 지원하도록 컴포넌트 간 경계가 명확해야 함.
  (비동기 프로토콜을 이용한 메시지 기반의 통신으로 느슨한 결합의 시스템 아키텍처를 권장)

자세히 보면 마이크로서비스 아키텍처가 갖춰야 할 원칙이기도 합니다. 우리가 시스템을 좀 더 리액티브하게 개발하고자 한다면 가능한 컴포넌트간 결합이 느슨해야 한다는 것인데, 그래야만 한 컴포넌트에서 오류가 발생해도 다른 컴포넌트까지 전파가 되는 경우가 적기 때문입니다.

 

그렇다면 이러한 시스템은 어디에서 주로 많이 사용될까요?

 

• 클라우드, 컨테이너
• IoT

클라우드와 컨테이너를 통해 경량화 된 시스템을 배포하는 데 용이한데, 이렇게 경량화하고 분산된 시스템을 하나의 서비스로 만들기 위하여 Reactive를 사용할 수 있습니다.

 

IoT의 경우, 서버가 여러 센서, 하드웨어 등을 연결한 상태로 모니터링 한다거나 제어를 한다고 하였을 떄 이에 즉각 반응하고 처리할 수 있어야 하는 요구 사항을 구현하기 위해 Reactive를 사용하는 예시가 될 수 있습니다.

 

 

 

Reactive System

Reactive를 모태로 한 개념에는 Reactive Programming과 Reactive System이 있습니다. 사실상 Reactive Programming은 Reactive System에 하위에 속하는 개념입니다.

 

우리는 클라우드 환경과 분산 시스템을 구축하기 위해 시스템 레벨에서 아키텍트와 DevOps를 위한 생산성을 제공합니다. 흔히 우리가 배포 자동화나 테스트 자동화를 위해 사용하는 CI/CD 내지 형상 관리 시스템이 이에 해당합니다. 그런데, 이러한 것들도 Reactive System으로 구축한다면 보다 유연하고, 느슨한 결합을 가지면서 확장성 있는 시스템을 만들 수 있습니다. 이러한 시스템을 채택한 대표적인 아키텍처에는 Micro Service Architecture가 있습니다.

 

 

예를 들어, 커머스 서비스가 있다면 커머스는 사용자가 물건을 주문하고, 결제하여 배송까지해주는 서비스인데, 만약 느슨한 결합없이 강력하게 결합되어 있는 서비스라면 서로의 컴포넌트가 각 컴포넌트에 의존하게 됩니다. 이로 인해서 하나의 컴포넌트가 문제가 발생하면 모든 컴포넌트가 중단이 되고, 결국 서비스는 사용 불능에까지 이르게 됩니다.

 

하지만 위 화면처럼 서로가 독립이 되어 있고, 이들을 통신하는데 직접적인 결합이 아닌 간접적인 결합을 제공함으로써 하나의 컴포넌트에서 오류가 발생한다하더라도 다른 컴포넌트에는 영향을 미치지 않기 때문에 서비스가 사용 불능까지는 가지 않는 것입니다.

 

 

 

Reactive Programming

그렇다면 애플리케이션 레벨에서는 무엇이 요구될까요? 시스템에서는 느슨한 결합, 메시지 주도의 개발 등이 필요했다면 애플리케이션에서는 기본적으로 태스크를 비동기로 실행할 수 있어야 합니다.

 

만약, 동기로 실행한다면 어떨까요? 마우스 이벤트를 대기하고 있는 태스크가 이벤트를 받고 그것을 처리하는 동안에는 아무런 일도 처리할 수 없습니다. 따라서 결과를 보여주는 데까지 모든 시간이 소모하므로 Reactive한 프로그램이 될 수 없습니다.

 

사용자가 입력 이벤트를 발생시켰을 때 입력을 진행하는 동안 결과를 바로 보여줄 수 있도록 스레드를 이용하여 비동기를 처리함으로써 Reactive하게 구현할 수 있습니다. 따라서 Reactive Programming에서는 기본적으로 비동기가 요구됩니다.

 

하지만 서버 프로그래밍을 하다보면 모든 작업을 비동기로 구현하는 데는 한계가 존재합니다. 만약 리액티브한 아키텍처로 넘어가기 위한 생산적인 방법이 필요하다면 Strangler Pattern을 이용해볼 수도 있습니다.

 

Strangler Fig pattern - Cloud Design Patterns

 

 

 

마치며..

사실 이 글을 적기 이전에 RxJava라는 글에 대해서 포스팅을 했었습니다. 그 글을 다시 읽어보면서 무언가 Reactive Programming에 대한 설명이 없이 순수 RxJava에 대한 이야기를 한 것 같아 Reactive가 어떤 것인지 좀 더 상세하게 이야기 하고, 알고 사용하는 것이 좋다고 생각하여 적게 되었습니다.

 

Reactive를 처음 접하시는 분들인데, MSA를 하고 계시는 분들이라면 MSA로 운영하기 위해 Reactive가 필수적으로 있어야 한다라는 것은 어느 정도 공감하셨을 것이라고 봅니다. 메시지 기반과 이벤트 기반에 대해 좀 더 알고 싶으신 분들이 계신다면 아래의 글을 참고해보는 것도 좋을 것 같습니다.

 

What is #Reactive? Read Reactive Programming vs Reactive Systems @jboner & @viktorklang | @lightbend

저는 RxJava를 이용하여 안드로이드 프로그래밍을 했을 떄 처음 Reactive를 사용하였습니다. 당시에는 Reactive가 클라이언트에서만 사용할 수 있는 개념이라고 생각했었는데, 이번에 Reactive 글을 적게 되면서 현재 현업에서 Python을 가지고 MSA 기반의 서비스로 전환한 아키텍처 또한 Reactive의 개념이 들어가 있었음을 다시 한 번 확인할 수 있었습니다.