Akka stream

copyright Fringe81 Co.,Ltd.
Akka Stream
@mtoyoshi

Amazon
Kinesis
1行目
2行目
3行目
4行目
・
・
・
処理
・・・処理

Amazon
Kinesis
1行目
2行目
3行目
4行目
・
・
・
・・・
Akka Actor
で処理

Akka Actor便利ですが
・メッセージ（データ）が型安全でない
・OutOfMemoryに遭遇
・メッセージ送受信の仕組み、汎用的

Akka Stream?
Typesafeより2015.07に1.0リリース
Akka Actor
Akka Stream
Akka HTTP

Migration Guide 1.0 to 2.0
https://github.com/drewhk/akka/pull/30/files

RxJava
Reactive Streams
(JEP266)
Vert.x
Akka
Stream
・・・
Slick3 mongoDB
a standard
for asynchronous stream processing
with non-blocking back pressure
その他
OSS

特徴
・バックプレッシャーによりバッファ溢れの危
険を回避しつつパフォーマンスにも配慮
・ReactiveStreams規格のものと接続可能
・ストリームを構成する豊富な部品群
・部品群の合成性、拡張性
・ビジュアルなグラフDSL

特徴
・API変更はこれからも続く(1.0->2.0)
・複数ノードにまたがった
　ストリームの構築は未対応
・モナってはいない

今日はOverview的な話
・Akka Streamの構成要素は？
・どういうふうにプログラミングする？
・バックプレッシャーが特徴みたい
　概念レベルの理解から一歩進めたい

部品群を組み合わせて RunnableGraphを作る
※１つ以上のSourceと１つ以上のSinkが必要

val source = Source(1 to 10)
val filter = Flow[Int].filter(_ % 2 == 0)
val map = Flow[Int].map(_ * 2)
val sink = Sink.foreach[Int](println)
val runnableGraph =
source.via(filter).via(map).to(sink)
runnableGraph.run()
RunnableGraphの構築と実行

Source(1 to 10)
.filter(_ % 2 == 0)
.map(_ * 2)
.runForeach(println)
RunnableGraphの構築と実行
こう書くことも出来る
val runnableGraph =source.via(filter).via(map).to(sink)
runnableGraph.run()

Source[Int] - Flow[Int,String] - Sink[String]
Source[Int] - Flow[String,Long] Sink[String]
Function1のように
InとOutの型が合えば合成可能

implicit val system = ActorSystem()
implicit val materializer = ActorMaterializer()
val runnableGraph =
source.via(filter).via(map).to(sink)
runnableGraph.run()
materializer
WHAT
HOW

利用可能な処理：
map
filter
collect
take / takeWhile
drop / dropWhile
flatten
fold
scan
grouped / groupBy
recover
などなど

val future: Future[List[Int]] = ...
val src: Source[List[Int], Unit] = Source(future)
src.mapConcat(identity).map(_ * 2)
def mapConcat[T](f: Out => Iterable[T])
Source[List[Int]]]だとList[Int]が１つ、
ストリームを流れる事になる。
mapConcatを使う事でList要素のIntそれぞれが
ストリームを流れるように出来る。

zipWithIndexを使おうと思った。
が、用意されてなかった。
...作る！
case class ZipWithIndex[T]() extends PushStage[T, (T, Int)] {
var i = -1
override def onPush(elem: T, ctx: Context[(T, Int)]): SyncDirective = {
i += 1
ctx.push((elem, i))
}
}
Source(List("A", "B", "C"))
.transform(() => ZipWithIndex())
.runForeach(println) // (A,0) (B,1) (C, 2)

Source#apply
使用頻度が多そう(?)なもの
・Iterableから
・Iteratorから
・Futureから
・Fileから↓
SynchronousFileSource(new java.io.File("..."))
Source[ByteString]が出来る。
※Akka2.4ベースになればJava7追加の
AsynchronousFileChannel等のNIO API使いたいとのこと。

ちょっとハマった
IterableからSourceを作ることが出来る
// Compile Error
val src = Source(Seq(1,2,3))
// Compile Success
val src = Source(List(1, 2, 3))
えっ？

ちょっとハマった
Iterable とは collection.Immutable.Iterable
// Compile Error
val src = Source(Seq(1,2,3))
// Compile Success
val src = Source(List(1, 2, 3))
Seq は collection.Seq、つまりcollection.Iterable
type Seq[+A] = scala.collection.Seq[A]
val Seq = scala.collection.Seq scala/package.scala

Source#apply
Source(initialDelay=1.second, interval=100.millis, tick="msg")
100ms毎にmsgというStringを下流に永遠に流す
Tcp().bind("127.0.0.1", 8888)
こういうSourceも作れる
TCP connectionを待ち
ByteStringをストリームとして処理する
Source(Props[MyActor])
Actorはメッセージ受けて
下流になんらかのデータを流していく

val src: Source[String, Cancellable] =
Source(initialDelay=0.second, interval=100.millis, tick="msg")
val sink: Sink[String, Future[Int]] =
Sink.fold[Int, String](0){ case (sum, _) => sum + 1 }
src sink
100ms毎に"msg"を送出 msgを受信する度に件数カウント
※foldは上流のデータが完了して集計終了となる
Cancellable Future[Int]
ストリームの実行者に渡される値
Materialized Value

