20年で1秒も止まらない実績から得たインスピレーション　リアクティブ原則とアクターモデルの強さで障害波及を抑制　

“リアクティブシステム”と“リアクティブプログラミング”

加藤潤一氏（以下、加藤）：「リアクティブシステムと、リアクティブプログラミングって同じですか？」みたいな話をよく聞きますが、同じ概念ではありません。

リアクティブプログラミングと聞くと、イメージするのがReactiveX。RxJSとかRxJava、アクターモデルやAkka、Erlangなどいろいろありますが。あと、もっとプリミティブなところでいくと、PromiseやFutureなどもリアクティブプログラミングの道具として、よく使われます。

これはリアクティブシステムと等価ではありません。リアクティブシステムは、アーキテクチャレベルでリアクティブ原則を適用します。その実現手段として、もちろんリアクティブプログラミングは使われます。ここはちょっと混乱しがちです。

そのツールを使ったからといって、自動的にリアクティブシステムにはなりません。例えばアプリケーション1ノードだけでデプロイして運用していて、そのノードが故障したら、全システムを失います。これだと、いくらリアクティブプログラミングのツールを使っていても回復力がないので、リアクティブシステムにはなりません。

AkkaなどのRx系を使って「リアクティブシステムだよ」って言っていても「リアクティブシステムじゃないじゃん」みたいな話になってしまうので、ここは混同しないようにしたほうがいいです。

リアクティブ原則

LightbendのCEOによって「リアクティブ原則」というものが発表されましたが、もうちょっと特徴的なところを話したいと思って。全部話すと大変なので、失敗を受け入れるとか、自律性を表明するという部分で説明していきたいと思います。

失敗を受け入れる。物事がうまくいかないことを期待し、回復力のために構築するというような説明がされていますが、もともとこのリアクティブ原則の前からBulkheadingという言葉があちこちで使われていて。最近だとAWSのSA（ソリューションアーキテクト）さんが書かれているスライドなどにも“Bulkhead”という言葉がけっこう出てきます。

これは何かというと船舶由来の用語で、大型貨物船の船倉、船の中の倉庫みたいなイメージです。これは、『Reactive Design Patterns』という本の中で紹介されている図のように、隔壁によって多くの区画に分割されている。

船底がなんらかの原因で破損した場合でも、影響を受けた区画だけが浸水し、ほかの区画は適切に密閉された状態を維持できるため、その船自体は浮力を保っているので沈没しない、みたいな話です。「タイタニックは沈没したやん」という話がありますが、あれは諸説ありますが、別の要因だったという説もあって。こういった区画がなされていて、1つ穴が開いたからといって一気に船が沈むことがないように、Bulkheadingされているような考え方があります。

アクターモデルの考え方と構造

アクターモデルでも同じような考え方があります。Akkaをずっと使い続けている話をしていましたが、Chatworkの中でもアクターモデルはわりと使われています。

（スライドの）右の図はアクターで作られた1つのアプリケーションだと思ってもらって。右上の頂点の3つはアクターシステム側です。ユーザーという階層の下に青い部分で書いているのはすべて1個1個個別のアクターで、ヒエラルキーになっています。中間に位置する、ブランチと言っていいのかわかりませんが、ブランチ的な位置にあるアクターは、子どものアクターをもっているので、すべてスーパーバイザーになっています。中間管理職的なポジションです。

スーパーバイザーであるコンポーネント、Akkaだとアクターになりますが、簡単に故障するような仕事をしてはいけないと言われていて、失敗しやすい仕事はヒエラルキーの下層の専門のコンポーネントに任せます。この図でいうと、一番下の末端はネットワークのI/O・ディスクのI/Oがやったり。I/Oは失敗がつきものなので、そういった仕事は下層に任せます。

このような構造を採用することで、障害が発生しても全体に波及することを抑制できます。上はコントロールや意思決定をしているので、そこが故障するのは確率的には低く、I/Oをやっているところが故障しやすい。

障害発生時はスーパーバイザーに判断を委任します。その指示に従ってコンポーネントを再起動して復旧する考え方があります。この図の赤い部分が故障しても、b1とかに「故障したんだけど」と通知がいって、「じゃあお前は再起動しろ」「停止しろ」を言われて。再起動ベースが基本なので、再起動されます。

コールスタックが登っていって、誰もキャッチしていなかったらプロセスが落ちることはよくあると思いますが、アクターの場合、例外的な状況がエスカレーションすることはありますが、基本的には局所化されているので、異常な部分だけが隔離されて回復することを繰り返します。

Unixプロセス、JVMのプロセスとしてはほとんど再起動しない。部分的なアクターのプロセス、軽量プロセスだけが入れ替わるようなことを継続できるので、特にJVMみたいにJITのプロファイルなどをもっていて、簡単に再起動ができないものだと、こういった考え方がすごく有効に働くところがあります。

なぜアクターモデルなのか

なぜアクターモデルなのかは、障害に強いということと、あと非同期・ノンブロッキングであったり、位置透過性とかがありますが、過去の歴史を見ると、発端はErlangです。

今だとErlangとかElixerがそのアクターモデルを使えるわけですが、過去に電話交換機で使われていたことがあって、稼働率が99.9999999パーセント。かなりの稼働率を誇っていますが、たしか20年で1秒未満も止まらない実績があったり、WhatsAppでもC10Kと呼ばれる問題です。1台のサーバで100万クライアント捌いたとか。

そういった実績があり、AkkaなどはLightbend社のCTOのJonasさんが、Erlangからインスピレーションを受けて開発した。Erlangの2倍のスループットを発揮したりと、JVM上でもこういった利点を活かしたシステム開発ができるようになってきました。

ScalaやErlangはマルチコア危機と言われていた時期に生まれたプログラミング言語で、苦行と言われるマルチスレッドプログラミングを取り除いてくれるようなことを期待されて生まれてきました。

ChatworkのAkka導入

ChatworkのAkkaの導入はかなりいろいろなところで進んでいます。本当に濃淡がありますが、最初はメッセージデータベースと書かれているところです。NTTデータさまにも協力してもらって、CQRS、イベントソーシングのシステム、Kubernetesをちょうど最初に導入した時期です。AkkaとHBaseとKafkaを使って構築して、今も運用が続いています。ほかにもマイクロサービスでAkkaを積極的に採用しています。

この青い部分が、アーキテクチャ刷新プロジェクトでもAkkaを採用しているところです。真ん中のコアアプリケーションだけがすっぽり残っていて、これはPHPの部分ということになりますが、ここの本丸の部分にも手を入れていこうというのが、アーキテクチャ刷新のプロジェクトです。

（次回につづく）