• Save
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
Upcoming SlideShare
Loading in...5
×
 

NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기

on

  • 9,046 views

2014년 5월 28일 NDC14 발표자료입니다.

2014년 5월 28일 NDC14 발표자료입니다.

Statistics

Views

Total Views
9,046
Views on SlideShare
2,424
Embed Views
6,622

Actions

Likes
37
Downloads
2
Comments
0

13 Embeds 6,622

http://blog.naver.com 3695
http://news.imaso.co.kr 2506
https://twitter.com 209
http://cafe.naver.com 81
http://lacti.me 75
http://blog.lacti.me 22
http://192.168.10.39 16
http://www.slideee.com 11
https://www.irccloud.com 3
http://plus.url.google.com 1
http://www.google.co.kr 1
http://memolog.blog.naver.com 1
http://feedly.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 전문연구요원
  • 단어 클라우드가 한 물 가긴 했지만 제 슬라이드에 나오는 단어들로 한 번 그려 봤습니다. <br /> 좋아 보이는 단어들이죠? 단어들 중에 핵심은 가장 크게 그려진 Functional Reactive Programming 입니다.
  • 가장 첫 순서인 “다시 만난 세계”에서는 프로그래밍 언어를 처음 배우던 때로 돌아가서 <br /> 프로그래머들이 잊고 있었던 세계를 다시 만나 보려고 합니다. <br /> 우리가 만약 지금처럼 절차적으로 프로그래밍하는 것에 완전히 길들여져 있지 않았더라면, <br /> 처음 그 갈림길에서 다른 길을 갔더라면 어땠을 지 생각해 보겠습니다.
  • 대충 이렇게 표현하고, 프로세서는 프로그램을 한줄씩 따라가며 함수를 호출하고 결과 값을 얻어낼 것입니다. <br /> 컨트롤이 한줄씩 명령을 실행하기 때문에 이런 방식을 명령형Imperative 또는 절차적Procedural 이라고 합니다.
  • 그런데 이렇게 표현하면 어떨까요? <br /> 그 합성함수를 조금 다른 방식으로 그려 본 것입니다. <br /> F 와 g 는 각자 아주 간단한 계산을 하는 블록입니다. <br /> 데이터는 계속 흐르고, f와 g는 독립적으로 각자 주어진 일을 수행합니다. <br /> <br /> 그런 의미에서 이 그림은 선언적Declarative입니다.
  • 작은 단위의 두 블록을 합쳐서 하나의 큰 블록이 있다고 볼 수도 있겠죠.
  • 생각해 보면 우리가 생각할 수 있는 거의 모든 것을 이 그림으로 표현할 수 있습니다. <br /> 데이터가 흐르는 작은 단위로 소프트웨어를 구성하고 그것을 조합해서 큰 소프트웨어 전체에 데이터가 흐를 수 있게 하면 좋을 것 같다는 생각이 듭니다.
  • 이런 생각은 프로그래밍의 초창기부터 있어 왔습니다. <br /> 1973년이라고 적혀 있지만 사실 2013년에 만들어진 이 발표자료는 1973년 기준으로 ’40년 후의 프로그래밍'에 대해서 얘기하는데,
  • 이미 40년 전부터 이러한 아이디어들은 알려져 있었습니다. <br /> 계산을 하는 여러 개의 독립적인 단위와 그들 사이의 연결을 통해서 연산이 이루어지는 방식이 주류가 될 거라고 예상을 했습니다.
  • 아무리 봐도 데이터의 흐름이 컨트롤의 흐름보다 좋아 보이지만, 70년대와 80년대를 지나면서 데이터 플로우는 대세를 잃게 됩니다.
  • 가장 직접적인 원인이라면 컴퓨터의 시초가 된 튜링머신과 그로부터 탄생한 모든 컴퓨터들이 모두 이 방식이었다는 데에 있겠지만, <br /> 무엇보다 가장 큰 원인은 어느 한 회사였습니다. 그 회사의 상표가..
  • 이렇게 생겼는데, 이 회사에서 프로세서를 너무 잘 만들었고, <br /> 그 프로세서에서 매우 효율적으로 돌아가는, 컨트롤 플로우에 기반한 프로그래밍 언어와 소프트웨어가 주류가 되기 시작했습니다. <br /> <br /> 컴퓨터 한 대로는 어쩔 수 없으니 고성능을 위해선 여러 대로 분산해서 써야 하게 되었습니다. <br /> 이제 컨트롤 플로우 방식을 선택해야 했던 요인들이 없어졌으니, 다시 데이터플로우에 눈길을 돌릴 때가 된 것입니다.
  • 리액티브 프로그래밍은 데이터 플로우 방식의 프로그램을 구현할 수 있는 하나의 패러다임입니다. <br />
  • 그런데 같은 동작을 엑셀에서 했다면 어떨까요? <br /> 3, 4를 입력하고 C를 저렇게 정했다면 <br /> A, B의 값을 바꾸면 C의 값도 자동으로 변하겠죠. <br /> 이것이 바로 Reactive Programming 의 가장 특징적인 개념입니다.
  • 엑셀에서처럼, Reactive 하게 C = A + B 라고 했다는 말은 사실 다음과 같은 데이터 흐름을 정의한 것과 같습니다. <br /> 보셨듯이, 절차적procedural, 명령형imperative이지 않고 선언적declarative이며, 컨트롤의 흐름에 관계 없이 데이터의 흐름에 기반해 있습니다. <br /> 프로그램이 이렇게 선언적으로 짜여 있다면 C = A + B 라고 하고 A, B의 값이 바뀌면 자동으로 C의 값도 변화하는 셈이죠. <br /> <br /> <br />
  • 즉, 리액티브한 시스템을 위해서는 독립적인 여러 개의 계산 단위와 데이터들이 그들 사이로 흐르는 방식이 필요하고, <br /> 그렇게 되어야 분산 시스템을 제대로 만들 수 있습니다. <br /> <br /> 찾아보면 이런 방식이 우리 주변에 정말 많이 있습니다.
  • 가장 유사한 것으로는 논리회로가 있습니다. 그림은 ‘전가산기’라고 부르는 덧셈을 하는 회로이죠. <br /> 이런 회로가 아주 복잡해지면 CPU가 되고 메모리가 되기도 하구요, <br /> 이런 하드웨어를 만들기 위해서 사용되는 Verilog 같은 언어들은 데이터플로우 패러다임으로 분류됩니다.
  • 밴드에서 연주하는 음악도 각각의 악기가 보내는 전기적인 신호가 각종 이펙터와 믹서를 거쳐서 출력 결과를 내놓는 것이었구요.
  • 좀더 크게 보면 우리가 회사와 세상에서 하는 모든 일들은 각자 살아가는 사람들이 서로 메시지를 주고 받으면서 <br /> 제가 지금 하고 있는 일도 여러분들께 메시지를 전달하고 있는 것이죠. <br /> <br /> 이러한 새로운 패러다임을 컴퓨터로 구현하기 위해서는 어떻게 해야 할까요? 다른 패러다임들이 무엇이 있는지부터 찾아봅시다.
  • 위키피디아에서 “프로그래밍 패러다임"이라고 검색하면 여러 프로그래밍 패러다임이 총망라되어 있는데, 그걸 한 번 그려 봤습니다. <br /> <br /> 너무 이론적이거나 겹치거나 중요하지 않은 것들도 있지만 일단 이렇구요, <br /> 이 중 어떤 패러다임이 지금까지 사용되어 왔는지를 시간에 따라 살펴보겠습니다.
  • 가장 먼저 나와야 할 패러다임은 튜링 머신으로 표현했던 단일 하드웨어에 가장 가까운 패러다임은 명령형Imperative 입니다. <br /> 기계어는 순서대로 규칙에 따라 명령어의 나열일 뿐이기 때문이죠. 아시다시피 이것을 직접 작성하는 것은 너무도 비생산적인 일이라 프로그래밍 언어가 생기기 시작합니다.
  • C 언어는 프로시져를 통해 함수 단위로 코드를 재사용하고, 중괄호 블록들로 컨트롤의 흐름이 더 명시적이 될 수 있었죠. <br /> 하지만 C는 플랫폼 독립적인 어셈블리란 말이 있듯이 대규모의 코드를 유지하는 데에 한계가 있었고, 프로그래밍 역사 수업에서 언급되는 “소프트웨어 위기 “가 찾아옵니다.
  • 그래서 나오는 C++, Java, C# 와 같은 객체지향 프로그래밍 언어들은 좀 더 많은 패러다임을 지원하게 되었습니다. <br /> 이 방식으로 다양한 객체지향 디자인 패턴과 아키텍처들이 발생했죠. <br /> 그리고 이 정도가, 현재까지의 소프트웨어 시장을 이룬 주류라고 할 수 있을 것 같습니다. <br />
  • 여기에 리액티브 프로그래밍을 위한 개념을 추가한 것이 바로 오른쪽입니다.
  • 그래서 명령형 순차적 방식의 코딩은 최대한 피하면서 데이터의 흐름을 기반으로 소프트웨어를 만드는 것이 리액티브한 패러다임이라고 할 수 있겠습니다. <br /> 이런 패러다임에 알맞은 코드는 어떤 형식이어야 할까요?
  • 즉 명령을 나열하는 대신 데이터가 흐르는 방식을 선언하는 방식으로, <br /> 명령들을 순차적으로 실행하는 것이 아닌 작은 단위들이 동시에 실행되는 방식으로 전환이 필요할 때라는 것이 이 발표의 주제입니다.
  • 어떻게 그렇게 할 수 있을까요? 리액티브 매니페스토 라고 하는, 일종의 선언문을 소개하고자 합니다.
  • 이 네 가지의 근본이 되는 Event-Driven 에 대해 알아보려고 합니다. <br /> Event-Driven 을 이해하기 위해선 시간에 대한 이해가 필요합니다. <br />
  • 우리가 아는 함수는 입력을 주면 출력을 리턴합니다. 그런데 문제가 있어요. <br /> 이 함수는 동기적으로 호출되기 때문에, 입력이 들어가고 출력이 나올 때까지 이 함수를 실행한 스레드는 당연하게도 다른 일을 못한다는 것입니다. <br /> 우리가 객체지향 프로그래밍 패턴이라고 배웠던 것들 중에 대부분이 이것을 당연하게 생각하고 있는데,
  • 그것의 결정체라고 할 수 있는 엔터프라이즈 자바 어플리케이션의 콜스택을 한번 봅시다. <br /> 진짜 하려고 했던 일은 노란색 네모가 가리키는 것 뿐인데, 나머지가 저렇게 많은 화면을 차지하고 있습니다. <br /> 더 문제는 스레드는 수백개 이상으로 만들기 부적절한 비싼 자원인데, 이걸 각각의 사용자가 한 스레드씩 잡아먹고 있다는 점이죠. <br /> <br /> 수만명 규모 이상의 부하를 처리하기 위해서는 그래서 비동기 방식이 필수적입니다.
  • <br /> 만약 블로킹 호출이 아닌 이벤트기반 프로그래밍이라면 아래와 같은 형태가 가능합니다. <br /> 그림은 이 정도이지만 실제로는 1000배 이상의 차이가 날 것입니다.
  • 완전히 이벤트드리븐 방식이 되면 이렇게 싱글스레드만으로도 엄청난 성능을 낼 수 있게 됩니다. <br /> 쿼드코어 컴퓨터라면 스레드 4개를 사용해서 성능을 더욱 높일 수 있겠죠. <br /> <br /> 그런데 이 중 하나라도 블로킹하는 아이가 있으면 어떻게 될까요? 스케일이 다른 네모가 등장하면서 다른 네모들이 끼어들 자리가 없게 되겠죠.
  • Event Driven 방식을 위해 가장 먼저 필요한 것은 운영체제 차원에서의 지원입니다. 여기에선 윈도우 진영이 제일 빨랐습니다. <br /> 초기 온라인 게임서버들이 윈도우 위주이고 여기 계신 서버개발자분들 중 다수가 IOCP의 전문가이신 것도 이것과 관련이 있죠. <br /> … <br /> 그런데 이 NodeJS와 VertX는 치명적인 뻘짓을 하고 맙니다.
  • 비동기 방식을 위해 콜백을 인자로 넣어 버린 것이죠.
  • NodeJS의 콜백 함수들은 대개 이런 식으로 생겼습니다. 비동기 호출을 하고,
  • 콜백 방식으로 비동기 작업을 3번 정도만 하려고 해도, 이런 식으로 함수 안에 함수 안에 함수 넣기를 반복하게 됩니다. <br /> 몇 단계씩이나 들어가는데다 에러처리와 로직이 뒤엉키면서 관리할 수 없는 구조가 되어버립니다. <br /> NodeJS API들이 다 이런 식으로 되어 있어서 프로그램을 짜다 보면 어느새 이렇게 콜백 지옥에 빠져 있고, <br /> 코드를 잘 정리한다거나 컴파일러 변환을 한다거나 하는 식의 몇 가지 해결방법이 고안되어 있긴 합니다만 근본적인 해결책은 아니죠.
  • 우리는 이렇게 되어 있었던 함수에 콜백을 추가할 것이 아니라,
  • 대신 M 이란 아이를 사용할 수 있습니다.
  • 이 M에서 바로 함수형 리액티브 프로그램이 시작됩니다. <br />
  • 함수형 프로그래밍은 함수를 일급 시민인 프로그래밍 방식이라고 정의를 하죠. <br /> 단순히 함수를 변수로 저장하고 인자로 넘기거나 리턴값으로 쓸 수 있다는 말인데,
  • 간단하게 설명하고 넘어가겠습니다.
  • 이렇듯 이 포장지를 이용해서 문맥을 유지한 채 함수를 차례차례 적용하는 것이 가능합니다.
  • 시간관계상 이 네 가지의 근본이 되는 Event-Driven 에 대해 알아보려고 합니다.
  • 자바스크립트 생태계에선 , 우선 아까 말했듯이 NodeJS는 망하긴 했지만, 클라이언트사이드에서 쏟아져나오고 있는 많은 MVVM 프레임웍들이 리액티브 프로그래밍의 개념을 구현하고 있습니다. <br /> Q Promise라는 퓨처 모나드와, Javascript Promise라는 표준이 발표되어 있으며, Rx의 자바스크립트 포팅도 물론 있습니다.
  • 이에 반해 구글에서 새로 만들고 있는 Dart는 언어 차원에서 Future와 비동기 스트림을 지원합니다. <br /> 정말 현명한 선택이 아닐 수 없죠.
  • FRP 방식으로 웹상에서 위젯과 3D 그래픽까지 표현할 수 있는 ELM이란 언어도 있습니다. <br /> 홈페이지에 가시면 정말 순식간에 슈퍼마리오 게임을 만드는 영상을 볼 수 있는데 신기하더군요.

NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기 NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기 Presentation Transcript

  • 2
  • 3
  • © Google 4 비트코인 마이너와 구글 데이터센터의 공통점은?
  • 5
  • • • f : X → Y int main() { return 42; } a b c 1 2 3 X Y f 6
  • a b c 1 2 3 X Y f : X → Y ㄱ ㄴ ㄷ Z g : Y → Z f g 7
  • a b c X ㄱ ㄴ ㄷ Z g ∘ f : X → Z g ∘ f 8 합성함수
  • … int y = f(x); int z = g(y); … 9 컨트롤이 움직이면서 한 줄씩, 순차적으로 실행함 → 명령형, 절차적
  • f g 10 컨트롤이 아닌 데이터가 흐른다면?
  • g ∘ f 11 두 블록을 묶어서 그리면 합성함수가 됨
  • 12 여러 개의 작은 블록 사이로 데이터가 흐르도록 구성해서
  • ANYTHING 13 큰 소프트웨어 전체에 데이터가 흐르게 만들자!
  • © Google 14 공통점: 데이터의 흐름
  • 15 40년 된 아이디어
  • 16
  • 17 7~80년대가 지나면서 컨트롤 흐름 방식이 대세가 됨 데이터가 흐를 것인가 컨트롤이 흐를 것인가의 싸움
  • 18 컨트롤이 흐르는 튜링머신
  • 19 그 방식으로 승승장구한 회사 하지만 그래프가 꺾이기 시작
  • 20
  • 22
  • A = 3 B = 4 C = A + B A = 4 B = 5 print C 23 당연히 7이 출력될까?
  • 24 엑셀은 대표적인 Reactive Programming
  • C = A + B + A C B 25 순서대로 실행될 명령들이 아닌, 데이터가 흐르는 방법을 나타내는 것
  • 26 사실은 우리에게 너무나 익숙한 방식
  • 27 게이트 사이로 전기 신호가 흐름
  • © Behringer 28 믹서를 통해 오디오 신호가 흐름
  • © Manu Cornet 29 사람 사이의 모든 의사소통
  • Declarative Logic Abductive Answer Set Constraint Functional Inductive Functional Functional Logic Dataflow Reactive Cell-Oriented Structured Object-Oriented Prototype-BasedClass-Based ModularBlock-Structured Point-Free Style Procedural Event-Driven Service-Oriented Time-Driven Concurrent Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array Metaprogramming Template Reflective Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level Imperative Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional Programming Paradigms @ Wikipedia
  • Declarative Logic Abductive Answer Set Constraint Functional Inductive Functional Functional Logic Dataflow Reactive Cell-Oriented Structured Object-Oriented Prototype-BasedClass-Based ModularBlock-Structured Point-Free Style Procedural Event-Driven Service-Oriented Time-Driven Concurrent Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array Metaprogramming Template Reflective Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level Imperative Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional 31 … mov ah, 09h lea dx, msg int 21h …
  • Declarative Logic Abductive Answer Set Constraint Functional Inductive Functional Functional Logic Dataflow Reactive Cell-Oriented Structured Object-Oriented Prototype-BasedClass-Based ModularBlock-Structured Point-Free Style Procedural Event-Driven Service-Oriented Time-Driven Concurrent Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array Metaprogramming Template Reflective Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level Imperative Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional 32 typedef struct { int x, y } POINT; void foo(POINT *p) { if (p->x > 0) { p->y *= -1; } }
  • Declarative Logic Abductive Answer Set Constraint Functional Inductive Functional Functional Logic Dataflow Reactive Cell-Oriented Structured Object-Oriented Prototype-BasedClass-Based ModularBlock-Structured Point-Free Style Procedural Event-Driven Service-Oriented Time-Driven Concurrent Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array Metaprogramming Template Reflective Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level Imperative Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional 33 template<typename T> class Foo { T t; public: Foo(T t) : t(t) {} void foo() { cout << t; } };
  • Declarative Logic Abductive Answer Set Constraint Functional Inductive Functional Functional Logic Dataflow Reactive Cell-Oriented Structured Object-Oriented Prototype-BasedClass-Based ModularBlock-Structured Point-Free Style Procedural Event-Driven Service-Oriented Time-Driven Concurrent Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array Metaprogramming Template Reflective Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level Imperative Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional 34
  • 선언적 Logic Abductive Answer Set Constraint Functional Inductive 함수형 Functional Logic 데이터플로우 리액티브 Cell-Oriented 구조적 객체지향 Prototype-Based클래스 기반 모듈성블록 기반 Point-Free Style 순차적 Event-Driven Service-Oriented Time-Driven 동시적 Relativistic Action Agent-Oriented Aspect-Oriented Automata-Based End-User Expression-Oriented Feature-Oriented Non-Structured Array 메타프로그래밍 템플릿 리플렉션 Homoiconic Automatic Flow-Based Concatenative Function-LevelValue-Level 명령형 Semantic Concept ProbabilisticLanguage-Oriented Natural Language Discipline-Specific Domain-Specific Grammar-Oriented Intentional 35
  • 명령형 imperative 선언적 declarative 순차적 procedural 동시적 concurrent 36 생각하는 방식을 바꿔야 할 때
  • 37
  • Event-Driven 이벤트에 반응하기 Scalable 부하에 반응하기 Resilient 실패에 반응하기 Responsive 사용자에 반응하기 38
  • 1• • • 39
  • 10-3• • • 40
  • 10-6• • • 컨텍스트 스위치 41
  • 10-9• • • 42
  • • • • • • • • • 43 너무 느림!!
  • OUTPUT foo(INPUT a); 44 너무나 당연하게 입력이 들어가고 출력이 나올 때까지 스레드가 아무것도 하지 못한다고 가정하고 있음 객체지향 프로그래밍 패턴을 구성하는 인터페이스
  • • • • • • • • • 45 너무 느림!!
  • © Peter Thomas 46 사용자당 스레드 하나 점유 + 최하단의 JDBC가 블로킹
  • 47 스레드는 한정된 자원이라, 더 많은 사용자를 수용할 여유가 없다!
  • 48 스레드에게 자유를 돌려주는 리액티브 프로그래밍
  • 49 적은 스레드로도 더 많은 사용자를 수용가능
  • • • • • • • • 51
  • function foo(a, callback); 52 node.js와 vert.x의 치명적인 뻘짓
  • foo(a, function(err, result) { if (err) { // handle error } else { // use result } ); 53
  • // 흔한 콜백 지옥 function compositeTask(t0, callback) { task1(t0, function(err, t1) { if (err) { callback(err); } task2(t1, function(err, t2) { if (err) { callback(err); } task3(t2, function(err, t3) { if (err) { callback(err); } callback(null, t3); }); }); }); } 54
  • OUTPUT foo(INPUT a); 55 콜백 대신 어떻게?
  • M<OUTPUT> foo(INPUT a); 56
  • INPUT => M<OUTPUT> INPUT => OUTPUT 57
  • Checkpoint! 58
  • 59
  • 60
  • © Aditya Bhargava 61 어떤 값
  • © Aditya Bhargava 62 그 값을 감싸서 어떤 효과를 주는 것
  • © Aditya Bhargava Maybe, Option, Optional, Nullable 63 값이 없을 수도 있는 모나드 타입
  • © Aditya Bhargava 64 그냥 값에는 +3을 적용할 수 있었는데-
  • © Aditya Bhargava 65 모나드에는 바로 적용할 수 없다!
  • © Aditya Bhargava 66 그래서 map
  • © Aditya Bhargava 67 값이 없으면 아무 것도 하지 않음
  • © Aditya Bhargava 68 문맥을 유지한 채 함수를 적용할 수 있다!
  • f g 69 블록과 화살표로 나타내면…
  • +3 +4 © Aditya Bhargava 70
  • © Aditya Bhargava 71 여러 종류의 모나드 타입들
  • 72 움짤로 보는 모나드
  • 73
  • 74
  • 75
  • 76 unit, return, just mapMany, bind, thenCompose, >>=
  • a = unit(2) b = a.flatMap(x -> unit(x+3)) c = b.flatMap(y -> unit(y+4)) // c == unit(9) +3 +4 77
  • 하나 다수 동기 Try<T> Iterable<T> 비동기 Future<T> 78 ???
  • 79
  • 하나 다수 동기 Try<T> Iterable<T> 비동기 Future<T> Observable<T> 80
  • 81 비동기 데이터 스트림 쿼리 연산 병렬처리 제어 Rx Reactive Extensions (.NET, 2009) RxJava (2012) rxjava-scala rxjava-groovy rxjava-clojure rxjava-jruby rxjava-kotlin RxJS RxCPP RxPy (2011) (2012) (2013)
  • 82
  • Iterable (pull) Observable (push) 데이터 받기 T next() onNext(T) 에러 발생 throws Exception onError(Exception) 완료 returns onCompleted() 83
  • Iterable (pull) Observable (push) getDataFromLocalMemory() .skip(10) .take(5) .map(s -> s + "foo") .forEach(println) getDataFromNetwork() .skip(10) .take(5) .map(s -> s + "foo") .forEach(println) 84
  • +3 +4 Observable<int> add(Observable<int> input) { return input.map(x -> x+3) .map(y -> y+4); } 85
  • query1 query2 Observable<int> query1(int input); Observable<int> query2(int input); Observable<int> query(Observable<int> input) { return input.flatMap(query1) .flatMap(query2); } 86
  • x + y Observable<int> zip(Observable<int> xs, Observable<int> ys) { return zip(xs, ys, (x, y) -> x + y); } yx 87
  • • • • • • • • • • • 88
  • TCP Dispatcher Handler Handler Handler … Data Grid DB Driver … 89
  • TCP Dispatcher Handler Handler Handler … Data Grid DB Driver … 90 Node
  • Node 1 Node 2 Node 4Node 3 91
  • Node 1 Node 2 Node 4Node 3 92 Service
  • Service A Service B Service D Service C Service E 93
  • Service A Service B Service D Service C Service E 94
  • Service A Service B Service D Service C Service E 95
  • Event-Driven 이벤트에 반응하기 Scalable 부하에 반응하기 Resilient 실패에 반응하기 Responsive 사용자에 반응하기 96
  • 97
  • http://www.reactive-streams.org/ 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 105