【CEDEC2016】大ヒットゲーム『モンスターストライク』を支えた負荷分散の手法…モニタリングとDBスケールアウト、キャッシュをどう活用したか


ミクシィ<2121>XFlag Studioの大塚弘記氏は、「モンスターストライクを支える負荷分散手法」と題するセッションを行った。セッションでは、スマートフォンゲームアプリ『モンスターストライク』で行われているサーバサイドの負荷分散の手法とともに、大規模運用時に発生する問題や障害へのアプローチを紹介した。

『モンスターストライク』では、負荷分散を行うにあたって、

(1)サーバーの状態を確認するモニタリングシステムの整備
(2)負荷の最もかかるデータベースを中心にいかにしてスケールアウトするか
(3)データの特性に合わせたキャッシュの活用

の3つのポイントが重要であると語った。以下、それぞれの項目をわかりやすく紹介していった。


 
(1)モニタリングシステム

まず、モニタリングシステムは、サーバーが生きている・あるいは落ちたといったいわゆる「生存監視」だけでなく、高い負荷状態の原因を特定するための材料を記録するためにも整備しておく必要があるという。つまり、負荷に対して、効果的な対策を判断するために必要だという。
 

具体的にはCPUやメモリー、IO、ミドルウェアのリソースの状況のほか、アプリケーションのアクティブの状況、クエリーカウント、スレッドの状態などデータベースエンジン内のデータも重要と述べた。パフォーマンスについては、APIを叩いた時にどれくらいで返ってくるのかなども重要だという。
 

また、監視ツールには、オープンソースと有料のものがある。オープンソースとしては、CludForecast、Kurado、Cacti、有料サービスとしてはMackerel、NewReclicなどが存在している。それぞれ計測できるものが微妙に違うものの、仮に不足しているものがある時にはプラグインを作って対応する、といったことも可能だ。またpull型よりもpush型がおすすめだそうだ。

では、どういった情報を取るかについては、ボトルネックになりやすいデータベースに関する情報がほしいとのこと。それ以外の情報は、「あるだけあったほうがいい」という。そして、それぞれの情報を集めることで、それをもとに効果的な対策が取捨選択できる。あくまでビジネスの継続・推進が優先とし、「憶測ではなく、計測で判断する」を大事にしているそうだ。
 


 
(2)負荷の最もかかるデータベースを中心にいかにしてスケールアウトするか

では、データベースのスケールアウトをどうするか。データベース・サーバーを複数台に増やしていくものだが、無駄なクエリーの発生など非効率な状況を改善しないまま行うと、余計にコストが上がってしまうという。増設後、問題がより大きくなり、改修のためのコストがかかるというだけでなく、メンテナンスを行ったときに運用が止まってしまうため、機会損失になる可能性がある。
 

データベースをどうやって分割するか。
1)垂直分割…一部のテーブルを別のデータベースに移動させる。
2)水平分割…1つのテーブルの各行を別々のテーブルに分散させる。いわゆるシャーディングと呼ばれている。100人のユーザーデータがあるとすると、特定のアルゴリズムに応じて25人を4つに分ける、といったやり方だ。ミクシィでは、Modulo演算を使っているとのこと。
 

なお、シャーディングにあたって、ライブラリを活用した、シンプルな運用を行うように心がけているそうだ。ハックすることも可能だが、その場合、バージョンアップ時の対応コストが上がる問題もあるうえ、暗黙的に制御される構造には依存することも避けたいという考えがあるという。シャーディングミドルウェアについては、障害が起きた時の運用が複雑になるため、採用を見送ったという。
 


 
(3)データの特性に合わせたキャッシュの活用

キャッシュも負荷分散を行う上で重要な要素だ。キャッシュを取るタイミングは大きく

(1)After Comit:データベースにコミットした瞬間に生成
(2)Read database:データベースを読んだ時にキャッシュを生成

と2つのタイミングがある。更新頻度が低い場合には、After Comitが有効だが、頻繁にデータの書き換えがあるスマートフォンゲームでは非効率となる。したがって、Read databaseがメインになっているという。
 

また、キャッシュプールを複数使うという工夫も行っているそうだ。その際、アクティブとスタンバイの2種類を作り、Writeは両方のプールで行い、Readはアクティブな方で行うとのこと。サーバーを増やしたい場合、スタンバイの方を増やした後、アクティブに切り替えることでサーバーを停止することなくスケールアウトできる、というメリットが有るらしい。
 

最後に、データの特性に合わせてキャッシュの方法やタイミング、キャッシュアソシエーションのほか、キャッシュのトラフィックもコントロールする必要があると述べた。またインフラ側のパフォーマンスも考慮すべきだという。クラウドサービスによってはネットワークのパフォーマンスが遅い場合があり、いくらキャッシュしても速度が改善しないという問題が起こる。最後に質疑応答に答えて講演を終えた。

 
(編集部 木村英彦)
株式会社MIXI
https://mixi.co.jp/

会社情報

会社名
株式会社MIXI
設立
1997年11月
代表者
代表取締役社長 木村 弘毅
決算期
3月
直近業績
売上高1468億6800万円、営業利益:191億7700万円、経常利益156億6900万円、最終利益70億8200万円(2024年3月期)
上場区分
東証プライム
証券コード
2121
企業データを見る