はじめに
Streamerioアドベントカレンダー二日目です!
時間が大分ギリギリのタイミングで書き始めていますが、少し焦りつつ気楽にやっていきます!
(昨日の記事はこちら! Streamerioってどんなゲーム?)
筆者は記事を書き慣れていないので読みづらい部分も度々あるかと思われます。
気になる点があれば、コメントやフィードバックをいただけると嬉しいです。
また今回工夫点と書き紹介している内容ですが、経験のあるエンジニアの方なら当たり前だよと感じる内容かもしれません。お手柔らかにみていただけると幸いです。
今日の題目は「同時接続300人に耐える技術!フロント編!」ということで、まずほんとに300人耐えるのかというところから動画を見せて行こうかなと思います。
はい、こちらです。
実際に人を300人集めるのは僕の影響力じゃ全然簡単ではないので、ローカルからk6で300のBotを立てるという方式にしています。
それらのBotはあくまでプログラムで動きますが、人とあまり変わらないかなと思っています。
フロントの工夫点1
折角なので昨日の記事でお見せした技育展でのデモのときのサーバーの状態を確認しながらお話します。
まず、今回視聴者が押した回数について全部DBに記録を取っていたのでそちらのサマリを見せます。
びっくりするくらい敵のボタンを押した人が多く、実際にプレイしていた僕は少し悲しくなりました。絶対に許しませんからね!!
さて、冗談はおいておき、サマリについてですが、大体2分行かない程度デモを行っていた気がするのでここにでている合計が約4万程度なので秒数で割ると単純計算で秒間300~400程度ボタンが押されていた計算になります。
みてわかると思いますがあれ、あんまりだなと思われると思います。
これで大体秒間100行かない程度ですね。
ここに乖離があることにフロントの工夫点があります。
実はフロントからのボタン押されたタイミングでのリクエストは押すたびに走っているわけではなく、1.5秒間Web上でカウントが取られた後、まとめて送るという方式を取っています。
これにより、毎秒400リクエストが飛ぶ訳ではなく、同時接続者数/1.5のリクエストしか飛ばなくなり、多少サーバーに余裕がでるという感じです。
単純なことですし、他でもよくあることなのかもしれませんが思いついたときこれだ!っとなったので採用した次第です。
またリクエストを送った際のレスポンスに視聴者数なども返しているのですが、1.5秒間隔しか送られないためリアルタイム性が感じられないなとなったのでそこは前回までの差分を計算しつつ多少の予測をいれた値も使ってアニメーションを行いわかりづらくするということを行いました。
フロントの工夫点2
お次の工夫点ですが、これは簡単に紹介します。
昨日話した内容でリザルトで名前とともに自分の押した結果などが画面に表示されるというのがあったかと思われます。
今回そこの実装にあたり、毎回のリクエストを誰が送っているかというのを識別する必要がありました。
ですので、今回は初回アクセスのタイミングでサーバーに視聴者IDの発行をお願いし、DBの保存とともにULIDを払い出すということを行いました。
発行されたIDをcookieに保存し、リクエストとともに送ることで特定をするという塩梅です。
自分の中でユーザーの識別には認証認可を使うという意識はあったのですが、今回のアプリを作るにあたってセンシティブな情報を持つわけでもなく、視聴者的にもすぐ使いたいからそんな面倒なことしたくないとなりそうだなと思い解決策を悩んだところこちらを思いついたので採用しました。
以上となります。
まとめ
フロントエンドの工夫点として使ったことを2つ紹介しました。
個人的にはなかなかいいアイデアだったなと思いながら使っているものになります。
特に1つ目は最初ハッカソンで発表したタイミングではあまり思いついておらず、そのときもデモを行っていたのですが、リクエスト数が飛びサーバー側はうまく受け取れないリクエストも大分あったので改善できてよかったです。
また何か今回の内容できになった部分があればコメントいただけると嬉しいです!
明日は「同時接続300人に耐える技術!サーバー編!#1」を書くつもりなのでよろしくお願いします![]()

