というお題でGoogle App Engine / Java のスケールアウトの動作の考察について発表させていただきました。
appengine java night 3で発表したLT資料はこちらです。
おなじみ？の、ひがさんのツッコミとフォローのおかげで議論が深まってよかったです。
スケーラブルなアプリケーションをAppEngineで構築するヒントになれば幸いです。
実はこういう勉強会でお話をするのは初めてでした。
発表の機会を頂いた皆様、ありがとうございます。
LightningじゃなくてLongだというツッコミごもっともです。
（40分くらい使ってしまったらしい）
後続で発表できなかったかた、ほんとすいませんでした。
自分も議論に混じったりしながらだったので、うまく覚えておけなかったんですが、
ひがさんのトークからいくつかポイントをメモっておきます。
ちょっと記憶があやふやでデタラメ書いてるかもしれないので
ツッコミ推奨です。
- AppEngineが1instance/vm である証拠
- Runtime#hashCodeが毎回同じなのは多分いつも同じ起動順序をたどっているということ。 Thread idはstaticフィールドで管理されているので同一VM内であればインスタンスのロードが ClassLoaderで分離されているとしても変わらないとおかしい。 VM自体に手を入れているとは考えられないため、ほぼ1instance/vmで間違いない。
- 実質1Thread/instanceの理由の予想
- スレッド使ってしまうと利用リソースの予測が立たなくなる。
- リクエストをキューイングしている理由の予想
- これも同様に利用リソースの予測が立たないから。ストリーミング(というか、KeepAliveのことかな？) を止めてるのはこのためだと思われる。
- TaskQueueがうまくスケールしない理由
- あらかじめ継続的なリクエストでインスタンスがあったまってないと 処理が分散されにくいからではないか。@kazunori_279さんのところだと、テストなどでインスタンスがあったまっていたので、うまくTQも分散されていたのかもしれない
- 初期化の件
- appengineではインスタンスの初期化は鬼門。今までのJavaフレームワークの概念では インスタンスの初期化で頑張って（リソースを相当割いて）、アプリの高速化を図っていたが、appengineでは逆の視点が必要⇒専用のフレームワークが必要と考えられる。
0 件のコメント:
コメントを投稿