既にお聞きかと思いますが、Google App Engine が 2011 年の後半に Preview を卒業するとともに、課金体系が変更になる予定です。新しい料金表はこちらにあります:
。ただ料金表を見るだけでは、多くの疑問が残ることでしょう。この FAQ では新しい課金体系に関して多く寄せられる質問に対してのお答えを提供するために作成しました。この FAQ を見てさらにご意見などあればぜひお聞かせください。FAQ がきちんとまとまれば、公式ドキュメントに追加する予定でいます。もしこのリストにないご質問があればお気軽にお聞きください。なるべくわかりやすく答えるようにしたいと思います。
Q: 現在アドミンコンソールに表示されているインスタンスの数に応じて課金されると考えるべきですか？
A: いいえ。私たちはインスタンスの利用率を最適化するようにスケジューラーの動作を変更しているところですので、インスタンスの数はある程度減るはずです。Java をお使いであればアプリケーションをスレッドセーフに書くことで、1 つのインスタンスで同時に複数の接続を処理することができるようになります。そのようにすることで、課金されるインスタンスの数を減らすことができるでしょう。
Q: どのようにすれば稼働しているインスタンスの数をコントロールできますか？
A: 新しいスケジューラーでは、トラフィックを捌くためにどれだけのインスタンスを起動するかを指定する助けになるようなパラメータをいくつか設定できるようになる予定です。これらパラメータについての詳しい情報は、下記の「新しいスケジューラーでどんなパラメータが指定可能ですか？」をご覧ください。
Q: 1 つのインスタンスがなるべくたくさんのリクエストを捌けるようにするためにはどのようなことに気をつければ良いでしょうか。
A: 最も大きな要素は、アプリケーションがリクエストを処理する際のレイテンシーです。サービスが素早くレスポンスを返すのなら、1 つのインスタンスはたくさんのリクエストを捌けるようになるでしょう。また、Java アプリケーションは
並列リクエストをサポートしており、1 つのリクエストが終了すのを待つ間にも、別のリクエストを処理することができます。これは、アプリケーションで必要となるインスタンスの数を劇的に減らすことができます。
Q: Python では並列リクエストをサポートするのでしょうか？またサポートする場合、コードを書き換える必要はありますか？
A: App Engine では Python の並列リクエストを Python 2.7 のリリースでサポートする予定です。我々は、たくさんの Python ユーザーの方々から、並列リクエストがある Java へ移行しなければならないのではないかという心配の声を良く聞いていました。それに対処するため新しい課金体系にひとつ変更を加えました。Python 2.7 サポートは現在進行中ですがまだ完成しておりませんので、Python 2.7 実行環境をリリースするまでは、Python には半分のサイズのインスタンスを（半分の価格で）提供する予定です。さらなる情報については、下記の「Python 2.7 を使用するために、コードにどんな変更を加える必要がありますか？」をご覧ください。
Q: 平均的に、インスタンスはどれくらいのリクエストを処理できますか？
A: （Python でも Java でも）シングルスレッドのインスタンスは現在のところ同時に 1 つの接続のみ処理できます。したがって、レイテンシーと、そのインスタンスで毎秒いくつのリクエストを処理できるかどうかの間に直接の関係があります。例えば、レイテンシーが 10ms であればインスタンス毎に毎秒 100 リクエストですし、レイテンシーが 100ms であれば、インスタンス毎に毎秒 10 リクエストといった具合です。マルチスレッドのインスタンスでは同時にいくつものリクエストを処理できます。したがって、CPU をどれだけ使用したかと、そのインスタンスで毎秒いくつのリクエストを処理できるかどうかの間に直接の関係があります。例えば、1 つの B4 インスタンス（2.4GHz に相当）で、リクエスト毎に 10 Mcycle を使用したとすると、インスタンス毎に毎秒 240 リクエストを処理できますし、100 Mcycle を使用したとすると、インスタンス毎に毎秒 24 リクエストを処理できるといった具体です。これらの数字は理論上の最大値ですが、実際にもこれに非常に近い性能を得られるはずです。マルチスレッドのインスタンスは現在
Java のみでサポートされており、今年後半には Python でもサポートを始める予定です。
Q: なぜ Google は古いモデルと同じ CPU ではなく、インスタンスの数で課金するように変更したのですか。これは顧客が望んでいたことなのでしょうか？
A: CPU への課金では、App Engine が使用するリソースの一部しかカバーできていませんでした。App Engine がコードを実行する際には、一定の CPU とメモリを持ったインスタンスを作成します。レスポンスを待っている間、CPU が動いていない時でも、インスタンスはそこに存在し、「使用中」であるとみなされます。つまりこの状態でも基本的に Google はコストを支払っていることになります。現状のモデルでは、高いレイテンシーを持つ（言い換えれば長い間何もせず居座っている）アプリケーションは Google にとって非常にコスト高になるために、スケーリング機能を制限していました。つまり、この変更によって、リソースを利用した分だけお支払いいただくことになる一方、開発者のみなさんは、どのようなアプリケーションでも制限なく動かせるようになります。
Q: 既存の顧客にはどのような意味があるのでしょうか？
A: 多くのお客様は現在、支払い額を抑えるために CPU の使用量を抑えていました。逆に、メモリをたくさん使用している（レイテンシーの高いアプリケーションによる）ケースも多くありました。新しいモデルでは、もしそうすることによって CPU をたくさん使用するとしても、レイテンシーの低いアプリケーションを作成することが推奨されます。
Q: 新しいモデルでは always-on はどのようになるのですか？
A: App Engine が Preview を卒業すると、プレミアムアカウントのすべてのアプリケーションと、ての有料アプリケーションでは、アイドル状態のインスタンスをいくつ立ち上げておきたいかを設定できるようになる予定です。Always On とは、インスタンスの立ち上げ時にレイテンシーが高くなるのを避けるために、いつもアイドル状態のインスタンスを立ち上げておくことができるようにデザインされていました。多くのアプリケーション（特に並列リクエストが有効ならば）ではアイドルインスタンスは 1 つで十分なはずです。つまり多くのお客様にとって、有料アプリケーションにして $9 お支払いいただければ、最小のアイドルインスタンスを 1 に設定することで、無料枠の 24 インスタンス時間/日 を利用してインスタンスをいつも立ち上げておくことができるようになります。
Q: 新しいスケジューラーでどんなパラメータが指定可能ですか？
A: 新しいスケジューラーでは 4 つの設定可能な項目を用意してパフォーマンスとコストの調整を行えるようにする予定です。
- Min Idle Instances: この項目では、トラフィックが来てインスタンスが必要になったときに、すぐに使えるインスタンスがあることを保証するために、いくつのインスタンスを動かしたままにしておくかを設定します。注意点として、このオプションは有料アプリケーションとプレミアアカウントのアプリケーションのみで利用できます。
- Max Idle Instances: この項目では、トラフィックに備えるためにスケジューラーが動かしたままにするインスタンス数の最大値を設定します。この値を低くすればコストを抑えられるかもしれない一方、トラフィックが急激に増える場合には、インスタンスのスタートアップコストが余計にかかることになります。
- Min Pending Latency: この項目では、インスタンスが起動する前に、リクエストが Pending Request Queue で待つ時間の下限を設定できます。この時間内に処理が行われるリクエストによって、新しいインスタンスが作られることはないでしょう。
- Max Pending Latency: この項目では、リクエストが処理可能なインスタンスなしに、Pending Request Queue で実際に待っていられる最大時間を設定します。ここで設定した時間よりも長く待たされているリクエストに対しては、即座に新しいインスタンスが起動されます。
Q: スケジューラーの設定項目は課金とコストにどのような影響を与えますか？
A: 個々の設定項目は下記のように影響を与えます。
- Min Idle Instances: この設定値を増やすことで、その数だけインスタンスが常時起動するようになりますので、コストは増加するでしょう。
- Max Idle Instances: この設定値を減らせば、アイドル状態のインスタンスが減るので、コストを下げることができるでしょう。また、それを超えた分のアイドル状態インスタンスに関しては課金をしません。つまりこの設定値はスケジューラーに対する提案ですが、スケジューラーがこれを無視したばあいには、超過分のインスタンスに対する課金はしません。例えば、Max Idle Instances の数を 5 に設定しているにも関わらず、スケジューラーが 16 のインスタンスをしばらくそのままにしていたならば、5 つのインスタンスにのみ課金されることになります。
- Min Pending Latency: この設定値を減らせば、 スケジューラーがより積極的にインスタンスを立ち上げるようになるので、課金額は増えるでしょう。
- Max Pending Latency: この設定値を増やせば、スケジューラーはより頻繁に、新しいインスタンスを立ち上げる前に、既存のインスタンスを使おうと試みるようになるので、課金額は減るでしょう。
Q: On-Demand インスタンスと Reserved インスタンスの違いはなんですか？
A: On-Demand インスタンスは、事前にいくつのインスタンスを使用するかコミットせずに使用できます。Reserved インスタンスは週にどれだけの Instance Hours を使用するのか事前にコミットすることです。Reserved インスタンスはより安いのですが、事前にコミットした分に関しては、使用したかどうかに関わらず、全額をお支払いいただく必要があります。必ずしも Reserved インスタンスをその間ずっと動かしておく必要はありません。
Q: つまり、Reserved インスタンスは、ずっと動かす必要があるわけではないのですね？
A: その通りです。事前にコミットすることで instance hour の単価が下がるのが Reserved インスタンスです。
Q: インスタンスを元にした課金の時間単位はどのようになりますか？例えば 1 つのインスタンスを 5 分間使用したら $0.08 / 60 * 5 だけ支払うことになるのでしょうか？
A: インスタンスは実際の稼働時間に加えて、スタートアップの費用として別の 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 セントになります。
Q: 新しいモデルではメモリの量も課金対象になるようですが、普段とは異なったメモリを積んだフロントエンドインスタンスを購入することはできますか？
A: 今のところ、単一のメモリを積んだフロントエンドインスタンスのみ提供予定です。
Q: フロントエンドインスタンスは Task Queue や Cron のリクエストを処理できますか？
A: はい。
Q: 使わなかった Reserved インスタンスを翌週に使用することはできますか？
A: 残念ながら使えません。ある週に事前コミットした Reserved インスタンスは実際にその週の間に使用したかどうかにかかわりなく課金されます。
Q: 実験的な Go Runtime は並列同時リクエストをサポートしますか？
A: 現在のところサポートしませんが、鋭意作業中ですので、楽しみにお待ちください。
Q: Python 2.7 を使用するために、コードにどんな変更を加える必要がありますか？
A: 基本的には、現在の Python 2.5 用のコードはそのまま Python 2.7 でも動作しますが、いくつか大事な変更をする必要があるかもしれません:
- Django 1.2 を使用してください: 現在の Python ランタイムはデフォルトで Django 0.96 を使用します（実は webapp 組み込みの template システムを使用すると Django を使うことになります）。Python 2.7 は新しいランタイムなので、この古いバージョンをパッケージ、サポートする予定はありません。Django 1.2 以降のバージョンをサポートする予定です。これに備えるためには、コードが Django 1.2 で動作することを確認しておくのが一番良い方法です。Django 1.2 を使用する方法については、
こちらに解説があります。
- Python 2.7 サポート: 言うまでもないことかも知れませんが言っておきますと、新しいランタイムで使用するためには、コードが Python 2.7 で動作する必要があります。
Q: Python 2.7 では並列リクエストはどのように動作しますか？
A: 現在の Java ランタイムがスレッドにより並列リクエストをサポートしているのと同様に、並列リクエストはスレッドを使用します。
- WSGI 準拠のフレームワークを使用してください: 並列リクエストの恩恵を受けるためには、CGI インターフェースではなく、その替りに WSGI 準拠のフレームワーク（これは App Engine に同梱している webapp フレームワークも含まれます）を使用する必要があります。
- スレッドセーフ: Python 2.7 ではスレッドを使用して並列リクエストをサポートしているので、この恩恵を受けるためにはコードがスレッドセーフである必要があります。
- もちろん前の質問で述べてある Python 2.7 対応も必要です。
コストQ: 有料アプリケーションの $9/app/month は手数料なのですか？それとも最低の利用料なのですか？
A: 現在までにいただいたフィードバックによって、$9 を元々は手数料としてアナウンスしていましたが、それを変更し最低利用料として徴収することにしました。言い換えると、アプリケーションをスケールさせるためには依然として月額 $9 をお支払いいただく必要がありますが、毎月の利用料のうちはじめの $9 を別途お支払いいただくことはありません。プレミアムアカウントの $500／アカウント／月 は依然、運用サポートのコストとして計上されます。
Q: 殆どの顧客は有料アプリケーションに移行する必要があるでしょうか？
A: いいえ。現在のアクティブアプリケーションの大半は Free Quota の範囲に収まると考えています。
Q: 既存のアプリケーションは免除を受け現在の課金モデルのままでいるのでしょうか？
A: いいえ。既存のアプリケーションも、App Engine が Preview を卒業する時に新しい課金モデルに移行します。
Q: Backends には無料クオータはありますか？
A: はい。すべてのアプリケーションは $0.72/day の backends 無料クオータがあります。
Q: 殆どの顧客について、支払額は上がるのでしょうか？もしそうだとすると、なぜ Google は App Engine を値上げするのですか？
A: はい。お支払いいただいているお客様のほとんどについては、課金額が上がるでしょう。App Engine の Preview 期間を通じて、App Engine の典型的な利用パターンや、この商品を稼働させるためのコストなどを観察することができました。Google App Engine を Google の正式なサービスにするにあたり、我々は将来にわたって継続可能な収入モデルが必要でしたので、料金を変更することになりました。
Q: 1 - 2 年後にハードウェアの価格が下がるのに応じた料金体系の変更を予定していますか？
A: 今のところ、（どちらの方向にも）料金の変更は予定していません。
APIQ: API 呼び出しに関する課金はどれくらいになりますか？
A: ほとんどの場合、API 呼び出しに対する価格は現在と同程度になる予定です。ただし CPU 時間に対して課金する代わりに呼び出し回数に応じた課金になります。例えば、Channel API は $0.01/100 channels といった具合です。これはだいたい現在のお客様がお支払いいただいている額（ただし現在では CPU 時間として課金されています）と同程度です。Datastore API が一番大きく変わります。詳細は下記に記します。
Q: 料金表のページでただチェックが付いている API については、どのような料金体系になるのですか？
A: それらの API は App Engine からは無料で使用できます。
Q: XMPP はどのように課金されますか？存在確認メッセージの送信にはいくらかかるのでしょうか？
A: 外向きに送信した Stanza に応じて課金されます。受信したメッセージはその他のリクエストと同様に Web のリクエストとして計算されますので、使用された帯域と、リクエストを処理するのに使用した Instance Hour に課金されます。存在確認メッセージに対しては、帯域については課金の対象にしますが、メッセージに対する直接の課金はしません。これは、課金対象が CPU 時間から Stanza に変わったことを除けば、現在とほぼ同様です。
Q: email を受信するのにはどれくらいコストがかかりますか？
A: 受信 email は他のリクエストと同様に Web リクエストとして計算されますので、email の受信に使用した帯域と email の処理に使用したインスタンス時間に対して課金されることになります。これは基本的に、現在の動作と同様です。
Q: Front End キャッシュについて、きちんとドキュメント化し、公式なサービスの一部として提供する予定はありますか？
A: いくつかの選択肢について考慮していますが、現状ではいつ発表できるか未定です。
Q: 管理者への email 送信は、普通の email より安いか、または無料ですか？
A: 検討の余地がありそうです。もしこの件が重要だとお考えであれば、下記の issue にスターを付けてください:
http://code.google.com/p/googleappengine/issues/detail?id=5235Datastore APIsQ: どの操作が課金の対象になりますか？
A: 下記の 3 種類になります:
- 書き込み操作（Entity Put, Entity Delete, Index Write）: これらの操作は 100, 000 回毎に $0.10 かかります。
- 読み込み操作（Query, Entity Fetch）: これらの操作は 100,000 回毎に $0.07 かかります。
- 軽微な操作（Key Fetch, Id Allocation）: これらの操作は 100,000 回毎に $0.01 かかります。
Q: Entity のサイズはコストに影響しますか？
A: いいえ。
Q: Datastore API に対する新しい課金体系では、db のバッチ処理をなるべく使うようにする必要はないのでしょうか？コストの面では、db.get(key1); db.get(key2) は db.get([key1, key2]) と同じですか？
A: バッチ処理は直接コストに影響しません。ただし、バッチ処理を使用すれば、我々のバックエンドとの情報のやり取り回数が減るので、レイテンシーを低くできるでしょう。
Q: db.get([key1, key2]) を実行して entity を 2 つ取得しました。どれだけの「操作」をしたことになりますか？
A: 2 回 Entity Fetch をしたことになります。
Q: key2 が存在せず、entity は 1 つしか取得できなかった場合はどうなりますか？
A: 変わりません。2 回 Entity Fetch をしたことになります。
Q: db.get(key1) は 5kb の entity を取得するとします。db.get(key2) は 500 kb の entity を取得するとします。料金に違いはありますか？
A: ありません。
Q: 新しい課金体系では、1,000 個の key を取得する keys-only クエリを実行し、その中から必要な 500 個の entity を取得する方が経済的でしょうか、それとも普通の（keys-only ではない）クエリで 1,000 個の entity を取得した方が良いでしょうか？
A: 前者の方が経済的です。1,000 個の key 取得 + 500 個の entity 取得 = $0.0001 + $0.00035 = $0.00045 ですが、1,000 個の entity 取得 = $0.0007 です。
StorageQ: ログの保存領域は「Storage Quota」として計算されますか？
A: いいえ。現在はアプリケーション毎に、限られた量のログのみ保存されており、Storage Quota としては加算されません。
利用タイプQ: プレミアムアカウントの 「$500/アカウント」はどういう意味ですか？Google Apps Account 毎に $500 なのでしょうか？もしくは開発者毎かアプリケーションのオーナー毎なのでしょうか？
A: 組織毎です（もしあなたが Google Apps のお客様なら、Google Apps アカウントと考えてもらって良いでしょう）。したがって、例えばあなたが gregco.com で働いており、プレミアムアカウントに申し込んだとすると、gregco.com のユーザーは gregco.com アカウントに対して課金されるアプリケーションの作成が可能になります。
Q: 非営利団体に対する特別なプログラムの提供予定はありますか？
A: おそらく。現在議論中です。
Q: 学術利用に対する特別なプログラムの提供予定はありますか？
A: おそらく。現在議論中です。
Q: オープンソースプロジェクトに対する特別なプログラムの提供予定はありますか？
A: おそらく。現在議論中です。
固定クオータQ: M/S から HR Datastore に移行する場合、新しいアプリケーションを利用することになると思います。この新しいアプリケーションでは、新らに小さく変更された email クオータを持つことになりますか？古いアプリケーションでは 2,000 の制限だったのですが、これと同様の制限に変更してもらうことはできませんか？
A: はい。M/S から HRD に移行するケースでは、email クオータを緩和することができます。
