とあるアプリの開発運用(トラブルシュート)

Copyright © DRECOM Co., Ltd All Rights Reserved.RailsDevCon 2010

2010/11/20

Copyright © DRECOM Co., Ltd All Rights Reserved. 2222

自己

紹介


株式会社ドリコム

ソーシャルゲーム開発デザイン部

大仲能史

@onk


株式会社ドリコム

ソーシャルゲーム開発デザイン部

大仲能史

@onk

ソーシャルゲームの企画と開発


ソーシャルゲームとは


ソーシャルゲームとは

SNS上にウェブブラウザ上で動作するAPI

などの動作環境（アプリケーション・プ

ラットフォーム）が提供され、これを基盤

として制作されたアプリケーションソフト

を、ソーシャルアプリケーション（Social

Application）と総称し、その中のゲーム

のことをソーシャルゲームと呼ぶ。

Wikipedia より


大規模SNS上の

ソーシャルアプリ開発

重要なポイントは？


•API利用

•人口爆発

•短納期


API利用

• ユーザはSNSにアクセス

• Gadgetサーバがユーザのリクエストを転送

• アプリケーションはAPIに問い合わせてHTML

を生成


API利用

• 2-legged OAuth

– GadgetサーバからのRequestを検証

– こちらからのRequestに署名

• SNS内の機能を使うときもAPIを利用

– アプリの招待

– Activityの送信

– アプリからMessage送信

– 位置情報取得

– アプリからフォトアップロード

– SNS内のポイントでの決済サービス

– etc


人口爆発

• mixi

2,190万人

• mbga

2,167万人

• gree

2,246万人

• hangame

3,432万人

• ixen

175万人

• ybga

100万人


人口爆発


短納期

2ヶ月でリリースは想定の範囲内


短納期

毎月2回リリース必須


どんな対策が必要？


agenda

• API利用

– デバッグの勘所

• 人口爆発

– 負荷を想定する

– 正しくwebアプリを作る

• 短納期

– 何を犠牲にして何を得るか

– 超高速でPDCAサイクルを回す


agenda(gem)

• net-http-spy

• masochism

• data_fabrick

• faker

• resque

• activerecord-import

• scribe


ミドルウェア環境

• MySQL 5.1

• memcached 1.4.5

• Redis 1.2.6 (近々2.0.4に)

• TokyoTyrant 1.1.40

• Ruby 1.9.2-p0

• Rails 3.0.3

• unicorn 2.0.0

• nginx 0.7.67


基本サーバ構成図

• 仮想化しています

– CPU Xeon L5520

(2.26GHz 8コア)

– メモリ 32GB

• webにCPUを多く割

り当て

• cacheとdbにメモリ

を多く割り当て


agenda

• API利用


• 人口爆発

– 何を想定しなければいけないか

– 正しくwebアプリを作るということ

• 短納期




たった一つの

大事なこと


困ったら

request/response

を確認する


あくまでフィクションです

• リリース1週間前に「課金APIがどうして

も通らない」とprintデバッグしつつ悩ん

でいる人が居るんですよ。フィクション

ですけど。

• 結論から言うと

request.path

を使っていたためにクエリパラメータが

消えてたんですが。


request/responseを確認する

• 困ったらTCPレイヤまで降りてパケット

を見よう

• ライブラリのエラーメッセージから追う

よりもHTTPのステータスコードを見る

方が早い

– APIが本文にエラーメッセージを入れて返し

てくれている場合も多い


位置情報を取得しようとしたら

• 住所を取得したつもりが

「東北自動車道」

というものが取れたりとか

• Placemarkが複数返ってきているので他

のPlacemarkの住所を使えばOK


oauthのverifyが通らない

• 2-legged OAuth

– requestに署名を付けて送る仕組み

• 署名の検証が通らない

– requestを眺めて

– requestから組み立てたBaseStringを確認す

れば

– 違いに気づける


知ってると便利な小技

• net-http-spy

– Net::HTTPにloggerを仕込む

irb > require "net-http-spy"irb > Hase.container.handler("john.doe").person

