サーブレット対リアクティブ: 正しいスタックを選定する - Rossen Stoyanchev氏のQCon SF 2017でのプレゼンテーション

Rossen Stoyanchev氏、Pivotal所属のSpring Frameworkコミッタであるが、"サーブレット対リアクティブ: 正しいスタックを選定する"というプレゼンテーションをQConサンフランシスコ 2017で行った。Spring Framework 5で新しいリアクティブなwebフレームワークspring-webfluxを導入した。これは従来のサーブレットベースのwebフレームワークspring-mvcと並んで存在するものだ。Stoyanchev氏は、プレゼンテーションでこれら2つのフレームワークの実行モデルの違いと、spring-mvcではなくspring-webfluxする際の決断方法について話した。

Stoyanchev氏は言う。リアクティブプログラミングはアプリケーションに非同期性をもたらすものである、と。従来Javaでは、アプリケーションに非同期性を持ち込む際に開発者はスレッドとスレッドプールを使ってきた。しかしこのアプローチは効果的でなく、うまくスケールしない。違う言語やプラットフォームでは多くの進んだアプローチや解決策がさまざまある。

Stoyanchev氏は何かを並列にするためには多くのスレッドが必要であるというのはJavaでよくある誤解であり、実際には事実ではないと述べた。一定数の少ないスレッドでJavaの並列化を達成できる。HTTPソケットを使い、ソケットを通じてデータのチャンクをプッシュすることでできる。このメカニズムはイベントループと呼ばれ、アイデアはNode.jsで広まった。このようなアプローチはスケールでき耐障害性がある。Spring 5のspring-webfluxは非同期性の提供にイベントループを使っている。

Stoyanchev氏によると、Java 8のラムダ、これはspring-webflux作成へのモチベーションの1つであるが、ラムダが関数型プログラミングを手の届くものにしてくれ、新しいことをする可能性を生み出し、違う方法でリクエストを処理している。

Stoyanchev氏はSpring Frameworkでのspring-webfluxの導入でサーブレットベースのspring-mvcが近い将来非推奨になるわけではないと言う。spring-webfluxはspring-mvcと並ぶ選択肢と考えている。現在多くのアプリケーションがspring-mvcを使用しており、spring-webfluxに切り替える理由はとくにない。さらに、すべてのアプリケーションがspring-webfluxへのよい候補というわけでもない。

2つのフレームワークにある大きな違いはspring-mvcがスレッドプールに基づいており、一方spring-webfluxはイベントループメカニズムに基づいているということだ。両方のモデルとも@Controllerといったアノテーションを共通で使えるようサポートしている。

開発者はリモートサービスを呼び出すためにspring-mvcのコントローラからリアクティブクライアントを実行できる。spring-webfluxはTomcatやJettyといったサーブレットコンテナをサポートする。NettyやUndertowといった非サーブレットのランタイムもサポートする。

Stoyanchev氏によると、過去2009年にSpring 3.0がサーブレットAPI向けに非同期サポートを導入した。これは長時間実行プロセス向けであることを意味した。スレッドはコンテナに戻され、レスポンスはプロセスが完了するとすぐに書き込まれた。この機能によりspring-mvcベースのアプリケーションでのリアクティブクライアント実行のサポートが可能となった。

spring-webfluxではサーブレットAPIはアダプタのレイヤである。これがあることで非サーブレットコンテナに加えてサーブレットベースのコンテナに対してもサポートできる。

Stoyanchev氏はspring-webfluxではWebFilterとWebHandlerがノンブロッキングであると言う。これらのメソッドはReactorにおいてpromise型であるMono<void>を返す。Mono<void>は完了か処理失敗かについての情報を持っている。

spring-mvcはリアクティブクライアントをサポートするが、一度処理がサーブレットAPIまで到達すると処理はブロッキングモードで動作する。

結論としてStoyanchev氏はspring-mvcとspring-webfluxでの選択における注意を述べた。もし現行のアプリケーションがspring-mvcでうまく動いていてスタックの変化を求めるような問題がないなら、Stoyanchev氏はspring-mvcのままにすべきと提案している。彼はアプリケーションの依存について考えるのも良いアイデアであると提案している。もしアプリケーションにブロッキングな依存があるならおそらくspring-mvcスタックのままのほうがよい。

開発者はspring-mvcのコントローラにリアクティブクライアントを書けば、リモートサービスを呼び出したりリアクティブなデータを取り出したり、レスポンスをストリームにしたりするようなリアクティブな機能を今も活用できる。

spring-webfluxは簡単にストリームを上げ下げするようなユースケースにうまくフィットする。スケーラビリティや高性能が主要事項であるようなアプリケーションのためのものとも考えられるだろう。

Stoyanchev氏によると、spring-webfluxは必ずしもより速くなるわけではないが、スケーラビリティやハードウェアリソースの効率的な利用といった課題をよりうまく扱う。またレイテンシの問題もよりうまく扱う。