BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース RSocket - SpringOneで発表された、リアクティブアプリケーションのための新たなアプリケーションネットワークプロトコル

RSocket - SpringOneで発表された、リアクティブアプリケーションのための新たなアプリケーションネットワークプロトコル

原文(投稿日:2018/10/01)へのリンク

ワシントンDCのSpringOne Platformカンファレンスで発表されたRSocketは、言語に依存しない、新たなレイヤ7アプリケーションネットワークプロトコルだ。Reactive Streamsバックプレッシャをベースとし、双方向で多重化が可能な、メッセージベースのバイナリプロトコルで、Facebook、Netify、Pivotalなどのエンジニアが開発したJavaJavaScriptC++Kotlinによる実装が公開されている。プロトコルはリアクティブスタイルのアプリケーションを意識して設計されており、基本的にノンブロッキングで、多くの場合(ただし必須ではない)非同期動作と組み合わせて使用される。サブスクライバが準備完了を示すまではパブリッシャがデータを送信できないという、リアクティブバックプレッシャの考え方を採用したことが、“非同期”とは大きく異なる点だ。

“個人的な意見として”、とCloud FoundryのJavaエクスペリエンスリーダであるBen Hale氏は言う。“リアクティブプログラミングこそが、Javaによる高効率アプリケーションの次なるフロンティアだと思います。” しかしリアクティブプログラミングには2つの大きな障害がある、と氏は言う - データアクセスとネットワークだ。R2DBCが前者の問題への対処を意図しているのに対して、RSocketは後者の問題に対処するためのものだ。

マイクロサービス形式のアプリケーションでは、通信プロトコルとしてHTTPが広く使用されている。新たにプロトコルを開発した理由として、PivotalでProject Reactorのリーダを務めるStephane Maldini氏は、HTTPがまったく別の世界のために設計されたものである点を指摘する。

私たちはiPhoneやAndroid携帯で通知を受け取っています。常に何かを要求して応答をもらっているわけではありませんし、デバイスを操作せずに複数のリプライを受け取る場合もあります。あるいはスマートウォッチを使ってバックエンドサーバとインタラクションして、統計情報を取得するようなこともします。バックエンドサーバ通信を行うスマートアシスタントもあります。このような対話モデルは、いずれも私たちが接続体験(connected experience)と呼ぶものの一部です。HTTPはこのような目的で設計されたものではありません。

Maldini氏が指摘するHTTPの重要な問題のひとつは、さまざまなエラーを再試行やタイムアウト、サーキットブレーカなどで処理する責任が、すべてクライアント側にあることだ。リアクティブアーキテクチャを使って構築されたアプリケーションは、効率性とスケーラビリティに優れているが、“リアクティブのサポートはアプリケーション境界まで”だ、とMaldani氏は主張する。

RSocketがHTTPとは違う部分のひとつは、4つのインタラクションモデルを定義していることだ。

  1. Fire-and-Forget: リクエスト/レスポンスに最適化されており、ノンクリティカルなイベントのログなど、レスポンスが不要な場合に便利である。
  2. Request/Response: HTTPとまったく同じ、ひとつのリクエスト送信に対してひとつのレスポンスを受信する場合。この場合も、非同期で多重化されている点において、HTTPに対するアドバンテージがある。
  3. Request/Stream: コレクションを返すリクエスト/レスポンスと同じ。コレクションは完了するまでクエリするのではなく、ストリームとして返される。例えば、口座番号の送信に対して、口座のトランザクションをリアルタイムで応答する。
  4. Channel: 任意のインタラクションモデルが可能な、双方向のメッセージストリーム。

メッセージベースというのは、単一のコネクション上で多重化をサポート可能であるという意味である。さらに、TCPのように完全な双方向性を持つため、クライアント側からサーバに接続すれば、双方のコネクションは等価になる - すなわち、サーバがクライアントにデータを要求することも可能だ。

RSocketはまた、メッセージ単位でのフロー制御もサポートする。基調講演では、FacebookエンジニアのSteve Gury氏が次のように説明した。

メッセージ送信時に、受信可能な応答数を指定することも可能です。サーバはその制約を守らなくてはなりません。それらの応答の処理が終了すれば、さらに要求することができます。RSocketはチェーン全体でも動作します。つまり、複数のRSocketコネクションをリンクすれば、フロー制御はエンドツーエンドで機能します。

Hale氏が後日の追加セッションで述べたように、本質的に、RSocketが解決する問題とは、プロセス間のバックプレッシャ、つまりネットワーク上のバックプレッシャである。

プロセス内で処理できる以上のデータを要求しないという保証は可能です。しかし、サービスメッシュ内の別のマイクロサービスをコールしなければならない場合はどうなるでしょうか?データ全体が具体化しないこと、すべてのデータが送信されないことを、どうやって保証すればよいのでしょう。

RScoketはトランスポート非依存であり、TCP、WebSocketAeron UDPの他、セマンティックロスのない混合トランスポートプロトコルもサポートする。いずれの場合も、バックプレッシャとフロー制御の両方が引き続き機能する。

接続の再開もサポートされている。RSocket接続の確立時に、以前の接続のIDを指定することができる。サーバがそのストリームをまだメモリ内に持っていれば、ストリームのコンシュームを再開することが可能だ。

前述の講演の中でHale氏は、プロトコルの動作方法について、さらに詳細な解説をしている。すでに述べたように、RSocketはメッセージ駆動のバイナリプロトコルである。“ネットワーク接続では一般的に、リクエスト/レスポンスのインタラクションは、個別のフレーム設置に分解されます”と氏は言う。“それぞれのフレームが、ある種のメッセージをカプセル化しているのです。” マシン間の通信への影響の大きさから、フレームにはJSONやXMLのような可読性のあるものではなく、バイナリが使用される。すべてのメッセージングプロトコルがそうであるように、ペイロードはバイト列に過ぎないので、XMLやJSONなど、任意の形式が可能である。

FacebookでRSocketが使用されている場所のひとつが、GraphQLサブスクリプションと見なされるライブクエリへの応答を担当する、LiveServerと呼ばれるサービスである。応答はデータで行われるが、将来のアップデートでストリームにも対応する予定だ。

 
 

この記事を評価

採用ステージ
スタイル
 

この記事に星をつける

おすすめ度
スタイル

BT