본문 바로가기

Programming/Scala

Reactive Manifesto

Reactive Programming 이 붐이다. 

우리나라는 어떻게 진행되고 있는 지 몰라도 해외에서는 이 패러다임이 대세인 것이다. 

특히 미국에서.



오늘은 그래서 이 프로그래밍 패러다임이 도대체 어떤 것을 표방하는 지 알아보도록 하자.

일단 google 에서 "Reactive Manifesto" 라는 키워드로 검색을 해보면 아래 사이트가 메인으로 뜬다.


http://www.reactivemanifesto.org


해당 사이트에 가보면 "The Reactive Manifesto" 라는 글귀가 보이면서 소개가 나온다.

이 사이트에 소개된 글을 한국어로 번역해 보면 나도 도움이 될 거 같아서 번역을 해볼까 한다. 

(더 좋은 번역이 있거나 제안이 필요할 경우 댓글을 남겨주길 바란다.)


다양한 도메인에서 소트웨어 관련 일을 하다보면, 이러한 소프트웨어들에서 공통된 패턴을 발견할 수 있다.

이러한 소프트웨어로 만들어진 시스템은 보통 robust (견고한), resilient (탄력적인, 복구가 쉬운), 

flexible (유연한) 한 구조를 갖는다.


그리고 이러한 요구사항이 최근들어서 더욱더 필요하게 되었다. 몇년 전만 해도 큰 응용프로그램은 서버 수십대, 

수십초의 응답시간, 유지보수에 몇시간이 걸리고, 수십 GB 의 데이터를 가진 것이었다. 


하지만, 오늘날은 응용프로그램들이 모바일부터 multi-core 프로세서로 작동하는 클라우드기반의 클러스터까지 

배포가 되고 있다.

사용자들은 mili second 단위의 응답시간과 100% uptime 을 기대한다. 데이터는 peta 바이트 수준이다. 

오늘날의 요구사항은 단순히 어제의 소프트웨어 아키텍쳐와 맞지 않는다.


우리는 시스템 아키텍처에 대한 일관적인 접근방법이 필요하다고 믿고, 이러한 것들은 이미 인식하고 있다.

이러한 것들은 Responsive(응답성), Resilient(복구성), Elastic(융통성) 

그리고 Message Driven (메시지 기반) 이다. 이러한 아키텍처가 바로 Reactive System 이다.


Reactive System 기반의 시스템은 보다 유연하고, 응집도가 낮고 (loosely-coupled) 확장성이 있다.

이 점이 시스템을 보다 개발과 변경이 쉽도록 도와준다. 이 시스템은 보다 고장(failure)에 대해 안전하다.

Reactive System 은 높은 응답성과 사용자들에게 쌍방향의 피드백을 제공한다.


Reactive Systems 은:


Responsive: 시스템은 가능하면 주어진 시간안에 응답한다. 응답성은 사용성과 실용성에서 초석이고,

문제점들이 빠르게 발견되고 효율적으로 처리되는 것을 의미한다. 응답성이 있는 시스템은 빠르고 일관된 응답시간

에 초점을 맞추는데, 양질의 서비스를 제공하기 위해 최대 응답시간을 설정한다. 이 일관된 방식이 에러처리를 

간단하게 하고 최종 사용자에게 믿음을 주고, 향후의 상호작용을 고취시킨다.



Resilient: 시스템이 고장이 났음에도 불구하고 응답할 수 있는 상태를 유지한다. 이 시스템은 고가용성(high-availibility), mission critical 한 시스템에도 적용이 되는데,  이렇지 않은 시스템은 고장이 나고나서 응답을 할 수 없다. 

Resilience 는 Replication (복제), containment (억제), isolation (고립), delegation (위임) 을 하여 달성할 수 있다. 

각각의 구성요소 (component) 를 서로 억제하고, 고립시켜서 시스템의 일부가 고장이 나더라도 전체에 영향이 가지 않고 복구할 수 있도록 한다.  각각의 구성요소 복구는 다른(외부의) 구성요소에게 위임하고, 고 가용성이 (HA) 필요한 곳은 Replication 확보할 수 있다. 특정 구성요소를 사용하는 Client 는 이러한 복구로부터 영향을 받지 않는다.



Elastic: 시스템은 부하가 바뀌는 상황에서도 Responsive 를 유지한다. Reactive 시스템은 입력의 변화가 있을시,

이러한 입력에 해당하는 서비스에 할당된 자원들을 증가/감소 시켜 대응해야 한다. 이 디자인은 경쟁 포인트 혹은 집중된 병목이 없다는 것을 암시하고, 이러한 입력들을 분배하고 나누고, 복제하는 능력을 갖는다. Reactive 시스템은 예측가능하고 Reactive 관련있는 성능 지표를 제공하는 스케일링 알고리즘을 (scaling algorithm)지원한다. 이 시스템은 하드웨어와 소프트웨어 플랫폼을 에 대해서 가성비 좋은 방식 (cost-effective way)으로 탄력성(elasticity)을 달성한다.



Message Driven: Reactive 시스템은 컴포넌트들(component) 간에 경계를 나누기 위해서 비동기 방식의 메시지 전달을 (asynchronous message passing)사용하는데, 이 점이 낮은 밀집도, 고립(isolation), 위치 투명성(location transparency) 를 확보하게 해 준다. 이러한 경계가 시스템 고장을 (failure) 메시지라는 형태로 위임할 수 있는 방식을 제공하게 해 준다. 명시적인 메시지 전달방식을 채용하면 부하관리, 탄력성, 흐름제어(flow control) 을 가능하게 하는데,

시스템 안의 메시지 큐의 형성, 모니터링(monitoring), 필요하다면 back-pressure 를 통하여 할 수 있다.

통신수단으로서의 위치투명한 메시징은 (location transparent messaging) 하나의 호스트 혹은 

클러스터상의 여러 머신들에 대해서도 동일한 개념과 의미를 이용하여 고장(failure)에 대해서 대응할 수 있도록 한다.

Non-blocking 통신은 수신자가 자원이 이용가능할 경우에 사용할 수 있도록 하여 

시스템적으로 오버헤드를(overhead) 줄일 수 있도록 한다. 






큰 규모의 시스템들은 작은 부분들로 이루어져있기 때문에 구성요소들의 Reactive 특성에 의존한다. 이것이 의미하는 바는 Reactive 시스템은 디자인 패턴들을 적용하여 이러한 특성들이 모든 수준의 규모에 적용가능하고 서로 구성할수 (결합) 있도록 해준다. 세계에서 가장 큰 시스템도 이러한 특성에 기반을 둔 아키텍쳐를 사용하여 매일 수십억의 사람들에게 서비스를 제공하고 있다. 이제는 이것들을 매 순간마다 발견하는 대신 의식적으로 이러한 디자인 원리를 시작부터 적용해야 할 시간이 왔다.