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

18,212 views

Published on

関西ソーシャルゲーム勉強会・2014夏 - 関西ソーシャルゲーム勉強会 Doorkeeper ( http://ksgs.doorkeeper.jp/events/11635 ) で発表した資料です

Blog: http://sue445.hatenablog.com/entry/2014/07/12/204741

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

  1. 1. Copyright Drecom Co., Ltd. All Rights Reserved. 2014/07/12 @sue445 関西ソーシャルゲーム勉強会・2014夏
  2. 2. Copyright Drecom Co., Ltd. All Rights Reserved. 自己紹介 sue445 ● ドリコム サービス基盤部 ○ 主に社内ツール、社内ライブラリ系 ○ ガルロワ、フルボッコ、ジョジョSS、トレクルなど、最近のネ イティブアプリの課金決済系ライブラリ作ってます ○ たまにインフラ ● Ruby歴2年のルビーチョットデキルエンジニア ● 当時ドリコム入社1年半にして今回初めてガチャを作った(重 要) ● 好きな言語はJava(重要) ● 自称:TDDマニアなキュアエンジニア
  3. 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. 4. Copyright Drecom Co., Ltd. All Rights Reserved. 【CM】ワタシハ テスト チョットデキルTシャツ エンジニアならチェックしておきたい技術系Tシャツまと め - くりにっき
  5. 5. Copyright Drecom Co., Ltd. All Rights Reserved. 【CM】フルボッコヒーローズ http://official.fullbokko.drecom.jp/
  6. 6. Copyright Drecom Co., Ltd. All Rights Reserved.
  7. 7. Copyright Drecom Co., Ltd. All Rights Reserved. 今期の嫁: キュアハニー
  8. 8. Copyright Drecom Co., Ltd. All Rights Reserved. 本妻: キュアピース
  9. 9. 【最近のお気に入り】枕嫁
  10. 10. チラリズムよい
  11. 11. 【CM】プリキュアハッカソン2 開催!@弊社 http://connpass.com/event/7181/
  12. 12. Copyright Drecom Co., Ltd. All Rights Reserved. アジェンダ ● リセマラ is 何 ● 開発体制 ● 実績 ● アプリの構成 ● 工夫したこと ● Twitter APIの闇 ● よくある質問 ● エピローグ
  13. 13. Copyright Drecom Co., Ltd. All Rights Reserved. リセマラ is 何 ● 「リセットマラソン」の略 ● パズドラとかでゲーム開始直後にもらえるカードがランダムな ので、強いユニットが貰えるまでインストールとアンインストー ルを繰り返すこと ● 中の人的にはインストールユーザと実際のユーザの剥離が 出るのでつらい。。。
  14. 14. Copyright Drecom Co., Ltd. All Rights Reserved. ゲームリリース前に公式でリセマラできるようにしたw 当時のドメインも resemara.fullbokko.drecom.jp
  15. 15. Copyright Drecom Co., Ltd. All Rights Reserved. Attention!! ● ここに掲載してる技術情報は2014年3月時点のものなので 若干古いです ○ 事前登録期間が2013年12月~2014年2月のため
  16. 16. Copyright Drecom Co., Ltd. All Rights Reserved. 解決策 実演
  17. 17. Copyright Drecom Co., Ltd. All Rights Reserved. Twitterで認証してつぶやけば何回でもガチャ回せる
  18. 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. 19. Copyright Drecom Co., Ltd. All Rights Reserved. メンバー ● 開発 x 1 ○ sue445(サーバ周り全部) ○ ガチャ演出周りで助っ人(2週間くらい) ● デザイン x 1 ○ 絵とコーディング回り ● 企画 x 1 ● 開発計1ヶ月弱くらい ○ 途中で仕様変更が何回もあったので実開発は2週間くら い
  20. 20. Copyright Drecom Co., Ltd. All Rights Reserved. 実績 ● Twitter/Facebook認証数 ○ 約10万人 ● 事前登録数:48万人 ○ 業界最多?(たぶん) ● ガチャ総回転数 ○ 996万回 ○ 瞬間最大風速0:00~0:10でガチャ13500回転くらい
  21. 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. 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. 23. Copyright Drecom Co., Ltd. All Rights Reserved. フラゲガチャのKVS構成(サーバ節約) web-02 VIP web-01 redis(M) redis(S) 自分自身にVIPをつけるこ とで最低限の台数でHA構 成を構築
  24. 24. Copyright Drecom Co., Ltd. All Rights Reserved. ステージング環境の構成 ● Debian Wheezy ● OpenStackの自分用Railsアプリ頻出ミドル全部入りスナップ ショットからインスタンス立てて環境構築 ○ nginx, mysql, redis, memcached, git, tmux, 自分の dotfilesなど ● 詳しくは弊社外道父のブログ参照 ○ OpenStackでつくる開発環境と外道塾 発表資料 | 外道 父の匠
  25. 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. 26. Copyright Drecom Co., Ltd. All Rights Reserved. 機能 作った ● 事前登録 ● リセマラガチャ ● シリアル生成 ● DM送信 作ってない ● レポート系(工数削減のため) ○ GoogleAnalytics ○ fluentd (事前登録とガチャ) ● メンテナンス画面 ○ 忘れてたw
  27. 27. Copyright Drecom Co., Ltd. All Rights Reserved. 工夫したこと ● 事前登録 ● リセマラガチャ ● TwitterのDM大量送信
  28. 28. Copyright Drecom Co., Ltd. All Rights Reserved. 事前登録
  29. 29. Copyright Drecom Co., Ltd. All Rights Reserved. 事前登録 仕様 ● 認証不要 ● 「事前登録する」のPOSTの度に一意なシリアルコードを作る ● シリアルコードがiOSかAndroidかアプリ側で識別したい 問題点 ● 表示したシリアルを全部DBに突っ込んでたら死ぬ(容量的に も負荷的にも) ● 認証かかってないため、GoogleのクローラとかがPOSTする と事前登録数が水増しされてしまう
  30. 30. Copyright Drecom Co., Ltd. All Rights Reserved. 表示したシリアルを全部DBに突っ込んでたら死ぬ問題 解:シリアルコードの暗号・復号化社内ライブラリ使った ● 別アプリで作ってたのを流用 ● 見た目は12文字の数字だけど、39ビット分の情報を持たせ、 報酬IDや連番も含ませたり整合性チェックもできるようにした ● 連番をredis counterで持たせた ○ iOSとAndroid各1つずつ ○ 本当なら発行したシリアルを全部DBにINSERTするとこ ろだが、redis counterを2つだけ使うだけで万事解決
  31. 31. Copyright Drecom Co., Ltd. All Rights Reserved. クローラによる水増し問題 ● bodyにformタグを全て含めないことで、スクレイピングしただ けではボタンを押せないようにした ● Ajax使えばクローラはだいたいごまかせる(気がする) ● 後発の他社の事前登録ガチャはこの対策してないように見 えた
  32. 32. Copyright Drecom Co., Ltd. All Rights Reserved. クローラによる水増し問題 HTML上はformタグ のactionが空 onclickでsubmit直前 に設定する
  33. 33. Copyright Drecom Co., Ltd. All Rights Reserved. リセマラガチャ
  34. 34. Copyright Drecom Co., Ltd. All Rights Reserved. リセマラガチャ 仕様が複雑
  35. 35. Copyright Drecom Co., Ltd. All Rights Reserved. リセマラガチャ 問題点 ● 6時間ごとにworkerで全ユーザのガチャ回数リセットすると ユーザ増えた時に処理に時間がかかって死ぬ ● ガチャ回す度にヒストリレコードINSERT&ガチャ総回転数 UPDATEしたらDBが負荷で死ぬ ● Twitterの性質上バズると局所的にアクセスが来るため負荷 が読めない ● そもそもの仕様が複雑 (;´Д`)
  36. 36. Copyright Drecom Co., Ltd. All Rights Reserved. 解決策 全部redisでよくね?
  37. 37. Copyright Drecom Co., Ltd. All Rights Reserved. リセマラガチャ
  38. 38. Copyright Drecom Co., Ltd. All Rights Reserved. 画面表示でSELECTすらしてないwww redis counter redis counter redis counter redis counter (with expire)
  39. 39. Copyright Drecom Co., Ltd. All Rights Reserved. ガチャ回す時は3種類のカウンタを同時に増やす 全員の総回 転数++ 自分の回転数++ 1ターム内のガチャ回数++
  40. 40. Copyright Drecom Co., Ltd. All Rights Reserved. MySQL使ってるのはたったこれだけ ● ユーザ認証 ○ 認証後にtwitterのaccess tokenをユーザマスタに入れる ● POSTする時にcurrent userでロック(SELECT ~ FOR UPDATE) ○ パワーアタック系のチート対策 ○ 1ユーザで複数同時に処理を走らせない ● ユニット確定時に報酬レコードをINSERTする
  41. 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. 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. 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. 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
  45. 45. Copyright Drecom Co., Ltd. All Rights Reserved. expireつけた結果 ガチャリセットのかかる0時, 6時, 12時, 18時きっかりに山ができ てるw
  46. 46. Copyright Drecom Co., Ltd. All Rights Reserved. cacti @db ピーク時でもCPU使用 率0.14% www
  47. 47. Copyright Drecom Co., Ltd. All Rights Reserved. cacti @web LAもピーク時で1〜2くらい
  48. 48. Copyright Drecom Co., Ltd. All Rights Reserved. Twitter APIの闇 1. 凍結済ユーザの判別が困難な問題 2. DM送信コストが結構高い件について 3. アプリのパーミッションが大雑把な問題
  49. 49. Copyright Drecom Co., Ltd. All Rights Reserved. 1. 凍結済ユーザの判別が困難な問題 他ユーザから凍結済ユーザを見ようとすると403(エラー (Forbidden)になるが、凍結済ユーザ自身は普通に見れ る
  50. 50. Copyright Drecom Co., Ltd. All Rights Reserved. @sue445_sst5 が凍結済ユーザ
  51. 51. Copyright Drecom Co., Ltd. All Rights Reserved. 何が問題か? ● 凍結済でもTwitterで認証してログインできる ● ガチャ回せる ● つぶやく時に初めてエラーになる ○ 調べたら凍結済ユーザでもGET系は全部大丈夫 で、POST系が全部失敗。。。 ● 事前登録終了後にDMでシリアルコードを送れない ○ CSのコストup
  52. 52. Copyright Drecom Co., Ltd. All Rights Reserved. 結局どうした? 諦めた(キリッ ● 公式アカウント(@fullbokkoheroes)経由でチェックす るにしてもRateLimitがあるので限界がある ● 15分間で180回までなので焼け石に水
  53. 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. 54. Copyright Drecom Co., Ltd. All Rights Reserved. 【解決方法】並列送信 ● redisは使ってたけどSidekiqやResque(Rubyの並列処理の ライブラリ)は入れていなかったので昔ながらのThreadを使っ た ○ 数回しか使わないスクリプトのためだけにセットアップす るのが抵抗あった ● 普通にやるとThreadが一度に全実行されるため同時実行す るスレッド数を制限する必要ある ○ サーバの負荷とAPI実行時の帯域がやばい
  55. 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. 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. 57. Copyright Drecom Co., Ltd. All Rights Reserved. 適切なパーミッションって? アプリの仕様上つぶやきとDM送 信できればいいのでRead and writeが適切(重要)
  58. 58. Copyright Drecom Co., Ltd. All Rights Reserved. アプリに適切なパーミッションが大事 ● 不要なパーミッションはつけない ○ 何も考えずに適当に「Read, Write and Access direct messages」にするのはセキュリティ的によろしくない ○ twitterでアプリ連携する=自分の家の合鍵を他人に預ける のと同じ ● パーミッションが広いと意識の高いユーザが不安に思 う ○ 懐中電灯アプリで電話帳やGPSにパーミッションがあるの と同じような感じ ● 下手すると事案に発展する可能性がある
  59. 59. Copyright Drecom Co., Ltd. All Rights Reserved. ここで他社事例を見てみ ましょう
  60. 60. Copyright Drecom Co., Ltd. All Rights Reserved. セーフw
  61. 61. Copyright Drecom Co., Ltd. All Rights Reserved. アウトおおおおおおおおおおおお
  62. 62. Copyright Drecom Co., Ltd. All Rights Reserved. アウトおおおおおおおおおおお
  63. 63. Copyright Drecom Co., Ltd. All Rights Reserved. もし間違えて認証しちゃったら ● https://twitter.com/settings/applications で認証を取り消せ ばok
  64. 64. Copyright Drecom Co., Ltd. All Rights Reserved. 【重要事項】 ● アプリのパーミッションは一応変更出来る ○ 変更するとユーザから取得したaccess tokenは全部無効 になる ○ 認証を事前に取得しておいて後から使うような使い方だ と、途中でパーミッションを変えると死ぬ ● それ以外の情報(アプリ名やアイコンなど)は途中で変えても 問題なし
  65. 65. Copyright Drecom Co., Ltd. All Rights Reserved. よくある質問 ● Q. 失敗談 ○ A. 1回だけ間違えて本番落としたw ○ その時点ではまだデプロイしてはいけないものを間違え て本番に上げた ○ cap deploy:rollback は神 ○ 【教訓】何かあってから命綱を作るのは手遅れ。命綱は常 に整備しておくべき ● Q. 最初からRedisメインにしようと思った? ○ 「一定時間で回数リセット」って仕様聞いた時にKVS使っ た方がいいような予感はしてた ○ 既存アプリだとDBがボトルネックで詰まるのをよく見てた ので、極力DBを使わない構成にしたかった
  66. 66. Copyright Drecom Co., Ltd. All Rights Reserved. 【結論】
  67. 67. Copyright Drecom Co., Ltd. All Rights Reserved. 用途を絞ればKVS最強
  68. 68. Copyright Drecom Co., Ltd. All Rights Reserved. エピローグ
  69. 69. Copyright Drecom Co., Ltd. All Rights Reserved. フラゲガチャが正式に事業化された https://flyinggacha.com/
  70. 70. Copyright Drecom Co., Ltd. All Rights Reserved. ● 他部署が運用してるので僕はノータッチ ● ベースは全く一緒だけどフルボッコでまずかった部分を改良 してくれてる(感謝) ● 2~3ヶ月で切り捨てる想定で設計したシステムを引き継がせ てしまって心が痛む('A`) ○ 後からちゃんと改修してくれた ● Twitterを使った事前登録したい場合には是非弊社にお声が けを! ○ https://www.drecom.co.jp/contact/form/
  71. 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
  72. 72. 会社概要 社名: 証券コード: 本社: 電話番号: 社員数: 設立年月日: 資本金: 事業内容: 株式会社ドリコム 3793 東証マザーズ 〒153-0064 東京都目黒区下目黒1丁目8-1 アルコタワー17F TEL:03-6682-5700 FAX:03-6682-5711 239名 (正社員・契約社員のみ) 2001年11月13日 1,124百万円 (2014年3月末現在) ソーシャルゲーム事業 ソーシャルラーニング事業 アドソリューション事業 Copyright Drecom Co., Ltd. All Rights Reserved.
  73. 73. Copyright Drecom Co., Ltd. All Rights Reserved. ご静聴ありがとうございました!

×