もっくんのITメモ

昨日のポストでBackendsは「Instance時間による課金」と書きましたが、間違いでした。。。 Backendsは「Instance時間とCPU時間の両方で課金」が正しいみたいです。 昨日の実装で動かしているとQuotaのBackendsだけでなく、CPUTimeがどんどん消費されていき、最終的に無料割り当て分をすぐに食いつぶしてしまいました。 スケールするInstanceの方はログを見ても1時間に1回、1回あたり300ms程度しかCPU時間を消費していません。 明らかに想定外の動きでした。ログに出ない分意識しなかったというのが、敗因です。 BackendsのInstanceであっても、スケールする通常のInstanceであってもCPU時間での課金はあるので、無限ループの実装は不可能ということになります。 ということで、BackendsのAlwaysOnのオプションと違いを見いだせなくなってしまいました。 testBedを卒業して正式サービスに昇格する際には全てがInstance時間に対しての課金になるため、有効だとは思うんですが。。。

先日のGoogle App Engine SDK 1.5のリリースで処理時間に制限のないBackendsがリリースされ、さらにこれまで処理で利用したCPU時間に対して課金される仕組みが今後Instanceの起動（アサイン）時間に対して課金されるようになることが発表されました。 つまり、Instanceが1時間起動している間に100回リクエストを捌こうと10回捌こうと金額は変わらないということです。 従来であれば、cronでの最小間隔である1分間に1回処理を実行すると最初の数秒はCPU時間を消費して処理を実行して、残りの40～50秒は何もしない、イコール課金されないという方が理にかなっていました。 しかし、Instance時間になるとたとえ40～50秒間処理を行わなてもInstanceが起動されている間は常に課金されてしまいます。 そうなると、いかにCPUが働いていない40～50秒間を有効に使うか、ということが問題になります。 そこで考えたのが、無限ループです。 特定の処理を無限にループする事によって、Instanceの起動時間全てをループ内の処理に割り当てることができ、Instance時間を有効に活用することができます。 あいにく、まだInstance時間は通常のスケールするInstanceに対しては適用されませんが、BackendsではInstance時間でのQuotaの計算がされています。 将来的な変化に慣れるためにもちょっと実装してみました。 今回ははじめてFlaskというフレームワークを使って書いてみました。 これです。 ==========ここから========== @app.route('/') def put_queue():     taskqueue.add(url=url_for('work'),target='test')     return 'Done' @app.route('/work',methods=['POST']) def work():     for var in range(3600):         now = datetime.datetime.now() + da