Why Reactive Matters #ScalaMatsuri
-
Upload
yuta-okamoto -
Category
Software
-
view
12.805 -
download
5
Transcript of Why Reactive Matters #ScalaMatsuri
ScalaMatsuri 2016
Why Reactive MattersYuta Okamoto (@okapies) 2016/01/30
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 運営委員その2です
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 製のライブラリをいくつか公開してます
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 に関する文書の翻訳とかリアクティブに関する技術の紹介とか
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
例: 非同期クリックストリームからマルチクリックを検出
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 呼び出しを 並行処理として組み合わせる
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
例: 二つのマイクロサービスへの非同期クエリを束ねて出力
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)
• Asynchronous & event-driven programming
• Concurrent / parallel processing
• Scalability of the system & the organization
• Fault tolerance (Resilience)
課題: 非同期・並行並列プログラミングを楽にしたい
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
〈データフロー〉と〈変更の伝播〉を指向するパラダイム
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;
Reactive Execution Model
次いで、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;
Reactive Execution Model
もう一度 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
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
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
Challenges
• Asynchronous & event-driven programming
• Concurrent / parallel processing
• Scalability of the system & the organization
• Fault tolerance (Resilience)
DONE!
Reactive ◯◯
Programming model !
Runtime engine !
Architecture=
vs
vs
リアクティブ・アーキテクチャ
Single machine !
!
Distributed system
近年、分散システムが一般的になりつつある
Why distributed systems?
• Asynchronous & event-driven programming
• Concurrent / parallel processing
• Scalability of the system & the organization
• Fault tolerance (Resilience)
→ 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.”
http://www.reactivemanifesto.org/
世の中の大規模システムが既に採用しているアーキテクチャを 〈リアクティブ・システム〉と呼ぼう
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
〈非同期メッセージ駆動〉が全ての基盤
http://www.slideshare.net/Typesafe_Inc/going-reactive-2016-data-preview/6
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
マニフェストはシステムの実現方法には触れていない → 実例として〈マイクロサービス〉を調べてみる
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
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
昨今のビッグデータ処理フレームワークはリアクティブなアーキテクチャを採用していることが多い
https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru
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 として可視化した例
http://www.gearpump.io/overview.htmlGearpump’s underlying
Reactive architecture
Gearpump のアーキテクチャの例 Akka を使ったリアクティブ・システムになっている
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 上でもポータブルに実行できる
Apache Dataflow (New!)
http://googlecloudplatform.blogspot.co.uk/2016/01/Dataflow-and-open-source-proposal-to-join-the-Apache-Incubator.html
Google 主導によるデータフロー記述の標準化の取り組み
https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru
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:
• Asynchronous & event-driven programming
• Concurrent / parallel processing
• Scalability of the system & the organization
• Fault tolerance (Resilience)
リアクティブは非同期イベント駆動、並行並列処理、 スケーラビリティ、耐障害性の課題を解決する
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
〈リアクティブ〉はシステムのあらゆる階層で有効な概念 プログラミングモデルよりランタイムの能力が重要な時代