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-...
Declarative
Logic
Abductive
Answer Set
Constraint
Functional
Inductive
Functional
Functional Logic
Dataflow
Reactive
Cell-...
Declarative
Logic
Abductive
Answer Set
Constraint
Functional
Inductive
Functional
Functional Logic
Dataflow
Reactive
Cell-...
Declarative
Logic
Abductive
Answer Set
Constraint
Functional
Inductive
Functional
Functional Logic
Dataflow
Reactive
Cell-...
Declarative
Logic
Abductive
Answer Set
Constraint
Functional
Inductive
Functional
Functional Logic
Dataflow
Reactive
Cell-...
선언적
Logic
Abductive
Answer Set
Constraint
Functional
Inductive
함수형
Functional Logic
데이터플로우
리액티브
Cell-Oriented
구조적
객체지향
Pro...
명령형
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, fun...
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, >>=
하나 다수
동기 Try<T> Iterable<T>
비동기 Future<T>
78
???
하나 다수
동기 Try<T> Iterable<T>
비동기 Future<T> Observable<T>
80
82
Iterable (pull) Observable (push)
데이터 받기 T next() onNext(T)
에러 발생 throws Exception onError(Exception)
완료 returns onComplet...
Iterable (pull) Observable (push)
getDataFromLocalMemory()
.skip(10)
.take(5)
.map(s -> s + "foo")
.forEach(println)
getDa...
+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> ...
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
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기
Upcoming SlideShare
Loading in...5
×

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

17,435

Published on

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

Published in: Software, Technology
0 Comments
165 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
17,435
On Slideshare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
2
Comments
0
Likes
165
Embeds 0
No embeds

