Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

appengine4java-scaleout

3,507 views

Published on

2009-12-04 #ajn3 LTで利用した資料

Published in: Technology

appengine4java-scaleout

  1. 1. Twitter ID: WdWeaver スケールアウトの真実?
  2. 2. 注意 <ul><li>個人かつ無料でできる範囲でやってることなんで、ある一例として考えてください。
  3. 3. GDD でも言ってるように、たぶんより良い方法があれば勝手に変えてくる部分だと思います。 </li></ul>
  4. 4. Google App Engine の制限 <ul><li>リクエストレートの制限 </li><ul><li>無料クオータ </li><ul><li>7,400 件 / 分 </li></ul><li>課金クオータ </li><ul><li>30,000 件 / 分 </li></ul></ul><li>リクエストハンドラの制限 </li><ul><li>レスポンスタイム </li><ul><li>30 秒 </li></ul><li>同時動的リクエスト </li><ul><li>30 </li><ul><li>どうしても増やしたい場合は Google に相談 </li></ul></ul></ul></ul>
  5. 5. GAE/J のスレッドって <ul><li>インスタンス1つにつき </li><ul><li>スレッドグループ見る限り 9 スレッド
  6. 6. リクエストを処理するスレッドは一つっぽい </li><ul><li>Network Runtime Thread って名前が付いてる
  7. 7. スレッド ID はいつも同じ </li></ul><li>複数のリクエストがキューに積まれるっぽい </li><ul><li>どの程度積んでるかこの情報ほしいですね
  8. 8. TaskQueue なら分かるのに </li></ul></ul></ul><ul><li>同時動的リクエスト数=インスタンス数 </li><ul><li>インスタンスが 30 前後まで起動するってことだと思われます
  9. 9. 制限を変えるには Google に相談 </li></ul></ul>
  10. 10. 重要そうなこと <ul><li>1 インスタンスにつきリクエストを処理できるスレッドは一つっぽい
  11. 11. レスポンスタイムに対する保証はない </li><ul><li>実際には 1 秒しかかからない処理でも、キューの状況によっては、レスポンスが戻ってくるまでに、相当の時間がかかることがある。 </li><ul><li>後で説明しますが、アクセスが集中したときに積まれたリクエストは、 10 秒前後までかかる可能性があります。 </li></ul></ul></ul>
  12. 12. 実験 <ul><li>Jmeter の設定 </li><ul><li>スレッド、リクエスト数 </li><ul><li>60Thread
  13. 13. 10Request </li></ul><li>リクエストの実行間隔 </li><ul><li>30req/sec
  14. 14. 無償クオータで単純計算すると 123req/sec 程度が上限 </li></ul></ul><li>テスト用サーブレット </li><ul><li>Thread.sleep(1000)
  15. 15. Session は今回使いません </li></ul></ul>
  16. 16. 結果 <ul><li>成功したリクエスト </li><ul><li>586 </li></ul><li>失敗したリクエスト </li><ul><li>14 </li></ul><li>スケールしたインスタンス数 </li><ul><li>16 </li></ul></ul>
  17. 17. Wait1 秒の時の実行結果
  18. 18. Wait1 秒の時の実行結果
  19. 19. ( 参考 )Wait5 秒の時の実行結果
  20. 20. 傾向 <ul><li>インスタンス起動直後のエラーが多発 </li><ul><li>Request was aborted after waiting too long to attempt to service your request
  21. 21. 全部 10 秒前後での失敗
  22. 22. ただしインスタンスの起動に 10 秒かかっているわけではない </li></ul><li>あとは全部成功 </li><ul><li>参考であげた、 Wait5 秒のサーブレットの場合だと、 410 回 (70% 近く ) 失敗した </li></ul></ul>
  23. 23. いろいろ予想 <ul><li>インスタンスは起動したらすぐにリクエストがキューに積まれるっぽい </li><ul><li>リクエストが集中している場合 </li></ul></ul>
  24. 24. いろいろ予想 <ul><li>キューに積まれたリクエストの生存期間は 10 秒前後っぽい </li><ul><li>この時間を越えてキューに残ったリクエストはすべて Request was aborted となり、キューからフラッシュされる模様
  25. 25. このエラーはハンドルできない
  26. 26. うまくスケールしない場合、エラーの頻発につながりそう </li></ul><li>重い処理が同一インスタンスにキューされまくると失敗しまくりそうな気がする </li></ul>
  27. 27. いろいろ予想 <ul><li>重い処理はスケールの反応が遅いと思われる </li><ul><li>同時リクエスト数が多い場合だとスケールし始めるが、インスタンス起動のトリガが自身に対するリクエストなので、相当の時間リクエストが継続する状況じゃないとダメ、と考えられる </li></ul></ul>
  28. 28. いろいろ予想 <ul><li>リクエストの生存期間を考えると 10+ ハンドラ処理時間 ( 秒 ) 程度で処理できる範囲にスケール自体は一時的に落ち着きそう </li><ul><li>実験結果の 10 秒オーバしている処理は、キューが空のインスタンスに新たに振り分けられたリクエストの気がする
  29. 29. インスタンス間のキューの移動もやっているかも </li></ul><li>スケールのタイミングは立ち上がり済みのインスタンスのキューの制限オーバじゃないかな
  30. 30. 重い処理の場合、リクエスト保持は 10 秒の制限があるから、破棄されて空っぽになったところにまた新しくキューが振り分けられて、新しいインスタンスがなかなか立ち上がらないんじゃないかな </li></ul>
  31. 31. スケールの反応を良くするには <ul><li>10 秒ってのがキーワードかもしんない。いかに 10 秒以内にたくさんのリクエストを捌けるか
  32. 32. インスタンスの起動に時間がかかると、うまくスケールしない原因になるかも
  33. 33. キューに入ったリクエストが失敗する可能性を考慮すべき
  34. 34. インスタンス自身の起動時間がかかるような場合は NoClassDefFoundError でインスタンスの初期化に失敗することもある
  35. 35. なるべく全てのリクエストハンドラは短時間で処理できるようにスライシングして、スケールしたときの処理完了までの時間を短くしておいたほうが良さげ </li></ul>
  36. 36. たとえば 1.とにかく処理は整合性を保てるレベルで細かく分割し、 Ajax/Flash で結果を統合とか 2. TQ は処理段階ごとにパイプラインを構築して実行。時間がかかる場合は分割して次のパイプラインに渡す感じとか 3. 500 エラーはとりあえずクライアント側でリトライするような実装。 TQ はリトライがあるから大丈夫かな。
  37. 37. どうなるか <ul><li>Request 数が増える⇒ Google さん儲かる
  38. 38. TQ たくさん使ってくれる⇒ Google さん儲かる </li></ul>

×