val rg1: RunnableGraph[Cancellable] =
src.to(sink)
val rg2: RunnableGraph[Future[Int]] =
src.toMat(sink)(Keep.right)
val rg3: RunnableGraph[(Cancellable, Future[Int])] =
src.toMat(sink)(Keep.both)
val (cancellable, futureInt) = rg3.run()
※src.toMat(sink)(Keep.left)と同義

val src: Source[String, Cancellable] =
Source(initialDelay = 0.second, interval = 100.millis, tick = "msg")
val sink: Sink[String, Future[Int]] =
Sink.fold[Int, String](0){ case (sum, _) => sum + 1 }
val rg: RunnableGraph[(Cancellable, Future[Int])] =
src.toMat(sink)(Keep.both)
val (cancellable, futureInt) = rg.run()
futureInt.foreach(println)
Thread.sleep(1000 * 5)
cancellable.cancel()

・Publisher（Reactive Stream）から
Source#apply

実行時の挙動確認
通常のScala Collectionとの違い

(1 to 3)
.map{ i => println(s"A: $i"); i }
.map{ i => println(s"B: $i"); i }
.foreach(i => println(s"C $i"))
A: 1
A: 2
A: 3
B: 1
B: 2
B: 3
C: 1
C: 2
C: 3
Scala Collection

Source(1 to 3)
.map{ i => println(s"A: $i"); i }
.map{ i => println(s"B: $i"); i }
.runForeach(i => println(s"C: $i"))
A: 1
A: 2
B: 1
A: 3
B: 2
C: 1
B: 3
C: 2
C: 3
Akka Stream

source map:A map:B sink:C
1
1
2
3
2
3
1
2
3
1
2
3
各ステージの処理は
並行に実行される

source map:A map:B sink:C
1
1
2
3
2
3
1
2
3
1
2
3
ステージ内では
一件ずつ逐次処理

Backpressureの挙動確認
スレッドとバッファの関係

Backpressure?
（背圧制御）
上流と下流のデータ流量制御の仕組み
バッファ溢れを防ぐ

PushModel
　上流が下流にデータを流し続ける
　下流側で処理追いつかずバッファ溢れの可能性
Pull Model
　下流から上流にリクエストするとデータが流れる
　溢れないが下流側の待ちが大きくなる
dynamic Push/Pull Model
　下流から上流にn件リクエストする
　上流は下流に要求分流す
　 initial-buffer-size(4), max-buffer-size(16)

// スレッドプールの定義
// バッファの定義
akka.actor.default-dispatcher.fork-join-executor.parallelism-max = 1
akka.stream.materializer {
initial-input-buffer-size = 1
max-input-buffer-size = 1
}

このうち
mapCはかなり重い処理とする
source mapA mapB sinkmapC
heavy!

source mapA mapB mapC
1
1
2
3
4
5
6
7
...
2
3
1
1
2
sink
1
2
2
スレッド = 1
バッファ = 1
3
3
4
3
※ は
各ステージ上での
処理実行を表す

1
1
2
3
4
5
6
7
...
2
3
1
sink
1
2
2
スレッド = 1
バッファ = 2
3
2
4
1
2
4
5

1
1
2
3
4
5
6
7
...
2
3
1
sink
1
スレッド = 2
バッファ = 2
2
4
1
2
4
5
6
3
スレッドは２本あるので
１の処理中も上流は
処理が行われる

1
1
2
3
4
5
6
7
...
2
3
1
sink
1
スレッド = 2
バッファ = 2
2
4
1
2
4
5
6
3
スレッドは１本余っているが
バッファ = 2に達しており
バックプレッシャーが効いて
上流は処理が行われない

1
1
2
3
4
5
6
7
...
2
3
1
sink
1
スレッド = 2
バッファ = 2
2
4
1
2
4
5
6
3
mapCでは１の処理が終わって
２の処理が始まった。
これにより上流のバッファに１つ空きが
出来たので上流では処理が１つ進む

1
1
2
3
4
5
6
7
...
2
3
1
sink
1
スレッド = 2
バッファ = 2
2
4
1
2
4
5
6
3
スレッドは１本余っているが
バッファ = 2に達しており
上流は処理が行われない
mapCへの
大量流入を
防ぐ

上流がストップしている状態を
回避/改善しようとすると？
案１：上流の処理を進める為の施策
案２：重いmapCを改善する施策

案1-1：
bufferステージを置く
上流の処理を進める施策

重い処理の前にbufferステージを設けることで
上流の処理を進めることが出来る。
ストリーム全体では各ステージのバッファは
2としていても
bufferステージのバッファは4といったように
異なる値を設定することが出来る。
※なおbufferステージ以外でも個別にバッファ数を指定可能
val buffer = Flow[Int].buffer(4, OverflowStrategy.backpressure)
... mapB.via(buffer).via(mapC) ...