CONNECT: ["localhost", 8080]GET /social/rest/people/@me/@self?fields=id,name,displayName,thumbnailUrl,gender,dateOfBirth&xoauth_requestor_id=john.doe&oauth_consumer_key=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2FSocialHelloWorld.xml&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1290204829&oauth_nonce=ROb9UmacNPtJYnaPtE7C7n7yWU8TpMWfHDI4EbY0yY&oauth_version=1.0&oauth_signature=8Cl2X%2FVDiwVd6gglSZX0s9aWaa4%3DBODY: Net::HTTPOK

# => {"container_user_id"=>"john.doe", "nickname"=>"Johnny", "thumbnail_url"=>nil, "gender"=>1, "birthday"=>nil}


知ってると便利な小技

• WEBrick::HTTPProxyServer

– Proxyを通せる環境なら便利

• tcpflow

– tcpdumpの保存しないバージョン

– webサーバに来るアクセスを覗き見したいと

きとか


agenda

• API利用


• 人口爆発



• 短納期




負荷を想定する

アクセス数

データ量


アクセス数

巨大SNSだから

ソーシャルだから

スモールスタートさせてくれない

口コミや招待インセンティブの力は異常

リロードするたびにユーザが増加

いきなりオススメに載ったりも……


アクセス数

リリース1週間で10万ユーザ突破

1ヶ月で30万ユーザも視野に

1ユーザ平均100クリック/Dayとして

10万ユーザで1,000万imp


いきなり

1,000万imp

＝

230 imp/sec

(ピーク時は平均の2倍)


230 imp/sec

どれぐらいのサーバ台数が必要なのか

• web/ap

– 230 Throughput / sec

– レスポンスを1秒で返すなら230worker必要

– Railsが200MB弱使うので40GBのメモリが

必要

– メモリ8GBが5台


230 imp/sec

• cache

– 5query/impとして1,150 QPS出ればOK

– メモリに載っているなら1台で十分

• db

– 10query/impとして2,300 QPS出ればOK

– それなりなマシンなら1台で十分かも？

– 足りないならmaster/slave分散必須

– 更新に耐えられないならpartitioningも必要


データ量

1Clickで1レコード増加するアクション

– あしあと帳とか

– 課金ログとか

1秒1クリック＝2,592,000クリック/月

1ヶ月で数千万レコード超に成長するDB


データ量

• 捨てられないデータがあるとすぐに

数十GB突破

• メモリに載りきらない


まずはDBをなんとかする


メモリに載らないなら

メモリを増やせば

いいじゃない


master/slave分散

• 更新系のクエリはmasterに、参照系のク

エリはslaveに行くよう分散する


master/slave分散

• 代表的なgem

– acts_as_readonlyable

– multi_db

– masochizm

– db-charmer

– data_fabric

– octopus


master/slave分散

• 実装はそこまで難しくない

• Rails 2.2でConnectionPoolingを導入

• initialize– ActiveRecord::Base.establish_connection

– @connection_poolsにconnectionを保存

• find_by_sql– ActiveRecord::ConnectionAdapters::ConnectionHandler#retrieve_connection


Partitioning

• ゲームは更新系のクエリが多い

– 体力が減った

– 経験値が増えた

– 対戦してアイテムを奪った

• 参照系のクエリをslaveに逃がしても

更新系のクエリだけでmasterのDiskIOが

限界に達する


垂直分割

• カテゴリごとに別のDBへ


垂直分割

テーブル単位で別のDB

JOIN不能


垂直分割

Modelから

has_many

has_one

belongs_to

が消滅


RDBMSを

リレーショナルに使わない


水平分割

• 複数のテーブルにデータを分散


Replication＋Partitioning＝

Sharding


Sharding

• 代表的なgem

– db-charmer

– data_fabric

– octopus


MongoDBにすれば解決


負荷テスト

以上のようなことが必要かどうかを把握

するために，またどのぐらい改善された

かを確認するために負荷テストは必須な

のです。

どこまで耐えられるのかを知っておくた

めに過負荷テストも必須なのです。


負荷テスト

リリース前に

50万ユーザが3ヶ月

遊んだ想定のデータを作り

本番想定と同じアクセス負荷をかける

• テストデータ生成に便利なgem

– faker


負荷テスト

• 何に注目する？

– ThroughPut

– DiskIO

– connection数


ThroughPutの改善


最速でユーザに

レスポンスを返す


最速でレスポンスを返す

• 時間がかかる処理はレスポンスだけ返し

裏で重い処理を実行するという手法

