質問: Node.jsについて以前以下の質問をさせていただいた際に > > 将棋のようなターン性ゲームのサーバーをNode.jsで構築する際に > > サーバープログラムを更新したいときに、現在ゲーム中のプレイヤーの処理を中断せず更新したい。 > > > 以下の回答を頂きました。 ``` Node.jsはWebSocketのパイオニア的な存在なので、 凄まじいパフォーマンスを出しそうに見えますが、 コヤツは実は1台のマシンで1万の同時接続を捌けません。 1サーバに同時接続出来る人数を5000人とかに絞って、 縦割りで実装すれば今回の質問のような所まで問題を持っていけると思います。 ですが、そもそも別方向で考えれば質問文の疑問も一発解決出来る妙案があります。 フロントで動くWebSocketのAサーバはロジック部分を持たず、 ユーザとの通信のみに集中します。 つまり、本質問で懸念しているロジックを更新するためにプロセスを落としたら接続どうするねん問題から逃げます。 そしてサーバーサイドにもう一台、WebサーバもしくはWebSocketサーバを立ち上げます。 これをBサーバと名付けます。 Bサーバはロジック部分を受け持ちます。 ゲームの進行状況、対戦者の情報、スコア...といった状態も持たせておきます。 Aサーバからの接続を待ち受けて、リクエスト通りにゲームを進行させ、結果をAサーバに返します。 AサーバはBサーバにお伺いを建てながらプレイヤー達に結果を返します。 つまり、Bサーバはフロントからアクセス出来ないようにしつつ、1台サーバを噛ませる事でフロントからの接続を切らせずにバックエンドを更新する事が可能になるでしょう。 この場合、ゲームのアップデートの為にBサーバを落とすとなると、 プレイ中のデータが全て消えてしまいます。 なので極力Bサーバの変数領域やメモリ空間等にゲームのデータを持たせてはいけません。 RedisやMySQL等のデータベースに持たせるような作りにしましょう。 後はAサーバ→Bサーバへお伺いを立てるリクエストが失敗したら、 再度通信するような仕組みを作っておけばBサーバは更新し放題になるでしょう。 ``` 上記の回答を図にすると ``` [サーバー]-[フロント] ``` ではなく ``` [Bサーバー]-[Aサーバー]-[フロント] ``` とサーバーを噛ませることで、Bサーバーを更新してもフロントからの接続を切らないことが可能と理解しました。 しかし実際の通信量で考えると、毎回Aサーバー⇒Bサーバーに通信するため [1]と[2]で通信料は変わらないと思うのですが [2]の方法だと1万の同時接続は可能になるのでしょうか。
回答: > > [1]と[2]で通信料は変わらないと思うのですが > > > データ量は変わらないかもしれませんが、通信**数**は大きく違ってきます。 「1万ユーザーに1つずつデータを送る」より「1つの接続で1万のデータを送る」ほうが、負荷は圧倒的に軽いです。