こんにちは、IDCF営業の木村です。 2017年8月3日、Yahoo! JAPANの社員食堂にて、 トーセ様、ORATTA様、ドリコム様、XFLAGスタジオ様の豪華面々に、 有名タイトルの裏側を支えるチーム作りや技術を大公開していただきました！
ビール片手に、キャッシュを活用したDBの効率運用やNagiosによる監視体制といったサーバー運用からチーム体制まで、ここだけの話が盛りだくさんだったので、 今回は当日の様子を本ブログでご紹介したいと思います！
「夏だ！飲もうぜ！Game Day ～ビッグタイトルの裏側～＠ヤフー社員食堂」
まずはアジェンダ(敬称略)
・株式会社トーセ：「サーバ運用の魔法について」
・株式会社ORATTA：「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」
・株式会社ドリコム：「ダビマスの裏側を支える技術と体制」
・XFLAG スタジオ：「モンストとサーバ運用体制」
・XFLAG スタジオ：「小規模アプリ開発者が中から見るモンスターストライク」
1つ1つ紹介していきます～
株式会社トーセ：「サーバ運用の魔法について」
東証一部上場の老舗ゲーム開発会社、トーセ様からは、これまでの大中小様々なサーバー運用実績からそのノウハウを語っていただきました。
登壇者：株式会社トーセ 南方氏
結論！サーバー運用に魔法なんてない！？
ゲームのサーバー担当をされているみなさんなら、きっと困っているであろうサーバーの「コスト」「トラブル回避」「負荷軽減」。
これらを「安く！」「トラブルなく！」「負荷もなく！」、そんな魔法は実は存在しませんでした…。
でも、安心してください！魔法はないですが、ちゃーんと種と仕掛けのある手品で解決できるんです！
サーバー運用のポイント
1．コスト対策
お金を掛けようと思えばいくらでも掛けられるサーバーコストですが、
事前に何秒の遅延を許容できるか？バースト時のスケールアウトまたはスケールアップにどの程度の対応時間を予測しておくか？
これらを事前に明確にしておくことで、リッチ過ぎない、最適なインフラ環境を実現できるそうです。
また、今やネイティブゲームなら当たり前になっているCDN(コンテンツキャッシュ)を活用して、 安定かつ安価に大量配信を実現することもポイントですね。
ちなみに！IDCFではYahoo! JAPANを支えるコンテンツ配信技術を使った安定かつ安価なCDN(コンテンツキャッシュ)をご用意しています！
2．トラブル回避
どんなに対策、予測していてもトラブルは必ずと言っていいほど起こるもの…。
バックアップを取るだけでなく、そこからちゃんと切替えられるかの事前試験が重要です。
また、メンテナンス明けやコンテンツ更新明けなど売上増加が見込まれるときは、トラブルの機会損失の方が影響が大きいのでしっかりとサーバー増強と事前のウォームアップが大切になります。
3．負荷軽減
負荷は軽減できないので、分散させましょう！フロントサーバーの分散、DBのキャッシュ、Worldの開放時間の分散など、普段何気なくやっていることが重要になってくるんですね。
株式会社ORATTA：「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」
創業から8期目、毎年2倍成長の目標を掲げる急成長企業のORATTA様からは大ヒットタイトル『戦国アスカZERO』におけるエンジニアの力を最大化するチーム作りについてお話しいただきました。
登壇者：株式会社ORATTA 市川氏
結論！エンジニアが活性化する環境作りで、エンジニアの力を最大化！
メンバーも少なくないし、能力も高いのに、なんだか活気のない雰囲気ってありますよね。
機能追加やUX改善、バグ修正など、日々のやらねばならぬ業務はやりつつ、働くエンジニアが活性化していくチームビルディングは、文化作りにありました！
チームビルディングのポイント
1．エンジニアがプロジェクトを愛せる文化
愛があれば自分事で考え行動できるように、
エンジニアにも自身のプロジェクトに愛を持ってもらう仕掛けづくりが大切とのことです。
具体的には、
・作品に触れられるチャンネルを社内に用意
・作品へ本音でぶつかるチャンネル用意
いち開発者よりも前に、いちユーザーとして作品に触れる機会をつくることで、ユーザー目線での改善案や別チーム間でのコミュニケーションが活性化したそうです。
2．エンジニアが他のチームに感謝される文化
他チームやメンバーのために力を発揮できるエンジニア集団にするために、
他のメンバーから感謝される仕組みづくりを整えたそうです。
具体的には、
・各チーム合同での運用改善MTG
⇒別チームが抱える問題をKeep(継続)、Problem(問題)、Try(挑戦)の軸に分け、みんなでブレストして洗い出し
・風呂部(フロンティア部)
⇒業務時間を使って、業務改善・技術開拓のために自分のしたいことをする時間を確保
これによって、エンジニア発信でプロジェクト全体の課題解決や改善案が生まれるようになったそうです。
3．気軽にナレッジ情報を発信できる文化
営業もそうですが、どうしても個人プレーになりがちな日々の業務。
お互いのスキルアップと相互助長の目的で、
情報を発信しやすい環境づくりが肝要ですよね。
具体的には、
・情報収集/学習時間を「毎朝」確保
・収集/学習した内容を情報共有サービス(esa.io)で「毎日」情報発信
これによって、一人一人のアンテナが高くなり、 自発的な勉強会が開催されたり、発信の場が拡大していったそうです。
ついつい日々の業務に忙殺されがちですが、 こういったインプットとアウトプットの時間を作ることって本当に大切だと感じます。
登壇資料 -「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」
株式会社ドリコム：「ヒットタイトル『ダビマス』を支える技術と体制」
ドリコム様からは「人々の期待を超える」ために、大ヒットタイトル『ダービースタリオンマスターズ』における技術と体制についてお話しいただきました。
登壇者：株式会社ドリコム 白石氏
戦略～IP Strategy～
IRにも記載がありますが、ドリコム様はIP1戦略を掲げており、『ダビマス』もその一環。
コンテンツがリッチ化＆多様化している昨今ですと、なかなかオリジナル作品でヒット作を生むのは至難の業です。
一方、マーケティングやプランニングの観点では、一定のユーザーがすでについているIPはとても有用ですよね。
ただし、IP作品にはステークホルダーがとにかく多くて、その分制約も多いのが実情です…。
そんな中、ドリコム様にはステークホルダーとの信頼と実績を築くための技術と体制がありました。
『ダビマス』を支える技術
アプリ：Cocos2d-x、C++
ミドルウェア：Ruby on Rails、Ruby、NoSQL
インフラ：IDCFクラウド、AWS
利用されている技術はゲーム開発では一般的なものが多いですね。
実際、ドリコム様でもこれまでで実績のある言語やミドルウェアをあえて選択しており、実績のある技術とメンバーで開発期間の短縮を図ったそうです。
一方で、技術的な未来投資もちゃんと考えられており、今回は"マルチクラウド化"をキーワードにIDCFクラウドを採用いただきました！
昨今、いろいろな企業様でマルチクラウドというキーワードが出ていますが、 1社にロックされるのではなく、マルチな環境を利用できることでエンジニアのスキルと会社としてのリスクヘッジが取れるメリットがありますよね。
マーケティングスケジュールが非常にシビアなIP作品で、ドリコム様は開発期間の短縮と自社の技術未来投資、両方を実現する方法で技術採用と体制をしっかり考えられているのが勉強になりました。
『ダビマス』を支える体制
冒頭に記載した通り、IPには多くのステークホルダーが存在しており、IP固有の問題も多々あるそうです。
ドリコム様もやはりIPタイトルでは多くの苦労をされているんですね。
特に次の3点
1. クオリティとリリース時期の問題
2. そのIPが持つ固有の問題
3. マーケティングスケジュールのコントロール問題
IPの世界観を損なわず、プロモーションや季節感に合わせたリリーススケジュール調整が大変とのこと。
優秀なエンジニアだけでなく、渉外できるメンバーアサインやプロジェクト全体を管理進行できる体制づくりがIPタイトルの成功の秘訣なんですね。 ドリコム様では開発だけでなく運営もされているので、マーケティング含めて体制構築をされているのがよく伝わりました。
IDCFでもインフラレイヤーだけでなく、こうしたゲーム開発～リリースまでの苦労を少しでも軽減できるようなお手伝いをしていきたいものです。
まとめ！『ダビマス』からの学び
・ステークホルダーとの信頼関係大事！
IPは今の時代のゲーム成功においてとても有用で将来性もあります。 ただし、逆に言えばIPがもつ世界観もあるし、ましてTVアニメや連載中漫画などでは絶対に失敗は許されない厳しい世界…。 その大切なコンテンツをゲーム化するにはしっかりと信頼関係を構築することが最も大切な要素の一つなのですね。
・渉外大事！
これはゲーム開発だけでなく、日々の私たちの業務においても関係者が増えれば増えるほど連絡や交渉は難しくなるものですよね。だからこそ、社内だけでなくちゃんと外部との連携を密に行うことが特に重要なんですね。
・計画大事！
単に開発スケジュールを引くだけでなく、タイトルの持つ季節感や独自のスケジュールに合わせ、いつ、だれが、何をするか、しっかりと計画を立てて進める。 できているようで意外と抜け漏れがあったりするもので、PDCAサイクルを日々回していくことが基本的に大切なことであることを再認識できました。
・関係者全員を含めた細かい共有大事！
何度か記事でも書いていますが、とにかくこれにつきますね。 言った言わない、聞いた聞いてない。本当によくおこる問題です。特に関係者が多ければ多いほど…。 今はSlackやChatworkなどさまざまなコミュニケーションツールがあるため、全員がいつでも確認、認識してみんなで進めることも成功には欠かせない要素ですね。
どれも当たり前かもしれませんが、 当たり前のことをちゃんとやることがIPタイトルでの成功の鍵。
開発期間が限られていると開発終盤のベロシティも気にしなくてはならないし、 社内リソースだけでなく、社外関係者全体と認識をしっかり合わせつつ、進めていく大変さが伝わってきました。
ちなみに、ドリコム様ではIPタイトルだけでなく、今後IP×ブラウザ領域にも積極挑戦されるそうです。
メンバーも絶賛募集中で、これからの動きに注目ですね。
登壇資料 -「ヒットタイトル『ダビマス』を支える技術と体制」
XFLAG スタジオ：「モンストとサーバ運用体制」
XFLAG スタジオ様からは、誰もが知っているあのスマホアプリ『モンスターストライク』(以下、モンスト)のサーバー運用体制と、その工夫について語っていただきました。
『モンスト』の説明は不要かと思いますが、2013年にリリースされ、今では3DSや昨年は映画にもなったXFLAG スタジオ様の代名詞的タイトル。最大4人で同時に楽しめるひっぱりハンティングRPGです。そのモンストの裏側の運用体制をお話しいただきました。
ちなみに、XFLAG スタジオ様のロゴのB.B.Qは、字のごとくバーベキューを意味しているそうです。
XFLAG スタジオ様のコンセプトは、
「家族や友達と集まって、熱く盛り上がれる場所を創る」
バーベキューはその代名詞のような存在のため、ロゴにも採用されたそうです。素敵ですね。
登壇者：株式会社ミクシィ XFLAG スタジオ 松本氏
『モンスト』とサーバー運用体制
メンバーはSREチーム8名、サーバーチーム9名の計17名。
SREは負荷対策と運用改善、サーバーチームは新機能開発で編成されており、CSや解析等はプロダクトを跨いで組織が存在しているそうです。
特にこのSREとサーバーチームで、日々の運用だけでなく、メンテナンス時の運用体制をしっかりと定義づけることで、迅速な対応ができるようにされているそうです。
通常運用～PagerDutyの活用～
XFLAG スタジオ様では、万一のシステム障害対応時、障害発生から20分以内に対応開始できるように当番制を敷いているそうです。
二人一組、1週間交代のローテーションをさせることで、 いつ起こるかわからない障害に対して備えられているんですね。 当番手当もちゃんとあるところがなお素敵です！
さらに、体制だけでなく”気づく”仕組みもXFLAG スタジオ様ならでは。
監視は一般的なNagiosを利用されていて、”PagerDuty”というツールを活用されているそうです。
この”PagerDuty”が優秀で、あらかじめ決めたスケジューリングやエスカレーションポリシーに基づき、Nagiosの検知キックによってアクションを起こせるツールです。 万が一の障害時にはSlackにもアラート通知ができ、二人一組の当番体制とメンバー全員がすぐに気づける仕組みづくりをされていました。
日々の運用の中でも新しい便利なSaaSを活用しているところがさすがです。
メンテナンス
通常運用とは別に、メンテナンスも事前に体制と方法が決められているそうです。
特にメンテナンスの決め事は次の4点
- メンテナンス時間は0:00～5:00
- メンテナンス内作業はGitHub Issueで管理
- サーバー人員は事前に座組みを決めておく
- 作業は自宅で行えるように
メンテナンス時も基本的には二人一組で、作業量に応じて人数を増やされるそうです。 特徴的だなと感じたのは、深夜組、早朝組、通常組の3組編成であること！
深夜組は、上記のメンテナンス時間帯で実際に作業を担当
早朝組は、5:00～のメンテナンス明け、万が一の不具合や負荷観察を担当
さらに、通常組もあらかじめ編成しており、計画メンテナンスでも万全の体制を敷かれていました。
また、ここでもGit Hub IssueやSlackを活用して、各担当者だけでなく関係者全員で作業内容をチェックできるように工夫されているのも、国民的な大規模ゲームを運営するシビアさが感じられます。
結論！『モンスト』の運用の肝は事前準備と密なコミュニケーション！
XFLAG スタジオ様では事前の体制づくりにもみられるように、想定外の事象に誰がどのように対応できるかを具体化させていました！
また、メンバー全員でコミュニケーションを取りながら進めることを大切にされていることがよくわかりました。
XFLAG スタジオ：「小規模アプリ開発者が中から見るモンスターストライク」
XFLAG スタジオ様からもう1名！ ご存知の通り、ネイティブゲーム市場では『モンスト』規模のタイトルも限られてきます。 小～中規模アプリ開発から見て『モンスト』の開発が、どんな特徴をもっているか語っていただきました。
登壇者：株式会社ミクシィ XFLAG スタジオ 川又氏
『モンスト』のサーバー構成
既にSlide Shareで公開されているのでご存知の方も多いかもしれませんが、
『モンスト』のサーバー構成には次の4つの特徴があるそうです。
- クラウド×オンプレのハイブリッド構成
- データセンターレベルでの冗長化
- TURNサーバーを利用したマルチプレイ
- DB性能限界の解決としてキャッシュ比重が大きい
みなさん、ユーザー増加によるDB性能限界は苦労されているかと思います。
マシンパワーで解決できる場合、IDCFであればioMemory搭載の高性能サーバーを採用しクラウドハイブリットで利用されるケースが多くあります。 XFLAG スタジオ様でもまさにこの構成を採用いただきました。
一方で、やはりパワーだけでは解決できない問題もありますよね。 XFLAG スタジオ様でもWorld分割したり、スケールアップ対策などもちろん実施されていますが、これまでの小規模アプリ開発から見たとき、特に特徴的だったのが4点目の「キャッシュ比重」だったそうです。
『モンスト』での複数キャッシュ活用パターン
DBの性能限界解決のアプローチとして大きく特徴的なのは次の2点です。
① データセンターレベルでのキャッシュ冗長
XFLAG スタジオ様ではデータセンター自体が冗長化されていることはお伝えしましたが、 キャッシュももちろんデータセンター間で冗長化されています。
1プールあたり約40台超、1プール全体で2TB超の容量をもっており、これを2プール用意されているそうです。さすがの規模ですね…。
また2プール両方に同時書き込みを行っており、メンテナンスなしでプールの切り替えが可能かつ増強も可能な構成にして、『モンスト』の高い可用性を維持しているんですね。
② データの性質に応じたキャッシュ活用
また、規模だけでなくデータの性質をちゃんと理解して、それぞれにあったキャッシュパターンを採用されています。
具体的には、次の5つの観点がありました。
Mirroring
MirroringではReadの多い静的なデータで主に利用されているそうで、Keyデータにsuffixをつけて、Memcachedサーバーの分散も同時に行っています。Local Cache(memory / file)
Local Cachedのmemoryではリクエスト単位で生存期間の短いデータを、fileではファイルとして書き出されるデータを使い分け、キャッシュサーバーに繰り返し問合せさせないように負荷対策の仕組みをされています。Compress
トラフィック量を削減させるためにCompressを活用することで、負荷とコストの両軸で対策をされています。Versioning
VersioningではMirroringとは異なりKeyにPrefixを付与することで、Versioningで一部のデータのみ削除した際、Prefixを変更させてHitさせない構成にされています。Double Write
先にも記載したように万が一の大規模障害時に備え、2プール同時に書き込みを行っています。
以上のように、データの性質や保持期間、データサイズ、冗長性担保有無などの観点で、 細かくパターンを仕分けしキャッシュをさせることで、 ユーザー増やイベント時のDB性能限界解決に結びつけているんですね。
『モンスト』ともなるとデータセンター冗長やサーバー台数など、ちょっと桁の違う規模でしたが、 規模だけでなく、開発/運用メンバーの工夫のもとに、支えられていることがよくわかりました。
登壇資料 -「小規模アプリ開発者が中から見るモンスターストライク」
まとめ
以上！長くなりましたが、ビッグタイトルを支える裏側についてでした！ 共通してうかがえたのは、「事前準備」と「コミュニケーション」の重要性 ビッグタイトルだからこそ、基本が重要になってくるんですね。
IDCFでもより多くのビッグタイトルを支えられるように日々サービスを磨いていきます！
写真：Yahoo! JAPAN公式カメラ隊（阪倉 秀幸、倉増 崇史）
-
IP：Intellectual Property(知的財産)。 ↩
