ISUCON7本戦惜敗記(学生枠)

問題

リアルタイム協力クッキークリッカー風味ゲーム Chair Constructer Online

roomと呼ばれる概念があり、協力してひたすら椅子を生産する部屋を作れる。 roomに入るとWebSocketでリアルタイム通信が発生する。

このゲームの処理を、4台(いずれもCPU 2Core 2.3GHz, MEM 2GB)のサーバーで捌かなければならない。

回線に関しては、参加者がアクセスするグローバル系統、サーバー間の通信とベンチマーカーの通信が流れるローカル系統がある。 それぞれの系統は同じスイッチに収容され、各々帯域制限があるので、後々それも問題になったであろうが、そこまでパフォーマンスが上がらなかった。

問題の詳細に関しては後々公開されるであろうイメージを参照されたし。

結果

学生中4位、12位(kstm)

振り返り

構成把握、ユーザの振る舞いの想定が非常に甘かった。

特にWebSocketの中身。メッセージの分布なり統計なりきちっと出せていればroom毎の分散はしなかった可能性がある。

ところが、かなり早い段階でWebSocketの負荷分散単位をroom単位と決めてしまった。 メリットとしては、roomに関する情報をサーバー間で同期性、一貫性を担保する必要がないところ。 デメリットは、1台のサーバーで支えられる以上の負荷がroomにかかっていた場合、それ以上捌けないところ。

セッション数を見たところ、 この分散方式だとセッションが集中するサーバーとそうでないサーバーが出てしまった。 数字としては、 ss -to state established あたりで監視していたが、4台中2台が暇な状態であった。

一番混み合っているサーバは90〜100セッションを捌いていたが、暇なサーバに至っては、10セッションに満たない。

アプリケーションが負荷を十分に発生できなかったという話もあるが、 私は、2年前のISUCONから人間タスクランナと、ネットワーク、インフラ担当なので、 アプリケーションのパフォーマンスが上がらなかった原因などの解説はチームメイトに譲ることにする。

参照URL