Akka-Streams in Production

Akka-Streams in Production

1

自己紹介

• 会社：株式会社サイバーエージェント

• 名前：來田一宣

• 仕事：アドテクスタジオ->Smalgo->サーバサイドエンジニア

• 言語：Java(5年), Scala(1年半), 他細々と

2

アドテクスタジオとは

• 色々な広告プロダクトの開発がされている部署

3

Smalgo（DSP)とは

• 成果報酬型DSP（Demand-Side Platform）

• 最大秒間6万req/secのやりとり

• 分析データ量はよくわからないくらい多い量

4

ここから本題

Akka-Streamsを さわったことある人？

Akka-Streamsとは？

• Reactive-StreamsのAkka実装

7

Reactive-Streamsとは？

• JVM上のnon-blockingでback-pressureな非同期ストリーム処理の標準仕様

8

Back Pressureとは

• Subscriberが自分が処理できる量をPublisherにリクエストを送ることで無駄なくSubscriberが処理できる量を処理する仕組みがBack pressure

9

publisher1op/s

subscriber 100op/s

問題なし

publisher100op/s

subscriber 1op/s

問題あり

10

publisher100op/s

subscriber 1op/s

①1reqいけるよ

②じゃあ1reqするね

コードで見るAkka-Streams

簡単な例①

13

簡単な例②

14

簡単な例③

15

どのようにProductionで使用したのか

実現したいこと

• キューに入ったユーザのマークデータを使ってほぼリアルタイムにIDを生成しそれをRedisに詰める

17

掻い摘むと

• キューからマークデータを取得

• マークデータからIDを生成

• IDデータをRedisに詰める

• おまけ：結果をロギング

18

普通にAkkaでやろうとすると

• キューを監視するActor

• 独自ロジックでIDをつけるActor

• Redisに詰めるActor

19

もしキューを監視するActorが遅かったら？• 問題なし（台数を増やせばいい）

20

もしIDを生成するActorが 遅かったら？• キューを監視するActorはそんな事お構いなしにIDを生成するActorに送りつづける

• 問題あり（メモリは有限バッファーのサイズには限りがある）

21

もしRedisに詰めるActorが 遅かったら？• IDを生成するActorはそんな事お構いなしに

Redisに詰めるActorに送りつづける

• 問題あり（メモリは有限バッファーのサイズには限りがある）

22

背圧制御を自分で実装するのは結構面倒

そうだAkka-Streams を使おう

Akka-Streams選定理由

• Akkaでやりたかった

• パフォーマンスを追求したかった

• 複雑にならずにシンプルにしたかった

• 技術的挑戦をしたかった

26

実装例

キューからデータを取得

28

IDを生成

29

IDをRedisにつめる

30

結果をlogging

31

これらの処理群を結合し実行

32

Fault Tolerance について

• 1.0-M4バージョンからAkka-StreamsのStream内で例外が起きた場合に全体を再起動するなどの設定が可能（Akka Streams内のActorを管理しているSupervisorのカスタマイズが可能)

33

メリット

• 簡単に背圧制御を実現することが可能

• メンテナンス性が高い（見通しが良いコード

• テストが書きやすい

• パフォーマンスが高い

34

デメリット

• まだ実験的なライブラリである

• 初期の学習コストが高い（Akkaの知識、Akka-Streamsの知識が必要）

• 複数台のサーバにまたがって処理できない（今後実装されるかも）

35

まとめ

• 今回紹介した機能以外も色々なことが可能なのでこの発表を聞いて少しでも興味が出たかたがいたら幸いです

36

サイバーエージェントのアドテクスタジオでは Scalaプログラマを絶賛募集中です

ご清聴ありがとうございました