Flow[Int].buffer(4, OverflowStrategy.dropNew)
ただし設定したバッファ値に
達した場合はBPが効く
bufferの前後で極端な処理速度の差が
ある場合はあまり効果ない
捨てる指示をすれば上流の処理は続行

案1-2：
conflateステージを置く
上流の処理を進める施策

def conflate[S](seed: Out => S)(aggregate: (S, Out) => S)
...
.conflate(List(_)){ (elems, elem) => elem :: elems }
...
← 要素を捨てて良いなら
...
.conflate(identity){ (e, _) => e }
...
BPが効いている間、aggregate関数が実行される
※下流へはList[T]
※下流へはT
まとめあげ効果で下流へのデータ数が減る
下流が要素数に応じて遅くなるなら効果はない

案2-1：
mapAsyncステージに変える
重いmapCを改善する施策

val mapC = Flow[Int].mapAsync(4) { n =>
Future { 重い処理 }
}
処理の終了を待たずに
次の処理を開始する
※入力と出力の順序は保証される
mapC
1
2
3
4

案2-2：
Fan-Outな部品を用い
parallelに処理する
重いmapCを改善する施策

Balanceは入力１、出力NなFan-Outな部品
均等に下流に流す
Mergeは入力N、出力１なFan-Inな部品
同期はしない
来たものから下流に流す
※順序は保証されなくなる
balance merge
元のmapC
元のmapC

新しいmapC
新しいFlowとしてmapCを定義出来る
balance merge
元のmapC
元のmapC
balance merge
元のmapC
元のmapC
新しいmapC

val mapC = Flow() { implicit builder =>
import FlowGraph.Implicits._
val balance = builder.add(Balance[Int](2))
val merge = builder.add(Merge[Int](2))
val map = Flow[Int].map(重い処理)
balance ~> map ~> merge
(balance.in, merge.out)
}
Flowは入力と出力の
ポートを１つずつ持つ
要素追加
データフロー定義

val runnableGraph =
FlowGraph.closed() { implicit builder =>
val src = Source(1 to 10)
val mapFlow = Flow[Int].map(_ * 2)
src ~> balance ~> map ~> merge ~> sink
}
RunnableGraphを作ることも出来る

val runnableGraph =
FlowGraph.closed() { implicit builder =>
val src = Source(1 to 10)
val mapFlow = Flow[Int].map(_ * 2)
src ~> balance ~> map ~> merge ~> sink
}
RunnableGraphを作ることも出来る
実際はコードフォーマッタに潰されるので
こう書いています
src ~> balance
merge ~> sink

FlowGraphとMat値
val sink: Sink[Int, Future[Int]] = Sink.fold(0){_ + _}
val rg: RunnableGraph[Future[List[Int]]] =
FlowGraph.closed(sink, sink) ((f1,f2) => Future.sequence(f1 :: f2 :: Nil)) {
implicit builder => (sink1, sink2) =>
Source(1 to 10) ~> balance ~> sink1
balance ~> sink2
}
val ret: Future[List[Int]] = rg.run()

その他の
Fan-Out, Fan-Inな部品

<Fan-Out>
Balance 入力を均等に出力に振り分ける
Broadcast 入力を全出力に等しく流す
Unzip (A,B)の入力をAの出力とBの出力に流す
UnZipWith 任意の型の入力をタプルにして出力
FlexiRoute Fan-Out型の部品を作るためのベース

<Fan-In>
Merge 複数入力を1本に
同期することなしに来たものから出力する
Zip ２つの入力AとBを(A,B)にして出力する
同期する
ZipWith ２つの入力AとBを(A,B)にして出力する
同期する
(A,B)を任意の型に加工して出力する
Concat 1つ目の入力を流し終えたら２つ目の入力を流す
FlexiMerge Fan-In型の部品を作るためのベース

Error Handling

・null要素は流せない
・例外が起きるとストリームは失敗として終了
Stop ストリーム失敗終了(default)
Resume 該当の要素を捨てて次の処理を再開
Restart ・該当の要素を捨てる
・そのステージを再作成する
・処理を再開
※fold等状態を持つものは状態がクリアされてしまうので注意
Supervision Strategies

Test
libraryDependencies += Seq(
…,
"com.typesafe.akka" % "akka-testkit_2.11" % "2.3.14" % "test",
"com.typesafe.akka" % "akka-stream-testkit-experimental_2.11" % "1.0" % "test"
)

本番用
Source
本番用
Sink
本番用
Flow
本番用
Flow
テスト用
Source
テスト用
Sink
SourceやSinkは外部環境との接続点になりがちで
テストしづらい事が多い。
テスト時はテスト用のデータを流すSourceとつなげた
り、akka-stream-testkitに用意されているTestSinkと
つなげて期待通りの結果が流れてくるかを確認したり
する。

val probe = source.runWith(TestSink.probe[Result])
probe
.request(2)
.expectNext(Result(1),Result(2))
.request(100)
.expectNext(Result(3))
.expectComplete()
requestで下流から上流へデータを要求できる
expectNextで流れてくるデータの確認
最後にデータが全て流れ終わったかどうかの確認

ありがとうございました

Akka stream

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Akka stream (20)

More from Masaki Toyoshima (7)

Akka stream