データ通信が益々ストリーム化されるようになってきているなか、標準化を目指す団体、Reactive Streamが登場した。
オープンソースの利点として、現場レベルでの標準規格の浸透を加速させるという事があげられる。解決すべき大きな問題がある場合には、優秀な人達が集まってきて問題を解決し、結果を共有する。
標準化団体とはよく、現存するベンダが標準規格を決める際に、自分のマーケットに利益をもたらすよう立ちまわるための土俵に成り下がると言われることもある。
言い換えれば交渉事は幾度も行われる割に、肝心のコードは大して生み出されないということだ。
こういった場合、定義が不明瞭であることによって、標準仕様の実装がベンダ毎でバラバラになったりする事がよくある。最近、reactivestreams.orgをリードする団体の一つであるTypesafeのチーフアーキテクト、ビクター・クラングと話す機会があった。オープンソースはJavaバーチャルマシン(JVM)で非同期ストリームベースで処理を行う仕組みの標準化を試みているという。
クラングと、Twitter、Oracle、Pivotal、Red Hat、Applied Duality、Typesafe、Netflix、the spray.ioといった企業の開発陣、それにダグ・リーは、動画配信やその他、何万ものリクエストを並列で処理するといった、大量のデータをリアルタイムで扱うようなコンピューティングでは、今後ますますストリームベースの処理が求められることになると考えている。
問題があるとすれば、データの流量制御が行われずに、処理できるデータよりも入ってくるデータの方が多くなれば、システムはいずれクラッシュするということだ。
ReadWrite(RW):昨今のコンピューティングにおけるReactive Streamへのシフトの要因は何ですか?
ビクター・クラング（VK)：これは別に新しい話だというわけじゃない。というより、人々がHadoopやそのたのバッチフレームワークを使うようになった中、とうとうリアルタイムストリーミングが必要になる時が来たという事なんだ。いざそうなると、入力データは継続して流れてくるから全体のサイズは前もってわからない。バッチの場合は前もって分かるんだが。
無限とも言えるデータが流れてくることになると、今度はそのフローをコントロールする必要がある。データの供給元が供給先を圧倒しないような流量制御をシステムを持つ必要がある。これはバッチベースの処理からストリームベースの処理になって初めて見えてくる問題だ。
ユーザは長年、独自のネットワークプロトコルを構築するため、あるいは彼らのアプリケーションが有する特定のニーズに応えるために、より”反応性”が高いストリームを求めてきた。どんな時であれ、ネットワーク上でIPを持つデバイスと通信する際にはこういった抽象化が必要になる。
reactivestream.orgでは、包括的に異なった規格同士に互換性を持たせ、動作させるためにどうすればいいかという、根本的な問題に取り組もうとしている。長いこと、これに対する案として、別の実装と接続できるような実装を構築するためのエコシステムを作り上げて、開発者がその上で開発を行うというプランを考えていた。例えばTwitterのストリーミングライブラリとRxJavaのストリーミングライブラリを繋げ、それをReactorやAkka Streamsや他のJVMの実装に接続するようなやり方だ。
RW:主要メンバーは誰ですか?
VK:まず我々Typesafeは、業界がReactive ApplicationChallengeと呼んでいるものに取り組むためのオープンソースのプラットフォームを持ってる事から、早い段階で参加している。Twitterと、PivotalのReactorチーム、Applied Dualityのエリック・メージャー、Netflixのベン・クリステンセンとジョージ・キャンベルのようなメンバーが加入してくれた時は興奮した。RedHatとOracleも参加しているし、Javaの並列処理の原動力となる「java util concurrent」を開発したダグ・リーのような重要なメンバーも居る。このプロジェクトのゴールの一つは、将来のJavaのためにJSRを作ることだ。
メンバーはそれぞれ自分の役割を果たしているが、このレベルのメンバーがこの作業のための時間を作るのは非常に難しいことだ。
RW:標準仕様というものは開発者にとってあまり魅力的に思われない傾向がありますが、貴方はどのようにしてこういった重要な人物たちを惹きつけたのですか?
VK:そうだね。平均的な開発者の標準仕様に対する反応というのは、猫に水をぶっかけたときみたいなもんだ。冗談はさておき、我々はオープンソースでプロジェクトを始めている。我々はこのプロジェクトが一般的なものでないと考えている。というのも一般的なステップをひっくり返してるんだ。まず仕様を決めて、それが正しいかどうかテストする、そして最後に、なぜ仕様がこうなったのか、又はならなかったのかという説明を考え出す。つまりソリューションを作ってしまってからそれを分解して、自分たちが「こういう仕様でやってます」という事の裏付けをとる。こういったプロセスを通して、最もいい仕様を決めるんだ。
RW:この場合ですと、開発者自身も運用や開発運用上の問題に取り組んでいる様に思えますが
VK:開発者は運用者をひどい目に合わせることもある。これはそういった問題を是正して、運用の人間が怒鳴りこんでこないようにするという取り組み事でもあるんだ。
以前の場合は、システムが処理できる以上のデータを入力しないように運用者が注意する必要があった。システム負荷が変動する中でこれを保証するのは簡単じゃない。
RW:主要なJavaの開発者をインスパイアするような例を挙げてもらえますか?
VK:エンタープライズのJava開発者にとって難しいケースとはなんだろう? もしTCP接続でオーダーが飛んできて、それを次の接続に渡す前に処理を完了しないといけない場合、出て行くデータよりも入りのデータのほうが早く片付く事を保証しないといけない。でないとOut of MemoryでJVMがハングするからね。
Web開発に例えると、何人のユーザが同時に使っていようが関係なくユーザからの入力をストリームで受け付け、それをオーバーロードさせないようAmazon S3などのサーバに保存できるか、とかになるだろうか。これが今解決しようとしている問題だ。
画像提供：Shutterstock
※本記事はReadWrite Japanからの転載です。転載元はこちら。
