More Related Content Similar to Resemaraを支えた技術 フライングゲットガチャの舞台裏 #ksgstudy #ドリコム (20) More from Go Sueyoshi (a.k.a sue445) (15) Resemaraを支えた技術 フライングゲットガチャの舞台裏 #ksgstudy #ドリコム2. Copyright Drecom Co., Ltd. All Rights Reserved.
自己紹介
sue445
● ドリコム サービス基盤部
○ 主に社内ツール、社内ライブラリ系
○ ガルロワ、フルボッコ、ジョジョSS、トレクルなど、最近のネ
イティブアプリの課金決済系ライブラリ作ってます
○ たまにインフラ
● Ruby歴2年のルビーチョットデキルエンジニア
● 当時ドリコム入社1年半にして今回初めてガチャを作った(重
要)
● 好きな言語はJava(重要)
● 自称:TDDマニアなキュアエンジニア
3. Copyright Drecom Co., Ltd. All Rights Reserved.
趣味で作ってるもの
● 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 !
4. Copyright Drecom Co., Ltd. All Rights Reserved.
【CM】ワタシハ テスト チョットデキルTシャツ
エンジニアならチェックしておきたい技術系Tシャツまと
め - くりにっき
12. Copyright Drecom Co., Ltd. All Rights Reserved.
アジェンダ
● リセマラ is 何
● 開発体制
● 実績
● アプリの構成
● 工夫したこと
● Twitter APIの闇
● よくある質問
● エピローグ
13. Copyright Drecom Co., Ltd. All Rights Reserved.
リセマラ is 何
● 「リセットマラソン」の略
● パズドラとかでゲーム開始直後にもらえるカードがランダムな
ので、強いユニットが貰えるまでインストールとアンインストー
ルを繰り返すこと
● 中の人的にはインストールユーザと実際のユーザの剥離が
出るのでつらい。。。
14. Copyright Drecom Co., Ltd. All Rights Reserved.
ゲームリリース前に公式でリセマラできるようにしたw
当時のドメインも resemara.fullbokko.drecom.jp
15. Copyright Drecom Co., Ltd. All Rights Reserved.
Attention!!
● ここに掲載してる技術情報は2014年3月時点のものなので
若干古いです
○ 事前登録期間が2013年12月~2014年2月のため
18. Copyright Drecom Co., Ltd. All Rights Reserved.
詳しいこと
● フライングゲットガチャ セミナー資料
○ http://www.slideshare.net/drecom/drecom-20140225-
seminar-31882381
● 【ドリコムセミナーレポート】『フライングゲットガチャ』はなぜ成
功したのか? マーケティング担当者がその秘訣を語る。 |
Social Game Info
○ http://gamebiz.jp/?p=127470
19. Copyright Drecom Co., Ltd. All Rights Reserved.
メンバー
● 開発 x 1
○ sue445(サーバ周り全部)
○ ガチャ演出周りで助っ人(2週間くらい)
● デザイン x 1
○ 絵とコーディング回り
● 企画 x 1
● 開発計1ヶ月弱くらい
○ 途中で仕様変更が何回もあったので実開発は2週間くら
い
20. Copyright Drecom Co., Ltd. All Rights Reserved.
実績
● Twitter/Facebook認証数
○ 約10万人
● 事前登録数:48万人
○ 業界最多?(たぶん)
● ガチャ総回転数
○ 996万回
○ 瞬間最大風速0:00~0:10でガチャ13500回転くらい
21. Copyright Drecom Co., Ltd. All Rights Reserved.
本番環境の構成
● 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
● 負荷が読めないのでとりあえずミニマムスタートしてみたが
割となんとかなった
22. Copyright Drecom Co., Ltd. All Rights Reserved.
よくあるKVS構成
web-xx web-xx job-xx job-xx
redis-01
(Master)
redis-02
(Slave)
VIP
23. Copyright Drecom Co., Ltd. All Rights Reserved.
フラゲガチャのKVS構成(サーバ節約)
web-02
VIP
web-01
redis(M) redis(S)
自分自身にVIPをつけるこ
とで最低限の台数でHA構
成を構築
24. Copyright Drecom Co., Ltd. All Rights Reserved.
ステージング環境の構成
● Debian Wheezy
● OpenStackの自分用Railsアプリ頻出ミドル全部入りスナップ
ショットからインスタンス立てて環境構築
○ nginx, mysql, redis, memcached, git, tmux, 自分の
dotfilesなど
● 詳しくは弊社外道父のブログ参照
○ OpenStackでつくる開発環境と外道塾 発表資料 | 外道
父の匠
25. Copyright Drecom Co., Ltd. All Rights Reserved.
アプリ周り
● Ruby 2.0.0-p353 + Rails 4.0.2
○ リリース当時(2013/12/16)では最新
○ 途中で2.1.0出たけど数ヶ月でお役御免だったのでス
ルー
● capistrano 3
○ v2 -> v3で全部変わってたのでtaskを全部書き直した
○ webサーバ2台なのにクラスタリスタート作ったw
○ 開発期間短いながらも自分のアプリで人柱になって、有
志の手により社内gem化された
26. Copyright Drecom Co., Ltd. All Rights Reserved.
機能
作った
● 事前登録
● リセマラガチャ
● シリアル生成
● DM送信
作ってない
● レポート系(工数削減のため)
○ GoogleAnalytics
○ fluentd (事前登録とガチャ)
● メンテナンス画面
○ 忘れてたw
29. Copyright Drecom Co., Ltd. All Rights Reserved.
事前登録
仕様
● 認証不要
● 「事前登録する」のPOSTの度に一意なシリアルコードを作る
● シリアルコードがiOSかAndroidかアプリ側で識別したい
問題点
● 表示したシリアルを全部DBに突っ込んでたら死ぬ(容量的に
も負荷的にも)
● 認証かかってないため、GoogleのクローラとかがPOSTする
と事前登録数が水増しされてしまう
30. Copyright Drecom Co., Ltd. All Rights Reserved.
表示したシリアルを全部DBに突っ込んでたら死ぬ問題
解:シリアルコードの暗号・復号化社内ライブラリ使った
● 別アプリで作ってたのを流用
● 見た目は12文字の数字だけど、39ビット分の情報を持たせ、
報酬IDや連番も含ませたり整合性チェックもできるようにした
● 連番をredis counterで持たせた
○ iOSとAndroid各1つずつ
○ 本当なら発行したシリアルを全部DBにINSERTするとこ
ろだが、redis counterを2つだけ使うだけで万事解決
31. Copyright Drecom Co., Ltd. All Rights Reserved.
クローラによる水増し問題
● bodyにformタグを全て含めないことで、スクレイピングしただ
けではボタンを押せないようにした
● Ajax使えばクローラはだいたいごまかせる(気がする)
● 後発の他社の事前登録ガチャはこの対策してないように見
えた
32. Copyright Drecom Co., Ltd. All Rights Reserved.
クローラによる水増し問題
HTML上はformタグ
のactionが空
onclickでsubmit直前
に設定する
35. Copyright Drecom Co., Ltd. All Rights Reserved.
リセマラガチャ
問題点
● 6時間ごとにworkerで全ユーザのガチャ回数リセットすると
ユーザ増えた時に処理に時間がかかって死ぬ
● ガチャ回す度にヒストリレコードINSERT&ガチャ総回転数
UPDATEしたらDBが負荷で死ぬ
● Twitterの性質上バズると局所的にアクセスが来るため負荷
が読めない
● そもそもの仕様が複雑 (;´Д`)
38. Copyright Drecom Co., Ltd. All Rights Reserved.
画面表示でSELECTすらしてないwww
redis counter
redis counter
redis counter
redis counter
(with expire)
39. Copyright Drecom Co., Ltd. All Rights Reserved.
ガチャ回す時は3種類のカウンタを同時に増やす
全員の総回
転数++
自分の回転数++
1ターム内のガチャ回数++
40. Copyright Drecom Co., Ltd. All Rights Reserved.
MySQL使ってるのはたったこれだけ
● ユーザ認証
○ 認証後にtwitterのaccess tokenをユーザマスタに入れる
● POSTする時にcurrent userでロック(SELECT ~ FOR
UPDATE)
○ パワーアタック系のチート対策
○ 1ユーザで複数同時に処理を走らせない
● ユニット確定時に報酬レコードをINSERTする
41. Copyright Drecom Co., Ltd. All Rights Reserved.
よくあるガチャのテーブル構成(適当)
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
42. Copyright Drecom Co., Ltd. All Rights Reserved.
リセマラガチャのテーブル構成
users
user_rewa
rds
rewards
1 n n 1
● rewards = cards + gachas
○ 今回はガチャ1つしかやらないので分ける必要もなかった
○ rewardsをガチャの度に全件取得するコストが心配だった
が、ガチャで使う最低限のカラムしかないため余裕だった
● ガチャ履歴もログに出してfluentdで送るようにしたのでガ
チャのhistoryテーブルも不要
43. Copyright Drecom Co., Ltd. All Rights Reserved.
redis内訳
users (各ユーザに対してカウンタが設定)
● ガチャ合計回転数
● 1ターム内のガチャ回転数
○ 0, 6, 12, 18時にexpire
● 1ターム内のリセット回数
○ 0, 6, 12, 18時にexpire
ユーザに紐付かない系
● シリアルコード内の連番(iOS, Androidそれぞれ)
○ 事前登録する度にインクリメント
○ 事前登録数はこれの合計
● 全ユーザ合計のガチャ回転数
● ★5(一番レアリティの高いユニット)の放出数
44. Copyright Drecom Co., Ltd. All Rights Reserved.
redisの値に有効期限をつける方法
EXPIRE key sec or EXPIREAT key unixtime
● リセマラでは後者を利用
● redis-objectsのドキュメントには一切書いてなかったがソー
ス見たら実装されてた
○ ただしunixtimeなので Time#to_i して渡す
● ガチャ回す時にINCRとEXPIREATを同時に使う
● 現在時間を元に次の6時, 12時 … を算出するのが一番大変
だったw
○ 時間のテストはdelorean最強
○ https://github.com/bebanjo/delorean
48. Copyright Drecom Co., Ltd. All Rights Reserved.
Twitter APIの闇
1. 凍結済ユーザの判別が困難な問題
2. DM送信コストが結構高い件について
3. アプリのパーミッションが大雑把な問題
49. Copyright Drecom Co., Ltd. All Rights Reserved.
1. 凍結済ユーザの判別が困難な問題
他ユーザから凍結済ユーザを見ようとすると403(エラー
(Forbidden)になるが、凍結済ユーザ自身は普通に見れ
る
51. Copyright Drecom Co., Ltd. All Rights Reserved.
何が問題か?
● 凍結済でもTwitterで認証してログインできる
● ガチャ回せる
● つぶやく時に初めてエラーになる
○ 調べたら凍結済ユーザでもGET系は全部大丈夫
で、POST系が全部失敗。。。
● 事前登録終了後にDMでシリアルコードを送れない
○ CSのコストup
52. Copyright Drecom Co., Ltd. All Rights Reserved.
結局どうした?
諦めた(キリッ
● 公式アカウント(@fullbokkoheroes)経由でチェックす
るにしてもRateLimitがあるので限界がある
● 15分間で180回までなので焼け石に水
53. Copyright Drecom Co., Ltd. All Rights Reserved.
2. DM送信コストが結構高い件について
● ユニットを確定してたら事前登録終了後にDMでシリアルを送
る
● 年末にDMを送ったら1時間半で7000通しか送れなかった
○ 秒速1.3通
○ Twitter API叩くコストが意外に高い
● 発行したシリアルは50000枚
○ ガチャ35000枚, お年玉15000枚
○ このままだと全部DM送るのに65000秒(=18時間)かかる
ことにw
○ ヤバイ
54. Copyright Drecom Co., Ltd. All Rights Reserved.
【解決方法】並列送信
● redisは使ってたけどSidekiqやResque(Rubyの並列処理の
ライブラリ)は入れていなかったので昔ながらのThreadを使っ
た
○ 数回しか使わないスクリプトのためだけにセットアップす
るのが抵抗あった
● 普通にやるとThreadが一度に全実行されるため同時実行す
るスレッド数を制限する必要ある
○ サーバの負荷とAPI実行時の帯域がやばい
55. Copyright Drecom Co., Ltd. All Rights Reserved.
【解決方法】並列送信
● ruby-threadのThread pool使った
○ 20スレッドでDM45000通送るのに約40分
○ 秒速18通
● jobサーバがないのでDM送信の度に本番のwebを1台切り
離して即席jobサーバにしてた(つらい)
○ ピーク時避ければweb1台でも耐えられた
● rubyのプロセスだけでCPU 50〜60%くらい使った
● SidekiqやResqueでqueueの数制限するのが大正解
56. Copyright Drecom Co., Ltd. All Rights Reserved.
3. アプリのパーミッションが大雑把な問題
Twitterアプリのパーミッションは大きく分けて3種類
● Read only
○ GETは出来るがPOSTはダメ
○ 例)Twilog
● Read and write
○ GETとPOSTはOK
○ DMは送信出来るが受信は出来ない
○ 例)ボット
● Read, Write and Access direct messages
○ ↑ + DM送受信OK
○ 例)普通のTwitterクライアント
57. Copyright Drecom Co., Ltd. All Rights Reserved.
適切なパーミッションって?
アプリの仕様上つぶやきとDM送
信できればいいのでRead and
writeが適切(重要)
58. Copyright Drecom Co., Ltd. All Rights Reserved.
アプリに適切なパーミッションが大事
● 不要なパーミッションはつけない
○ 何も考えずに適当に「Read, Write and Access direct
messages」にするのはセキュリティ的によろしくない
○ twitterでアプリ連携する=自分の家の合鍵を他人に預ける
のと同じ
● パーミッションが広いと意識の高いユーザが不安に思
う
○ 懐中電灯アプリで電話帳やGPSにパーミッションがあるの
と同じような感じ
● 下手すると事案に発展する可能性がある
63. Copyright Drecom Co., Ltd. All Rights Reserved.
もし間違えて認証しちゃったら
● https://twitter.com/settings/applications で認証を取り消せ
ばok
64. Copyright Drecom Co., Ltd. All Rights Reserved.
【重要事項】
● アプリのパーミッションは一応変更出来る
○ 変更するとユーザから取得したaccess tokenは全部無効
になる
○ 認証を事前に取得しておいて後から使うような使い方だ
と、途中でパーミッションを変えると死ぬ
● それ以外の情報(アプリ名やアイコンなど)は途中で変えても
問題なし
65. Copyright Drecom Co., Ltd. All Rights Reserved.
よくある質問
● Q. 失敗談
○ A. 1回だけ間違えて本番落としたw
○ その時点ではまだデプロイしてはいけないものを間違え
て本番に上げた
○ cap deploy:rollback は神
○ 【教訓】何かあってから命綱を作るのは手遅れ。命綱は常
に整備しておくべき
● Q. 最初からRedisメインにしようと思った?
○ 「一定時間で回数リセット」って仕様聞いた時にKVS使っ
た方がいいような予感はしてた
○ 既存アプリだとDBがボトルネックで詰まるのをよく見てた
ので、極力DBを使わない構成にしたかった
70. Copyright Drecom Co., Ltd. All Rights Reserved.
● 他部署が運用してるので僕はノータッチ
● ベースは全く一緒だけどフルボッコでまずかった部分を改良
してくれてる(感謝)
● 2~3ヶ月で切り捨てる想定で設計したシステムを引き継がせ
てしまって心が痛む('A`)
○ 後からちゃんと改修してくれた
● Twitterを使った事前登録したい場合には是非弊社にお声が
けを!
○ https://www.drecom.co.jp/contact/form/
71. Copyright Drecom Co., Ltd. All Rights Reserved.
あわせて読みたい
ドリコムを支えるインフラ
● 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