非同期ストリーム処理の標準化を目指す "Reactive Streams" とは
TL でこんなのが流れてたので少し調べてみた。
Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe
— Twitter Engineering (@TwitterEng) 2014, 4月 17
Reactive Streams って?
”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”(公式サイトより)。
ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指している。
ここで言う”非同期ストリーム処理”とは、(広義の)リアルタイム性が求められるデータ処理中心のアプリケーション、より具体的にはビデオストリーミングや数百万ユーザのトランザクション処理など。
下のインタビュー記事では、Reactive Streams を策定する理由として、API 策定による相互運用性の向上と共に、バックプレッシャー (back pressure) による流量制御の必要性が挙げられている。
以上から分かるように、この "API" はユーザが直接使うものではなく、各フレームワークが、この API を使ってエンドユーザ向けの DSL を提供するためのもの。これにより、異なるフレームワーク間の相互運用性を担保できる。逆に言うと、ユーザがデータ変換や分割・結合を記述する方法は守備範囲ではない。
なお、この仕様が出てきた背景としては、去年の秋くらいから "Reactive Manifesto"(日本語訳)というキャンペーンが始まっていて、Reactive Streams はその流れに連なっていると思われる。
どんな仕様なの?
現状、SPI コンポーネントの構成要素は以下の三つ。普通の Pub/Sub だけど、バックプレッシャーを伝える方法が定義されているのが特徴?
- Publisher
- Subscriber からの要求に応じて、潜在的に無制個の順序付けされた要素を提供する。Publisher は複数の Subscriber に配信することができ、処理率に応じて配分する。
- これ以上、要素を提供できないときは Subscriber の
onComplete
メソッドを呼ぶ。
- Subscriber
- 一つ以上の Publisher を購読して、順序付けされた要素ストリームを受け取る。Producer が Subscriber に要素を渡すときは
onNext
コールバックを呼ぶ。Subscriber は、Producer をブロックせずに非同期処理するかキューイングする必要がある。
- 一つ以上の Publisher を購読して、順序付けされた要素ストリームを受け取る。Producer が Subscriber に要素を渡すときは
- Subscription
- Subscriber から Producer へ要求を伝えるときに使う。Subscriber が Subscription の
requestMore(int)
メソッドを呼ぶと、Publisher は 制限時間 T が経つ前に最高 N 回までonNext
メソッドを呼び出せる。
- Subscriber から Producer へ要求を伝えるときに使う。Subscriber が Subscription の
API レベルでは、上記の Publisher に対応する型として Producer が、Subscriber に対応するものとして Consumer が定義される。また、両者を組み合わせて入力と出力の両方を行う Processor も提供される。
【追記】組み合わせるとこんな感じ?
So glad ! http://t.co/tUFxBpfYrF is up !akkaStream.produceTo(rxjavaObservable).produceTo(reactorStream).produceTo(vertxStream) !
— Stephane Maldini (@smaldini) 2014, 4月 17
誰が関わってるの?
Scala 言語と Akka フレームワークの開発をしている Typesafe 社が中心となって仕様策定を進めている。Akka 開発者による解説記事はこちら。
それ以外にも、以下のような人々やプロダクトが関わっている。
- Gavin Bierman: Oracle の人で Java や JVM に関わってるっぽい。
- Jon Brisbin, Stephane Maldini: Pivotal Software 所属で、要するに Spring Framework のひと。Spring IO の基盤である "Reactor" の開発者。Reactor についてはこの辺に日本語記事がある。
- Mathias Doenitz, Johannes Rudolph: Akka を使った HTTP サーバ "Spray" の開発者。現在は Typesafe 傘下で、Akka 自体の開発にも携わっている(はず)。
- George Campbell, Ben Christensen: Netflix が開発している JVM 向けの Rx (Reactive Extensions) 実装である "RxJava" の開発者。
- Marius Eriksen: Twitter の非同期 RPC フレームワーク "Finagle" の開発者。今のところドキュメントに Finagle の名前は見えないけど、将来的には実装を提供していくのだろうか。
- Tim Fox, Norman Maurer: 非同期アプリケーションフレームワーク "Vert.x" の開発者で、現在は Redhat 所属。Norman は、Java のイベント駆動フレームワークとして広く使われている Netty の主要開発者でもある。Vert.x と Reactive Streams の関係についてはこの記事で解説している。
- Doug Lea: ”Java並行処理プログラミング”の筆者の一人。また、java.util.concurrent (JSR-166) の作者として著名な人物。
- Erik Meijer: Microsoft で LINQ や Reactive Extensions に関わっていたらしい。現在は退職して Applied Duality という会社を立ち上げている。
JVM エコシステムの各方面で実績のある人物・プロダクトが、ズラッと一堂に会しているのが印象的。特に、Oracle の人や Doug Lea 氏が関わっている辺りを見ても、標準化に対する本気が伺える。(元)Microsoft の人が一枚噛んでるのも興味深い。
批判とか
Reactive Streams の”思想的根拠”である Reactive Manifesto に対する批判。たしかに、”そもそも "Reactive" って何だよ” というのがよく分からない感じはある。
ただ、Akka というプロダクトは明らかに Erlang/OTP に対するリスペクトから出てきたものだし、本人達もそれを隠しているわけではない(例えば、Akka の公式サイトの名前は "Let it crash")。アクターモデルを広めたいという意図こそあれ、Erlang の成果を横取りしようとしている、というのは考え過ぎじゃないかなぁと。【追記】: @pokarim さんから「(引用した発言に)そのような意図はない」とご指摘を受けたので訂正します。失礼しました。
まとめ
非同期ストリーム処理フレームワークは乱立気味、というか思い切り乱立しているので、使う側からすると「標準化してくれるのは助かるなぁ」という感想。
とりあえず、これから出てくる実装を開発者が各々の立場から調べて、フレームワークの相互運用性や流量制御といったフィーチャーが、自分たちのユースケースに対してどの程度メリットがあるのか判断していけば良いのではないかと思う。
あと、そういえば Storm に声は掛かってないんだろうか? 明らかにこのモデルに乗っけられそうだけど。