こんにちは。技術本部所属コンシューマーエンジニアの伊藤です。
先日のCEDEC 2019での『スマホゲームリリース時に絶対サーバを落とさないための負荷試験』の講演に、朝早い時間にもかかわらず多数の方にご参加いただき、誠にありがとうございました。

本講演ではCygamesで行っているリリース前の負荷試験の取り組み方についてご紹介いたしました。

今回のフォローアップ記事では講演内容のポイントのおさらいおよび、いただくことが多かったご質問にお答えしたいと思います。

講演内容のポイント

・快適に遊べることが目標

いつでも安定して素早いレスポンスのサーバを提供することで、ゲームの面白さを損なうことなくユーザーに届けたいと思っています。それを実現する手段の一つが負荷試験です。すべては、Cygamesのビジョンにもある「最高のコンテンツ」につながると考えています。

・必要十分な計測体制

やはりこの格言に尽きると思います。

ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。

Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
by Rob Pike

・計測・修正のイテレーションサイクルをできるだけ速く

負荷試験を専門で行うチームがいることも、負荷試験業務の最適化により間接的にイテレーション速度向上に寄与しています。つまるところ、リリースまでに何回イテレーションサイクルを行えたかが安定リリースの鍵となります。

いただいたご質問

Q：本番と同等以上の規模の負荷をかけるのが難しい場合はどのようにすればいいですか?

A：サーバ構成は同じで数分の一サイズに縮小した、相似形の環境を用意して負荷試験する方法があります。しかし、測定結果の精度は劣りますので注意が必要です。また、複数並べて明らかにスケールアウトすることがわかっている設計では、最小単位での性能を計測することでフルサイズの負荷試験の代用と見なせる場合もあります。

Q: リリース後に負荷試験することはありますか?

A:はい。あります。大きい機能の追加/改修時には負荷試験を行う場合があります。ご質問の趣旨とは話がずれますが、他に工夫している点としては、リリース前にも言えることですがメンテナンスを入れずにスケールアウトできるようにする設計であったり、メンテナンスを入れたとしても一部機能／短時間に留める機能を準備しています。

Q: 負荷試験をCIに組み込んだ例が知りたいです

A:node.jsサーバの負荷試験を行った際の例をご紹介いたします。講演でご紹介したmochaを使って正常系の負荷試験シナリオを作ると同時に、バグチケット番号と紐づいたテストケースをソースコード修正と一緒にコミットするようにしました。外形テストと負荷試験シナリオが同じ仕組みなので、高負荷状態や多数のクライアントが接続しているような状況でだけで出るようなバグも再現・修正確認しやすくなります。併せてCIで日常的にこの蓄積したテストシナリオを実行することでデグレードのチェックも行うことができ、非常に開発効率を上げられました。

Q: 負荷試験の工数があまりかけられません

A:リリース後に負荷で遊べない状態になるよりも、ある種の保険として負荷試験はやっておいたほうが良いです。ゲームを遊べないユーザーのストレスに加えて、緊急メンテ時の開発チームの負担も大きくなり、ひいては「よりゲームを面白くしていくことに時間を割きづらく」なってしまいます。
つまりリリース後の運用が、

• 「負荷の問題がある」というマイナスの状態から、「負荷に問題がない」ゼロの状態に持っていくか
• 「負荷に問題がない」というゼロの状態から、「より面白くする」プラスをより大きくしていく

というようにスタート時の状況が大きく違ってきてしまいます。こういった点を工数の検討材料にしてはいかがでしょうか。

Cygamesではユーザーのみなさんが安定して快適に遊べるゲーム環境を提供するために、ご紹介した以外にも様々な工夫を行い日々新たな改善を行っています。ご興味を持っていただいた方は、ぜひほかの講演やこちらもご覧いただけると幸いです。