appengine4java-scaleout

Twitter ID: WdWeaver スケールアウトの真実？

注意
個人かつ無料でできる範囲でやってることなんで、ある一例として考えてください。
GDD でも言ってるように、たぶんより良い方法があれば勝手に変えてくる部分だと思います。

Google App Engine の制限
リクエストレートの制限
無料クオータ
7,400 件 / 分
課金クオータ
30,000 件 / 分
リクエストハンドラの制限
レスポンスタイム
30 秒
同時動的リクエスト
30
どうしても増やしたい場合は Google に相談

GAE/J のスレッドって
インスタンス１つにつき
スレッドグループ見る限り 9 スレッド
リクエストを処理するスレッドは一つっぽい
Network Runtime Thread って名前が付いてる
スレッド ID はいつも同じ
複数のリクエストがキューに積まれるっぽい
どの程度積んでるかこの情報ほしいですね
TaskQueue なら分かるのに
同時動的リクエスト数＝インスタンス数
インスタンスが 30 前後まで起動するってことだと思われます
制限を変えるには Google に相談

重要そうなこと
1 インスタンスにつきリクエストを処理できるスレッドは一つっぽい
レスポンスタイムに対する保証はない
実際には 1 秒しかかからない処理でも、キューの状況によっては、レスポンスが戻ってくるまでに、相当の時間がかかることがある。
後で説明しますが、アクセスが集中したときに積まれたリクエストは、 10 秒前後までかかる可能性があります。

実験
Jmeter の設定
スレッド、リクエスト数
60Thread
10Request
リクエストの実行間隔
30req/sec
無償クオータで単純計算すると 123req/sec 程度が上限
テスト用サーブレット
Thread.sleep(1000)
Session は今回使いません

結果
成功したリクエスト
586
失敗したリクエスト
14
スケールしたインスタンス数
16

Wait1 秒の時の実行結果

( 参考 )Wait5 秒の時の実行結果

傾向
インスタンス起動直後のエラーが多発
Request was aborted after waiting too long to attempt to service your request
全部 10 秒前後での失敗
ただしインスタンスの起動に 10 秒かかっているわけではない
あとは全部成功
参考であげた、 Wait5 秒のサーブレットの場合だと、 410 回 (70% 近く ) 失敗した

いろいろ予想
インスタンスは起動したらすぐにリクエストがキューに積まれるっぽい
リクエストが集中している場合

いろいろ予想
キューに積まれたリクエストの生存期間は 10 秒前後っぽい
この時間を越えてキューに残ったリクエストはすべて Request was aborted となり、キューからフラッシュされる模様
このエラーはハンドルできない
うまくスケールしない場合、エラーの頻発につながりそう
重い処理が同一インスタンスにキューされまくると失敗しまくりそうな気がする

いろいろ予想
重い処理はスケールの反応が遅いと思われる
同時リクエスト数が多い場合だとスケールし始めるが、インスタンス起動のトリガが自身に対するリクエストなので、相当の時間リクエストが継続する状況じゃないとダメ、と考えられる

いろいろ予想
リクエストの生存期間を考えると 10+ ハンドラ処理時間 ( 秒 ) 程度で処理できる範囲にスケール自体は一時的に落ち着きそう
実験結果の 10 秒オーバしている処理は、キューが空のインスタンスに新たに振り分けられたリクエストの気がする
インスタンス間のキューの移動もやっているかも
スケールのタイミングは立ち上がり済みのインスタンスのキューの制限オーバじゃないかな
重い処理の場合、リクエスト保持は 10 秒の制限があるから、破棄されて空っぽになったところにまた新しくキューが振り分けられて、新しいインスタンスがなかなか立ち上がらないんじゃないかな

スケールの反応を良くするには
10 秒ってのがキーワードかもしんない。いかに 10 秒以内にたくさんのリクエストを捌けるか
インスタンスの起動に時間がかかると、うまくスケールしない原因になるかも
キューに入ったリクエストが失敗する可能性を考慮すべき
インスタンス自身の起動時間がかかるような場合は NoClassDefFoundError でインスタンスの初期化に失敗することもある
なるべく全てのリクエストハンドラは短時間で処理できるようにスライシングして、スケールしたときの処理完了までの時間を短くしておいたほうが良さげ

たとえば１．とにかく処理は整合性を保てるレベルで細かく分割し、 Ajax/Flash で結果を統合とか２． TQ は処理段階ごとにパイプラインを構築して実行。時間がかかる場合は分割して次のパイプラインに渡す感じとか３． 500 エラーはとりあえずクライアント側でリトライするような実装。 TQ はリトライがあるから大丈夫かな。

どうなるか
Request 数が増える⇒ Google さん儲かる
TQ たくさん使ってくれる⇒ Google さん儲かる

http://d.hatena.ne.jp	189
http://www.slideshare.net	26
http://k.hatena.ne.jp	1
http://webcache.googleusercontent.com	1
http://twitter.com	1

appengine4java-scaleout

by WdWeaver a.k.a Wada3 on Oct 19, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 218

Statistics

appengine4java-scaleout — Presentation Transcript