
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
加藤潤一氏(以下、加藤):「リアクティブシステムと、リアクティブプログラミングって同じですか?」みたいな話をよく聞きますが、同じ概念ではありません。
リアクティブプログラミングと聞くと、イメージするのが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の導入はかなりいろいろなところで進んでいます。本当に濃淡がありますが、最初はメッセージデータベースと書かれているところです。NTTデータさまにも協力してもらって、CQRS、イベントソーシングのシステム、Kubernetesをちょうど最初に導入した時期です。AkkaとHBaseとKafkaを使って構築して、今も運用が続いています。ほかにもマイクロサービスでAkkaを積極的に採用しています。
この青い部分が、アーキテクチャ刷新プロジェクトでもAkkaを採用しているところです。真ん中のコアアプリケーションだけがすっぽり残っていて、これはPHPの部分ということになりますが、ここの本丸の部分にも手を入れていこうというのが、アーキテクチャ刷新のプロジェクトです。
(次回につづく)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10