本格戦国RPGとしておよそ3年もの間、ランキング上位に位置し続けているスマートフォン向けゲーム「戦国炎舞 - KIZNA - ⁠」⁠（⁠以降、戦国炎舞⁠）⁠。開発運営元である（⁠株⁠）サムザップにて、そのインフラの設計やサーバサイドの開発はどのように行われているのかを、サーバサイドエンジニアの中村一謹氏、そしてインフラエンジニアである富塚真氏（写真1）にお話を伺いました。

1日1億リクエストを処理する強靱なバックエンド

――まず、戦国炎舞のサーバサイドの構成を教えていただけますか。

富塚：Linux、Apache、MySQL、PHPのいわゆるLAMP構成で、それにmemcachedやRedisを組み合わせています。MySQLに瞬間的なアクセスが集中しないように、フロント側でmemcachedに入れて、さらにレスポンスを求める処理にRedisを使う形です（図1⁠）⁠。

――戦国炎舞のリクエスト数はどの程度なのでしょうか。

中村：サイバーエージェントのゲーム事業に携わる子会社11社のグループをSGE（Smartphone Games and Entertainmentの略）と呼んでいるのですが、そのSGEの中でも戦国炎舞はリクエスト数が多い部類になります。このゲームはいわゆるGvG（Guild vs Guild）と呼ばれる種類のゲームで、戦国炎舞は1日に3回大規模バトルである「合戦」が開催されます。30分間で獲得した「合戦ポイント」で勝敗が決まるのですが、この間のリクエスト数がおおよそ3,000万で、これが3回あるので1日あたり約1億リクエストになります。

富塚：このGvGが戦国炎舞のおもしろさの肝になっているので、そこでユーザーがストレスなく遊べるかどうかが一番大変なところです。

中村：「合戦」は約20名対20名の戦いになるため、1つのレコードに対して最大で同時に40件のリクエストが発生する可能性があります。そこでデータの不整合が起きないようにというのが、最も注意している部分です。ただ整合性を保つことだけを考えて、ロックをかけてガチガチに固めてしまうとレスポンスにも影響しますから、そのバランスがポイントになっていますね。

MySQL＋Redisの組み合わせで永続性とレスポンスを両立

――同時リクエストが発生した際、ロック処理を適切に行いつつレスポンスを担保するのは難しい部分だと思いますが、どういった工夫をされているのでしょうか。

中村：戦国炎舞をリリースした当初は、不整合が起きないようにロックをしっかりかけるなど堅めの設計にしていました。それでもゲームをリリースして時間が経ち、遊んでいただけるユーザーが増えてくると、どうしてもレスポンスが悪くなる面があったんです。もちろんロックは今でもかけていますが、絶対不整合が起きてはならない部分とそうでない部分を分け、優先順位を付けて処理するような形に改善しています。具体的には、GvGでメインに使うデータに関しては現在はほとんどRedisを使っていて、GvG以外のユーザーデータなどに関してはMySQLを使う形です。

――Redisに書き込むのはどういったデータでしょうか。

中村：基本的には揮発性の高いデータですね。保存期間も短期間で、あとあと必要になるデータはMySQLに書き込んでいます。

富塚：Redisはファイルにも書き込めるので、永続性を担保することも不可能ではありません。ただ、データの更新量が膨大なため、ファイルに書き込んでしまうとパフォーマンス面でかなり厳しくなってしまいます。そのため、レスポンスを重視する方向にシフトしました。現在はほぼオンメモリだけで使っている状況です。

――日々運用されている中で、課題に感じていることはありますか。

中村：1つはユーザー数の増加による負荷の問題ですね。またサービスを開始してから3年間が経過し、蓄積されたマスタデータやログが膨大になっているんです。その影響で突然パフォーマンスが低下することもあり、その大量の情報をどうするかは悩ましいところです。

――増え続けるデータをどうするかは、インターネット上でサービスを提供するうえでなかなか答えが出ない問題だと思いますが、それに対してどのような解決策を考えているのでしょうか。

中村：ユーザーからの問い合わせの中でも、特に金銭に絡む部分はすべて残す方針にしています。それ以外のデータ、たとえば数年前のイベントのデータといったものは、いったん別のサーバに移して、運用中のサーバからは削除する方針で対応しています。

快適なゲームプレイのための努力と工夫

――ちなみに、サーバサイドの構成はサービススタート時からあまり変わっていないのでしょうか。

富塚：そうですね。基本的な構成は大きく変わっていませんが、それぞれのWebサーバやキャッシュ、あるいはRedisといったそれぞれの役割の中でサーバの台数が増えているイメージです。これまでSGEとして数多くのゲームをリリースしているので、その中で得られたノウハウを活かしつつ、最初から処理を複数のサーバで分割したり、あるいはスケールアウトしやすいような設計にしています。

――データベースのレスポンスを考えたとき、テーブルの分割による負荷分散は必要になってくると思いますが、戦国炎舞ではどのように対処されたのでしょうか。

富塚：すべてのテーブルの水平分割はなかなか現実的ではないですし、運用開始当初から完全に分割した状態でスタートすることも困難でした。あるタイミングで分割しなきゃいけない状態になったときに、膨大なテーブルの中から今この状態をより改善するためにどれを分割すべきか、最適な答えを探し出すのは難しかったですね。

