Resemaraを支えた技術フライングゲットガチャの舞台裏 #ksgstudy #ドリコム

Copyright Drecom Co., Ltd. All Rights Reserved.
2014/07/12 @sue445
関西ソーシャルゲーム勉強会・２０１４夏

自己紹介
sue445
● ドリコム　サービス基盤部
○ 主に社内ツール、社内ライブラリ系
○ ガルロワ、フルボッコ、ジョジョSS、トレクルなど、最近のネ
イティブアプリの課金決済系ライブラリ作ってます
○ たまにインフラ
● Ruby歴2年のルビーチョットデキルエンジニア
● 当時ドリコム入社1年半にして今回初めてガチャを作った（重
要）
● 好きな言語はJava（重要）
● 自称：TDDマニアなキュアエンジニア

趣味で作ってるもの
● rubicure
○ https://github.com/sue445/rubicure
○ プリキュアのRuby実装
● Gitpeach
○ https://github.com/sue445/gitpeach
○ issueをカンバン風に管理
○ Gitlab用のwaffle.ioクローン
● Chrome Gitlab Notifier
○ https://github.com/sue445/chrome-gitlab-notifier
○ Gitlabの通知をChromeで受け取る拡張
● and more !

【CM】ワタシハテストチョットデキルTシャツ
エンジニアならチェックしておきたい技術系Tシャツまと
め - くりにっき

【CM】フルボッコヒーローズ
http://official.fullbokko.drecom.jp/

今期の嫁: キュアハニー

本妻: キュアピース

【最近のお気に入り】枕嫁

【CM】プリキュアハッカソン2 開催！＠弊社
http://connpass.com/event/7181/

アジェンダ
● リセマラ is 何
● 開発体制
● 実績
● アプリの構成
● 工夫したこと
● Twitter APIの闇
● よくある質問
● エピローグ

リセマラ is 何
● 「リセットマラソン」の略
● パズドラとかでゲーム開始直後にもらえるカードがランダムな
ので、強いユニットが貰えるまでインストールとアンインストー
ルを繰り返すこと
● 中の人的にはインストールユーザと実際のユーザの剥離が
出るのでつらい。。。

ゲームリリース前に公式でリセマラできるようにしたｗ
当時のドメインも resemara.fullbokko.drecom.jp

Attention!!
● ここに掲載してる技術情報は2014年3月時点のものなので
若干古いです
○ 事前登録期間が2013年12月～2014年2月のため

解決策
実演

Twitterで認証してつぶやけば何回でもガチャ回せる

詳しいこと
● フライングゲットガチャセミナー資料
○ http://www.slideshare.net/drecom/drecom-20140225-
seminar-31882381
● 【ドリコムセミナーレポート】『フライングゲットガチャ』はなぜ成
功したのか？　マーケティング担当者がその秘訣を語る。 |
Social Game Info
○ http://gamebiz.jp/?p=127470

メンバー
● 開発 x 1
○ sue445（サーバ周り全部）
○ ガチャ演出周りで助っ人(2週間くらい)
● デザイン x 1
○ 絵とコーディング回り
● 企画 x 1
● 開発計1ヶ月弱くらい
○ 途中で仕様変更が何回もあったので実開発は2週間くら
い

実績
● Twitter/Facebook認証数
○ 約10万人
● 事前登録数：48万人
○ 業界最多？（たぶん）
● ガチャ総回転数
○ 996万回
○ 瞬間最大風速0:00～0:10でガチャ13500回転くらい

本番環境の構成
● web x 2
○ redisあいのり(redis 2.6.16)
○ それぞれにredis入れてVIPでアクセス（後述）
● db x 2 (fioではなく普通のHDD)
○ MySQL Percona server
● cache x 2
○ 最初はwebにmemcache同居だったけどメモリ的に厳し
かったので途中で追加してもらった
● いずれもCentOS 6
● 負荷が読めないのでとりあえずミニマムスタートしてみたが
割となんとかなった

よくあるKVS構成
web-xx web-xx job-xx job-xx
redis-01
(Master)
redis-02
(Slave)
VIP

