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

Copyright Drecom Co., Ltd. All Rights Reserved.

2014/07/12 @sue445関西ソーシャルゲーム勉強会・２０１４夏


自己紹介

sue445● ドリコム　サービス基盤部

○ 主に社内ツール、社内ライブラリ系○ ガルロワ、フルボッコ、ジョジョSS、トレクルなど、最近のネ

イティブアプリの課金決済系ライブラリ作ってます○ たまにインフラ

● Ruby歴2年のルビーチョットデキルエンジニア● 当時ドリコム入社1年半にして今回初めてガチャを作った（重

要）● 好きな言語はJava（重要）● 自称：TDDマニアなキュアエンジニア

http://official.fdfp.drecom.jp/

http://official.fullbokko.drecom.jp/

http://jojoss.bngames.net/

http://www.bandaigames.channel.or.jp/list/one_main/tc/


趣味で作ってるもの

● 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 !

https://github.com/sue445/rubicure

https://github.com/sue445/rubicure

https://github.com/sue445/gitpeach

https://github.com/sue445/gitpeach

https://github.com/sue445/chrome-gitlab-notifier

https://github.com/sue445/chrome-gitlab-notifier


【CM】ワタシハテストチョットデキルTシャツ

エンジニアならチェックしておきたい技術系Tシャツまとめ - くりにっき

http://sue445.hatenablog.com/entry/2014/07/03/111519





【CM】フルボッコヒーローズ





今期の嫁: キュアハニー


本妻: キュアピース

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

チラリズムよい

【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

http://www.slideshare.net/drecom/drecom-20140225-seminar-31882381



http://gamebiz.jp/?p=127470

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でつくる開発環境と外道塾発表資料 | 外道父の匠

http://blog.father.gedow.net/2013/07/24/openstack-gedow-school-and-development-environment/




アプリ周り

● 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 counterredis counter

redis counter

redis counter (with expire)


ガチャ回す時は3種類のカウンタを同時に増やす

全員の総回転数++

自分の回転数++

1ターム内のガチャ回数++


MySQL使ってるのはたったこれだけ

● ユーザ認証○ 認証後にtwitterのaccess tokenをユーザマスタに入れる

● POSTする時にcurrent userでロック(SELECT ～ FOR UPDATE)○ パワーアタック系のチート対策○ 1ユーザで複数同時に処理を走らせない

● ユニット確定時に報酬レコードをINSERTする


よくあるガチャのテーブル構成（適当）

users user_cards

gacha_cards

1　n n　　　1

cards

gachasgacha_histories

1 n

n

1

n 1

1

n

n 1


リセマラガチャのテーブル構成

users user_rewards 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

https://github.com/nateware/redis-objects

https://github.com/bebanjo/delorean

https://github.com/bebanjo/delorean


expireつけた結果

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


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


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


Twitter APIの闇

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


1. 凍結済ユーザの判別が困難な問題

他ユーザから凍結済ユーザを見ようとすると403(エラー(Forbidden)になるが、凍結済ユーザ自身は普通に見れる


@sue445_sst5 が凍結済ユーザ


何が問題か？

● 凍結済でもTwitterで認証してログインできる● ガチャ回せる● つぶやく時に初めてエラーになる

○ 調べたら凍結済ユーザでもGET系は全部大丈夫で、POST系が全部失敗。。。

● 事前登録終了後にDMでシリアルコードを送れない○ CSのコストup


結局どうした？

諦めた(ｷﾘｯ

● 公式アカウント(@fullbokkoheroes)経由でチェックするにしてもRateLimitがあるので限界がある

● 15分間で180回までなので焼け石に水

https://twitter.com/fullbokkoheroes


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の数制限するのが大正解

https://github.com/meh/ruby-thread

https://github.com/meh/ruby-thread


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

https://twitter.com/settings/applications


【重要事項】

● アプリのパーミッションは一応変更出来る○ 変更するとユーザから取得した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/

https://www.drecom.co.jp/contact/form/

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

http://www.slideshare.net/KenichiMitsuki/ss-35379098



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 #ドリコム

Documents

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