メニュー

2011年9月7日

Google App Engineの新料金体系ではMax Idle Instancesの設定が必須

詳しい料金について:
http://www.google.com/enterprise/cloud/appengine/pricing.html

FAQ:
http://googledevjp.blogspot.com/search/label/app%20engine


Admin ConsoleのBilling Historyから、新料金体系の見積もりを見ることが出来るようになっています。

これによりTwitterの#gaejaをはじめとして、各地で混乱が生じているようです。

Datastore Ops、Storage、Bandwidthなどは、従来から値上がりはしますが、計算式は大きく変わらず、2倍以下の値上がりなので、個人的には許容できます。

問題は「Frontend Instance Hours」です。
現行では「CPU Time」が意味合いとしては近いです。

ところが、計算方法が大きく異なり、見積もりでの値上げ幅が非常に大きいケースがあるようです。

PlusFeedの場合、31CPUHが 880IHになり、課金額も13倍に:
https://plus.google.com/104961845171318028721/posts/DamjzZBVxd7

またTwitterで見ていても、7~8倍というTweetも見られましたし、3倍程度というTweetも見られました。

これは、インスタンスの課金の時間単位の仕組みが独特のため、アプリの内容によって、影響が大きかったり小さかったりするためです。

FAQより引用:
インスタンスは実際の稼働時間に加えて、スタートアップの費用として別の 15 分間に対しても課金されます。この費用は App Engine がインスタンスを立ち上げたり落としたりする時にかかるリソースをカバーします。したがって、1 つの on-demand インスタンスで 5 分間トラフィックを処理したとすると、5 + 15 分間分、つまり $0.08 / 60 * 20 = 2.6 セント課金されることになります。また、インスタンスが止まって、15 分経過する前に再度立ち上がった場合には、このスタートアップ費用は一度だけ課金され、この間ずっとインスタンスは動いているとみなされます。例えば、On-Demand インスタンスが 5 分間トラフィックをさばいて、その後 4 分間止まり、さらにその後 3 分間トラフィックをさばいたとするならば、課金対象の時間は (5+4+3)+15 分になり、課金額は $0.08 / 60 * 27 = 3.6 セントになります。

ほとんどアクセスのないアプリがリクエストを受け取るとインスタンスが起動しますが、最低でも15分間=0.25IH=0.02$が課金単位なので、最悪のケースでは1リクエストで0.25IHも使ってしまいます。

24IH/dayの無料枠があるので、1リクエスト=0.02$ということは起きませんが、1リクエスト=0.25IHとすると、CPUHでの計算時よりも最悪1000倍のコストになります。

ただし、アクセスがある程度あるアプリでは、上記の問題はありません。

たとえば月間500万リクエストの場合、平均すると15分間では3600リクエストを処理します。
1リクエストを500msで処理するならば、現行のCPUHの計算では0.2~0.5CPUHくらいで、新料金体系が理想に近いスケジューリングで回れば0.25IH~0.50IHで処理できます。
大きくは変わらないですよね。

逆に影響が大きいのはcronなどで定期的に処理を回しているアプリ。

いままでは毎分cron起動して1秒の処理をしていた場合、1日で0.5CPUHくらいでした。
ところが新料金体系では24IHになります。48倍です。
もちろん、24IH/dayは無料枠におさまりますが、cronからTaskQueueをキックするなどして複数のインスタンスが起動してしまう場合は24IHを超えてしまい数十セントから数ドルの課金になるでしょう。

上記のケースではTaskQueueのrate、bucket sizeを調整して、Taskがスパイクせず平準化されて実行されるように設定すると問題が緩和されると思います。

# 新料金体系ではTQをどう設定したら良いか? など、情報があれば教えてください

値上りが大きくて困っている人は、Admin ConsoleのApplication Settings内にある「Max Idle Instances」を、1などの小さな値に設定することを強くお勧めします

どうやらMax Idle InstancesのデフォルトであるAutoは、非常に富豪的な設定で、使わなくなったインスタンスを延々と延命して、IHを浪費します。

よほどSpin-upが遅いアプリ以外であれば、これを小さくしても問題にはならないはずなので、新料金体系になるまでの期間で、どのくらいの値でいくらになるのかを見つつ、調整していくと良いと思います。


追記:
自分で管理しているアプリでMax Idle InstancesをAutoから1に変更したところ、Front Instance Hourが1/3ほどになりました。

2 件のコメント:

  1. 私もまだ試行錯誤中ですが
    cronからTaskQueueは、両方ともbackends枠を使うのがいいのではと考えています。

    返信削除
  2. Backendsはインスタンス数をコントロールできますし、無料枠もあるから良さそうですね

    返信削除