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から人間タスクランナと、ネットワーク、インフラ担当なので、 アプリケーションのパフォーマンスが上がらなかった原因などの解説はチームメイトに譲ることにする。