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

Akka stream