【セミナー】ディライトワークス＆ミクシィがゲーム運用のためのノウハウを伝授…インフラ事情は『FGO』＆『モンスト』にお任せ！

ディライトワークスは、3月7日、ゲスト企業と毎回1つのテーマについて掘り下げていく技術勉強会「TECH Night by DELiGHTWORKS」の第1回を開催した。初回となる「TECH Night #1」のテーマは、「FGO・モンストから学ぶ大規模ゲーム運用のためのサーバ・インフラの話」。
 
ステージにはミクシィ<2121>のXFLAG スタジオのエンジニアである小池知裕氏と佐藤良祐氏、ディライトワークスのプログラマーである高屋俊康氏が登壇した。本稿では「TECH Night #1」の発表内容について紹介していく。
 

 
バックエンドやフロントエンド、組織文化などゲーム業界に関するさまざまな技術的トピックを、開発秘話を交えながら紹介する「TECH Night by DELiGHTWORKS」。
 
初回となる「TECH Night #1」ではスマホゲームのインフラ事情をテーマに、ミクシィから小池氏と佐藤氏が『モンスターストライク』（以下、『モンスト』）のシステム監視手法を、ディライトワークスの高屋氏が『Fate/Grand Order』（以下、『FGO』）を支えるDB（データベース）の垂直水平分割について講演を行った。
 

●監視ツール今昔物語 ～上巻～

 

▲最初に講演を行うのは、ミクシィ開発本部SREグループの小池知裕氏。SNS「mixi」などでインフラ、システム運用を経験後、現在は『モンスト』をはじめとしたXFLAG スタジオのゲームアプリやモンスト公式サイト、社内で利用するサービス運用ツール、物理インフラ環境の運用など、幅広く従事している。
 
小池氏は、『モンスト』はオンプレミスとマルチクラウドにより運用されていると話し、それぞれの環境についてサービスのリリース初期から現在に至るまでの監視手法について解説した。
 
『モンスト』の稼働サーバ数はオンプレ・クラウド合わせて約1000台で、オンプレサーバとクラウドを併用。自社DC（データセンター）は2つの拠点があり、パブリッククラウドを複数ダイレクトリンク接続して運用しているという。
 

 
また、アプリケーションサーバはコア数換算で13000～26000coreを準備しているとし、これはイベントやキャンペーン時の負荷に備えるためだと続けた。
 
監視システムでは死活監視に「Nagios」というソフトウェアを使用しているが、続けて運用していくうえで問題点も多いという。その例として、対象サーバが多いうえ監視サーバが自分を監視できない点、サーバが原因なのかクラウドとの接続が切れたのかが分からないといった点を挙げる。これに対し、各拠点にNagiosを構築し、それぞれに相互監視させることで解決を図ったと話した。
 

 
また、Nagiosの設定ファイル（cfg）が煩雑で、複数の監視サーバの更新が面倒という問題もある。これに対し小池氏はNagios監視設定のcfgファイルをYAMLから生成し、各拠点の更新を一括で行うツールを内製、cfgファイルを更新するなどの対策を行ったと説明した。
 
 
 
さらに、監視項目をカスタマイズするため、SNMPのextend機能を利用し、サーバの中でコマンドを実行してその結果を返すようにしている。Nagiosのcheck pluginも社内でオリジナルのものを作っており、サーバの連続稼働時間やファイルシステムの「readonly」をチェックすることで障害検知を改善しているそうだ。
 
メトリクス監視には「CloudForecast」を運用するほか、「Kibana+Elasticsearch」でアプリケーションサーバのログを蓄積、集計や検索を行っている。また、一番新しいメトリクス監視ツール「grafana+InfluxDB」で各種データを集計し・蓄積し、可視化やダッシュボード作成、アラート設定もしていると述べた。
 
 
 
最後に、小池氏は監視で異常があった場合のアラートとして、各種監視システムと連携して通知が送れる「PagerDuty」を活用していると話す。二人一組でシステム障害に備えるOn-Call当番でサーバの開発チームとSREチームでローテーションを組んでおり、アラート発生時には15分で対応ができるなど、万全な体制が取れていると胸を張った。
 
 

