90分に1日のアクセスの半分が集中するゲームで、負荷問題と戦う！

小島　2011年の12月にサムザップにジョインしました。「戦国サーガ」や「戦国炎舞」を順番に担当して、今は新規プロジェクトにいます。「戦国炎舞」の時は、最終的にエンジニアリーダーを務めていました。

「戦国炎舞」の特徴としては、1日に3回、各30分の「合戦」というGvG（Guild vs Guild。プレイヤーの集団と集団が戦うシステム）のイベントがあって、そこにアクセスが集中します。実はこの90分に、1日のリクエストの約半分が集中しているんですよ。この負荷問題をどうハンドリングするかということが課題で、ユーザーの拡大と共にデータベースやサーバーを作り変えて来ているという背景があります。

「戦国炎舞」のチームは、デバッガーさんやイラストレーターさんも入れると70〜80人の規模になります。その中でエンジニアは30名ほどですね。クライアントサイドに10名ちょっと、サーバーサイドに15名強、そしてインフラ担当が2名おります。

チームの特徴としては、皆がユーザーなんですよ。自分たちで作って、自分たちで遊んで、課金しています（笑）。合戦にも毎日みんな参加するので、その時間にMTGなんてありえない、という感じです。だから不具合があった時にも、一番早く気が付くのが社内の場合も多いですね。

富塚　私は2010年8月に、インフラエンジニアとしてサムザップに入社しました。「戦国炎舞」にはリリースの時から関わっています。以前はスマートフォンゲームに関してはライトユーザーだったのですが、今はかなり「戦国炎舞」をプレイしていますね。自分がこんな風になるとは思わなかったです（笑）。

パフォーマンスを全エンジニアに可視化するため、Kibanaを導入

富塚　実は負荷問題に関しては、1年ほど前まで、常にパフォーマンスをチェックしていたのはほぼインフラエンジニアだけだったんです。でも、インフラエンジニアは問題の指摘はできても、実際に対応できるのはフロントやサーバーサイドのエンジニア。

彼らにもパフォーマンスが常に可視化されている状態を作りたいと考えて、Kibanaを使い始めました。

▼「Kibana」を活用してパフォーマンスを可視化

Kibanaを使うと、グラフでエラー数などを誰でもチェックできるようになります。実際にグラフ化してみたら、視覚的にわかるのでエンジニア同士もちょっと楽しそうに話すようになって、徐々に浸透していきました。今では、新機能のリリース時やイベントの際には、必ず皆がチェックするようになりました。

レスポンス速度に関してはしきい値を設定していて、例えば合戦中であればN秒以上のレスポンスが0.005％を越えたらNGということにしています。ここを上回ると、ユーザーがストレスを感じやすいためです。

Kibana導入によって、特定のページに対してエラーが何件出ているのか、といったことにすぐに気がつけるようになりました。不具合があったときに原因を突き止めるのが早くなったと思います。

エラー件数なども日々メールで送っているので、インフラ側から指摘せずとも各エンジニアが自発的に動いてくれる状態になりました。

データ取得・更新処理を高速化するために、Redisをオンメモリのみで活用

小島　パフォーマンスを少しでも改善するために、データベースにはRedis、MySQL、memcachedを使い分けています。最初はMySQLとmemcachedを基本にしていたのですが、合戦の処理をもっと上手く行いたいということがあって、Redisを導入しました。

Redisに決めた最大の理由は、とにかく高速なところです。それからmemcachedと違って、文字列型以外のデータが使えるんです。前後の関係を保持したままにできるリスト型や、あらかじめセットしたデータに応じて、自動でスコアをソートした上で保持してくれるソート済セット型。

これはリアルタイムランキングによく使われる機能ですが、「戦国炎舞」ではマッチングを高速にさばくために使っています。

Redisの使い方としては、データを永続できる機能は捨てています。永続的に保持したいユーザーの基本情報のようなものには、MySQLを使っていますね。合戦の時だけ、合戦ポイントの加算処理などをRedisでメモリ上でさばき、合戦が終わったらそれをMySQLに保存します。

更新処理をMySQLですべて実行していると、どうしても遅くなってしまいます。Redisを完全オンメモリで割り切って使うことで、合戦中に不具合が起きても、他の部分はある意味影響を受けない。このようなルールで使うことで、運用負荷はだいぶ下げられているかなと思います。

サーバーのパフォーマンスも上げるため、試行錯誤を繰り返す

富塚　インフラに関しては、最初はオンプレ環境で運用していました。ただ、リリースして初速が非常に良く、それまで弊社が経験したことのないスピードでダウンロード数が伸びていって。このまま自分たちで物理サーバーを調達していたら、スケールが間に合わない、絶対に限界がくると感じました。

そこで、リリースから半年ほどで、サイバーエージェント内にあるプライベートクラウドに移設しました。移行はなかなかすんなりいかず、試行錯誤した結果、一部は物理化をしてクラウドハイブリットな構成にしました。

ただ実は…今はほぼ、物理サーバーで運用しています。一番の理由は、パフォーマンスです。実感として、3倍ほど改善しています。

仮想サーバーですと、どうしても物理サーバよりもパフォーマンス的に劣ってしまいユーザーのレスポンスに影響してしまう。そのため物理サーバーに戻して、物理の本当の力を発揮してもらおうと。

さらに、コスト面ですね。結局ユーザーやリクエスト数が増えてくると、クラウドでもどんどん台数を増やすことになるので、管理工数もかかります。普通に物理に切り替えただけで、コストも3分の1くらいになったかと思います。

ユーザーのストレスをなくすため、より高速化と改善を進める

富塚　今後インフラに関しては、更にボトルネックを解消してよりレスポンスを高速化していきたいです。それからサーバー台数を、なるべく減らしていきたいと思っています。台数が多いと障害ポイントが増えるため、可能な限り増やさずに運用をしていきたいです。

小島　改善は、常に繰り返していきたいですね。今だからできる改善や、もうちょっとできそうだ、というところを見つけてどんどん進めていきたいと思っています。ユーザーのストレスをなくすことが一番ですね。そもそも自分たちもユーザーですし（笑）。

自分たちもより楽しめるように、そして、ユーザーの皆さんがこれからも、長く「戦国炎舞」で遊んでくれるように、どんどんサービスを良くしていきたいです。（了）