Why Reactive Matters #ScalaMatsuri

ScalaMatsuri 2016

Why Reactive MattersYuta Okamoto (@okapies) 2016/01/30

https://www.flickr.com/photos/livenature/204420128

https://www.flickr.com/photos/livenature/204420128

Who am I?

• Yuta Okamoto (@okapies)

• Software Engineer in the manufacturing industry

• Lover of Scala and Scala OSSs

• Also specialize in DevOps technologies

• A member of ScalaMatsuri 2016 committee

岡本雄太 (@okapies) と申します！ ScalaMatsuri 運営委員その２です

My OSS projects

• finagle-kafka (https://github.com/okapies/finagle-kafka)

• sircuit (https://github.com/okapies/sircuit)

• rx-process (https://github.com/okapies/rx-process)

Scala 製のライブラリをいくつか公開してます

https://github.com/okapies/finagle-kafka

https://github.com/okapies/sircuit

https://github.com/okapies/rx-process

Writings (in Japanese)

• Translations: • Reactive Manifesto v2.0 • Twitter’s “Effective Scala” • “Callbacks are imperative, promises are functional”

(https://gist.github.com/okapies/5354929) • Blog posts (http://okapies.hateblo.jp/):

• “What is Reactive Streams?” • “Introduction to Rx, for Functional Programmers” • “Three reasons why microservices choose Scala”

Scala に関する文書の翻訳とかリアクティブに関する技術の紹介とか

https://gist.github.com/okapies/5354929

http://okapies.hateblo.jp/

Relevant talks

• 12:00 - 12:40 (International Conf Hall):

• Reactive Microservices (Christopher Hunt)

• 15:00 - 15:40 (Media Hall)

• Without Resilience, Nothing Else Matters (Jonas Bonér)

本日の関連セッション今日はマニフェストの話は（あまり）しません

Challenges facing today's software

• Asynchronous & event-driven programming

• Concurrent / parallel processing

• Scalability of the system & the organization

• Fault tolerance (Resilience)

近年のソフト開発の課題: 非同期イベント駆動、並行並列処理、システムと組織のスケーラビリティ、耐障害性

(Microservices)

Reactive is everywhere!

• From frontend GUIs to backend servers

• Lots of similar but different concepts:

• Reactive Programming

• Reactive Streams

• Reactive Manifesto

フロントエンドからバックエンドまで様々な文脈で〈リアクティブ〉がキーワードになっている

Frontend GUI

Create a multi-clicks stream

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

accumulate clickswithin 250 msecs

map each list to its length

Asynchronous click stream in RxJS

例: 非同期クリックストリームからマルチクリックを検出

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

GUI and network servicehttps://github.com/reark/reark

A demo app inRxJava + Android

Combine async GUI events with JSON APIs in a concurrent fashion

例: 非同期な GUI イベントと JSON API 呼び出しを並行処理として組み合わせる

https://github.com/reark/reark

Microservicesval userAndTweets = Future.join( userService.findByUserId(userId), tweetService.findByUserId(userId))

find

finduserId userAndTweets

User Service

Tweet Service

http://www.slideshare.net/knoldus/finagle-by-twitter-engineer/16

join

Query other microservices and combine all two responses into a tuple asynchronously

in Twitter Finagle

例: 二つのマイクロサービスへの非同期クエリを束ねて出力

http://www.slideshare.net/knoldus/finagle-by-twitter-engineer/16

Bigdata processing

https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru

Distributed and parallel processing of big data

例: 大規模データの分散並列処理

in Google Cloud Dataflow


Reactive Streams in JDK 9

Reactive Streams が JDK 9 に（たぶん）入る

Reactive?

Reactive ◯◯

Programming model? !

Runtime engine? !

Architecture?＝

文脈によってかなり意味付けが異なるのが実情

Foundations of Reactive

• Reactive component

!

• Reactive data flow

リアクティブの基盤: コンポーネントとデータフロー

in out

1

2

AB C

Reactive Component

• Only react to input, and output some data

• Self-contained

in out

入力にのみ反応 (react) する自己完結したコンポーネント

Function? Object? Actor?

Sub-system?

Reactive Data Flow

Source

Source Sink

in out

A pipeline delivering data between inputs and outputs of components

コンポーネントの入力と出力を結びつけてデータを運ぶパイプライン

Reactive ◯◯

Programming model !

Runtime engine !

Architecture＝

まず〈リアクティブ・プログラミング〉の話から始めよう

vs

vs

Challenges (revisited)





課題: 非同期・並行並列プログラミングを楽にしたい

Why not use Callback?

// asynchronous eventdef mouseClick(f: (Int, Int) => Unit): Unit!// register a callback as an argumentmouseClick { case (x, y) => println(s"x: $x, y: $y”) }

なぜコールバックを使わないのか？

Callback

Callback Hell

• Hard to modularize the code

• Hard to manage state changes (side effects) and data dependencies

• Hard to control the order of execution (driven by external events)

コールバック地獄:モジュール化、副作用の管理、実行順序の制御が困難

Pyramid of Doom

var g = ...!step1 { a => step2 { b => step3 { c => step4 { d => // do something with a, b, c, d and g } } }}

+1

—1

×2

+

破滅のピラミッド: 依存性がピラミッドのように積み上がる外側の状態を暗黙に参照していてモジュール性が低い

Dependent async steps stacked like a pyramid

Implicit reference to states in the outer scopes

Reactive Component

• Reacts to inputs only when the asynchronous event is supplied through the data flows

in out

データフローからイベントが来た時にだけ反応する

Self Containment

• Each component isolates its internal state from others, and has independent lifecycle

• These properties are suited for asynchrony

自己完結性: 各コンポーネントの内部状態を互いに隔離独立したライフサイクルを持つので非同期処理に向いている

? ?in out

× ×Avoid using outer variables

Benefits

• Better modularity (composability)

• Better containment of state and failures

モジュール性が高く、状態や障害を封じ込めるのが容易

? ?in out

× ×

Execution order and dependencies

• How can execution be ordered in async programming?

• Solution: Reactive Programming

非同期プログラミングで実行順序をどうやって制御するか？ → リアクティブ・プログラミング

http://en.wikipedia.org/wiki/Reactive_programming

〈データフロー〉と〈変更の伝播〉を指向するパラダイム

http://en.wikipedia.org/wiki/Reactive_programming

Data flow

g1

g2

h

Source

Source Sink

fin out

A directed graph of the data flowing between operators

演算の間を流れるデータの有向グラフ

Conventional (Imperative) Style

A = 1;B = 2;C = (A+1) + (B-1)*2;

一般的な命令型のプログラムは〈上から順番〉に実行する

-1

×2

+

+1A

B C

Imperative code in data flowA = 1;B = 2;C = (A+1) + (B-1)*2;

1

2 41 2

2

命令型のプログラムをデータフローに写してみよう

Execution model

• The dataflow just describes the dependencies among the variables and operators

• Execution model specifies how the graph is executed

AB C

+1

—1

×2

+A = 1;B = 2;C = (A+1) + (B-1)*2;

データフローの計算方法は〈実行モデル〉で決まる

-1

×2

+

+1A

B C

Reassignment to variablesA = 1; B = 2;C = (A+1) + (B-1)*2; A = 2;

1 $ 2

2 4

Never propagated to C

Imperative Execution Model

××

××× ×

命令型の実行モデルでは、C を計算した後に A を変更しても（当然）何も起きない

-1

×2

+

+1A

B C

Reassignment to variablesA := 1; B := 2; C := (A+1) + (B-1)*2; A := 2;

1 $ 2

4 $ 52

1 $ 3

1 2Update of A is

propagated to C

Reactive Execution Model

リアクティブな実行モデルでは、A の変更がグラフに沿って伝播して C が再計算される

-1

×2

+

+1A

B C

Reassignment to variables

2

5 $ 72 $ 31 $ 2 2 $ 4

3

C := (A+1) + (B-1)*2; A := 2;B := 3;


次いで、B を変更しても同様に伝播する

Update of B ispropagated to C

-1

×2

+

+1A

B C

Reassignment to variables

2 $ 0

7 $ 532 4

3 $ 1

A := 2; B := 3; A := 0;


もう一度 A を変更しても反映される

Update of A ispropagated to C

Reactive Programming !

!

Functional-style Reactive Programming

(FRP)≈

一般に〈リアクティブプログラミング〉というと〈関数型～〉(FRP) を指すことが多い

e.g. (Akka Streams):

implicit val system = ActorSystem()implicit val mat = ActorMaterializer()!val a = Source(...)val b = Source(...)!val a1 = a.map(_ + 1)val b1 = b.map(_ - 1).map(_ * 2)!val c = (a1 zip b1).map{case (a, b) => a + b}!c.runWith(Sink.foreach(println))(mat)

AB C

+1

—1

×2

+

Build the data flowusing functional DSL

先ほどのデータフローを関数型のコードで記述した例

e.g. (Akka Streams):

implicit val system = ActorSystem()implicit val mat = ActorMaterializer()!val a = Source(...)val b = Source(...)!val a1 = a.map(_ + 1)val b1 = b.map(_ - 1).map(_ * 2)!val c = (a1 zip b1).map{case (a, b) => a + b}!c.runWith(Sink.foreach(println))(mat)Stick functions together with map

FunctionInput

AB C

+1

—1

×2

+

入力に適用する関数を高階関数 map で繋ぎ合わせる

Functional style and RP

• Why is functional programming suited for reactive programming?

• To answer this question, we should know “Why Functional Programming Matters?”

なぜ関数型は RP に適しているのか？「なぜ関数型プログラミングは重要」なのか？

Why Functional Programming Matters

• An influential paper authored by John Hughes (also known for QuickCheck and QuviQ)

• 1st version appeared in 1984 (30 years ago!)

• Discusses how to improve modularity in programming by leveraging the FP features

ジョン・ヒューズの著名な論文関数型によるモジュール性の向上について論じている

http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

Glues in FP languages

• Two vital glues in FP languages:

• Lazy evaluation

• Higher-order functions (combinators)

“The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together.”

関数型の重要な糊:〈遅延評価〉と〈高階関数〉「問題を分割する方法は、解を貼り合わせる方法に依存する」

Lazy evaluation

class Cons[A](hd: A, tl: => List[A]) extends List[A]!def nats(n: Int): List[Int] = new Cons(n, nats(n+1))def fizzbuzz(n: Int) = n match { case _ if n % 15 == 0 => "FizzBuzz" case _ if n % 3 == 0 => "Fizz" case _ if n % 5 == 0 => "Buzz" case _ => n.toString}nats.map(fizzbuzz).take(100).foreach(println)

必要になった分だけ新たに値を評価する ⇒ コードを生成器と選択器でモジュール化

Call by need (pull-based)

Modularize in generator and selector

Infinite list

Higher-order function

• Modularize a program into a general higher-order function & your specializing functions

!

!

• It enables separating your business logic from the context of the underlying datatypeプログラムを高階関数とユーザ関数にモジュール化 ⇒ ビジネスロジックとデータ型の文脈を分離

set. map(_ + 1) // Set[A]map. map(_ + 1) // Map[A, B]list.map(_ + 1) // List[A]

Localized context Shared business logic

Adopting FP glues to RP

• Lazy evaluation:

• Organize your program into a pipeline, consisting of generator/selector to handle async events piece by piece (push-based)

• Higher-order function:

• Separate your business logic from its underlying async, event-driven behavior

1. 非同期イベントを生成器・選択器で少しずつ処理2. ビジネスロジックを非同期イベントの挙動と分離

FP glues in FRP

implicit val system = ActorSystem()implicit val mat = ActorMaterializer()!val a = Source(...)val b = Source(...)!val a1 = a.map(_ + 1)val b1 = b.map(_ - 1).map(_ * 2)!val c = (a1 zip b1).map{case (a, b) => a + b}!c.runWith(Sink.foreach(println))

AB C

+1

—1

×2

+

generator

非同期の文脈を局所化した高階関数 (map, zip 等)を使い、ビジネスロジックをパイプライン化する

selector

Localized async context

• Most of FRP data flow DSLs are declarative: the data flow constructed by combinators is actually scheduled and executed by runtime

Separate the what from the how

implicit val system = ActorSystem()implicit val mat = ActorMaterializer()!val c = (a1 zip b1).map{case (a, b) => a + b}!c.runWith(Sink.foreach(println))(mat)

多くの FRP のデータフロー DSL は、宣言的に構築したデータフローをランタイム上で実行する

runtime!

Separate the what from the how

Input

Input

Output(2) Runtime

(1) Programming Model (DSL)

(Executing the how = propagation of change)

(Describing the what = data flow)

“What” を DSL で記述して “How” をランタイムで実行する

Reactive ◯◯

Programming model !

Runtime engine !

Architecture＝

vs

リアクティブなプログラミングモデルとランタイムには密接な関係がある

vs

Portability (multi-platform)

• A reactive program can be mapped onto different architectures by the runtime

• Single machine

• GPU cards

• Distributed environment

リアクティブなプログラムは様々なアーキテクチャ上にマッピングできる

Optimization

• The runtime can optimize data flow graphs to improve performance and stability

• Fusion, data-locality, balancing & caching

• Parallelization and distribution

• Verification and validation

ランタイムでデータフローを最適化できる融合、データ局所性、並列分散化、検証など

e.g. Fusing

• A new feature in Akka Streams 2.0

This new abstraction … is called fusing. This feature … will be now possible to execute multiple stream processing steps inside one actor, reducing the number of thread-hops where they are not necessary … will increase performance for various use cases, including HTTP.

複数の処理ステップを一つにまとめる融合 (fusing) 機能

http://akka.io/news/2015/11/05/akka-streams-2.0-M1-released.html

http://akka.io/news/2015/11/05/akka-streams-2.0-M1-released.html

Examples

• The Dataflow DSL + Runtime architecture is ubiquitous in recent years

• Akka Streams, ReactiveX, …

• Scientific computing: TensorFlow, Halide

• Bigdata processing: Spark, Google Cloud Dataflow, Asakusa Framework, Gearpump

データフロー DSL とランタイムの組み合わせは近年、様々な分野で適用されている

e.g. TensorFlow

http://download.tensorflow.org/paper/whitepaper2015.pdf

http://download.tensorflow.org/paper/whitepaper2015.pdf

Challenges





DONE!

Reactive ◯◯

Programming model !

Runtime engine !

Architecture＝

vs

vs

リアクティブ・アーキテクチャ

Single machine !

!

Distributed system

近年、分散システムが一般的になりつつある

Why distributed systems?





→ Reactive Systemsなぜ分散システムが必要か？

→ スケーラビリティ、耐障害性、マイクロサービス化

(Microservices)

http://www.reactivemanifesto.org/


Changes in application requirements

A few years ago Recent years

Configuration tens of servers thousands ofmulti-core processors

Responsetime

seconds milliseconds

Availability hours ofoffline maintenance 100% uptime

Data size gigabytes petabytes

大規模なクラスタとデータを扱いつつ、ミリ秒の応答時間と 100%の可用性を実現するシステムが必要

Changes in the way the systems are built

“We call these Reactive Systems.…

The largest systems in the world rely upon architectures based on these properties and serve the needs of billions of people daily.”


世の中の大規模システムが既に採用しているアーキテクチャを〈リアクティブ・システム〉と呼ぼう


Traits of Reactive Systems

リアクティブ・システムの四つの特徴: 即応性、弾力性、レジリエンス、メッセージ駆動

http://www.slideshare.net/Typesafe_Inc/going-reactive-2016-data-preview/6


Traits of Reactive SystemsRapid and consistent

response time to users

Stay responsiveunder failures

Asynchronous message- passing is the foundation

Stay responsiveunder varying workload

〈非同期メッセージ駆動〉が全ての基盤



Reactive Component in RSs

• Communicate only via messages

• Self-contained & isolated with asynchronous (binary) boundaries

Actor? Sub-system?

in out

非同期（バイナリ）境界で隔離されたコンポーネント同士がメッセージのみでやりとりする

Message Driven Architecture

• Enables elasticity through scaling, sharding, replication and location transparency

• Enables resilience through replication, isolation and task/error delegation (“Let it crash”)

メッセージ駆動によって弾力性とレジリエンスを達成

How do we build Reactive Systems?

We do not want to be prescriptive in the manifesto as to how this is achieved. — Martin Thompson

• The manifesto just describes the properties and qualities of reactive component/system

• Let’s examine a real world use case, called the microservice architecture (MSA)

http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2

マニフェストはシステムの実現方法には触れていない → 実例として〈マイクロサービス〉を調べてみる

http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2

Microservice Architecture

• A distributed system improving scalability of the large organization, such like Amazon, Netflix and Twitter

• Organizes small, independent and modular services around business capability (c.f. Conway’s Law)

• Can be regarded as an instance of the reactive system巨大な開発組織をスケールさせるための方法論

リアクティブ・システムの実例の一つと見ることができる

STORAGE & RETRIEVAL

LOGICPRESENTATIONROUTING

Redis

Memcache

Flock

T-Bird

MySQLTweet

User

Timeline

Social Graph

DMs

API

Web

Monorail

TFE

HTTP Thrift “Stuff”http://monkey.org/~marius/scala2015.pdf

e.g. Real world microservices in Twitter

http://monkey.org/~marius/scala2015.pdf

System Level Dataflow

• MSA is composed of (reactive) components and their business dependencies • This structure forms a system level dataflow

• Can we describe the whole distributed system as a code? A

B C

MSA はビジネス同士の依存関係に基づくデータフローを成す → 分散システム全体をコードとして記述できないか？

Reactive Big DataTM

• Reactive architecture on bigdata processing

• Spark

• Google Cloud Dataflow

• Gearpump (Intel)

• Asakusa Framework

昨今のビッグデータ処理フレームワークはリアクティブなアーキテクチャを採用していることが多い


Pipeline representing a DAG of steps

DAG でデータ処理パイプラインを記述する

in Google Cloud Dataflow


DAG on Spark

https://cloud.githubusercontent.com/assets/2133137/7625997/e0878f8c-f9b4-11e4-8df3-7dd611b13c87.png

実行中の Spark ジョブを DAG として可視化した例

https://cloud.githubusercontent.com/assets/2133137/7625997/e0878f8c-f9b4-11e4-8df3-7dd611b13c87.png

http://www.gearpump.io/overview.htmlGearpump’s underlying

Reactive architecture

Gearpump のアーキテクチャの例 Akka を使ったリアクティブ・システムになっている

http://www.gearpump.io/overview.html

http://knowledge.sakura.ad.jp/tech/4016/http://docs.asakusafw.com/preview/ja/html/asakusa-on-spark/user-guide.html

Asakusa Framework

Single DSL can be run on multiple bigdata

framework

Asakusa Framework で記述したコードは Hadoop 上でも Spark 上でもポータブルに実行できる

http://knowledge.sakura.ad.jp/tech/4016/

http://docs.asakusafw.com/preview/ja/html/asakusa-on-spark/user-guide.html

Apache Dataflow (New!)

http://googlecloudplatform.blogspot.co.uk/2016/01/Dataflow-and-open-source-proposal-to-join-the-Apache-Incubator.html

Google 主導によるデータフロー記述の標準化の取り組み

http://googlecloudplatform.blogspot.co.uk/2016/01/Dataflow-and-open-source-proposal-to-join-the-Apache-Incubator.html


Google Cloud as Runtime engine

Optimize

Schedule

Flow of pipelineUser code & SDK Monitoring UI

Data flow definition

データフロー・ランタイムとしての Google クラウドがデータフローの最適化とタスクのスケジュールを行う


General overview

ビッグデータにおけるリアクティブ・システムのアーキテクチャを一般化してみる

Dataflow

Reactive System

Cloud-level Runtime

General overview

• The cloud-level runtime:

• Optimizes the specified dataflow and schedules reactive components

• Obtains resources from a distributed resource manager such as YARN and

• Deploys the components to the allocated resources and run them as the reactive systemクラウドレベルのランタイムがデータフローをリアクティブシステムとして配備し実行する

Dataflow

Reactive System

Cloud-level Runtime

Web Service Orchestration

• The modern DevOps toolchain focus mainly on configuring a system on each node in an imperative manner (such as Dockerfile)

• The immutable infrastructure should be composed of the reactive components and described as the declarative dataflow (?)

ウェブサービスのオーケストレーションにもリアクティブ・システム＋データフローの手法が使えるのでは？

Summary

• Reactive Programming in concert with the Reactive Architecture offer solutions to the modern challenges:





リアクティブは非同期イベント駆動、並行並列処理、スケーラビリティ、耐障害性の課題を解決する

Summary

• Reactive components and the data flows are great tools to cope with asynchrony and distribution at every layer of the system

• The capability (performance, fault-tolerance and operability) provided by the runtimes weighs more than just the programming models in the current era

〈リアクティブ〉はシステムのあらゆる階層で有効な概念プログラミングモデルよりランタイムの能力が重要な時代