▲監視アラートは最終的にはマネージャー・事業責任者へと通知が向かうような仕組みになっている。
 
・「監視ツール今昔物語 ～上巻～」の投影資料はコチラ
https://speakerdeck.com/tmkoikee/delightworks-tech-night-1
 

●監視ツール今昔物語 ～下巻～

 

▲ミクシィ開発本部SREグループの佐藤良祐氏。2017年新卒入社。以来モンスターストライクのSREとしてアプリケーションコードの改修とインフラストラクチャの改善等に従事している。
 
続いて登壇した佐藤氏はまず、「監視とは何か？」を会場に向けて問いかける。佐藤氏自身も監視の理解について曖昧だったことを打ち明け、その疑問に対する答えが『入門 監視 ――モダンなモニタリングのためのデザインパターン』（以下、入門 監視）という1冊の本にあったと続ける。当時は「監視」を雰囲気でやっていたと話す佐藤氏だったが、この本が「監視」について言語化されていたおかげで内容を整理できたと話した。
 

 
『入門 監視』は各メトリクスを5分以上の長い間隔で監視していること、メトリクスの履歴を保存していないなどの問題点が記載されている。SNMPをサーバ監視に使わない方が良いと書かれている点は、アンチパターンをしている佐藤氏にとって“心に刺さるものがあった”と語った。
 

 
また、『入門 監視』ではSaaSの導入が勧められていることについても言及。ただし、SaaSサービスが監視できる項目数が少ないこと、コストが高くつくこと、自身でメンテナンスを行いたいなどの理由からSaaSの導入を見送ったそうだ。
 
現状の問題点として、監視サーバに可用性がないこと、監視するソフトウェア（SNMP、Nagios、libmysqlclient）が古くて依存性が大きいこと、メトリクスの履歴がないこと、メトリクスの取得間隔が5分と長いことを挙げる。
 

 
例えば、データセンター2のNagiosがダウンしてしまうと、データセンター2の監視が止まってしまう問題が発生してしまう。監視が停止してしまえば、データセンター2にいる他のサーバが障害を起こしていても気付くことができなくなってしまうのだ。
 

 
また、コマンドの古さが“古文書”のようなレベルで、解読が難しいという問題もある。サーバを監視するために使用している「libmysqlclient」を入れるも、OSをアップグレードするとバージョンが上がってしまう問題が起きてしまったと説明した。
 

 
そこで白羽の矢が立ったのが「Prometheus」という、ソースコードが一般公開されている監視ソフトウェア。Googleの内部の監視システムにインスパイアされて開発されたといういきさつを持ち、信頼性がかなり高いという。他にも、監視したい項目が設定できる点や、Nagiosと同じくPull型の仕組みで扱いやすい点も挙げた。
 
古いアプリケーションソフトウェアとなったNagiosを排除するために、「監視環境の高可用性」、「Prometheusのconfig自動生成」の2点を挙げる。障害が発生してもシステム全体の機能を続けられるようにバックアップを配置し、監視する設定は統一。さらにはPrometheus同士を監視させ、片方がダウンしても監視が続けられるような構成にしていると話した。
 
 

 
さらに、現状では自動的なサービス・ディスカバリがないことを述べ、旧来の監視設定からPrometheus用のファイルを自動生成していると説明。サーバによって監視する項目のexporterが違うため、上手く切り替えが行えるように自動生成を行っているそうだ。
 

 
既存の監視項目を洗い出し監視設定を再構成や収集したデータのまとめ、監視した設定を見るためGrafana Dashboardの構築、サービス・ディスカバリのためにControl Planeを構築するといった展望を話し、佐藤氏の講演は終了の時間を迎えた。
 
・「監視ツール今昔物語 ～下巻～」の投影資料はコチラ
https://speakerdeck.com/ryosan470/our-monitoring-past-and-future-tale
 

●想定外な規模へと成長し続けるサービスを支えるサーバ開発・運用の軌跡 ～DBの縦横分割スケーリング～

 

▲ディライトワークス株式会社シニアプログラマー高屋俊康氏。2016年2月入社。以来、『FGO』のサーバ周りの業務を担う。
 