特に戦国炎舞の場合、30分間のGvG中にリクエストが多いテーブルもあれば、特定の数秒間だけにリクエストが集中するテーブルもあります。そういった負荷の状態をすべて調べ、負荷が集中するテーブルのリクエストを分散するようにしてレスポンスを確保しています。

中村：そのほかの対策として、事前にキャッシュしてしまう方法があります。リクエストに備え、要求されるデータをあらかじめキャッシュしておくわけです。何もしなければ当然データベースにアクセスしてしまいますので、たとえば19時に「合戦」が始まるのであれば、その少し前にデータをキャッシュに載せておく。そういった工夫を積み重ねています。

――現状、戦国炎舞のインフラはパブリッククラウドを使っているのでしょうか。

富塚：現状はほぼ自社のプライベートクラウドで運用しています。ただ将来的には、オートスケールや時間単位でのリソースのコントロールなど、必要なときに必要な分だけサーバを立て、コストも意識しながら運用できる環境を整えたいと考えています。現状はピーク時の負荷に合わせてサーバ台数を固定して運用しており、コスト面での課題もあるため、今後はそういった面を改善していきたいですね。

――そういった環境が整えられると、運用の負担はかなり減りますよね。

富塚：サーバを増やすのに手がかからなくなるのが一番幸せです（笑⁠）⁠。インフラエンジニアは基本的に面倒くさがりなので、手間がかかることをどう楽にするかを常に意識していますね。

品質と速さのベースは、ユーザーファーストのチーム連携

――個人やチームとして、今後の取り組みについて考えられているものがあれば教えてください。

富塚：以前、上司に言われたことですが、サムザップの中だけでなく、外でも通用するインフラエンジニアにならなきゃいけないと考えています。その意味で、やはりAWS（Amazon Web Services）やGCP（Google Cloud Platform）などのパブリッククラウドを使いこなしていくことは重要です。ただ、インフラだけではサービスは成り立たないので、エンジニアとうまく連携しながら、いかに適切にパブリッククラウドを使いこなすかは考えていく必要があると思っています。

中村：戦国炎舞として直近で私自身が課題だと感じているのは、先ほどもお話しした肥大化し続けるログなどのデータをどう処理するかです。そこで、BigQueryなどにデータを流し、分析や解析のスピードも上げていくことに取り組みたいと考えています。たとえば問い合わせに答えるとき、grepで検索して10分かかっている処理を10秒に短縮できれば、業務の負担をかなり減らせますよね。こういった部分は、まだまだやれることがあると思っています。

――最後に、サムザップで求められているエンジニア像を伺わせてください。

富塚：特にサムザップの場合、コミュニケーションがすごく大事です。中村とも普段からよく喋っていますが、それはお互いの主張を押し付け合うのではありません。それぞれがユーザーファーストの視点を持ちながら、意思疎通を図ることで両者の落としどころを見つけていくんです。日常的なやりとりがサービスを提供するうえでの土台になっていますね。

中村：こうしたサービスでは運用が重要になってくるので、クオリティとスピードはどうしても求められます。バグは出せないし、とにかく早くやらなきゃいけない。この業界はどこもそうだと思いますが、制作途中で仕様が変更されることもあるので、そこを受け入れて前向きに取り組めるかも大切です。

それとサムザップは分業制でいろいろな職種に分かれていますが、意欲さえあれば、たとえばエンジニアとして働きつつ企画にも携わっている人もいます。自分で率先して手を挙げて、こういったことをやりたいと言える情熱がある人には、サムザップにぜひ来てもらいたいです。

富塚：基本的に自由で、抑えつけられることがないです。インフラであっても、たとえば登場したばかりの新しい技術を触ってみたい、サービスに組み込めるか調査したいと言えば、「⁠どうぞ、どうぞ」という感じで自由にやらせてもらえる。それで実際に試して良ければ、サービスにも反映しようということにもなるので、新しい技術に積極的にチャレンジしたい人には、やりがいのある職場だと思います。

――運用というと、どうしても決まった作業内容を繰り返すイメージがありますが、お話を伺っていると全然そういう感じではなさそうですね。

富塚：決まった仕事を繰り返す感じでは全然ないですね。自分たちで常に考えて、改善を繰り返しています。

中村：積み重ねてきた分は、独自のノウハウになっていますしね。

富塚：そういった部分は、エンジニアとしてすごくやりがいを感じるところです。

――多くのユーザーが快適に遊べる背景には、改善の積み重ねがあるわけですね。本日はありがとうございました。

本誌最新号をチェック！
WEB+DB PRESS Vol.130

2022年8月24日発売
B5判／168ページ
定価1,628円
（本体1,480円＋税10%）
ISBN978-4-297-13000-8

• 特集1
  イミュータブルデータモデルで始める
  実践データモデリング
  業務の複雑さをシンプルに表現！
• 特集2
  いまはじめるFlutter
  iOS/Android両対応アプリを開発してみよう
• 特集3
  作って学ぶWeb3
  ブロックチェーン、スマートコントラクト、NFT