Chatwork、LINE、Netflixが進めるリアクティブシステムとは？ メリットは？ 実現するためのライブラリは？：リアクティブプログラミング超入門（1）（1/2 ページ）
本連載では、リアクティブプログラミング（RP）の概要や、それに関連する技術、RPでアプリを作成するための手法について解説します。初回は、「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します。
「リアクティブ」という新たなプログラミングのパラダイム
最近、「リアクティブプログラミング」という言葉をよく見るようになりました。この「リアクティブプログラミング」（以下、RP）とは、“時間とともに変化していくデータ”（ストリーム）同士の関連性と操作を、“宣言”的に記述するプログラミングの手法です。
RPではデータを「ストリーム」として捉え、その“流れてくるデータ”を受け取ったタイミングで、操作を行います。ストリームにはユーザーの入力やネットワーク通信、キャッシュやファイル入出力など、さまざまなものがあります
操作が必要なデータを自分で取得して処理せず、ストリームから送られてきたデータに反応して処理するので、「リアクティブ」と呼ばれます。
RPを説明するための例としてよく挙げられるのが、Excelなどの表計算アプリケーションです。
上の画像ではC2のセルに関数を定義（宣言）し、A2セルとA3セルに入力した値を自動で足し算しています。A2セルやA3セルの値が変更されると自動的にC2セルが再計算されます。これが、「“時間とともに変化していくデータ”同士の関連性と操作を宣言的に記述するプログラミング」です。
ExcelのようなGUIでは、データが変わったときにユーザーインタフェース（以下、UI）の更新が実行されます。このときの処理が重要で、RPでは「イベント」（ここでは、A2セルとA3セルへの入力）や「変化する可能性があるデータ同士の関連性」（ここでは、A2セルとA3セルの足し算）の宣言により、「一方の値（ここでは、A2セルまたはA3セル）の変化を他の値（ここでは、C2セル）へ自動的に通知する」という処理フローになります。こうすることで、コーディング（Excelでいえば、VBA）において複雑になることが多い、インタラクションなデータのやりとりをシンプルに行えます。
本連載では、RPの概要や、それに関連する技術、RPでアプリケーションを作成するための手法、RPプラットフォームである「Lightbend Reactive Platform」の使い方などを、数回にわたって解説します。
RPはどのようなアプリケーションで使われているのか
一般的に、RPは以下のようなケースで使用することがよいとされています。
- GUIでの入出力処理
- 時間とともに状態が変化する処理
- 非同期通信処理
最近は大規模なサービスでもリアクティブシステムが増えてきています。実際に、どのようなアプリケーション（システム）がRPを採用しているのか見てみましょう。
Chatwork
Chatworkでは、AkkaのActorシステムを使用してメッセージ駆動を実現し（※後述）、リアクティブなシステムを構築しています。
CA ProFit-X
スマートデバイス向けの広告管理プラットフォームであるCA ProFit-Xもリアクティブなシステムで構築されています。このプロダクトではAkkaとAkka Streamを使用して、多数のメッセージを並列に効率よく処理しています。
LINE
LINEでは、既に多くのサービスを「マイクロサービス」として構築しています。以前は各サービスの通信ではHTTPによるRPCやJavaのThreadプログラミングを使用していましたが、現在はActor Modelによる並行処理やAMQPを使用した非同期通信を採用しています。
補足「マイクロサービスとは」
システムを複数の小さなサービスの集団として構築し、各サービス同士をRESTなどのシンプルな方法で連携するアーキテクチャです。一般的に、マイクロサービスを用いることで「システムが簡素化し、変化に強くなる」といわれています。
なぜRPが使われつつあるのか
近年、なぜRPがいろいろなところで採用されてきているのでしょうか。
RPを使用するメリットは、アプリケーションが以下のような特長を持つようになることです。
- モジュール性（Modularity）が高くなる
- 状態管理の自動化が容易になる
プログラミング的な視点でいえば、RPを用いることでデータ管理（状態の管理）が自動で行われるため、「振る舞い間の関係性だけを定義しておけばよい」というメリットがあります。
また、「リアクティブ」という言葉はシステム全体に使われることもあります。その場合は「リアクティブシステム」と呼ばれますが、これはユーザーに対して、どんなときでも（たとえ高負荷時や障害時でも）迅速にレスポンスを返すことができるシステムです。詳細は後述します。
リアクティブ関連用語の解説
ひと言で「リアクティブ」といっても、いろいろなリアクティブ関連の用語が存在します。ここからは、リアクティブに関連する幾つかの用語について簡単に整理します。
リアクティブ宣言
「リアクティブ宣言（The Reactive Manifesto）」とは、リアクティブシステムの概念や論理構成、実現したい価値やそのために必要な特性などについて定義しています。また、この宣言に賛同する人は署名を行うことも可能です。
リアクティブシステム
先ほどのリアクティブ宣言において、「リアクティブシステムとは、即応性、耐障害性、弾力性、メッセージ駆動を備えているシステム」と定義されています。
◆即応性（responsibility）
ユーザーの要求に対し、一貫して素早くレスポンスを返すことができる特性です。即応性に対応するためにアプリケーションでは並列処理を用いることもあります。
◆耐障害性（Resilient）
部分的にシステム障害が発生した場合でも、サービスへの影響を与えずに復旧させることができる特性です。障害発生を防ぐという意味ではなく、障害発生後にそれを回復させることが重要になります。
◆伸縮性・弾力性（Scalability／Elastic）
リアクティブシステムでは、どんな負荷状態でも高いレスポンス性を維持する必要があります。たとえ一時的に高負荷状態となっても問題なく即応性を保てるように、下記のような仕組みを持つ必要があります。
- 負荷を監視してシステムの状態を把握する
- 状況に応じてシステムリソースを増加、減少させる
- システムリソースのスケールに依存せず処理を分散、実行させる
- コンポーネント同士を疎結合にし、ボトルネックを持たないようにする
◆メッセージ駆動（Message Driven）
リアクティブシステムが実現したい価値は、システムの即応性を保持し続けることです。そのためには耐障害性、伸縮性・弾力性が必要です。そして、その特性を実現するのが、メッセージ駆動のアーキテクチャです。
このアーキテクチャは、各コンポーネント間をメッセージでやりとりします。また、メッセージはコンポーネント間通信を非同期で行います。
メッセージを送信したコンポーネントは結果を待たずに次の処理を実行できるので、効率良く処理が可能で、コンポーネント間の疎結合化にもつながります。また、メッセージ駆動かつ非同期で処理を行うことでハードウェアのリソースを効率良く使えるようになります。
リアクティブプログラミング（RP）
本稿の冒頭で、「RPとは“時間とともに変化していくデータ”同士の関連性と操作を宣言的に記述するプログラミングの手法」と述べました。これは、前項の「リアクティブシステム」を作る上で必要になるプログラミング手法です。前項の説明でも何度か出てきたように、リアクティブシステムを構築する上では「非同期」が必須で「並列処理」が求められることもあります。
関数型リアクティブプログラミング（FRP）
そのRPに関数型プログラミングの要素を加えたものを「関数型リアクティブプログラミング（Functional Reactive Programming）」（以下、FRP）と言います。FRPの特徴は、振る舞い（behavior）とイベントストリームを使用して処理を行うことです。
詳細は下記などを参考にしてください。
- 「Functional Reactive Programming（Wikipedia）」
- 「Functional Reactive Animation（Conal Elliott and Paul Hudak）」
- 「やさしいFunctional reactive programming（概要編）（maoeのブログ）」
React（JavaScriptライブラリ）
「React」はFacebookが公開している、UIを効率的に構築することを目的としたWebフロントエンドフレームワーク（JavaScriptライブラリ）です。詳細は「いまさら聞けないReact、Virtual DOM、JSX超入門 - ＠IT」を参照してください。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
Java EE 8/9はマイクロサービス、リアクティブに向かう――MVCは生き残れるのか
デジタルトランスフォーメーション時代に生き残れるエンジニアに求められるものとは何か。長らく、日本のJavaコミュニティで存在感を示し続け、現在は日本マイクロソフトでJavaエバンジェリストとして活動する寺田佳央氏に聞いた。
EJB、SOA、マイクロサービスへと至る大規模システム向けアーキテクチャの変遷
2000年前後からのアプリケーションアーキテクチャやEJB、SOAに触れながら、今後、大規模システム構築で主流になるであろう「マイクロサービス」アーキテクチャの意義と価値を考える。