高屋氏は『FGO』2度のデータベース分割を主なトピックにして、ローンチから本日に至るまでの経緯を解説。スマホゲームのゲームサーバ開発運用、WebサービスのAPIサーバ開発運用の参考にしてほしいと話した。
 

 
まず、Webサービスとしての概要を紹介。システムは「ASP.NET MVC4」で構築されAPIサーバとUnityで構築されたクライアントで構成されたものになっている。クライアントそれぞれが状態を持っているため、例えば戦闘が起こると画像だけでなく戦闘処理に必要なデータを送らなければならないといった特徴がある。
 
各ユーザーが固有の状態を保つため、ユーザーデータはキャッシュしにくく、基本的にはマスターデータしかキャッシュできない。最終ログインなど一部の状態はキャッシュしているが、基本的にはデータベースからとる必要があるそうだ。
 


 
ユーザーの状態が頻繁に変わり、データベースに対して読み込みと書き込みが走るため、サーバへの負荷が大きいといった問題点も挙げた。中でも、クエストで得られたアイテムを用いて呼び出すボックスガチャAPIの呼ばれる速度は、他のガチャAPIと比べて大きいことが観測されているそうだ。
 

 
また、CEDEC 2018での塩川洋介氏の「FGOとは自分自身との戦いを楽しむゲームである」というコメントを抜粋し、『FGO』にはユーザーの挙動が他のユーザー状態に対してほとんど影響を及ぼさないという特徴があると強調した。


 
【関連記事】
・【CEDEC 2018】ディライトワークス塩川氏が語る「捨てる、プロデュース」の真意とは…今、明かされる「『FGO』らしくあり続けた、”愛”と”勇気”の物語。」

続いて、高屋氏はローンチから垂直分割するまでの経緯を説明。サービスは2015年7月30日に提供開始。ローンチ後は27日後に300万、11か月後には600万ダウンロードを達成するなど、非線形の増加をした。
 

 
ローンチ前の状況は、事前登録者数はローンチまでの7ヶ月と2日で70万人超え、事前予約からのインストール転換率は平均36%。このデータを参考にすると、インストール数は多めに見積もって30万程度だったという。
 
【関連記事】
・アプリマーケティング研究(3)　事前予約サービス経由のユーザのインストール転換率や翌日継続率について
 
いざ蓋を開けてみると、わずかローンチ1か月弱で300万DL越えを達成。サービスが広がる速度を事前に見積もる難しさを痛感したという。当初の設計を大幅に超えたアクセスにより、サービス提供が断続的に中断する事態が起こったと振り返った。
 
ユーザー数増加や新機能追加によりクエリ数が非線形増加し、データベースの処理速度をオーバー。クエリ消化が追いつかず、APIサーバにてMySQLコネクタの接続プールが枯渇し、サービス障害を引き起こしてしまったのだ。
 

 
ユーザーが増えると基本的にリソースの消費速度が増大するため、十分な供給を行わないと枯渇してしまう。その対応策として、APIサーバ・データベースではひとつひとつのインスタンスを強くする形のスケールアップ、またインスタンスを増やすという形のスケールアウトを行った。
 
 

 
クエリ数の非線形増加に対する初期対応として、高屋氏はクエリ処理速度の向上を試みたという。1APIのクエリ削減も試みたが、イベント等による機能追加によって、クエリ増加が追い越してしまう。最終的には何らかの形でスケールアウト（DB分割）をするしかないと考え、その時間を作るためにAWSによるMySQL互換リレーショナルデータベースの「Aurora」へ移行して時間を稼ぐ作戦を取ったそうだ。
 



 
しかし、移行直後Auroraバグによる障害を起こしてしまったため、急遽垂直分割を実装し投入。この際の基本構成は水平分割後の現在もこのままであるとのことだ。また、この際には一般的なトランザクションによるユーザ情報の保護が実装できなかったため、エラー発生時にDBクエリログを記録することと、インスタンス間のテーブル分配とコミット順を工夫することで、できるだけ事故発生時にユーザーに不利な影響が起きないよう配慮を行った。
 



 
垂直分割にしたことにより、新たに発生した問題もある。トランザクションをしていないので障害時のアクティブユーザーが増えるたびに修正が大変ということ。さらに、コミット順を指定するためにシーケンシャルにコミットしているので全体の処理秒数は全DBへのコミットの行数だけ増加してしまう。
 
