Martin Thompson氏がGoto Aarhus 2014でリアクティブマニュフェストの第2版を発表した。この新しいバージョンは最初のバージョンと名前やアプローチにわずかな違いがある。InfoQは氏にインタビューをし、今回の変更の意味とリアクティブコミュニティの将来について議論した。サンフランシスコで開催されたReact 2014カンファレンスは、リアクティブマニュフェストとその意味するところを探求し、リアクティブを実践している開発者が知見を共有するための場だ。
InfoQ: リアクティブマニュフェストは開発者コミュニティに受け入れられました。なぜ書き換える必要があったのでしょうか。
Martin:初版のリリース後、大量のフィードバックを頂きました。多くはポジティブなものでした。多くの開発者がアプリケーション開発の環境の変化を察知し始めていたのです。しかし、冗長であり、細部への焦点の当て方がバランスを欠いているという意見ももらいました。そこで、私たちはリアクティブシステムが持つべき属性により正確に焦点を当てたものに書き換えることにしました。"もっと時間があったなら、もっと短い手紙を書いただろう..."という言葉が当てはまります。幅広く頂いたフィードバックが焦点を絞り込むのに役に立ちました。
InfoQ: なぜ今なのでしょう。
Martin: この点についてはKresten Krab Thorupのような人がマニュフェストの中で主張しています。彼は自身の経験と他の人々が目撃していることを引き合いにして、多くの組織にとって今、インターネットが主要な、場合によっては唯一のマーケットとのチャンネルになっている世界にいるということを強調します。そして、このような環境とマルチコアのクラウドの世界の中で変化するプラットフォームを重ね合わせます。
InfoQ: マニュフェストの構造自体も変わりましたか。新しい版は叙述的ではなく規範的な書き方なのでしょうか。
Martin: マニュフェストは、なぜ今システムアーキテクチャに新しいアプローチが必要なのか、そして、新しいアプローチに必要な属性にだけ焦点を絞るのがいいと思いました。書き換え作業の一部として、リアクティブシステムの属性と性質について叙述したいと思いました。応答的であり、弾力があり、回復力があることがリアクティブシステムの主要な属性ですが、これらの属性はメッセージ駆動によって実現できます。他方どのようにこの属性を実現するのかについて、マニュフェストの中で規範的に言及するのは避けたいと思いました。実現については付録や幅広い議論の中で定時できればいいと思ったのです。
InfoQ: イベント駆動に対するメッセージ駆動には微妙な含意があると思いますが、リアクティブシステムに対する考え方を広げると思います。なぜ概念の名前をメッセージ駆動に変えたのですか。
Martin: おっしゃるとおり意味するところは微妙なものですが、とても重要です。つまり、コンポーネントの通信の仕方が重要なのです。イベントは重要なドメイン概念です。直接関数呼び出しに渡されたり、符号化されてメッセージに変換されたりします。イベントはメッセージを通じて通信するべき唯一の概念だと思います。他の3つの属性を達成するためには、非同期のバイナリ境界が必要だという点を強調したいと思いました。言語、ロケーション、並列モデルを疎結合にする境界です。分離の基礎的なレベルの話です。この境界を使って分離を実現することで、境界内で障害を扱うことができます。例外は境界を越えません。エラーはコンポーネント間をメッセージとして行き来し、ファーストクラスのコンポーネントとして扱われます。コンポーネントから応答を取得できなかった場合、障害が発生していると疑わざるを得ません。メモリはコンポーネント間で共有されません。共有される可変状態は競合の主要な要因であり、マルチコアの世界ではスケーリングの障害になります。通信のためにメモリを共有するのではなく、メモリを共有するために通信する設計に移行する必要があります。コンポーネントを分離することで競合を排除し、バッチ処理によって高コストを段階的に清算し、共有状態がない方法でマルチコア、クラウドの世界でスケーリングできるようにします。稼働時間100%を達成するには、ホットアップグレードができる必要があります。ホットアップグレードの中核要素は冗長なコンポーネント間でバージョンをエンコードしたメッセージをやり取りする機構です。
InfoQ:弾力性があることと拡張可能であることも正確には同義ではありません。両者の違いは、実装をする上で多くの解釈を生み出すと思います。拡張性では説明できないサービスの弾力性とはどのようなものなのでしょうか。
Martin: ほとんどの人は拡張性は拡大していくことと捉えています。しかし、ビジネスがコストを抑制するためには、縮小することも同じように重要なのです。私の小売業や観光業の顧客は繁忙期とそうでない時では、必要なリソースが3倍も違います。リソース量を繁忙期に合わせて保持するのは、無駄なことです。システムを設計して、拡大と縮小ができるようにする場合、私の場合は、結果として拡大のほうがうまくいきます。単純であることが重要であるという考えが大事だと習っていれば、そうなるでしょう。しかし、縮小することもシステムが障害に対処するための方法です。コンポーネントを除去することで、残りのシステムが負荷を処理するようになります。クラウドからリソースを簡単に確保できる世界では、弾力性という言葉のほうが状況を良く説明しているように思います。
InfoQ: その他のふたつの概念については変えませんでしたね。どうしてですか。
Martin: 応答的であることと回復力があることは、的を得た言葉であり、リアクティブシステムの属性をしっかり説明していると思います。回復力については先ほど述べたとおりです。先週、Extemporeというプログラミング言語のデモを見ました。人間とインタラクションできる3Dの壁のデモです。ビジュアライゼーションは素晴らしく、リアルタイムで人間のタッチに反応します。このようなシステムがあるのですから、単純なウェブページを表示するために数秒もかかってしまうサイトも変わらざるを得ません。性能を考慮する必要なないという開発者の言い訳は多くのアプリケーションで通用しなくなりつつあります。私たちにはもっと顧客でできることがあります。私の仕事は性能の限界を押し上げる企業とより効率的になり運用コストの大幅削減を実現できる顧客に分かれています。運用効率を追求するというトレンドは続くでしょう。IoTの時代も始まっていますから。
InfoQ: 一番重要な概念はあるのでしょうか。
Martin: リアクティブの属性はサービス要件の質と考えることができます。すべてのシステムは独自の要件を持っています。それらの要件は設計として取り込まれる必要があります。しかし、リアクティブの属性はそれらの要件よりも改造するのが難しいのです。
InfoQ: サービスをリアクティブにするのに必要なアプローチに順番はあるのでしょうか。
Martin: 私は顧客を助けるときにふたつのやり方があります。新しいシステムの開発かマイグレーションかです。チームが良いなら完全な再開発のほうが簡単です。しかし、そのようなチームを皆が抱えているとは限りませんし、再開発に気の進まない人もいます。システムの境界を特定し、非同期バイナリ境界で分離するのが良いでしょう。そうすることでコンポーネント毎に進化させることができます。これらのコンポーネントには既存のシステムと統合するために腐敗防止レイヤが必要です。最初のステップを進めたら、後は最適なコンポーネントのサイズが見つかるまで再帰的に進めます。リアクティブシステムと聞くと多くの人はメッセージングキューシステムが必要だと考えます。しかし、そうではありません。どんな通信の仕組みであれ、非同期バイナリ境界を提供するものであれば効率的です。それが、メッセージングシステムかもしれませんし、ウェブソケットかもしれません。または、RESTで実現した非同期プロトコルでもかまいません。リアクティブシステムを構築するためにできることはたくさんあります。実際、ファイナンスの世界では事例が豊富です。Erlang、Akka、Goやさまざまなイベント処理製品を使うのもいいでしょう。リアクティブシステムは新しいものではありません。例えば、Tandemは10年前にすでにリアクティブの属性を実現していました。将来、大きく成長する分野だと思います。JEEやRailsのようなアプローチは現在のサービスのニーズにはそぐわないということが明らかになりつつあるからです。
InfoQ:このモデルはサービスではなくシステムに拡張できるのでしょうか。それとも、リアクティブなサービスのシステムを構築するためのものでしょうか。
Martin: このモデルはコンポーネントやサービスで構成するシステムで、メッセージング駆動の高品質なサービスを応答的で回復力があり弾力性があるように、構築するのに一番向いています。マイクロサービスアーキテクチャへ移行するにつれ、これらの属性は重要になります。共有リソースで競合が起きたら、結合が強く不安定だということです。同期呼び出しはこの環境ではプログラミングの麻薬です。最初の進捗は良いですが、次第に厄介になります。拡張性がなく、不安定なために性能と開発の柔軟さが確保できないからです。気づいたときには手遅れです。私たちにはリアクティブの属性が必要であり、メッセージのやり取りのためのプロトコルを使う必要があります。プロトコルを考慮しなければ、マイクロサービスの世界は調整地獄になります。新しいことではないのです。多くの領域でこれらのパターンは、既に明らかにされており、再発見されています。通信事業者や金融、オンラインゲーム、大規模なソーシャルネットワークなどでは同じような設計パターンが網羅されています。私たちの産業には新し物好きだらけで、ギーグは十分にはいません。私たちは過去を振り返り、過去の素晴らしい礎の上にに、並列分散システムの先進的な実践者が、実践していく必要があります。この分野についての素晴らしい仕事を取り上げるカンファレンスを開催しています。今年の始めにはロンドンでReact Confを開催しました。このカンファレンスでは、Joe Armstrong氏がErlangの開発について話してくれました。11月にはサンフランシスコで開催するつもりです。Leslie Lamport氏、Pat Helland氏といった素晴らしい面々が講演者として参加してくれます。彼らの経験の上に私たちの実践を積み上げる必要があります。ニュートンやアインシュタインの実績を無視したら現在の物理学はどうなるでしょう。
InfoQ: 新し物好きがギーグの世界へ進むにはどうしたらいいでしょうか。
Martin: 素晴らしい質問です。よく尋ねられるんですよ。リアクティブマニュフェストの中心には過去の素晴らしい仕事に注意を向けることがあります。これまで以上に過去に目を向けるべきです。過去に目を向けるためにカンファレンスを開催しました。Roland Kuhn 氏やJamie Allen氏のように書籍を執筆することで過去に光を当てる人たちもいます。ErlangやTandemのような既存の手法に学ぶのは価値あることです。Akka、Go、Rust、Elixirのような新しいアプローチにももちろん価値はあります。根本的には、これらのアプローチの基底には、バイナリ境界を分離のために提供し、応答的で回復力があり、弾力があるという属性を実現する、メッセージ通信の仕組みがあります。このトピックについてはガイダンスを提供してくれる素晴らしいペーパーがあります。残念ながら簡単に要約できるようなものではありません。私たちがもっと参照しやすくする必要があります。
InfoQ: ありがとうございました。
Martin: こちらこそ。
氏のブログMechanical Sympathyには、リアクティブシステムやその他のシステムに関連する設計や性能について書いてある。