Akka stream

copyright Fringe81 Co.,Ltd.

Akka Stream

@mtoyoshi

AmazonKinesis

1行目

2行目

3行目

4行目

・・・

処理

・・・処理

AmazonKinesis

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.0https://github.com/drewhk/akka/pull/30/files

RxJava

Reactive Streams(JEP266)

Vert.xAkka

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

利用可能な処理：

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 Errorval src = Source(Seq(1,2,3))

// Compile Successval src = Source(List(1, 2, 3))

えっ？

ちょっとハマった

Iterable とは collection.Immutable.Iterable// Compile Errorval src = Source(Seq(1,2,3))

// Compile Successval src = Source(List(1, 2, 3))

Seq は collection.Seq、つまりcollection.Iterabletype 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: 1A: 2A: 3B: 1B: 2B: 3C: 1C: 2C: 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: 1A: 2B: 1A: 3B: 2C: 1B: 3C: 2C: 3

Akka Stream

source map:A map:B sink:C

各ステージの処理は並行に実行される

source map:A map:B sink:C

ステージ内では一件ずつ逐次処理

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

Backpressure?（背圧制御）

上流と下流のデータ流量制御の仕組みバッファ溢れを防ぐ

PushModel　上流が下流にデータを流し続ける　下流側で処理追いつかずバッファ溢れの可能性

Pull Model　下流から上流にリクエストするとデータが流れる　溢れないが下流側の待ちが大きくなる

dynamic Push/Pull Model　下流から上流にn件リクエストする　上流は下流に要求分流す　 initial-buffer-size(4), max-buffer-size(16)

implicit val system = ActorSystem()

implicit val materializer = ActorMaterializer()

// スレッドプールの定義

implicit val system = ActorSystem()

// バッファの定義

implicit val materializer = ActorMaterializer()

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

11234567...

スレッド = 1バッファ = 1

※ は各ステージ上での処理実行を表す

11234567...

スレッドは２本あるので１の処理中も上流は処理が行われる

11234567...

スレッドは１本余っているがバッファ = 2に達しており

バックプレッシャーが効いて上流は処理が行われない

11234567...

mapCでは１の処理が終わって２の処理が始まった。

これにより上流のバッファに１つ空きが出来たので上流では処理が１つ進む

11234567...

スレッドは１本余っているがバッファ = 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 { 重い処理 } }

処理の終了を待たずに次の処理を開始する

※入力と出力の順序は保証される

案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

新しい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 ~> map ~> merge

(balance.in, merge.out) }

Flowは入力と出力のポートを１つずつ持つ

要素追加

データフロー定義

val runnableGraph = FlowGraph.closed() { implicit builder => import FlowGraph.Implicits._

val src = Source(1 to 10) val mapFlow = Flow[Int].map(_ * 2) val sink = Sink.foreach[Int](println)

src ~> balance ~> map ~> merge ~> sink balance ~> map ~> merge }

RunnableGraphを作ることも出来る

val runnableGraph = FlowGraph.closed() { implicit builder => import FlowGraph.Implicits._

val src = Source(1 to 10) val mapFlow = Flow[Int].map(_ * 2) val sink = Sink.foreach[Int](println)

src ~> balance ~> map ~> merge ~> sink balance ~> map ~> merge }

RunnableGraphを作ることも出来る

実際はコードフォーマッタに潰されるので

こう書いています

src ~> balancebalance ~> map ~> mergebalance ~> map ~> mergemerge ~> 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) => import FlowGraph.Implicits._

val balance = builder.add(Balance[Int](2))

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

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

テスト用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

Software

Basics of Akka

Susanjani akka

Mge akka 1

ChatWork の新メッセージングシステムを支える技術 · akka-actor, akka-stream, kafka-stream Kafkaからドメインイベントをデキューし、HBaseにRead Modelを構築する。

Akka Actor presentation

Akka framework

Zen of Akka

Akka Bava Ekkada

Sachi Akka

Akka/Actor introduction

Akka Unit Testing

Akka & Actor model

Madu akka 2

Paatti Amma Akka

Jasmin Akka 1

Eresha akka

Akka basics

Autortiesîbu Svarîgâkie AKKA/LAA sasniegumi samits un ...nizâcijai AKKA/LAA bija trîspadsmitais darbîbas gads, kopâ ar AKKA gadiem — piecpadsmitais darbîbas gads un ceturtais

Mikkam6 akka - Hu

Akka http 2