他にも、アクセス増加によるDB増設によりレイテンシのさらなる悪化およびコミット失敗率が上昇してしまうことや、1テーブルが際限なく大きくなるために対応が間に合わないと溢れてしまうといった問題も残っている。
 
こういった問題を解決するために、高屋氏は垂直分割から水平分割への切り替えが有効だったと述べる。2017年9月20日には1000万ダウンロードを達成し、2018年2月28日には1200万DLまで到達。垂直分割後の600万DLから見ると、倍にあたる。データベースインスタンスも増加し、4分割から4ヶ月後には5分割に増やし、10ヶ月後には6分割にまで増加した。
 

 
ユーザーIDでシャーディングする方針に決定。APIサーバを実装しつつ、垂直分割したテーブルを水平分割に並べるオペレーションを実施した。
 
 
 
▲DMS移行構成図。トラブル対策として事前の負荷試験や複数の方法で切り戻し用の垂直分割DBを構築している。
 
水平分割の実装の要点について、高屋氏は以下の5つを挙げる。
 
①ユーザーIDから接続先DBを選ぶ
基本的にはモデル内で完結。そうでないとゲームサーバの実装を全て書き換えることになってしまう。また、運営オペレーションや集計用にクエリを自由に送れるモデルが存在していたため、消去を行った。
 

 
②複数DBアクセスの並列化
全シャードへSELECTしないと真の最新ログインユーザー一覧が取れないため、並列化を行った。並列化の実装として、各シャードへのアクセスをタスク化した上で一気にTask.WhenAllで一気に待機する実装を入れている。
 

 
③フレンドポイント付与処理の変更
ひとつのAPI呼び出し内で2ユーザーの状態更新が行われる場合があった。、2つのユーザーに対してポイントの加算処理を行う際、両ユーザーがお互いに相手をサポートとして選択しており、かつユーザーが別シャードにいた場合はデッドロックしてしまう。そのため、ユーザーID順に加算処理を行うよう変更。
 

 
④データのシャーティングにおける例外
ユーザーIDと対応するフレンドコードの生成など、実装上テーブルのUNIQUE制約に依存している部分があった。設計の大幅変更になってしまうため、これら一部テーブルをシャーディングしないことによるリスクを容認することにした。
 

 
⑤分散トランザクションについて
TransactionScopeを使って実装したが、障害テスト時にどんなクエリが失敗したかが分からないままレコードがロックされるため、ロールバックして良いか判断がつかない場合が発生したため、使用しないこととした。


 
水平分割の投入は2018年7月11日に開始。この分割により、レイテンシ削減やデータ処理の堅牢化が期待できるという。その成果については、APIサーバのログを元に検証を行っている。
 
 

▲IISログのtime-takenカラムを集計して毎分ごとの代表値で比較している。
 

 
水平分割の移行直前とダブルライト終了時、データベースへの書き込み負荷が高いボックスガチャイベントの最終日という2つの事例を選んでの検証では、見事レイテンシが半減するという結果を打ち出した。
 
 
 
2度の分割を行った感想について、データベースのスケーリングを後から追加変更するのは大変なため最初から考えておくべきであること、大きな変更時は別観点から構築された策を二つ以上持っておくべきだったと高屋氏はふりかえった。
 

 
今後の課題として、メンテ明け直後のアクセスが猛烈に遅くなる問題への対処など安定したサービスの提供、またコスト最適化を考えていきたいと話した。
 
・「想定外な規模へと成長し続けるサービスを支えるサーバ開発・運用の軌跡 ～DBの縦横分割スケーリング～」の投影資料はコチラ
https://speakerdeck.com/walkure/history-of-a-large-scale-web-api-service-development-and-operation-with-vertical-and-horizontal-database-partitioning

---

イベントの後半にはAmazon Web Services(AWS)、Googleによるライトニングトーク(LT)大会が実施。講習後の懇親会では登壇者の方々に直接質問できる機会が用意されていた。
 
「TECH Night by DELiGHTWORKS」はこれから定期的に開催されるとのことなので、本講演会に興味を持った方はぜひチェックしてみてほしい。