フラゲガチャのKVS構成（サーバ節約）
web-02
VIP
web-01
redis(M) redis(S)
自分自身にVIPをつけるこ
とで最低限の台数でHA構
成を構築

ステージング環境の構成
● Debian Wheezy
● OpenStackの自分用Railsアプリ頻出ミドル全部入りスナップ
ショットからインスタンス立てて環境構築
○ nginx, mysql, redis, memcached, git, tmux, 自分の
dotfilesなど
● 詳しくは弊社外道父のブログ参照
○ OpenStackでつくる開発環境と外道塾発表資料 | 外道
父の匠

アプリ周り
● Ruby 2.0.0-p353 + Rails 4.0.2
○ リリース当時(2013/12/16)では最新
○ 途中で2.1.0出たけど数ヶ月でお役御免だったのでス
ルー
● capistrano 3
○ v2 -> v3で全部変わってたのでtaskを全部書き直した
○ webサーバ2台なのにクラスタリスタート作ったｗ
○ 開発期間短いながらも自分のアプリで人柱になって、有
志の手により社内gem化された

機能
作った
● 事前登録
● リセマラガチャ
● シリアル生成
● DM送信
作ってない
● レポート系（工数削減のため）
○ GoogleAnalytics
○ fluentd (事前登録とガチャ)
● メンテナンス画面
○ 忘れてたｗ

工夫したこと
● 事前登録
● リセマラガチャ
● TwitterのDM大量送信

事前登録

事前登録
仕様
● 認証不要
● 「事前登録する」のPOSTの度に一意なシリアルコードを作る
● シリアルコードがiOSかAndroidかアプリ側で識別したい
問題点
● 表示したシリアルを全部DBに突っ込んでたら死ぬ（容量的に
も負荷的にも）
● 認証かかってないため、GoogleのクローラとかがPOSTする
と事前登録数が水増しされてしまう

表示したシリアルを全部DBに突っ込んでたら死ぬ問題
解：シリアルコードの暗号・復号化社内ライブラリ使った
● 別アプリで作ってたのを流用
● 見た目は12文字の数字だけど、39ビット分の情報を持たせ、
報酬IDや連番も含ませたり整合性チェックもできるようにした
● 連番をredis counterで持たせた
○ iOSとAndroid各1つずつ
○ 本当なら発行したシリアルを全部DBにINSERTするとこ
ろだが、redis counterを2つだけ使うだけで万事解決

クローラによる水増し問題
● bodyにformタグを全て含めないことで、スクレイピングしただ
けではボタンを押せないようにした
● Ajax使えばクローラはだいたいごまかせる（気がする）
● 後発の他社の事前登録ガチャはこの対策してないように見
えた

クローラによる水増し問題
HTML上はformタグ
のactionが空
onclickでsubmit直前
に設定する

リセマラガチャ

仕様が複雑

問題点
● 6時間ごとにworkerで全ユーザのガチャ回数リセットすると
ユーザ増えた時に処理に時間がかかって死ぬ
● ガチャ回す度にヒストリレコードINSERT＆ガチャ総回転数
UPDATEしたらDBが負荷で死ぬ
● Twitterの性質上バズると局所的にアクセスが来るため負荷
が読めない
● そもそもの仕様が複雑 (;´Д｀)

解決策
全部redisでよくね？

画面表示でSELECTすらしてないｗｗｗ
redis counter
redis counter
redis counter
redis counter
(with expire)

ガチャ回す時は3種類のカウンタを同時に増やす
全員の総回
転数++
自分の回転数++
1ターム内のガチャ回数++

MySQL使ってるのはたったこれだけ
● ユーザ認証
○ 認証後にtwitterのaccess tokenをユーザマスタに入れる
● POSTする時にcurrent userでロック(SELECT ～ FOR
UPDATE)
○ パワーアタック系のチート対策
○ 1ユーザで複数同時に処理を走らせない
● ユニット確定時に報酬レコードをINSERTする

よくあるガチャのテーブル構成（適当）
users
user_car
ds
gacha_car
ds
1　n
n　　　1
cards
gachas
gacha_his
tories
1 n
n
1
n 1
1
n
n 1