– 画像/Flashの合成

– APIを叩く

– ポイント付与

– クエスト達成判定

– 農園の作物が育ったかどうか


5秒制限

5秒以内にレスポンスを返せなかったら

アプリをメンテナンス状態にされる


例えば

• 経営シミュレーションアプリで

TOPページ→マイページ

という遷移

• TOPページへのアクセスを検知して

非同期に売買処理をしながら

TOPページというレスポンスを返す

• マイページに行ったときには完売になっ

た品物の姿が！


非同期処理

• ユーザのアクセスをトリガーとして動作

• レスポンスは最速で返して裏で処理する

• 代表的なgem

– resque

– delayed_job


Resque

• 管理画面が秀逸

– キューの状況

– workerの状況

– 失敗したjobの把握や再実行

• Resque Scheduler

– バッチ処理もRailsで管理

• cronの管理から開放

– 毎回Railsの起動をしなくても良い


その他の工夫

• BULK INSERT

– 複数レコードのINSERTを1回で行う

INSERT INTO `example_table` VALUES(1, 'aaa', 11),

(2, 'bbb', 22),

(3, 'ccc', 33),

(4, 'ddd', 44);


BULK INSERT

• いつ使う？

– 友だち関係をDBに保存したい

– 友だち全員に通知を飛ばしたい

• 便利なgem

– activerecord-import


正しくwebアプリを作る

手抜きかな？

と思いながら

作ったところは

必ず

ボトルネックになります


例えば

• 1日の回復数の上限に達しているかどうか

を調べるのに履歴テーブルのcountを

取っているとか

–カウンターキャッシュを随所で使う

• ユーザ数×アイテム数だけレコードがで

きるとか

–間違いなく水平分割必須になる

– 1レコードにJSON化して入れてみる

• like 検索厳禁は当然


ユーザ数数万程度を

想定しているコードは

全てNG



• GAEでの制限の意味が分かってくる

– リクエスト処理時間30秒制限

–関連が存在しない

– 1,000件しか取れない



• 巨大SNSから流れてくるユーザ数は

エンジニアの甘えを許してくれない

• 自らの技術的水準を飛躍的に向上させる

チャンス


agenda

• API利用


• 人口爆発



• 短納期




何を犠牲にして速度を得るか

• ドキュメントは最小限に

– Railsっぽい設計ならばER図を見れば中身が

分かる

– RESTっぽい設計ならばURLを見れば中身が

分かる

ER図とURL設計書以外のドキュメントは

(開発中は)管理しない



• ドキュメントは最小限に



• 迷う時間を最小限に

– Railsっぽいかどうかを考える

Do You Ride on Rails?


超高速でPDCAサイクルを回す

• 売上＝DAU*Daily ARPU*継続日数

• 注視KPI

– DAU

– ARPU/Day

–継続日数

– Install数

– バイラル率


超高速でPDCAサイクルを回す

• Plan, Do, Check, Action

• Do, Actionは速度を上げるのが難しいの

でPとCを最速にすることを考える


PDCAサイクルを超高速で回す

• Plan最速

–考えなくても施策が出てくる

–常に施策を考え続けられる環境を作る

• Check最速

– 何もしなくてもデータが手元に集まってくる

–常に施策の結果を閲覧できる環境を作る


いつでも見られる環境を作る



• ログの集約・収集

• ログ？

– ユーザの行動を記録したもの

• ログインした

• ガチャを回した

• コメントした

• 友達にアイテムを渡した



• 1日3GB分のログが溜まっていく

• 数十サーバに分散されているので

集約や収集がとても面倒

• rsync?

• syslog-ng?

• scribe！


scribe

• facebook++

• scribeサーバ間で勝手に転送してくれる

• エラー時の再送の面倒も見てくれたり


scribe

• 転送量が心配になってきたので

MessagePackを使おうかなぁと

考えています


まとめ

• APIには

– 送受信している内容の確認が鉄則

• 人口爆発には

– 負荷試験と監視大事

– データ量に耐えうる設計

– 正しく作ることを常に意識する

• 短納期には

– The Rails Way に任せる

– 動向把握を最速で行うことで意思決定速度UP


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

とあるアプリの開発運用(トラブルシュート)

Documents

Transcript of とあるアプリの開発運用(トラブルシュート)