長年ライブサービスゲームを携わってきた僕は、未経験のインターンとしても、経験を積んできたおじさんでも、数えくれないほど本番環境を壊した経験があります。その記憶が睡眠不足の脳から消える前に、より印象に残った件について書いてみたいと思います。

gloops で本番環境を壊した話

この件は僕がインターンだったとはいえ、初めてのエンジニアとしての仕事で、初めて本番環境を壊した件なので、13 年後になっても忘れていない話です。障害は 1 回だけでなく、2 回も起こしてしまい、ゲームが一番ユーザー数が多く、売り上げが高い時間帯にゲームをダウンさせました。

ゲーム自体は、UI がサーバー側でレンダリングされていたウェブアプリで、キャラクターを動かすシーンなど、より重い UI は Flash で作られていました。チーム連携を取るための掲示板もありました。

元気でまだ青いインターンだった僕は、掲示板の最新投稿を見るためにユーザーがページを再読み込みしないといけないのが非常にダサいと思い、リアルタイムで掲示板が自動的に更新されたら、かっこいいではないかと思いました。AJAX が流行っている 2012 年だし、新しい投稿を非同期的にポーリングしない理由なんてないんじゃないかと。もちろん、そんな理由をを真剣に考えようともせず、行動に移ったのみです。

結果として、バトルのイベントが始まった途端、サーバーが負荷に耐えきれず、ゲームが動かなくなってしまいました。Redis を採用した再挑戦も同じ結果になってしまい、流石にそれ以上は機能をリリースすることはありませんでした。

反省

思い返してみると、行動力がありながら未経験だったインターンの僕が、本番環境で負荷テストをしても良いチームに入っていたという事情が、障害の一番の原因だったと思っています。ゲームをダウンさせないで済む実装方法はあったかもしれませんが、それを知る経験と実力はなかったのです。

以上の内容はポーリングがどうとか意見を述べようという意図は全くありません。他のプロジェクトでリアリタイム通信を受け取る方法としてポーリングを採用したこともあり、WebSocket にデータを丸投げするより、ポーリングを使うと結果整合性の問題と直接向き合わないといけないので、ポーリングのほうが技術的選択肢として全然アリだと思っています。