【特別企画】ソーシャルゲームのDevOpsを支える技術(前編)~魔法少女リリカルなのはINNOCENTの舞台裏~

この記事を読むのに必要な時間:およそ 6 分

イベントの中盤

イベントの中盤ではリソース監視を継続し,ユーザのイベント参加率を考慮しながら,サーバの増強効果を確認します。この時点ではトラフィックが急増することもほとんどないため,イベント準備期間と開始直後に問題点の改善が済んでいれば比較的落ち着いた状態が保てます。

とはいえ,いつまでも落ち着いた状態のままではいられないため,イベント終盤に向けての計画を確認し,すでに指摘済みの改善点の漏れがないか,イベント開始直後に見つかった一時的にレスポンスが遅いリクエストの再確認を行います。

レスポンスが遅い原因がデータベースへのクエリにある疑いが生じた場合,処理時間が短いが,発行回数が多いクエリを疑います。単純にスロークエリの記録しきい値を変更しても,発行回数が多く,問題があるタイプのクエリの発見は難しいため,MySQL付属のmysqldumpslowコマンドを利用します。

mysqldumpslow -s t mysql-slow.log

上記のコマンドを調査したいスロークエリログに対して実行すると,クエリ処理時間と実行回数を計算した合計処理時間が,上位のものからソートした結果として得られます。このコマンドの結果を分析し,問題が見つかった場合は開発側にフィードバックを行います。

イベント中盤ではユーザの振る舞いも安定しているため,この時点で発見された問題を無理に改善しようとすると,結果として必ずしも最適にならない恐れがあります。そのため修正するかどうかはイベント終盤時に問題になりうるかどうかという視点で協議し,判断を行います。

イベントの終盤

イベントの終盤が迫り,とくに最終日になるとイベント参加者も追い込みに入ります。

図2の7月26日18時ごろから見られるように,イベント終了間際になると200Mbps超のトラフィックがさらに急増し,600Mbps超にもなります。

トラフィック急増の原因は,このイベントの場合はユーザによるWebサーバ上でのFlashリアルタイム合成要求数の増加なのですが,合成処理によるCPU利用率の上昇がレスポンスタイムに大きな影響を与えないように,Webサーバのロードアベレージを確認します。

図3のグラフがイベント中のWebサーバのロードアベレージになります。イベント終了の1~2時間前ぐらいからトラフィックが急増する傾向があるため,サーバ起動時間を考慮して事前プロビジョニングを行います。図4のグラフでは16時と20時にサーバを追加し,最終的にはWebサーバの数は60台になりました。

図3 イベント中のWebサーバのロードアベレージ例

図3 イベント中のWebサーバのロードアベレージ例

図4 図3のイベント終了間際を拡大

図4 図3のイベント終了間際を拡大

イベント期間中は定期的にイベントランキングの公開を行っていますが,イベント終了間際では公開を停止しています。これは参加者による駆け込みアクセス増の防止を目的としています。

“駆け込みアクセス増⁠とは,イベント終盤になると,ランキング報酬が獲得できる順位争いが加熱化し,ランキングを取得する目的で集計間際に大量のポイントを獲得されることがあります。フィーチャーフォンやスマートフォンのブラウザでの利用を想定したゲームではありますが,PCなどからツール等を利用して参加する一部ユーザが存在します。ツールを利用するとフィーチャーフォンやスマートフォンのブラウザでは実行不可能な速度でゲームへの参加が可能になるため,対策として駆け込みアクセスなどの連続アクセスにはしきい値を強化するなど監視を強化し,ユーザ間で公平なリソース利用となるように注意しています。

終了間際のリアルタイム最適化

イベントの終了が近くなると,これまで行った最適化の効果を検証し,イベントを無事に終了させるためにリソース監視だけでなくDBサーバで実行中のプロセスを確認し,問題の早期発見に努めます。

MySQLで実行中のプロセスを確認するには次のコマンドを実行します。

mysql>show full processlist;

イベントの終盤ではユーザの行動ログが蓄積され,データが肥大してきます。データが肥大してくると,これまでに行ったスロークエリログを利用したクエリの改善が有効でなくなるケースが存在します。

図5のグラフはユーザのプレイデータが保持されているDBサーバ上で,Select Scanされた数を記録したものです(これまでのサンプルとは別のイベントのもの⁠⁠。Select Scanはテーブルやインデックスの先頭行から全件検索を行った回数を意味します。

図5 DBサーバ上でSelect Scanされた数を記録したもの

図5 DBサーバ上でSelect Scanされた数を記録したもの

SELECT文を用いたクエリのチューニングではインデックスを使用して探索する行数の範囲を少なくするのがセオリーですが,全件探索を行う場合もあるため,一定数のSelect Scanは存在します。しかし,Select Scanが意図せず急増している場合はMySQLが利用するインデックスが変化した可能性があるため,調査を行います。

MySQLのオプティマイザはデータ量と利用頻度によって利用するインデックスを変化させるため,事前のクエリ実行計画結果と利用されるインデックスが違ってしまう場合があります。その場合は「force index(インデックス名)」でインデックスのヒントをオプティマイザに与え,利用するインデックスを変更するように発行するSQL文を変更します。

場合によっては,クエリの実行速度を最優先するためにインデックス追加や削除などをイベント中に最適化することもあります。MySQL 5.6ではインデックスの追加と削除がオンラインで可能なため,イベント終盤でゲームの中断を行わずに済みます。

イベント後

無事にイベントが終了できると,運営側もやっと一息つけます。イベント終了時刻を超えるとトラフィックが急減するため,イベント中に増強したサーバを停止し,課金を抑えるといったイベント終了作業を行います。

また,想定よりも悪かった部分や良かった部分を次回のイベントに活かせるように抜き出し,調査項目に挙げるなどの振り返りを行います。振り返りは地道なことですが,地道なことを継続し,経験を蓄積することが,企画・開発・運用が協力した少人数での運営には重要になります。

次回予告

今回はDevOpsの考え方を実践するソーシャルゲーム『魔法少女リリカルなのはINNOCENT』のインフラ構築の方針,データ分析による継続した改善について我々の取り組みを紹介しました。

後編では,DevOpsのおもに「Dev」に重きを置いたソーシャルゲーム開発の裏側と,クラウド事業者のIDCフロンティアから見たソーシャルゲームトラフィックのさばき方を紹介したいと思います。

著者プロフィール

水野拓宏(みずのたくひろ)

(株)ユビキタスエンターテインメント 取締役 CTO

Facebook:https://facebook.com/takuhiro.mizuno
Twitter:https://twitter.com/mizunon


宮嶋史尋(みやじまふみひろ)

(株)ユビキタスエンターテインメント R&Dディビジョン 第2セクション


藤城拓哉(ふじしろたくや)

(株)IDCフロンティア カスタマーサービス本部 ソリューションアーキテクト

バックナンバー

仮想化

  • 【特別企画】ソーシャルゲームのDevOpsを支える技術(前編)~魔法少女リリカルなのはINNOCENTの舞台裏~