Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reactive Systems と Back Pressure

2,041 views

Published on

最先端情報吸収研究所(AIAL)勉強会

Published in: Technology
  • Be the first to comment

Reactive Systems と Back Pressure

  1. 1. Reactive Systems と Back Pressure 最先端情報吸収研究所(AIAL) 勉強会 2016年8月19日
  2. 2. 自己紹介 • 池添明宏 (いけぞえ あきひろ) • Twitter: @zoetro • 昔はロボットとか、C#とか、AngularJSとか。 • 最近はJavaとかScalaを書くことが多い。
  3. 3. 本日の内容 • Reactive Systems • 対障害性 • RxJavaのBack Pressure実装 • Back Pressureの活用
  4. 4. REACTIVE SYSTEMS
  5. 5. なぜReactiveが必要なのか • さまざまな非同期イベントを扱う機会が増えている。 − GUI − マイクロサービス − ビッグデータ解析 − ノンブロッキングI/O • 複雑になりがちな非同期処理をきれいに書きたい。 → Reactive Programming • 性能がよく、柔軟性・耐障害性の高いシステムをつくりたい。 → Reactive Systems
  6. 6. Promise/Futureではダメなのか? • ReactiveもPromise/Futureも非同期処理を扱うための手段。 • Promise/Futureが主に1回きりのイベントを取り扱うのに対して、 Reactiveではイベントストリームを扱う。 • Promise/Futureの強み − 言語によっては async/await が利用できる。 − 標準で利用できるケースが多い。 • Reactiveの強み − 様々なオペレータが用意されていて、複数のストリームを組み合わせたり、時間を 考慮した処理が簡単に書けたりする。
  7. 7. Webサーバのアーキテクチャ • マルチプロセス/マルチスレッドモデル (Servletなど) − 1つのリクエストを1つのプロセス/スレッドで捌く。 − リクエスト数が増えた場合にメモリ使用量が大幅に増える (C10K問題) • イベント駆動モデル (Node.jsなど) − 複数のリクエストを1つのスレッドで捌く。 − I/O処理でのブロックは禁止。すべてノンブロッキングI/Oを利用する。 • ハイブリッドモデル (Vert.x, Play Framework, Akka HTTPなど) − イベント駆動モデルのノードを複数個用意し、メッセージをやり取りしながら連携する。 − マルチスレッドモデルとイベント駆動モデルの両方の利点を持つ。 同期処理でOK Promise/FutureでOK Reactiveが欲しい
  8. 8. Reactiveを取り入れたフレームワーク • Webアプリケーションフレームワーク − Spring Framework 5, Vert.x 3 • データベース − Slick 3, MongoDB • ライブラリ − Akka Streams, RxJava, Reactor • JVM系以外でも多数のライブラリ・フレームワークでReactiveな概念が 取り入れられている。
  9. 9. Reactive Systemの歴史 • Reactive Programmingとは • Rx (Reactive Extensions) • ReactiveX • The Reactive Manifesto • Reactive Streams
  10. 10. • 時間や外部の入力と共に変化する値を、反応的 (reactive) に処理するプロ グラミングパラダイム。 • アニメーション、GUIプログラミング、センサやロボット制御プログラム などを実現するときに役立つ。 • 2種類の入力の概念を扱う − Behavior: 時間に伴い連続的に変化する値 (温度、株価など) − Signal: 時間順に並ぶ離散的なイベント (マウスクリック、人物検知センサなど) • Haskell界隈ではFRP (Functional Reactive Programming) として、古くか ら利用されている。 Reactive Programmingとは
  11. 11. Reactive Programmingとは • コード例 • イベントストリーム var a = 1 var b = a + 1 a = 10 // aを書き換える print b // => 11 時間[t] xs:[e1, e2, e3,e4, e5] 非同期に発生するイベントを無限リストのように扱う
  12. 12. Rx (Reactive Extensions) • Microsoft Research社でErik Meijer氏が中心となり開発。 • 2009年にC#向けのライブラリとして公開された。2014年にはOSS化。 • 非同期に流れてくるデータに対して関数を適用するスタイルのライブラ リ。 • FRPとLINQのコンセプトをベースに、シンプルかつ柔軟で実用性の高い ライブラリとなっている。
  13. 13. Rx (Reactive Extensions) • Rxの特徴 − Signalのみに特化 − エラーハンドリング − リソース管理 − スケジューラ − テストのための機能 − Hot Observable, Cold Observable − LINQライクなAPI − 豊富な関数群
  14. 14. Rx (Reactive Extensions) • イベントを時間的に流れてくるデータの無限リストとして扱う。 • イベントに対しても、普通のリストと同じようにmap, reduce, filterな どの処理が使える。 observable .filter(x -> x > 5) .map(x -> x * x) .subscribe(x -> out.println(x)); list.stream() .filter(x -> x > 5) .map(x -> x * x) .forEach(x -> out.println(x)); Stream API RxJava
  15. 15. Rx (Reactive Extensions) • コードはそっくりだが、データの 流れが違う。 • Iterator − Action側からデータソースに対して データを取りにいく (Pullスタイル) • Observable − データソース側からActionに対して データを通知する (Pushスタイル) Iterator <T> Observable <T> Action Action T next() onNext(T) Pullスタイル Pushスタイル
  16. 16. ReactiveX • Rxを気に入った開発者たちが、次々と他の言語へ移植していった。 • Netflix社などが中心となり、各種言語でのRx実装をとりまとめている。 − RxJava, RxJS, RxSwift が人気。 − RxCpp, RxScala, Rx.rb, RxPy, RxKotlin, RxPHP などの実装もある。 − UniRx, RxAndroid, RxCocoa など、特定のフレームワーク向け実装もある。 • ドキュメントが充実している。
  17. 17. Reactive Streams • JVMにおける非同期ストリーム処理のAPIの標準化 • Akka Streams, Reactor, RxJava, Ratpack, Vert.xなどが対応。 • Reactive Programmingをおこなう際には、上流から下流までインタ フェースが統一されていることが望ましい。 • Java 9でReactive Streamsの標準インタフェースとしてFlow APIの導入 が検討されている。
  18. 18. The Reactive Manifesto http://www.reactivemanifesto.org/ • Scalaを開発しているTypesafe社 (現Lightbend社) が提唱 • Reactiveをプログラミングモデルだけでなく、システムのアーキテクチャ に対して適用。 • 下記の特徴を持ったアーキテクチャをReactive Systemsと呼ぶ。 − 即応性: システムは可能なかぎり素早く応答を返すこと。 − 耐障害性: システムは障害が発生しても即応性を保ち続けること。 − 弾力性: システムは処理量が変動しても即応性を保ち続けること。 − メッセージ駆動: 上記を達成するため、コンポーネント間の通信に非同期なメッセー ジパッシングを利用する。
  19. 19. Reactive Systemsとは Component Component Component • コンポーネントは分散配置可能。各コンポーネント 間では非同期なメッセージのやりとりをおこなう。 • コンポーネント内ではReactive Programmingのモ デルを利用する。
  20. 20. 対障害性
  21. 21. Reactive Systemsで起きがちな問題 • Reactive Systemsでは非同期のメッセージパッシングで コンポーネント間の通信をおこなう。 • 下流のコンポーネントよりも上流のコンポーネントの処 理速度が早い場合、下流側のバッファがあふれてしまう。 Producer Consumer 処理が早い 処理が遅い バッファのあふれ
  22. 22. 対障害性を高めるために • 大きなバッファを用意する。 • 下流のバッファがあふれないように流量を調整する。 • バッファがあふれたらデータをドロップする。時間をおいて再送する。 • コンポーネントの障害を他のコンポーネントに伝わらないようにする。 • リソースを増やして負荷分散をおこなう。
  23. 23. Reactive Manifesto & Reactive Streams • Reactive Manifestoでは、下記の手段によってシステムの耐障害性を実 現すると記述している − レプリケーション − 障害の起きたコンポーネントの隔離 − Back Pressureによるフロー制御 • Reactive Streamsでは、Back Pressureを実現するためのインタフェー スが規定されている。
  24. 24. 分散メッセージングサービス • 大きなバッファを用意して、メッセージをあふれにくく する。 • Apache Kafka, Amazon Kinesis Streams • 一時的な負荷上昇や、一時的なコンポーネントの障害に対応可能。 Producer Consumer Consumerの速度に応じて メッセージを流す 下流は気にせず メッセージを流す
  25. 25. 障害の伝搬 • いずれかのコンポーネントに障害が発生した時、それが他のコンポーネ ントに伝搬してしまう可能性がある。 Component Component バッファのあふれ ムリ… thread thread thread まだ? まだ? まだ? リクエスト リクエスト リクエスト
  26. 26. 障害の伝搬 • リクエストごとにスレッドを立てる場合、スレッドプールが枯渇して呼 び出し元のコンポーネントまでクラッシュしてしまう。 Component Component バッファのあふれ ムリ… thread thread thread ムリ… ムリ… ムリ… リクエスト リクエスト リクエスト
  27. 27. 障害の隔離 (Circuit Breaker) • 処理の失敗が連続した場合、Circuit Openな状態へと遷移。 • Openな場合は、即座にエラーを返したりキャッシュを返したりする。 • 時間をおいて復旧した場合は、Closed状態に遷移。 Component Component バッファのあふれ ムリ… thread thread thread リクエスト リクエスト リクエスト ムリっぽいので しばらく切断します
  28. 28. Back Pressure • 下流から上流のコンポーネントに対して、受け入れ可能な 個数を通知する。 • 上流のコンポーネントでは、下流の速度にあわせてゆっく りメッセージを送信したり、間に合わない分は捨てたりな どの対策をおこなう。 Producer Consumer バッファ あと1個なら 大丈夫了解! request(1)
  29. 29. Back Pressureでどこまで遡るの? Component Component Component Component • 最上流まで遡る − 例えばユーザインタフェース • 対処できるところまで遡る − データサイズが小さい所 − DBやファイルの読み込みなど、待ちのつくれる所 ちょっと 待って ちょっと 待って 待とう… 待とう… ちょっと 待って
  30. 30. Back Pressureでどこまで遡るの? • 各コンポーネントが速度を調整してバランスをとる − 上流のスループットは落ちるが、システム全体として安定して動くようになる。 Component Component ゆっくり お願いします Component 本当はもっと速く 処理できるけど、 ゆっくり送信 本当はもっと速く 処理できるけど、 ゆっくり送信
  31. 31. RxJavaのBACK PRESSURE実装
  32. 32. RxJavaのBack Pressure実装 • 基本動作 • onBackpressureオペレータ • merge • publish
  33. 33. RxJavaのBack Pressure • SubscriberがObservableをsubscribeする。 • このときSubscriberにProducerをセットする。 • SubscriberはProducerに受け取り可能なデータの数を伝える。 • ObservableはProducerを介して送信可否を判断する。 • 送信可能であれば、onNextを呼び出してデータを送信する。 Subscriber Observable Producer onNext(x) request(n)
  34. 34. RxJavaのBack Pressure: onBackpressure • request()の呼び出しに応じて振る舞いを変更するためのオペレータが用 意されている。 • onBackpressureBuffer() − データをバッファリング。キャパシティの設定、あふれた時に実行されるコール バック処理、あふれた後にどうするかを指定できる。 • onBackpressureDrop() − requestが0の間に受け取ったデータはすべて捨てる。 • onBackpressureLatest() − requestが0の間に受け取ったデータは、最新のデータ以外すべて捨てる。
  35. 35. RxJavaのBack Pressure: onBackpressure SubscriberObservable onNext(x) request(n) onBackpress ureDrop onNext(x) 好きなタイミングで データを送信する requestが0でなければ データを送信する 受け入れ可能な数を 通知する requestが0の時に 受け取ったデータは捨てる
  36. 36. RxJavaのBack Pressure: merge • 複数のObservableをmergeした場合でも、Subscriberがrequestした数だけデータが 送信される。 • 例えばSubscriberがrequest(1)を送信した場合、Observable1かObservable2のどちら かが1つデータを送信することができる。早い者勝ち。 Subscriber Observable1 onNext(x) request(n) merge onNext(x) Observable2 request(n) onNext(x) request(n)
  37. 37. RxJavaのBack Pressure: publish • 複数のSubscriberにpublishする場合、Subscriberがrequestした数の最小値が上流へ と要求される。 • 例えばSubscriber1がrequest(1), Subscriber2がrequest(2)を送った場合、Observable はデータを1つだけ送信し、そのデータはpublishによって全Subscriberに分配される。 Subscriber1 Observable onNext(x) request(n) publish onNext(x) Subscriber2 request(n) onNext(x) request(n)
  38. 38. BACK PRESSUREの活用
  39. 39. 背景 • ログ管理システムを開発 − 顧客環境から取得したログファイルを、社内のログ管理システムにアップロード − ログデータはパースしてElasticsearchに登録 − Kibanaでログの分析をおこなう • 利用ユーザ数が増えて一度に大量の登録処理が実行されると、一部のロ グデータが失われる事態が発生した。
  40. 40. ログ管理システム Elasticsearch 登録画面 Kibana Log Files upload parse bulk insert グラフの生成 一度に大量のログを登録 すると、Elasticsearchの キューがあふれてしまう
  41. 41. Elasticsearch • Bulk API: インデックスの作成・削除・更新などの処理を一括で処理する 仕組み。リクエストはキューに蓄えられ、順次処理される。 • キューがあふれたときに受け取ったデータはドロップされる。 • キューのサイズを変更することで、ドロップされにくくすることは可能。 − threadpool.bulk.queue_size: デフォルト50。-1で無制限。 − ただしサイズを大きく設定すると、サーバのスペックによってはメモリ不足になる ので注意が必要。
  42. 42. Back Pressureを利用した改善策 • ElasticsearchのNodes Stats APIのでキューの状態を監視し、上流に受 け入れ可能な数を通知する。 • 上流では、受け入れ可能な数に応じて登録処理を実行。 • 登録タスクはサイズが小さいため、バッファがあふれる心配はない。 Elasticsearch request(n) 受け入れ可能 な数を通知 SubscriberObservable キューを チェック bulk insertonNext(x) 受け入れ可能ならば 次のタスクを処理 登録タスクのバッファ
  43. 43. Back Pressureを利用した改善策 • Back Pressureを利用することで、キューがあふれることなく、データ を登録することができるようになった。 • Back Pressureを利用しなくても、キューをチェックしながら登録すれ ばいいだけなのでは? − Reactive Streamsの仕様に従っていると、上流側・下流側の実装を柔軟に他のもの に変更しやすい。 − データの加工やバッファリングなど中間に様々な処理をはさんだり、コンポーネン トを分散させたりもしやすい。
  44. 44. まとめ • 非同期処理の記述性を向上させるReactive Programmingや、システム の安定性を向上させるためのReactive Systemsが注目を集めている。 • Reactive Systemsの対障害性を向上させる方法の1つとして、Back Pressureがある。 • RxJavaにおけるBack Pressureの実装を紹介した。 • ログ管理システムにおけるBack Pressureの活用例を紹介した。

×