リセマラガチャのテーブル構成
users
user_rewa
rds
rewards
1　　　n n　　　1
● rewards = cards + gachas
○ 今回はガチャ1つしかやらないので分ける必要もなかった
○ rewardsをガチャの度に全件取得するコストが心配だった
が、ガチャで使う最低限のカラムしかないため余裕だった
● ガチャ履歴もログに出してfluentdで送るようにしたのでガ
チャのhistoryテーブルも不要

redis内訳
users (各ユーザに対してカウンタが設定)
● ガチャ合計回転数
● 1ターム内のガチャ回転数
○ 0, 6, 12, 18時にexpire
● 1ターム内のリセット回数
○ 0, 6, 12, 18時にexpire
ユーザに紐付かない系
● シリアルコード内の連番（iOS, Androidそれぞれ）
○ 事前登録する度にインクリメント
○ 事前登録数はこれの合計
● 全ユーザ合計のガチャ回転数
● ★5（一番レアリティの高いユニット）の放出数

redisの値に有効期限をつける方法
EXPIRE key sec or EXPIREAT key unixtime
● リセマラでは後者を利用
● redis-objectsのドキュメントには一切書いてなかったがソー
ス見たら実装されてた
○ ただしunixtimeなので Time#to_i して渡す
● ガチャ回す時にINCRとEXPIREATを同時に使う
● 現在時間を元に次の6時, 12時 … を算出するのが一番大変
だったｗ
○ 時間のテストはdelorean最強
○ https://github.com/bebanjo/delorean

expireつけた結果
ガチャリセットのかかる0時, 6時, 12時, 18時きっかりに山ができ
てるｗ

cacti @db ピーク時でもCPU使用
率0.14% www

cacti @web
LAもピーク時で1〜2くらい

Twitter APIの闇
1. 凍結済ユーザの判別が困難な問題
2. DM送信コストが結構高い件について
3. アプリのパーミッションが大雑把な問題

