ajn13 MixiXmas2010

appengine ja night #13 開発事例紹介 mixi Xmas 2010 株式会社あゆた毛利真克

自己紹介
毛利真克
Twitter:@mouri45
会社：株式会社あゆた
HP: http://www.ayuta.co.jp
最近の仕事：ソーシャルアプリの受託開発
「これから始める人のための iPhone アプリ開発勉強会」主催 ( http://bit.ly/cDT4x6 )

mixi Xmas 2010
mixi 公式の mixi アプリ
ピーク時は 250 万ユーザが参加

システム構成 makeRequest http request JSON WebPage GAE/J (FW:Slim3) クーポン在庫及びタイアップサーバ PC アプリモバイルアプリ

Datastore 使用量
Datastore 使用サイズ：
95GB
Datastore 格納レコード数：
201,244,067 件

効果的な施策
設定情報を static 変数に保持
mixi アプリの制約に対する施策
spin-up に対する施策
その他

設定情報を static 変数に保持
設定情報を static 変数で保持し Memcache へのアクセスを減らす。
アプリケーション全体で利用するような設定情報は static 変数に格納することで Memcache へのアクセスが減らせる。
設定を反映させたい場合は全てのインスタンスの static 変数を更新する必要があるが、有効期限を設けて、定期的に更新するようにしておけば、デプロイしなおさなくても反映できる。

設定情報を static 変数に保持 Datastore request request Memcache Static 変数 Static 変数設定ファイルアップロード Static 変数が空、または有効期限が切れている場合は Memcache or Datastore から取得

mixi アプリの制約に対する施策
10 秒制限
PC アプリで makeRequest で呼び出した WebAPI 及びモバイルアプリの画面は 10 秒以内にレスポンスが返らなければタイムアウトとして扱われる。
JOIN 停止
モバイルアプリでタイムアウトが一定時間に一定回数発生するとアプリに未登録のユーザが新規にアプリに参加することができなくなる。
GAE 10s 10s

Datastore アクセスの遅延現象
他のアプリで通常の状態だと 1req にかかる時間は数百 ms だが、たまに遅くなることがあると報告を受けていた。
Datastore アクセスの遅延が集中して起こることが原因。
この状態に陥るとレスポンスタイムが 10 秒を超えるものも多く発生しているため mixi 側でタイムアウトとして扱われるようになり、 JOIN 停止になる懸念があった。

JOIN停止対策1
request が queue にたまる時間を短くする。
GAE に request が送られた際に処理可能なインスタンスが存在しない場合、 request は queue に積まれ、処理可能なインスタンスができるまで待機する。この待機時間には制限時間があり、それを超えるとエラーとしてレスポンスされる。制限時間のデフォルト値は 10 秒であるため、制限時間に達してエラーになった場合は、 mixi 側でもタイムアウトとして扱われている。
mixi の JOIN 停止の条件は、タイムアウトのみで、エラーなどは含まれない。
根本的な対策ではないが、 queue にたまる制限時間を短くすることで GAE 上で 10 秒かかるまえにエラーとしてレスポンスを返し、 mixi 側でタイムアウトとして扱われないようにすることで、 JOIN 停止を回避するように対応した。
※ 設定するには Google に依頼する必要がある

JOIN停止対策2
Datastore アクセス時の deadline の指定。
Datastore アクセスが遅延している状態では、アクセスに 10 秒以上要することがあり、その場合は mixi 側でタイムアウトとして扱われる。
Datastore アクセス時に DatastoreServiceConfig を使用することで Datastore アクセスの制限時間を指定することが出来る。
こちらも根本的な解決策ではないが、エラーにしてしまうことで JOIN 停止を回避するように対応した。

LowLevelAPI での指定方法 DatastoreServiceConfig config = DatastoreServiceConfig.Builder .withReadPolicy(new ReadPolicy(Consistency.EVENTUAL)) .deadline(5.0); DatastoreService ds = DatastoreServiceFactory.getDatastoreService(config); ここは Javadoc からひっぱってきたけど EVENTUAL はデフォルトじゃないらしいちなみに mixi Xmas2010 では Slim3 つかったので、この部分は利用していない

Slim3での指定方法デフォルト値を指定する場合 <?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>app-name</application> <version>1</version> <precompilation-enabled>true</precompilation-enabled> <system-properties> <property name="slim3.datastoreDeadline" value="5.0" /> <property name="java.util.logging.config.file" value="WEB-INF/classes/logging.properties" /> </system-properties> <sessions-enabled>false</sessions-enabled> <inbound-services> <service>warmup</service> </inbound-services> </appengine-web-app> アクセス毎に指定する場合 entity = Datastore. deadline (2.5).get(modelClass, key);

Spin-upに対する施策
通常の運用をしている際は、それほど問題にならない。
デプロイ時 (version を毎回変えていたので実際は version 変更時 ) に同時に Spin-up が起こるため、 JOIN 停止になることがあった。
これは、インスタンスの起動時間＋ spin-up 時のアプリの処理が遅いために発生していると考えられる。
Static 変数をフラグとして使用することで現在の request が spin-up かどうか判定可能なため、 spin-up であれば、レスポンスをすぐに返しクライアント側から request をリトライ（モバイルなら redirect で）することで、 mixi 側のタイムアウトが発生しづらくなるため JOIN 停止を回避することができる。
※ この施策については検証時間が取れなかったため実施しませんでした。

その他施策
Warm Up Requestsの利用。
queryよりbatch getを優先的に使用。
不要なsingle property indexが作られないようにする。

やらなかったこと
本来であれば、使用するべきだが、数億エンティティ・数百 req/sec という環境下で検証が十分行えなかったためやらなかったこと。
カスタムインデックスとマージジョイン
task queue の多用

カスタムインデックスとマージジョイン
下記の問題について、検証する時間がとれなかったこと、及びどちらも、 query 用にプロパティを用意することで single property index で代用できるため未使用とした。
5 月ごろに別案件で、カスタムインデックスが作られないという事象が報告されたので念のため未使用。
( ただし、問題が報告されたのは、運用が始まって後からカスタムインデックスを設定したケースなので、最初から設定しておくケースについては特に問題ないかも )
同じく 5 月ごろ別案件で、件数が多い kind でマージジョイン利用時にカスタムインデックスの生成を促すエラーが報告されたので念のため未使用。
（こちらは、現在は問題ないかも。データさえたくさん登録すれば検証は簡単なので、お試しあれ）
今もダメな事がある

task queueの多用
ベル鳴らし時に、鳴らした相手へのポイント付与やアプリ内アクティビティの登録処理に利用したかったが、秒間数百回実行される可能性があったため、検証を行う必要があった。結果的に、時間が取れなかったため、 task queue は決済機能など利用範囲を限定した。
運用中、データリカバリのために利用した task queue が 1.4.0 から入った task queue のデータの quota 制限にかかっていたため、今回のアプリにおいては正しい判断であった。
Task queue のデータの quota は設定で変えられるとのこと

失敗したこと
GAEでPVの取得
Keyの命名

GAEでPVの取得
モバイルアプリの PV をサーバ側で取得する必要があったが、 GAE のログは、一定以上量がたまると消えてしまうため、別の仕組みが必要と判断。（ログのダウンロードツールも取りこぼしが発生すると判断）
別の GAE アプリに対して img タグを使ってリクエストを送りページ名を記録する方法をとった。
Html <img … http://.../pageName.gif 透過 gif Jsp でレスポンス生成時に http:// 別アプリ /{pageName}.gif にアクセスする img タグを出力 Mixi アプリが稼動しているものとは別の GAE アプリを用意。リクエスト毎にページ名を記録することで後で PV を集計できるようにする。 mixi アプリ用 GAE PV 用 GAE ログに関しては google のほうで対策を検討中らしい

問題
予想以上に費用が高くついた… orz
最終的に EC2 に Apache を立ててログを集計する方法に変更

keyの命名
entityのkeyの生成の際にnameを指定できるが、この文字列の先頭にタイムスタンプを利用している部分があった。（queryの結果が指定した条件以外の部分がkey順に取得されるのでその特性を利用しようとしていたため）
key = Datastore. createKey (modelClass, keyName);

問題
GAE の datastore は、 BigTable を利用している。 BigTable 上でデータは複数の tablet server により管理されている。
ひとつの tablet server にアクセスが集中するか、サイズが 300MB を超えると tablet server の分割が起こり、その際に Datastore アクセスのタイムアウトエラーが発生しやすくなる。（ただし、問題になるのは数百 QPS ぐらいアクセスがあるような場合）
今回の問題は key 文字列の先頭にタイムスタンプを使用していたため tablet server にアクセスが集中してしまった。
http://bit.ly/hW2QG7
http://bit.ly/gqOVZO Index となるプロパティにタイムスタンプのような連続した値が格納されるケースも注意が必要（ただし、高アクセスな場合のみ）

解決策
key 文字列の先頭にハッシュ値をつけることでアクセスがひとつの tablet server に集中しないようにする。
12343 12344 12341 12342 ABC_12311 ABC_12312 12345 12346 12347 ABC_12345 GHI_12347 DEF_12346 DEF_12321 DEF_12322 GHI_12331 GHI_12332 アクセスが集中するアクセスが分散される

GAEは、劇的なスピードで、機能追加・パフォーマンス改善が行われている。
GAEはソーシャルアプリに向いている。
過去断念した人ももう一度トライしてみよう！
GAE/J+Slim3+Eclipseの生産性がすばらしい！

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

ajn13 MixiXmas2010

by Masakatsu Mouri on Feb 21, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 4

Statistics

ajn13 MixiXmas2010 — Presentation Transcript

https://twimg0-a.akamaihd.net	3
http://twitter.com	1