そもそも「Reactive」とは何か？
まずは参考資料をリストします。
InfoQより、「注目を集めるリアクティブプログラミング」：
※オーバービューとして
マルレク、2013年1月21日、開催テーマ「Reactiveプログラミング」、講演資料：
※「Reactive」の詳説
@okapies氏、2015年6月24日開催 JJUG 講演資料、「Reactive Streams入門」（12〜66枚目）：
※同じく「Reactive」の詳説、マルレク講演資料とは違った観点から
Typesafe社Blogより、"Modernizing Your Aging Architecture: What Every Enterprise Architect Needs To Know About Going Reactive"：
※現代のエンタープライズにおける課題と解法の認識について
「Reactive」とは、それを構成する技術要素から、次のように説明できるようです。
Reactive ＝ 並行（Concurrent） × 非同期 × イベント駆動
「Reactive」を捉えるとき、これら技術要素の組み合わせがシステムに次のような特性をもたらす、と言えることにここでは注目します。
ユーザーや他システムからのリクエストへの、処理量に対して（従来比で）高い応答性の発揮が可能となる
並行、非同期、イベント駆動を用いた設計やプログラミングスタイルを採用することが、構成コンポーネント／ロジック等の疎結合性、独立性を高めることに繋がる
エンタープライズ・システムにおける既存の二つの実行モード
ところで、エンタープライズ・システムにおける“処理（＝業務ロジック）”は、伝統的に下記二つの実行モードのいずれかであるとして設計されてきました。
o オンライン処理
・ユーザーまたは他システムからのリクエストに同期的に応答する実行モードです。
・現実的な時間内にユーザーまたは他システムへレスポンスを返す必要があるので、一回のリクエストにおける処理量は比較的少量です。
・アプリケーション要件として同期的に応答を返す必要があるような場合に、この「オンライン処理」となります。
o バッチ処理
・ユーザーまたは他システムからのad-hocな要求で実行されるが、それらリクエストに同期せずに実行される処理です。処理の終了を待たずに、リクエストに対しては「処理を開始した」旨のみを返却します。または、スケジュールによって定期実行され、“表”のオンライン処理に対して、非同期な“バックグラウンド処理”の位置付けを担います。
・処理対象たり得る条件に合致するデータのエントリーを、まとめて一括して処理しますので、一回の実行あたりの処理量は相対的に大量です。
・「バッチ処理」が求めらる要件には、次のようなものがあります：
(1) 単に処理量が多いため、オンライン処理から切り離して実行する必要がある
(2) 業務ロジックとして、業務プロセス上の異なるアクティビティに関わるものなので、設計上、保守観点上、他業務ロジック（※オンライン処理や他のバッチ処理）から分離、疎結合化しておきたい
オンライン処理とバッチ処理の応答性（＝同期の程度）を比較すると次のようになるでしょう。
|
実行モード
|
応答性（＝同期の程度）
|
|
オンライン
|
リアルタイム
（ミリ秒レベル）
|
|
バッチ
|
日〜時〜分レベル
|
既製のアプリケーション実装用フレームワークや運用ツールも、二つのいずれかの実行モード用として仕立てられているのが普通です。
こうして整理すると、既存の二つの実行モードは「秒レベル」の応答性をカバー出来ていないことに気付きます。
エンタープライズ・システムに第三の実行モードをもたらす「Reactive」
「Reactive」は、エンタープライズ・システムにおいて第三の実行モードを可能とします。
o リアクティブ処理
・ユーザーまたは他システムからのリクエストに、非同期的に応答する実行モードです。
・イベント駆動での実行が基本なので、一回の実行で処理対象となるデータは、当該イベントの発生に関わる範囲に限られます。つまり、一回の実行での処理量は、バッチ処理よりも相対的に少ないと見積もられます。一方、並行性と非同期性を利用してScale-outして、単位時間あたりの処理量としては、オンライン処理よりは多い量をこなそうという意図があります。
・結果的に、時〜分〜秒レベルの応答性（＝同期の程度）を実現します。
|
実行モード
|
応答性（＝同期の程度）
|
|
オンライン
|
リアルタイム
（ミリ秒レベル）
|
|
リアクティブ
|
“ほぼリアルタイム”
（時〜分〜秒レベル）
|
|
バッチ
|
“バックグラウンド”
（日〜時〜分レベル）
|
本記事冒頭の方で示した、「Reactive」を構成する並行、非同期、イベント駆動という技術要素の組み合わせがシステムへもたらす特性によって、リアクティブ処理は下記のような「バッチ処理が求められる要件」に答えることができます。
(1) 大量処理のため、オンライン処理に対して非同期に実行する必要がある
(2) 業務プロセス上の異なるアクティビティに関わる業務ロジックを、設計上、オンライン処理や他バッチ処理から分離、疎結合化しておきたい
つまり、リアクティブ処理を用いることで、日〜時〜分レベルのバッチ処理を、時〜分〜秒レベルで完了する処理に、それぞれリプレースすることが可能と見込まれます。システムからバッチ処理＝“バックグラウンド処理”を排し、システム全体が“ほぼリアルタイム”に処理が実施されるようなものへと刷新可能、ということです。
次のようなケースにも革新をもたらすでしょう。オンライン処理に盛り込んでおけばリアルタイムな応答性で答えることができたような処理を、バッチ処理が求められる要件の(2)に基づいてバッチ処理として構成すると、分レベルの遅延をもってレスポンスするようになってしまいます。ユーザビリティと内部設計上の保守性とのトレードオフになってしまいます。リアクティブ処理は秒レベルの“ほぼリアルタイム”を実現できるので、ユーザビリティ（応答性）をサポートしつつ、設計上の保守性も担保できます。
「リアクティブ処理」では、業務のプロセスもコードに記述されることとなる
もう一つリアクティブ処理の利点があります。リアクティブ処理は、基本的にイベント駆動処理系として実装されるので、各処理が、どういった業務上のタイミング（＝特定の状態となった、というイベント）で実行されるのか、コードに明確に記述されることになります。既存のバッチ処理の多くはスケジューラーによる定期実行だったり、あるいはジョブとしての実行順序制御はあったとしても、データ処理の内容についての依存性が明確なわけではありません。データ処理の依存関係を取り違った順序でジョブを実行して、結果的に期待の処理が遂行されなかった、といったミスもまま起きます。バッチ処理系をリアクティブ処理系に置換することで、業務プロセスの“コード化”が進み、運用に頼る範囲を削減できることが期待されます。
「リアクティブ処理」を実現するためのミドルウエア（候補）
とりあえず列挙のみ。
- RxJava
- Asakusa Framework
- Apache Spark
- Amazon Lambda
◆以上
