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

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

インフラ構成は事前準備が重要

インフラ構築にからむ部分はサービス前の設計と事前検討が重要です。リリース後にインフラ構成の変更を行うのは一大事ですので,その備えがあるとないでは余裕が違います。

デプロイ環境専用のバージョニングシステムを用意する

開発用のバージョニングシステムだけでなく,デプロイ環境用のバージョニングシステムを用意してデプロイ履歴を管理します。

直接の手動配布やrsyncを行うことは絶対にせず,各本番サーバ経由でデプロイシステムを利用し,バージョニングシステムからファイルを適用することで更新を行うようにします。頻繁にコミットされる開発用とは分離しておくことで,問題発生時の原因絞り込みをわかりやすくし,巻き戻しやミス反映があっても相互に影響を与えることがありません。

リリース時からログを集約する

後述のユーザサポートや,リリース直後から発生するバグ調査のために,何十台ものWebサーバのアクセス/エラーログが必要になります。Fluentdなどで事前にログ集約をしておくと,いざ必要になったときにとても楽です。

負荷が想定を超えた場合を事前検討する

ソーシャルゲームは負荷との戦いです。想定外の場合でも,開発と運用で事前検討しておくことで協力して素早い対策を打つことができます。

事が起きてから「こうしておけば,スケールアウトできたのに!」では遅すぎます。リリース前に,現状の構成でスケールアウトできないポイントはどこなのか,そこに負荷がかかったらどうするのかを話し合って開発チームにフィードバックして修正しておくことが重要です。

テスト環境は可能な限り本番環境に近づける

テスト環境と本番環境の違いは,本番デプロイ後のバグを引き起こす原因になります。とくにDB回りの環境差はトラブルになりやすい原因なので,次の点が要注意ポイントです。

テスト環境でもDB分割を行う

テスト時にはDBの水平や垂直分割を行わず,本番でのみ分割しているのを見ることがあります。本番でのみ実行されるような動作は可能な限り減らすべきですので,きちんとDB分割された環境でテストすることが重要です。

テスト環境でもマスター/スレーブ構成を用意する

上記と同様,テスト環境でのマスター/スレーブ構成も行っておくと安心です。テストをマスターのみで行っていると,予期せぬ動作やレプリケーション停止を起こす可能性があり,本番反映で慌てることになります。

追跡性を確保する

携帯向けソーシャルゲームでは,デッキ構築やカード合成などの複雑な操作を狭い画面で行うということもあり,根本的にユーザの操作ミスや勘違いが起きやすい環境です。そのため,ユーザサポートには本当のバグと誤操作に基づいた報告が混ざることになりますので,それを判別できるように,すべてのデータを追跡可能にする必要があります。

たとえば本作品では,次のデータがサービスインにさかのぼってすべて追跡可能なログを残しています。

カードの出入り

ユーザが受け取った1枚1枚のカードにはすべて個別のレコードとシリアルIDが割り当てられています。これを使ってその入手方法と,削除されたのであれば論理削除フラグとその理由,その際に別のカードレコードに変化したのであれば,その変化先のカードシリアルIDが保持されています。

たとえば,⁠XというユーザがAというカードをイベントで手に入れ,それを合成してBを入手し,その後,Yというユーザにトレードで譲渡した」場合は,表1のようなレコードが残ります。これにより,⁠カードがなくなった」という問い合わせに対しても,すべての操作を追跡することができるのでバグなのかそうでないのかの判断ができます。

表1 カードの状態レコードの例(カラムの一部を変更して抜粋)

シリアルIDユーザIDカードID入手方法削除フラグ削除理由ID移動先シリアルIDレコード変更時刻
1XAイベント削除合成22013/11/28 00:00
2XB合成削除トレード32013/11/29 03:30
3YBトレード未削除2013/11/29 03:30

論理削除されたレコードは一定期間後にAWSのS3やGlacierなどのストレージにバックアップのうえで実削除され,必要であればDBに戻して検証を行えるようにしています。

課金ログ

カードと同様に課金ログについても,課金状態(支払処理中なのか,支払い済なのかなど)と購入アイテムの付与状態(付与中か,付与完了したかなど)のフラグを持っていて,これについてもトラッキング可能にしています。

課金は,外部のシステムと連携して行う都合上,予期せぬ異常があることは考えられますので,その場合でも「どの状態まで課金処理が進んだのか」の追跡が行えることが重要です。

開発と品質保証のコミュニケーションを取りやすくする

日々連続的に開発を進めるソーシャルゲームでは,品質保証部門(以下,QA部門)と開発部門との連携も重要です。連携にはバグトラッキングシステム(以下,BTS)を利用しますが,弊社ではこれに「QA部門がレポートを上げやすくする」という目標を設定しています。

弊社では技術的に詳しいテスターが常駐し確認を行っていますが,ゲームとしてのバランスなどを知るのに実際にプレイしている層に近いユーザの意見も取り入れたいため,何人かの学生アルバイトにもデバッグをお願いしています。このためQA部門が利用する報告のためのBTSは「開発者が見やすい」よりは「報告を上げやすい」という観点でシステム選定を行いました。

今までの案件から,学生アルバイトのような層から意見を吸い上げやすくするためには「BTSの習得コストと心理的ハードルが低い」ことが重要だというのが経験的にわかってきました。そのため,数年前から次に挙げるBTSを試験的に導入して,レポート数を比較してみました。

  • BugZilla
  • 影舞
  • Redmine
  • 2ch式スレッドフロー掲示板
  • Mantis

これらの中で,実際にレポート数が一番多く,気軽に意見をもらえたのは「2ch式スレッドフロー式掲示板」でしたが,報告すべき必須項目が設定できず,また気軽すぎたのかバグと関係ない内容まで投稿されてしまって,BTSとしての収拾がつかなくなることもありました。

そのため次点であった影舞を採用しました。影舞は報告項目のコントロールもしやすく,進捗管理も明確なのが採用の理由です。レポート項目も上記を反映して,⁠タイトル」⁠参考URL(ネットの報告に基づく場合)⁠再現方法」⁠スクリーンショット画像ファイル」に絞っています。

それ以外のものは上記2つに比べてレポート数も少なく,画面の印象が開発ツールっぽくて難しいという意見が多いようでした。私たち開発者にとっては使いやすいツールなのですが,レポートがもらえなくては意味がないので今回の選択からは外しています。

これにより小さな意見でも,学生アルバイトでも気になることがあれば報告しやすくなり,その意見を効果的に開発側に上げることが可能になりました。吸い上げられた意見は,DevOps定例にてチームで精査し,開発タスクとして取り入れるべきか否かを判断しています。

まとめ

ソーシャルゲームに限らずデプロイ頻度の高いプロジェクトでは,開発・運用・QAがそれぞれ目的を忘れず,できるだけ共通認識を持つようにし,立場の違いを超えて歩み寄って対話できるようにすることが重要だと考えています。これからも目的に沿って,より質の高いコンテンツを継続的にリリースできるよう努力してまりますので,興味を持っていただけたら,ぜひ『魔法少女リリカルなのはINNOCENT』をプレイしてみてください!

著者プロフィール

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

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

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


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

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


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

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

バックナンバー

仮想化

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

コメント

コメントの記入