Enviar búsqueda
Cargar
Reactive Systems と Back Pressure
•
7 recomendaciones
•
3,191 vistas
Akihiro Ikezoe
Seguir
最先端情報吸収研究所(AIAL)勉強会
Leer menos
Leer más
Tecnología
Denunciar
Compartir
Denunciar
Compartir
1 de 44
Descargar ahora
Descargar para leer sin conexión
Recomendados
遺伝的アルゴリズム(Genetic Algorithm)を始めよう!
遺伝的アルゴリズム(Genetic Algorithm)を始めよう!
Kazuhide Okamura
物体検知(Meta Study Group 発表資料)
物体検知(Meta Study Group 発表資料)
cvpaper. challenge
Sift特徴量について
Sift特徴量について
la_flance
backbone としての timm 入門
backbone としての timm 入門
Takuji Tahara
ドラレコ + CV = 地図@Mobility Technologies
ドラレコ + CV = 地図@Mobility Technologies
Kazuyuki Miyazawa
画像認識における特徴表現 -SSII技術マップの再考-
画像認識における特徴表現 -SSII技術マップの再考-
Hironobu Fujiyoshi
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
科学と機械学習のあいだ:変量の設計・変換・選択・交互作用・線形性
科学と機械学習のあいだ:変量の設計・変換・選択・交互作用・線形性
Ichigaku Takigawa
Recomendados
遺伝的アルゴリズム(Genetic Algorithm)を始めよう!
遺伝的アルゴリズム(Genetic Algorithm)を始めよう!
Kazuhide Okamura
物体検知(Meta Study Group 発表資料)
物体検知(Meta Study Group 発表資料)
cvpaper. challenge
Sift特徴量について
Sift特徴量について
la_flance
backbone としての timm 入門
backbone としての timm 入門
Takuji Tahara
ドラレコ + CV = 地図@Mobility Technologies
ドラレコ + CV = 地図@Mobility Technologies
Kazuyuki Miyazawa
画像認識における特徴表現 -SSII技術マップの再考-
画像認識における特徴表現 -SSII技術マップの再考-
Hironobu Fujiyoshi
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
科学と機械学習のあいだ:変量の設計・変換・選択・交互作用・線形性
科学と機械学習のあいだ:変量の設計・変換・選択・交互作用・線形性
Ichigaku Takigawa
Bitcoinを技術的に理解する
Bitcoinを技術的に理解する
Kenji Urushima
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
Norishige Fukushima
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
Kouhei Sutou
UnityとROSの連携について
UnityとROSの連携について
UnityTechnologiesJapan002
位置情報にまつわるデータ補間技術
位置情報にまつわるデータ補間技術
Hiroaki Sengoku
Marp Tutorial
Marp Tutorial
Rui Watanabe
畳み込みニューラルネットワークの研究動向
畳み込みニューラルネットワークの研究動向
Yusuke Uchida
最適輸送の解き方
最適輸送の解き方
joisino
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
SSD: Single Shot MultiBox Detector (ECCV2016)
SSD: Single Shot MultiBox Detector (ECCV2016)
Takanori Ogata
Python nlp handson_20220225_v5
Python nlp handson_20220225_v5
博三 太田
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
gree_tech
モバイルアプリ向けAWSネイティブアーキテクチャ
モバイルアプリ向けAWSネイティブアーキテクチャ
Rikitake Oohashi
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
Tetsutaro Watanabe
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
Preferred Networks
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
ゼロから始めるQ#
ゼロから始めるQ#
Takayoshi Tanaka
分散深層学習 @ NIPS'17
分散深層学習 @ NIPS'17
Takuya Akiba
Incremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend Development
Akihiro Ikezoe
Reactive
Reactive
Akihiro Ikezoe
Más contenido relacionado
La actualidad más candente
Bitcoinを技術的に理解する
Bitcoinを技術的に理解する
Kenji Urushima
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
Norishige Fukushima
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
Kouhei Sutou
UnityとROSの連携について
UnityとROSの連携について
UnityTechnologiesJapan002
位置情報にまつわるデータ補間技術
位置情報にまつわるデータ補間技術
Hiroaki Sengoku
Marp Tutorial
Marp Tutorial
Rui Watanabe
畳み込みニューラルネットワークの研究動向
畳み込みニューラルネットワークの研究動向
Yusuke Uchida
最適輸送の解き方
最適輸送の解き方
joisino
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
SSD: Single Shot MultiBox Detector (ECCV2016)
SSD: Single Shot MultiBox Detector (ECCV2016)
Takanori Ogata
Python nlp handson_20220225_v5
Python nlp handson_20220225_v5
博三 太田
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
gree_tech
モバイルアプリ向けAWSネイティブアーキテクチャ
モバイルアプリ向けAWSネイティブアーキテクチャ
Rikitake Oohashi
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
Tetsutaro Watanabe
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
Preferred Networks
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
ゼロから始めるQ#
ゼロから始めるQ#
Takayoshi Tanaka
分散深層学習 @ NIPS'17
分散深層学習 @ NIPS'17
Takuya Akiba
La actualidad más candente
(20)
Bitcoinを技術的に理解する
Bitcoinを技術的に理解する
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
UnityとROSの連携について
UnityとROSの連携について
位置情報にまつわるデータ補間技術
位置情報にまつわるデータ補間技術
Marp Tutorial
Marp Tutorial
畳み込みニューラルネットワークの研究動向
畳み込みニューラルネットワークの研究動向
最適輸送の解き方
最適輸送の解き方
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
SSD: Single Shot MultiBox Detector (ECCV2016)
SSD: Single Shot MultiBox Detector (ECCV2016)
Python nlp handson_20220225_v5
Python nlp handson_20220225_v5
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
モバイルアプリ向けAWSネイティブアーキテクチャ
モバイルアプリ向けAWSネイティブアーキテクチャ
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
統計的係り受け解析入門
統計的係り受け解析入門
ゼロから始めるQ#
ゼロから始めるQ#
分散深層学習 @ NIPS'17
分散深層学習 @ NIPS'17
Destacado
Incremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend Development
Akihiro Ikezoe
Reactive
Reactive
Akihiro Ikezoe
2014 akka-streams-tokyo-japanese
2014 akka-streams-tokyo-japanese
Konrad Malawski
社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPI
Akihiro Ikezoe
Embulkを活用したログ管理システム
Embulkを活用したログ管理システム
Akihiro Ikezoe
企業文化をぶち壊すな / Startup Culture
企業文化をぶち壊すな / Startup Culture
Takaaki Umada
RxJava@DAUG
RxJava@DAUG
Maxim Volgin
Превышаем скоросные лимиты с Angular 2
Превышаем скоросные лимиты с Angular 2
Oleksii Okhrymenko
RubyistのためのSilverlight2
RubyistのためのSilverlight2
Akihiro Ikezoe
Silverlight2でつくるリッチなTrac用UI
Silverlight2でつくるリッチなTrac用UI
Akihiro Ikezoe
Closure Toolsの紹介
Closure Toolsの紹介
Yusuke Amano
Zoetrope
Zoetrope
Ellie Buchan
Electron
Electron
Virginia Rodriguez
Webアプリケーションをもっと楽しく! 〜フロントエンドのお仕事〜
Webアプリケーションをもっと楽しく! 〜フロントエンドのお仕事〜
Yusuke Amano
企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策
企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策
Ryo Mitoma
こだわりのkintone
こだわりのkintone
Yusuke Amano
Understanding Akka Streams, Back Pressure, and Asynchronous Architectures
Understanding Akka Streams, Back Pressure, and Asynchronous Architectures
Lightbend
kintoneフロントエンド開発 モダン化への道
kintoneフロントエンド開発 モダン化への道
Yusuke Amano
ペアプロはリモートでもできる!
ペアプロはリモートでもできる!
Tatsuya Deguchi
サイボウズの方向性
サイボウズの方向性
naoki ando
Destacado
(20)
Incremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend Development
Reactive
Reactive
2014 akka-streams-tokyo-japanese
2014 akka-streams-tokyo-japanese
社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPI
Embulkを活用したログ管理システム
Embulkを活用したログ管理システム
企業文化をぶち壊すな / Startup Culture
企業文化をぶち壊すな / Startup Culture
RxJava@DAUG
RxJava@DAUG
Превышаем скоросные лимиты с Angular 2
Превышаем скоросные лимиты с Angular 2
RubyistのためのSilverlight2
RubyistのためのSilverlight2
Silverlight2でつくるリッチなTrac用UI
Silverlight2でつくるリッチなTrac用UI
Closure Toolsの紹介
Closure Toolsの紹介
Zoetrope
Zoetrope
Electron
Electron
Webアプリケーションをもっと楽しく! 〜フロントエンドのお仕事〜
Webアプリケーションをもっと楽しく! 〜フロントエンドのお仕事〜
企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策
企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策
こだわりのkintone
こだわりのkintone
Understanding Akka Streams, Back Pressure, and Asynchronous Architectures
Understanding Akka Streams, Back Pressure, and Asynchronous Architectures
kintoneフロントエンド開発 モダン化への道
kintoneフロントエンド開発 モダン化への道
ペアプロはリモートでもできる!
ペアプロはリモートでもできる!
サイボウズの方向性
サイボウズの方向性
Similar a Reactive Systems と Back Pressure
サーバサイドエンジニアが 1年間まじめにSPAやってみた
サーバサイドエンジニアが 1年間まじめにSPAやってみた
Itaru Kitagawa
リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi
リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi
Yuta Okamoto
Rxjavaとoptionalで関数型androidしよう
Rxjavaとoptionalで関数型androidしよう
Fumihiko Shiroyama
Zynga
Zynga
awsadvantageseminar
Aws privte20110406 arai
Aws privte20110406 arai
awsadovantageseminar
RxSwift x Realm
RxSwift x Realm
Kosuke Usami
全部入り!WGPで高速JavaScript+HML5体験
全部入り!WGPで高速JavaScript+HML5体験
AdvancedTechNight
Flowtype Introduction
Flowtype Introduction
Teppei Sato
GraphQLはどんな時に使うか
GraphQLはどんな時に使うか
Yutaka Tachibana
Scalaz-StreamによるFunctional Reactive Programming
Scalaz-StreamによるFunctional Reactive Programming
Tomoharu ASAMI
Rx入門
Rx入門
Takaaki Suzuki
JavaからScalaへ
JavaからScalaへ
takezoe
Redux, Relay, HorizonあるいはElm
Redux, Relay, HorizonあるいはElm
chuck h
ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03
Daiki Maekawa
Scalaでのプログラム開発
Scalaでのプログラム開発
Kota Mizushima
Going Serverless, Building Applications with No Servers
Going Serverless, Building Applications with No Servers
Keisuke Nishitani
Java Clientで入門する Apache Kafka #jjug_ccc #ccc_e2
Java Clientで入門する Apache Kafka #jjug_ccc #ccc_e2
Yahoo!デベロッパーネットワーク
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える
Tomoharu ASAMI
Play jjug2012spring
Play jjug2012spring
Takafumi Ikeda
Scalaの現状と課題
Scalaの現状と課題
Kota Mizushima
Similar a Reactive Systems と Back Pressure
(20)
サーバサイドエンジニアが 1年間まじめにSPAやってみた
サーバサイドエンジニアが 1年間まじめにSPAやってみた
リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi
リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi
Rxjavaとoptionalで関数型androidしよう
Rxjavaとoptionalで関数型androidしよう
Zynga
Zynga
Aws privte20110406 arai
Aws privte20110406 arai
RxSwift x Realm
RxSwift x Realm
全部入り!WGPで高速JavaScript+HML5体験
全部入り!WGPで高速JavaScript+HML5体験
Flowtype Introduction
Flowtype Introduction
GraphQLはどんな時に使うか
GraphQLはどんな時に使うか
Scalaz-StreamによるFunctional Reactive Programming
Scalaz-StreamによるFunctional Reactive Programming
Rx入門
Rx入門
JavaからScalaへ
JavaからScalaへ
Redux, Relay, HorizonあるいはElm
Redux, Relay, HorizonあるいはElm
ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03
Scalaでのプログラム開発
Scalaでのプログラム開発
Going Serverless, Building Applications with No Servers
Going Serverless, Building Applications with No Servers
Java Clientで入門する Apache Kafka #jjug_ccc #ccc_e2
Java Clientで入門する Apache Kafka #jjug_ccc #ccc_e2
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える
Play jjug2012spring
Play jjug2012spring
Scalaの現状と課題
Scalaの現状と課題
Reactive Systems と Back Pressure
1.
Reactive Systems と
Back Pressure 最先端情報吸収研究所(AIAL) 勉強会 2016年8月19日
2.
自己紹介 • 池添明宏 (いけぞえ
あきひろ) • Twitter: @zoetro • 昔はロボットとか、C#とか、AngularJSとか。 • 最近はJavaとかScalaを書くことが多い。
3.
本日の内容 • Reactive Systems •
対障害性 • RxJavaのBack Pressure実装 • Back Pressureの活用
4.
REACTIVE SYSTEMS
5.
なぜReactiveが必要なのか • さまざまな非同期イベントを扱う機会が増えている。 − GUI −
マイクロサービス − ビッグデータ解析 − ノンブロッキングI/O • 複雑になりがちな非同期処理をきれいに書きたい。 → Reactive Programming • 性能がよく、柔軟性・耐障害性の高いシステムをつくりたい。 → Reactive Systems
6.
Promise/Futureではダメなのか? • ReactiveもPromise/Futureも非同期処理を扱うための手段。 • Promise/Futureが主に1回きりのイベントを取り扱うのに対して、 Reactiveではイベントストリームを扱う。 •
Promise/Futureの強み − 言語によっては async/await が利用できる。 − 標準で利用できるケースが多い。 • Reactiveの強み − 様々なオペレータが用意されていて、複数のストリームを組み合わせたり、時間を 考慮した処理が簡単に書けたりする。
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.
Reactiveを取り入れたフレームワーク • Webアプリケーションフレームワーク − Spring
Framework 5, Vert.x 3 • データベース − Slick 3, MongoDB • ライブラリ − Akka Streams, RxJava, Reactor • JVM系以外でも多数のライブラリ・フレームワークでReactiveな概念が 取り入れられている。
9.
Reactive Systemの歴史 • Reactive
Programmingとは • Rx (Reactive Extensions) • ReactiveX • The Reactive Manifesto • Reactive Streams
10.
• 時間や外部の入力と共に変化する値を、反応的 (reactive)
に処理するプロ グラミングパラダイム。 • アニメーション、GUIプログラミング、センサやロボット制御プログラム などを実現するときに役立つ。 • 2種類の入力の概念を扱う − Behavior: 時間に伴い連続的に変化する値 (温度、株価など) − Signal: 時間順に並ぶ離散的なイベント (マウスクリック、人物検知センサなど) • Haskell界隈ではFRP (Functional Reactive Programming) として、古くか ら利用されている。 Reactive Programmingとは
11.
Reactive Programmingとは • コード例 •
イベントストリーム var a = 1 var b = a + 1 a = 10 // aを書き換える print b // => 11 時間[t] xs:[e1, e2, e3,e4, e5] 非同期に発生するイベントを無限リストのように扱う
12.
Rx (Reactive Extensions) •
Microsoft Research社でErik Meijer氏が中心となり開発。 • 2009年にC#向けのライブラリとして公開された。2014年にはOSS化。 • 非同期に流れてくるデータに対して関数を適用するスタイルのライブラ リ。 • FRPとLINQのコンセプトをベースに、シンプルかつ柔軟で実用性の高い ライブラリとなっている。
13.
Rx (Reactive Extensions) •
Rxの特徴 − Signalのみに特化 − エラーハンドリング − リソース管理 − スケジューラ − テストのための機能 − Hot Observable, Cold Observable − LINQライクなAPI − 豊富な関数群
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.
Rx (Reactive Extensions) •
コードはそっくりだが、データの 流れが違う。 • Iterator − Action側からデータソースに対して データを取りにいく (Pullスタイル) • Observable − データソース側からActionに対して データを通知する (Pushスタイル) Iterator <T> Observable <T> Action Action T next() onNext(T) Pullスタイル Pushスタイル
16.
ReactiveX • Rxを気に入った開発者たちが、次々と他の言語へ移植していった。 • Netflix社などが中心となり、各種言語でのRx実装をとりまとめている。 −
RxJava, RxJS, RxSwift が人気。 − RxCpp, RxScala, Rx.rb, RxPy, RxKotlin, RxPHP などの実装もある。 − UniRx, RxAndroid, RxCocoa など、特定のフレームワーク向け実装もある。 • ドキュメントが充実している。
17.
Reactive Streams • JVMにおける非同期ストリーム処理のAPIの標準化 •
Akka Streams, Reactor, RxJava, Ratpack, Vert.xなどが対応。 • Reactive Programmingをおこなう際には、上流から下流までインタ フェースが統一されていることが望ましい。 • Java 9でReactive Streamsの標準インタフェースとしてFlow APIの導入 が検討されている。
18.
The Reactive Manifesto http://www.reactivemanifesto.org/ •
Scalaを開発しているTypesafe社 (現Lightbend社) が提唱 • Reactiveをプログラミングモデルだけでなく、システムのアーキテクチャ に対して適用。 • 下記の特徴を持ったアーキテクチャをReactive Systemsと呼ぶ。 − 即応性: システムは可能なかぎり素早く応答を返すこと。 − 耐障害性: システムは障害が発生しても即応性を保ち続けること。 − 弾力性: システムは処理量が変動しても即応性を保ち続けること。 − メッセージ駆動: 上記を達成するため、コンポーネント間の通信に非同期なメッセー ジパッシングを利用する。
19.
Reactive Systemsとは Component Component Component • コンポーネントは分散配置可能。各コンポーネント 間では非同期なメッセージのやりとりをおこなう。 •
コンポーネント内ではReactive Programmingのモ デルを利用する。
20.
対障害性
21.
Reactive Systemsで起きがちな問題 • Reactive
Systemsでは非同期のメッセージパッシングで コンポーネント間の通信をおこなう。 • 下流のコンポーネントよりも上流のコンポーネントの処 理速度が早い場合、下流側のバッファがあふれてしまう。 Producer Consumer 処理が早い 処理が遅い バッファのあふれ
22.
対障害性を高めるために • 大きなバッファを用意する。 • 下流のバッファがあふれないように流量を調整する。 •
バッファがあふれたらデータをドロップする。時間をおいて再送する。 • コンポーネントの障害を他のコンポーネントに伝わらないようにする。 • リソースを増やして負荷分散をおこなう。
23.
Reactive Manifesto &
Reactive Streams • Reactive Manifestoでは、下記の手段によってシステムの耐障害性を実 現すると記述している − レプリケーション − 障害の起きたコンポーネントの隔離 − Back Pressureによるフロー制御 • Reactive Streamsでは、Back Pressureを実現するためのインタフェー スが規定されている。
24.
分散メッセージングサービス • 大きなバッファを用意して、メッセージをあふれにくく する。 • Apache
Kafka, Amazon Kinesis Streams • 一時的な負荷上昇や、一時的なコンポーネントの障害に対応可能。 Producer Consumer Consumerの速度に応じて メッセージを流す 下流は気にせず メッセージを流す
25.
障害の伝搬 • いずれかのコンポーネントに障害が発生した時、それが他のコンポーネ ントに伝搬してしまう可能性がある。 Component Component バッファのあふれ ムリ… thread thread thread まだ? まだ? まだ? リクエスト リクエスト リクエスト
26.
障害の伝搬 • リクエストごとにスレッドを立てる場合、スレッドプールが枯渇して呼 び出し元のコンポーネントまでクラッシュしてしまう。 Component Component バッファのあふれ ムリ… thread thread thread ムリ… ムリ… ムリ… リクエスト リクエスト リクエスト
27.
障害の隔離 (Circuit Breaker) •
処理の失敗が連続した場合、Circuit Openな状態へと遷移。 • Openな場合は、即座にエラーを返したりキャッシュを返したりする。 • 時間をおいて復旧した場合は、Closed状態に遷移。 Component Component バッファのあふれ ムリ… thread thread thread リクエスト リクエスト リクエスト ムリっぽいので しばらく切断します
28.
Back Pressure • 下流から上流のコンポーネントに対して、受け入れ可能な 個数を通知する。 •
上流のコンポーネントでは、下流の速度にあわせてゆっく りメッセージを送信したり、間に合わない分は捨てたりな どの対策をおこなう。 Producer Consumer バッファ あと1個なら 大丈夫了解! request(1)
29.
Back Pressureでどこまで遡るの? Component Component Component Component •
最上流まで遡る − 例えばユーザインタフェース • 対処できるところまで遡る − データサイズが小さい所 − DBやファイルの読み込みなど、待ちのつくれる所 ちょっと 待って ちょっと 待って 待とう… 待とう… ちょっと 待って
30.
Back Pressureでどこまで遡るの? • 各コンポーネントが速度を調整してバランスをとる −
上流のスループットは落ちるが、システム全体として安定して動くようになる。 Component Component ゆっくり お願いします Component 本当はもっと速く 処理できるけど、 ゆっくり送信 本当はもっと速く 処理できるけど、 ゆっくり送信
31.
RxJavaのBACK PRESSURE実装
32.
RxJavaのBack Pressure実装 • 基本動作 •
onBackpressureオペレータ • merge • publish
33.
RxJavaのBack Pressure • SubscriberがObservableをsubscribeする。 •
このときSubscriberにProducerをセットする。 • SubscriberはProducerに受け取り可能なデータの数を伝える。 • ObservableはProducerを介して送信可否を判断する。 • 送信可能であれば、onNextを呼び出してデータを送信する。 Subscriber Observable Producer onNext(x) request(n)
34.
RxJavaのBack Pressure: onBackpressure •
request()の呼び出しに応じて振る舞いを変更するためのオペレータが用 意されている。 • onBackpressureBuffer() − データをバッファリング。キャパシティの設定、あふれた時に実行されるコール バック処理、あふれた後にどうするかを指定できる。 • onBackpressureDrop() − requestが0の間に受け取ったデータはすべて捨てる。 • onBackpressureLatest() − requestが0の間に受け取ったデータは、最新のデータ以外すべて捨てる。
35.
RxJavaのBack Pressure: onBackpressure SubscriberObservable onNext(x) request(n) onBackpress ureDrop onNext(x) 好きなタイミングで データを送信する requestが0でなければ データを送信する 受け入れ可能な数を 通知する requestが0の時に 受け取ったデータは捨てる
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.
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.
BACK PRESSUREの活用
39.
背景 • ログ管理システムを開発 − 顧客環境から取得したログファイルを、社内のログ管理システムにアップロード −
ログデータはパースしてElasticsearchに登録 − Kibanaでログの分析をおこなう • 利用ユーザ数が増えて一度に大量の登録処理が実行されると、一部のロ グデータが失われる事態が発生した。
40.
ログ管理システム Elasticsearch 登録画面 Kibana Log Files upload parse bulk insert グラフの生成 一度に大量のログを登録 すると、Elasticsearchの キューがあふれてしまう
41.
Elasticsearch • Bulk API:
インデックスの作成・削除・更新などの処理を一括で処理する 仕組み。リクエストはキューに蓄えられ、順次処理される。 • キューがあふれたときに受け取ったデータはドロップされる。 • キューのサイズを変更することで、ドロップされにくくすることは可能。 − threadpool.bulk.queue_size: デフォルト50。-1で無制限。 − ただしサイズを大きく設定すると、サーバのスペックによってはメモリ不足になる ので注意が必要。
42.
Back Pressureを利用した改善策 • ElasticsearchのNodes
Stats APIのでキューの状態を監視し、上流に受 け入れ可能な数を通知する。 • 上流では、受け入れ可能な数に応じて登録処理を実行。 • 登録タスクはサイズが小さいため、バッファがあふれる心配はない。 Elasticsearch request(n) 受け入れ可能 な数を通知 SubscriberObservable キューを チェック bulk insertonNext(x) 受け入れ可能ならば 次のタスクを処理 登録タスクのバッファ
43.
Back Pressureを利用した改善策 • Back
Pressureを利用することで、キューがあふれることなく、データ を登録することができるようになった。 • Back Pressureを利用しなくても、キューをチェックしながら登録すれ ばいいだけなのでは? − Reactive Streamsの仕様に従っていると、上流側・下流側の実装を柔軟に他のもの に変更しやすい。 − データの加工やバッファリングなど中間に様々な処理をはさんだり、コンポーネン トを分散させたりもしやすい。
44.
まとめ • 非同期処理の記述性を向上させるReactive Programmingや、システム の安定性を向上させるためのReactive
Systemsが注目を集めている。 • Reactive Systemsの対障害性を向上させる方法の1つとして、Back Pressureがある。 • RxJavaにおけるBack Pressureの実装を紹介した。 • ログ管理システムにおけるBack Pressureの活用例を紹介した。
Descargar ahora