websocketとイミュータブルインフラ、難しい話

しいたけ @yuroyoro

「もしSocket.IOを複数Nodeでスケールしたいなら、LBでSticky Sessionせよ」と書いてあるが、ｲﾑｰﾀﾎﾞｰｲﾝﾌﾗの昨今、front-endをSticky Sessionでバランシングするのどうなん?

Yosuke Furukawa @yosuke_furukawa

@yuroyoro すごく面白い指摘だと思っていて、websocketみたいなステートフルガリガリな奴はイミュータブルインフラと相性が悪いと思うので、今のところスッキリした解決策はないですね。

Yosuke Furukawa @yosuke_furukawa

逆に言えばイミュータブルインフラでステートフルなサーバーの扱い方が整ってくるのであればWebSocketとイミュータブルインフラの相性は見直される可能性ありそう。

Jxck @Jxck_

@yosuke_furukawa @yuroyoro ステート is 何で、例えば Socket.IO なら HTTP の Cookie 共有はできるし、どうせそれは裏のセッションストレージなどで共有されているはず。 cont

Jxck @Jxck_

@yosuke_furukawa @yuroyoro コネクションについては切れる、けど WS はいつか切れる前提で作らないと使い物にならないと思う。そうでなくても切れるから。 cont

Jxck @Jxck_

@yosuke_furukawa @yuroyoro あと、俺たちが WS だと思って使ってたものは Socket.IO さんからみたら XHR LongPooling だった、なんだってー！な時代はもう少し続くのかなとも思うなどなど。難しいですね。

しいたけ @yuroyoro

@Jxck_ @yosuke_furukawa sticky session、serverがdownしたserverにしばらく振られ続けたり、うっかり期待するステートを持たないserverにfallbackされたりで辛い思い出であるので…

Yosuke Furukawa @yosuke_furukawa

@Jxck_ @yuroyoro コネクションはいつか切れる前提でサーバーは作らないといけないのはその通りでその切れる条件を満たさずにばっさりとblue-green deploymentってやってしまうと cont

Yosuke Furukawa @yosuke_furukawa

@Jxck_ @yuroyoro サーバーのメモリ中にあるデータ(ゲームプレイ中のデータ等cookieとかに入りきらないデータ)が消えてしまうなど問題が多そうなので 気を遣わないといけなくて、cont

Yosuke Furukawa @yosuke_furukawa

@Jxck_ @yuroyoro guilleが紹介しているやり方は一番シンプルな例を一例として用意しているだけだと思うので、イミュータブルインフラと組み合わせるならもっと工夫を入れないといけないと感じてます。まぁ難しいですね。。

Takuto Wada @t_wada

@yosuke_furukawa @Jxck_ @yuroyoro これは良スレ

Jxck @Jxck_

@yosuke_furukawa @yuroyoro まあ鉄板は Redis 後ろに立てて pub/sub でしょうけど、 socket.io-redis もちゃんとメンテされていくような雰囲気なので、そこは安心ですね。あとは、 MQTT が気になって気になって震える。

しいたけ @yuroyoro

@yosuke_furukawa @Jxck_ websocketに限らず、一般的なアプリケーションでも特定サーバのメモリにだけ状態があるアーキテクチャは耐障害性の観点から危険だと思うのですが、sticky sessionはその事に対しての免罪符になり得るので cont

しいたけ @yuroyoro

@yosuke_furukawa @Jxck_ 、そもそも使わない前提がいいと思うんですよね。ただリアルタイム性を要求されるゲーム等だと、たとえbackendになんらかのstorageを立ててレプリケーションさせても遅延が気になったりしそうですし……。難かしい…

Jxck @Jxck_

@yuroyoro @yosuke_furukawa そもそも使わないといかんともしがたい人が、泣く泣く導入するくらいの敷居が本当なのかもとは常々思います。要件が緩ければ別ですが、クリティカルなところはまだまだノウハウ足りてない感じはしますね。