読者です 読者をやめる 読者になる 読者になる

はらへり日記

腹に弾丸

オール◯ター感謝祭もどきアプリで社内イベントを乗り切る

Advent Calender JavaScript 勉強会 / カンファレンス

はじめに

この記事はアイスタイルアドベントカレンダー24日目の記事です。

qiita.com

納会の紹介

弊社では毎年、夏と冬に社員を労う納会なるものが開催されます。

【2015納会開催】今日はアイスタイルグループ納会が開催されました!グループ社員一堂に会して大賑わい♪毎年恒例の新入社員企画コーナーは題して「アイスタイル感謝祭'15」!アイスタイルにまつわるコアなクイズや、社長の吉松と経営陣の腕相撲大会などで盛り上がりました☆

Posted by アイスタイル on 2015年12月18日

写真を見るととても賑やかですね!

そして、この夏と冬には世にも恐ろしい納会新人企画というコンテンツがあります。

私は新卒なのでこの企画を行う立場にありました。

納会企画

この企画のハードルはなかなか高く、以下の要件を満たす必要がありました。

  • 400人近くの社員をたった数人で楽しませる
  • 一発芸は求められず、社員が楽しむことに軸を置く
  • 参加感を大切にする

なので例えば男子がスカートを履いて踊ったり、体を張った動画を作るといったことはあまり求められていませんでした。

つらい…(。ŏ﹏ŏ)

そこで僕は作りました。みんながリアルタイムで参加できるクイズシステムを。

Party

ソースは以下に置いてあります。

GitHub : sota1235/Party

ざっくりアプリの概要を紹介します

投票画面

参加者には投票画面のURLを事前に告知し、当日のイベントの際にアクセスしてもらいます。

今回は簡単に覚えられてかつネタっぽい納会.comを取得し、そこにアプリを展開しました。(現在は別のコンテンツに変わっています。画面を見たい方はdemo.納会.comへどうぞ)

ここでは問題への解答とコメントの投稿ができます。コメントに関しては後ほど解説します。

クイズ画面

イベントの際はこの画面をプロジェクター等で映し出す想定となります。

この画面は3種類のステートを持ち、タイトル画面、クイズ画面、画像画面となります。

基本的にはクイズ画面とタイトル画面を行き来します。

管理画面

クイズ画面を管理するための管理画面です。

クイズデータの登録、クイズの公開や回答数、解答オープンといった処理を全てここで行います。

また、任意の画像公開も可能になっています。(クイズに関係なく解説用画像を表示といった際に使用します)

実際に動かす

こんな感じ!

納会本番で使ってみた

コツコツ開発してきたこの子を実際に納会で使用してみました。

その様子は会社の公式Facebookページでもちらっと見えてたりします(」・ω・)」

このアプリ、実は〆切ギリギリまで作ってたのもあって充分にチューニングができていない状態でした。

とりあえずメモリを金の力でガン積みして動け!!!!って願ってたんですがその適当さが祟り、何匹かの魔物と戦う羽目になりました…。

それらを順番に紹介します。

本番の魔物その1:サイトにアクセスできない

サイトはグローバルドメインで公開し、当日の19時ぴったりにオープンしました。

また、事前に大々的にそのことを告知していました。

しかし、公開した瞬間にサイトがアクセスできない状態に陥りました。

社員は最大でも400~500人程度、その人たち全員が同時にアクセスしたとしてもサイトのリソース自体はほぼ静的なものであり、HTTPリクエストの数としてはそこまで問題になりません。

問題となったのはWebsocketのクライアント数でした。

Socket.IO, 及びExpressのデフォルトのクライアント数では500本近いコネクションを貼りっぱにすることができず、Expressのプロセスがいっぱいいっぱいになっていた状態でした。

幸い、上司の方がNode.js経験者だったので解決策を教えてもらい、サイトにアクセスできる状態にはなりました。

「本当に動くんだろうか…」という不安を抱えつつも企画がスタートします。

本番の魔物その2:管理画面からの通信が激遅い

先ほど紹介したように、本番のクイズ出題や回答数オープン等のタイミングは全て管理画面から行います。

ユーザからの投票(連打)の通信とこの管理画面からの通信は全てWebsocketで行っています。

しかし投票数が思った以上に多く、管理画面からの通信がクイズ画面にたどり着くのがめちゃくちゃ遅くなってしまいました。

当初は「みんなあんまり参加しなかったときのために複数回投票できるようにしよう」としていたため、1人がボタンを連打するとその分通信が発生していました。

ちなみに本番時の実際の投票数です。

うちの社員は500人もいないはずなんですが…

ってわけで1000以上の投票通信+画面上に表示されるフリーコメントをサーバが汗くせ捌いてる中に管理画面コマンドを送り込んでしまい、同じ通信に乗っけてしまっていたので案の定遅れてたわけですね。

司会が「回答オープン!」って言った時の何も起きない「シーン…」という感じは本当にトラウマです。

本番の魔物その3:画像が表示されない

魔物2で紹介したようにえげつない量のWebSocket通信が発生していたため、当然サーバが普段の性能を発揮できません。

それにも関わらず、あろうことながら僕は静的画像の配信元をexpressからnginxに変更するのを忘れていました。

すると何が起きるか?画像が読み込まれなくなります(^q^)

ちなみにその時のキャプチャがこちら。

完全な運試し問題になっています

フリーコメント機能によってヤジが飛んできたり、会場の空気が暖まっていたので逆に盛り上がりましたが、裏の僕の顔は真顔でした。

CDNサーバって偉大なんですね…身にしみました…。

反省

今回、本番でアプリが満足に動かなかったことに対する反省はいくらでもあるのですが、声を大にして言いたいのは負荷テストを必ず実施しましょうということに限ります。

今後、このPartyというアプリは全国で新人芸に苦しむ人々のために開発・保守を続けていきますが、まずはパフォーマンス面を改善していきたいと思っています。

ですのでもし使ってみた!って方がいらっしゃったら感想を教えて下さい。