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

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)

フラゲガチャのKVS構成（サーバ節約）

web-02

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

gachasgacha_histories

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

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

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回までなので焼け石に水

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/

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

Documents

裏面 · title: 裏面 created date: 11/16/2016 8:35:36 pm

チラシ裏title チラシ裏 created date 4/28/2016...

filemaker server...

ドリコムとサイバーコネクトツー、「フルボッコ...

チラシ裏title チラシ裏 created date 10/31/2014...

jeugia2019秋 b3裏...

裏 - yamaguchi utitle 裏 created date 6/5/2017 9:15:11 am

1130 裏込・裏埋工 - hokkaido...1130 裏込・裏埋工...

世界最大規模ibm x...

デザインの裏のデザインの裏のデザイン -...

オートローン裏...title オートローン_裏...

uist2016の舞台裏 (uist勉強会講演1/2)

ameba」サービスの舞台裏 -...

國際標準摩登舞之狐步舞與快步舞技巧分析shl.tpcu.edu.tw/ezfiles/24/1024/img/455/05.pdf ·...

裏ol - hibititle 裏ol created date 6/28/2016 11:19:23 am

opsworks事例紹介！ソニックガーデンのリモートワークを支えるリアルタイムツール”remotty”の舞台裏（2014/03/15...

【デブサミ関西b4】...

チラシパリ裏title チラシパリ裏 created date...

03 裏title 03_裏 created date 8/22/2014 11:08:53 am

アダージョオープニング裏title...

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

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