1. 凍結済ユーザの判別が困難な問題
他ユーザから凍結済ユーザを見ようとすると403(エラー
(Forbidden)になるが、凍結済ユーザ自身は普通に見れ
る

@sue445_sst5 が凍結済ユーザ

何が問題か？
● 凍結済でもTwitterで認証してログインできる
● ガチャ回せる
● つぶやく時に初めてエラーになる
○ 調べたら凍結済ユーザでもGET系は全部大丈夫
で、POST系が全部失敗。。。
● 事前登録終了後にDMでシリアルコードを送れない
○ CSのコストup

結局どうした？
諦めた(ｷﾘｯ
● 公式アカウント(@fullbokkoheroes)経由でチェックす
るにしてもRateLimitがあるので限界がある
● 15分間で180回までなので焼け石に水

2. DM送信コストが結構高い件について
● ユニットを確定してたら事前登録終了後にDMでシリアルを送
る
● 年末にDMを送ったら1時間半で7000通しか送れなかった
○ 秒速1.3通
○ Twitter API叩くコストが意外に高い
● 発行したシリアルは50000枚
○ ガチャ35000枚, お年玉15000枚
○ このままだと全部DM送るのに65000秒(=18時間)かかる
ことにｗ
○ ヤバイ

【解決方法】並列送信
● redisは使ってたけどSidekiqやResque(Rubyの並列処理の
ライブラリ)は入れていなかったので昔ながらのThreadを使っ
た
○ 数回しか使わないスクリプトのためだけにセットアップす
るのが抵抗あった
● 普通にやるとThreadが一度に全実行されるため同時実行す
るスレッド数を制限する必要ある
○ サーバの負荷とAPI実行時の帯域がやばい

【解決方法】並列送信
● ruby-threadのThread pool使った
○ 20スレッドでDM45000通送るのに約40分
○ 秒速18通
● jobサーバがないのでDM送信の度に本番のwebを1台切り
離して即席jobサーバにしてた（つらい）
○ ピーク時避ければweb1台でも耐えられた
● rubyのプロセスだけでCPU 50〜60%くらい使った
● SidekiqやResqueでqueueの数制限するのが大正解

3. アプリのパーミッションが大雑把な問題
Twitterアプリのパーミッションは大きく分けて3種類
● Read only
○ GETは出来るがPOSTはダメ
○ 例）Twilog
● Read and write
○ GETとPOSTはOK
○ DMは送信出来るが受信は出来ない
○ 例）ボット
● Read, Write and Access direct messages
○ ↑ + DM送受信OK
○ 例）普通のTwitterクライアント

適切なパーミッションって？
アプリの仕様上つぶやきとDM送
信できればいいのでRead and
writeが適切（重要）

アプリに適切なパーミッションが大事
● 不要なパーミッションはつけない
○ 何も考えずに適当に「Read, Write and Access direct
messages」にするのはセキュリティ的によろしくない
○ twitterでアプリ連携する=自分の家の合鍵を他人に預ける
のと同じ
● パーミッションが広いと意識の高いユーザが不安に思
う
○ 懐中電灯アプリで電話帳やGPSにパーミッションがあるの
と同じような感じ
● 下手すると事案に発展する可能性がある

ここで他社事例を見てみ
ましょう

セーフｗ

アウトおおおおおおおおおおおお

アウトおおおおおおおおおおお

もし間違えて認証しちゃったら
● https://twitter.com/settings/applications で認証を取り消せ
ばok

【重要事項】
● アプリのパーミッションは一応変更出来る
○ 変更するとユーザから取得したaccess tokenは全部無効
になる
○ 認証を事前に取得しておいて後から使うような使い方だ
と、途中でパーミッションを変えると死ぬ
● それ以外の情報（アプリ名やアイコンなど）は途中で変えても
問題なし

よくある質問
● Q. 失敗談
○ A. 1回だけ間違えて本番落としたｗ
○ その時点ではまだデプロイしてはいけないものを間違え
て本番に上げた
○ cap deploy:rollback は神
○ 【教訓】何かあってから命綱を作るのは手遅れ。命綱は常
に整備しておくべき
● Q. 最初からRedisメインにしようと思った？
○ 「一定時間で回数リセット」って仕様聞いた時にKVS使っ
た方がいいような予感はしてた
○ 既存アプリだとDBがボトルネックで詰まるのをよく見てた
ので、極力DBを使わない構成にしたかった

【結論】

用途を絞ればKVS最強

エピローグ

フラゲガチャが正式に事業化された
https://flyinggacha.com/

● 他部署が運用してるので僕はノータッチ
● ベースは全く一緒だけどフルボッコでまずかった部分を改良
してくれてる（感謝）
● 2～3ヶ月で切り捨てる想定で設計したシステムを引き継がせ
てしまって心が痛む('A`)
○ 後からちゃんと改修してくれた
● Twitterを使った事前登録したい場合には是非弊社にお声が
けを！
○ https://www.drecom.co.jp/contact/form/

あわせて読みたい
ドリコムを支えるインフラ
● drecomにおけるwinning the metrics battle
○ http://www.slideshare.
net/KenichiMitsuki/ss-35379098
● ドリコムのInfrastructure as code
○ http://www.slideshare.
net/y05_net/infrastructure-as-code-
35373108

会社概要
社名：
証券コード：
本社：
電話番号：
社員数：
設立年月日：
資本金：
事業内容：
株式会社ドリコム
3793　東証マザーズ
〒153-0064
東京都目黒区下目黒１丁目8-1　アルコタワー17F
TEL:03-6682-5700　FAX:03-6682-5711
239名（正社員・契約社員のみ）
2001年11月13日
1,124百万円
(2014年3月末現在)
ソーシャルゲーム事業
ソーシャルラーニング事業
アドソリューション事業

ご静聴ありがとうございました！

Resemaraを支えた技術フライングゲットガチャの舞台裏 #ksgstudy #ドリコム

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Resemaraを支えた技術フライングゲットガチャの舞台裏 #ksgstudy #ドリコム

Similar to Resemaraを支えた技術フライングゲットガチャの舞台裏 #ksgstudy #ドリコム (20)

More from Go Sueyoshi (a.k.a sue445)

More from Go Sueyoshi (a.k.a sue445) (15)