No notes for slide
  • 전문연구요원
  • 단어 클라우드가 한 물 가긴 했지만 제 슬라이드에 나오는 단어들로 한 번 그려 봤습니다.
    좋아 보이는 단어들이죠? 단어들 중에 핵심은 가장 크게 그려진 Functional Reactive Programming 입니다.
  • 가장 첫 순서인 “다시 만난 세계”에서는 프로그래밍 언어를 처음 배우던 때로 돌아가서
    프로그래머들이 잊고 있었던 세계를 다시 만나 보려고 합니다.
    우리가 만약 지금처럼 절차적으로 프로그래밍하는 것에 완전히 길들여져 있지 않았더라면,
    처음 그 갈림길에서 다른 길을 갔더라면 어땠을 지 생각해 보겠습니다.
  • 대충 이렇게 표현하고, 프로세서는 프로그램을 한줄씩 따라가며 함수를 호출하고 결과 값을 얻어낼 것입니다.
    컨트롤이 한줄씩 명령을 실행하기 때문에 이런 방식을 명령형Imperative 또는 절차적Procedural 이라고 합니다.
  • 그런데 이렇게 표현하면 어떨까요?
    그 합성함수를 조금 다른 방식으로 그려 본 것입니다.
    F 와 g 는 각자 아주 간단한 계산을 하는 블록입니다.
    데이터는 계속 흐르고, f와 g는 독립적으로 각자 주어진 일을 수행합니다.

    그런 의미에서 이 그림은 선언적Declarative입니다.
  • 작은 단위의 두 블록을 합쳐서 하나의 큰 블록이 있다고 볼 수도 있겠죠.
  • 생각해 보면 우리가 생각할 수 있는 거의 모든 것을 이 그림으로 표현할 수 있습니다.
    데이터가 흐르는 작은 단위로 소프트웨어를 구성하고 그것을 조합해서 큰 소프트웨어 전체에 데이터가 흐를 수 있게 하면 좋을 것 같다는 생각이 듭니다.
  • 이런 생각은 프로그래밍의 초창기부터 있어 왔습니다.
    1973년이라고 적혀 있지만 사실 2013년에 만들어진 이 발표자료는 1973년 기준으로 ’40년 후의 프로그래밍'에 대해서 얘기하는데,
  • 이미 40년 전부터 이러한 아이디어들은 알려져 있었습니다.
    계산을 하는 여러 개의 독립적인 단위와 그들 사이의 연결을 통해서 연산이 이루어지는 방식이 주류가 될 거라고 예상을 했습니다.
  • 아무리 봐도 데이터의 흐름이 컨트롤의 흐름보다 좋아 보이지만, 70년대와 80년대를 지나면서 데이터 플로우는 대세를 잃게 됩니다.
  • 가장 직접적인 원인이라면 컴퓨터의 시초가 된 튜링머신과 그로부터 탄생한 모든 컴퓨터들이 모두 이 방식이었다는 데에 있겠지만,
    무엇보다 가장 큰 원인은 어느 한 회사였습니다. 그 회사의 상표가..
  • 이렇게 생겼는데, 이 회사에서 프로세서를 너무 잘 만들었고,
    그 프로세서에서 매우 효율적으로 돌아가는, 컨트롤 플로우에 기반한 프로그래밍 언어와 소프트웨어가 주류가 되기 시작했습니다.

    컴퓨터 한 대로는 어쩔 수 없으니 고성능을 위해선 여러 대로 분산해서 써야 하게 되었습니다.
    이제 컨트롤 플로우 방식을 선택해야 했던 요인들이 없어졌으니, 다시 데이터플로우에 눈길을 돌릴 때가 된 것입니다.
  • 리액티브 프로그래밍은 데이터 플로우 방식의 프로그램을 구현할 수 있는 하나의 패러다임입니다.
  • 그런데 같은 동작을 엑셀에서 했다면 어떨까요?
    3, 4를 입력하고 C를 저렇게 정했다면
    A, B의 값을 바꾸면 C의 값도 자동으로 변하겠죠.
    이것이 바로 Reactive Programming 의 가장 특징적인 개념입니다.
  • 엑셀에서처럼, Reactive 하게 C = A + B 라고 했다는 말은 사실 다음과 같은 데이터 흐름을 정의한 것과 같습니다.
    보셨듯이, 절차적procedural, 명령형imperative이지 않고 선언적declarative이며, 컨트롤의 흐름에 관계 없이 데이터의 흐름에 기반해 있습니다.
    프로그램이 이렇게 선언적으로 짜여 있다면 C = A + B 라고 하고 A, B의 값이 바뀌면 자동으로 C의 값도 변화하는 셈이죠.


  • 즉, 리액티브한 시스템을 위해서는 독립적인 여러 개의 계산 단위와 데이터들이 그들 사이로 흐르는 방식이 필요하고,
    그렇게 되어야 분산 시스템을 제대로 만들 수 있습니다.

    찾아보면 이런 방식이 우리 주변에 정말 많이 있습니다.
  • 가장 유사한 것으로는 논리회로가 있습니다. 그림은 ‘전가산기’라고 부르는 덧셈을 하는 회로이죠.
    이런 회로가 아주 복잡해지면 CPU가 되고 메모리가 되기도 하구요,
    이런 하드웨어를 만들기 위해서 사용되는 Verilog 같은 언어들은 데이터플로우 패러다임으로 분류됩니다.
  • 밴드에서 연주하는 음악도 각각의 악기가 보내는 전기적인 신호가 각종 이펙터와 믹서를 거쳐서 출력 결과를 내놓는 것이었구요.
  • 좀더 크게 보면 우리가 회사와 세상에서 하는 모든 일들은 각자 살아가는 사람들이 서로 메시지를 주고 받으면서
    제가 지금 하고 있는 일도 여러분들께 메시지를 전달하고 있는 것이죠.

    이러한 새로운 패러다임을 컴퓨터로 구현하기 위해서는 어떻게 해야 할까요? 다른 패러다임들이 무엇이 있는지부터 찾아봅시다.
  • 위키피디아에서 “프로그래밍 패러다임"이라고 검색하면 여러 프로그래밍 패러다임이 총망라되어 있는데, 그걸 한 번 그려 봤습니다.

    너무 이론적이거나 겹치거나 중요하지 않은 것들도 있지만 일단 이렇구요,
    이 중 어떤 패러다임이 지금까지 사용되어 왔는지를 시간에 따라 살펴보겠습니다.
  • 가장 먼저 나와야 할 패러다임은 튜링 머신으로 표현했던 단일 하드웨어에 가장 가까운 패러다임은 명령형Imperative 입니다.
    기계어는 순서대로 규칙에 따라 명령어의 나열일 뿐이기 때문이죠. 아시다시피 이것을 직접 작성하는 것은 너무도 비생산적인 일이라 프로그래밍 언어가 생기기 시작합니다.
  • C 언어는 프로시져를 통해 함수 단위로 코드를 재사용하고, 중괄호 블록들로 컨트롤의 흐름이 더 명시적이 될 수 있었죠.
    하지만 C는 플랫폼 독립적인 어셈블리란 말이 있듯이 대규모의 코드를 유지하는 데에 한계가 있었고, 프로그래밍 역사 수업에서 언급되는 “소프트웨어 위기 “가 찾아옵니다.
  • 그래서 나오는 C++, Java, C# 와 같은 객체지향 프로그래밍 언어들은 좀 더 많은 패러다임을 지원하게 되었습니다.
    이 방식으로 다양한 객체지향 디자인 패턴과 아키텍처들이 발생했죠.
    그리고 이 정도가, 현재까지의 소프트웨어 시장을 이룬 주류라고 할 수 있을 것 같습니다.
  • 여기에 리액티브 프로그래밍을 위한 개념을 추가한 것이 바로 오른쪽입니다.
  • 그래서 명령형 순차적 방식의 코딩은 최대한 피하면서 데이터의 흐름을 기반으로 소프트웨어를 만드는 것이 리액티브한 패러다임이라고 할 수 있겠습니다.
    이런 패러다임에 알맞은 코드는 어떤 형식이어야 할까요?
  • 즉 명령을 나열하는 대신 데이터가 흐르는 방식을 선언하는 방식으로,
    명령들을 순차적으로 실행하는 것이 아닌 작은 단위들이 동시에 실행되는 방식으로 전환이 필요할 때라는 것이 이 발표의 주제입니다.
  • 어떻게 그렇게 할 수 있을까요? 리액티브 매니페스토 라고 하는, 일종의 선언문을 소개하고자 합니다.
  • 이 네 가지의 근본이 되는 Event-Driven 에 대해 알아보려고 합니다.
    Event-Driven 을 이해하기 위해선 시간에 대한 이해가 필요합니다.
  • 우리가 아는 함수는 입력을 주면 출력을 리턴합니다. 그런데 문제가 있어요.
    이 함수는 동기적으로 호출되기 때문에, 입력이 들어가고 출력이 나올 때까지 이 함수를 실행한 스레드는 당연하게도 다른 일을 못한다는 것입니다.
    우리가 객체지향 프로그래밍 패턴이라고 배웠던 것들 중에 대부분이 이것을 당연하게 생각하고 있는데,
  • 그것의 결정체라고 할 수 있는 엔터프라이즈 자바 어플리케이션의 콜스택을 한번 봅시다.
    진짜 하려고 했던 일은 노란색 네모가 가리키는 것 뿐인데, 나머지가 저렇게 많은 화면을 차지하고 있습니다.
    더 문제는 스레드는 수백개 이상으로 만들기 부적절한 비싼 자원인데, 이걸 각각의 사용자가 한 스레드씩 잡아먹고 있다는 점이죠.

    수만명 규모 이상의 부하를 처리하기 위해서는 그래서 비동기 방식이 필수적입니다.

  • 만약 블로킹 호출이 아닌 이벤트기반 프로그래밍이라면 아래와 같은 형태가 가능합니다.
    그림은 이 정도이지만 실제로는 1000배 이상의 차이가 날 것입니다.
  • 완전히 이벤트드리븐 방식이 되면 이렇게 싱글스레드만으로도 엄청난 성능을 낼 수 있게 됩니다.
    쿼드코어 컴퓨터라면 스레드 4개를 사용해서 성능을 더욱 높일 수 있겠죠.

    그런데 이 중 하나라도 블로킹하는 아이가 있으면 어떻게 될까요? 스케일이 다른 네모가 등장하면서 다른 네모들이 끼어들 자리가 없게 되겠죠.
  • Event Driven 방식을 위해 가장 먼저 필요한 것은 운영체제 차원에서의 지원입니다. 여기에선 윈도우 진영이 제일 빨랐습니다.
    초기 온라인 게임서버들이 윈도우 위주이고 여기 계신 서버개발자분들 중 다수가 IOCP의 전문가이신 것도 이것과 관련이 있죠.

    그런데 이 NodeJS와 VertX는 치명적인 뻘짓을 하고 맙니다.
  • 비동기 방식을 위해 콜백을 인자로 넣어 버린 것이죠.
  • NodeJS의 콜백 함수들은 대개 이런 식으로 생겼습니다. 비동기 호출을 하고,
  • 콜백 방식으로 비동기 작업을 3번 정도만 하려고 해도, 이런 식으로 함수 안에 함수 안에 함수 넣기를 반복하게 됩니다.
    몇 단계씩이나 들어가는데다 에러처리와 로직이 뒤엉키면서 관리할 수 없는 구조가 되어버립니다.
    NodeJS API들이 다 이런 식으로 되어 있어서 프로그램을 짜다 보면 어느새 이렇게 콜백 지옥에 빠져 있고,
    코드를 잘 정리한다거나 컴파일러 변환을 한다거나 하는 식의 몇 가지 해결방법이 고안되어 있긴 합니다만 근본적인 해결책은 아니죠.
  • 우리는 이렇게 되어 있었던 함수에 콜백을 추가할 것이 아니라,
  • 대신 M 이란 아이를 사용할 수 있습니다.
  • 이 M에서 바로 함수형 리액티브 프로그램이 시작됩니다.
  • 함수형 프로그래밍은 함수를 일급 시민인 프로그래밍 방식이라고 정의를 하죠.
    단순히 함수를 변수로 저장하고 인자로 넘기거나 리턴값으로 쓸 수 있다는 말인데,
  • 간단하게 설명하고 넘어가겠습니다.
  • 이렇듯 이 포장지를 이용해서 문맥을 유지한 채 함수를 차례차례 적용하는 것이 가능합니다.
  • 시간관계상 이 네 가지의 근본이 되는 Event-Driven 에 대해 알아보려고 합니다.
  • 자바스크립트 생태계에선 , 우선 아까 말했듯이 NodeJS는 망하긴 했지만, 클라이언트사이드에서 쏟아져나오고 있는 많은 MVVM 프레임웍들이 리액티브 프로그래밍의 개념을 구현하고 있습니다.
    Q Promise라는 퓨처 모나드와, Javascript Promise라는 표준이 발표되어 있으며, Rx의 자바스크립트 포팅도 물론 있습니다.
  • 이에 반해 구글에서 새로 만들고 있는 Dart는 언어 차원에서 Future와 비동기 스트림을 지원합니다.
    정말 현명한 선택이 아닐 수 없죠.
  • FRP 방식으로 웹상에서 위젯과 3D 그래픽까지 표현할 수 있는 ELM이란 언어도 있습니다.
    홈페이지에 가시면 정말 순식간에 슈퍼마리오 게임을 만드는 영상을 볼 수 있는데 신기하더군요.
  • Transcript of "NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기"

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

    ×