Posted on 07 September, 2011

TaskQueue の設定を変更する

TaskQueue をデフォルトの設定で使っていると、いくつかまとめて Task を登録した時に並列処理が走り、Frontend Instance が複数立ち上がってしまいます。そこで、max_concurrent_requests を設定することで、同時に実行される Task の数を制限できます。下記の yaml ファイルでは、“default” Queue の max_concurrent_requests を 1 に設定しています。

queue.yaml

queue:
- name: default
  rate: 5/s
  max_concurrent_requests: 1

もちろん、この設定によって Task の実行が遅くなりますが、インスタンスの数は抑えられるはずです。

9/8 追記: また、Task を追加するときに X-AppEngine-FailFast ヘッダーを追加することで、Task の実行のために新しいインスタンスを生成することを抑制できますので、こちらもインスタンスの数を減らす助けになるでしょう。

Backends を利用する

また Backends を利用することで、インスタンスの数を完全にコントロールすると共に、Backends の無料クオータを効率的に使うことができます。その設定例です。

backends.yaml

backends:
- name: backend
  class: B1
  instances: 1
  options: dynamic

queue.yaml

queue:
- name: default
  rate: 5/s
  target: backend

今回の queue.yaml では max_concurrent_requests の設定は外しましたが、backends の方で instances が 1 に設定されているので、インスタンスは1つしか立ち上がりません。また、この方法だと backends の無料クオータを利用することができます。

時間によって Task を積む queue を変える

これらの応用として、時間によって Task を積む queue を変更すると、例えば夜間のみ Backends で Task を実行し、昼間は Frontend instance で Task を実行するなどのことが結構簡単にできます。

もし TaskQueue が原因で Frontend Instance の数が増えてしまうという場合は、これらの設定のうちどれかを使用してみてください。

Happy tuning :)

Posted on 07 September, 2011

App Engine 1.5.4 SDK のプレリリースが出ました。ダウンロード URL

リリースノートを日本語でもお届けします。

App Engine Python SDK – Release Notes

Version 1.5.4


  • create_upload_url() で最大のファイルサイズを指定できるようになりました。
  • Zigzag merge join は 30 秒の Datastore deadline を超えて動作するようになりました。殆どのケースで成功するはずです。ただしごく一部のクエリーは依然としてタイムアウトしてしまいます。
  • Memcache API を非同期に呼べる機能が追加されました。
  • URL に空白が入っている task を作れてしまう問題を修正しました。
  • “transaction not found” というエラーメッセージを分かりやすくしました。
  • dev_appserver に -a 0.0.0.0 を指定したときに Blobstore のアップロードが動かない問題を修正しました。
  • bulkload.py の —dry_run が壊れていたのを修正しました。
  • db.Model().to_xml() メソッドが自動アップデートするプロパティーを間違って更新していたのを修正しました。
    関連 Issue
  • SDK が File パス中の “~” を展開しない問題を修正しました。
    関連 Issue
  • db.Model.init 内で is_saved() が使えない問題を修正しました。
    関連 Issue
  • GQL の IN クエリーに空白のリストを渡すと全てのエンティティがヒットする問題を修正しました。
    関連 Issue
  • SDK にて、降順のインデックスに対して cursor が動作しない問題を修正しました。
    関連 Issue
  • SDK の datastore stats 中の Typo を修正しました。
    関連 Issue

App Engine Java SDK – Release Notes

Version 1.5.4


  • BlobstoreService.createUploadUrl() で最大のファイルサイズを指定できるようになりました。
  • Zigzag merge join は 30 秒の Datastore deadline を超えて動作するようになりました。殆どのケースで成功するはずです。ただしごく一部のクエリーは依然としてタイムアウトしてしまいます。
  • Prospective Search API が Java アプリケーションで使えるようになりました。この API はまだ experimental なので、アプリケーションは最大 1000 まで subscription ができます。
  • クラスロードの仕組みを改善しました。多くの jar を持つプロジェクトでローディングリクエストのレイテンシーが減ることが期待されます。
  • Appcfg で set_default_version フラグが使用できるようになりました。
  • Java の Remote API が HTTP_X_APPENGINE_INBOUND_APPID を認識するようになりました。これで対象のアプリケーションで Java の Remote API を使用していても Datastore Admin コピー機能が使えるようになりました。
  • URL に空白が入っている task を作れてしまう問題を修正しました。
  • “transaction not found” というエラーメッセージを分かりやすくしました。
  • 開発サーバーの Blobstore 実装が immutable collection を書き換えようとする問題を修正しました。
    関連 Issue
  • SDKCONFIG, FINE, FINER, FINEST のログメッセージが表示されない問題を修正しました。
    関連 Issue

Posted on 02 September, 2011

この記事は http://code.google.com/appengine/articles/managing-resources.html の日本語訳です

はじめに

App Engine の 課金体系変更 の一環として、アプリケーションの利用レポートに含まれるリソースを変更しました。CPU Hours をなくし、ストレージ容量、帯域に加えて、利用されたインスタンス時間(Frontend、Backend)と、API 呼び出しの回数を元に計算するシステムに移行します。より詳しい情報については、 FAQ をご覧ください。(FAQ の日本語版 もあります。)

新しい課金体系が有効になる前に、我々は課金額の比較機能をリリースして、新しい課金体系でどのように課金額が変わるか確認できるようにしました。つまり、新しい課金額が有効になる前にアプリケーションを最適化して、その結果どのように新しい課金額が変わるか確かめることもできます。

この記事では、新しい利用レポートの見かたや、リソース管理のために使用できるいくつかの戦略と、それらの戦略がアプリケーションのパフォーマンスに与える影響について説明します。

現在と将来の利用レポートを見る

App Engine の日毎の利用レポートはアドミンコンソールの Billing History ページにあります。URL はこちらです: https://appengine.google.com/billing/history?app_id=$APP_ID 。各レポートの横にある [+] マークをクリックすると、その日の詳細が開き、現在と将来の利用レポートを見ることができます。このプレビュー利用レポートは下記のように見えるでしょう:
プレビュー利用レポートの一例

これから新しい課金額について、個々のアイテムがそれぞれ何を意味するのか説明し、リソース管理のために使用できる方法をいくつかご紹介し、それらの戦略がどのようにアプリケーションのパフォーマンスに影響を与えるのかを説明します。

インスタンスの利用量を管理する

新しい明細のはじめ 2 行の項目はアプリケーションのインスタンス利用量についてのものです。インスタンスについてはドキュメンテーションに記載があります。アドミンコンソール内の https://appengine.google.com/instances?app_id=$APP_ID という URL やダッシュボード: https://appengine.google.com/dashboard?app_id=$APP_ID のドロップダウンから “Instances” グラフを表示させることで、アプリケーションがどれだけのインスタンスを使用しているか確認できます。

App Engine のスケジューラー

App Engine はそのスケジューリングアルゴリズムによって、アプリケーションへの現在のトラフィックを捌くためにどれだけのインスタンスが必要なのか判断します。アプリケーションが受け取るすべてのリクエストについて、App Engine は、現在利用可能なインスタンス(アイドル状態のインスタンスか Concurrent Request を受け付けられるインスタンス)で処理するか、リクエストをペンディングキューに入れるか、そのリクエストを処理するために新しいインスタンスを立ち上げるかを決定しています。この判断をするためには、利用可能なインスタンスがあるかどうか、直近でどれくらい早くアプリケーションがリクエストを捌いていたか(レイテンシーを)、アプリケーションの新しいインスタンスが立ち上がってリクエストを処理しはじめるのにどれだけかかるか、などのデータを利用します。多くの場合、新しいインスタンスで処理する方が、既存のインスタンスで処理するよりも早いと判断すれば、リクエストを処理するために新しいインスタンスを立ち上げます。

もちろん、アプリケーションに対するトラフィックは一定ではありませんので、スケジューラーはアプリケーション毎にアイドル状態のインスタンスの数を把握しています。こういったアイドル状態のインスタンスは、ユーザーに対するレイテンシーなしにスパイクを捌くのに有効です。スケジューラーが、アイドル状態のインスタンスが多すぎると判断すると、使われていないインスンタンスのいくつかを落とし、リソースを再利用します。

アプリケーションが使用するインスタンスの数を減らすには

レイテンシーを減らす

アプリケーションのレイテンシーは、トラフィックを捌くために必要となるインスタンスの数に大きな影響を与えますので、アプリケーションのレイテンシーを小さくすることは、実際に立ち上げるインスタンスの数に大きく関わってきます。アプリケーションのレイテンシーを小さくするためには、下記のようなことが役に立ちます:

  • 良くアクセスされる共有データをなるべくキャッシュする – 別の言いかたをすれば – Memcache を使います。またレスポンスに Cache-Control ヘッダーを付ければ、データがより効率的にサーバーやブラウザーによってキャッシュされるようになります。たとえキャッシュを数秒間しかしなかったとしても、アプリケーションはより効率的にトラフィックを捌くことができます。Python のアプリケーションであれば、 実行環境でのキャッシュ も利用できます。
  • Memcache をより効率的に使用します – 個々に呼び出すのではなく、get、 set、 delete 等にバッチ呼び出しを使用します。
  • リクエストを処理するのに必ず必要では無い機能については Task を利用する – ユーザーからのリクエスト処理中にしなくても良い仕事は Task に任せましょう。レスポンスを返す前にこの処理を待つのに比べると、Task Queue にこの処理を送ってしまえば、ユーザー向けのレイテンシーをだいぶ小さくできるでしょう。Task Queue を使えば実行レートをコントロールできるようになり、負荷を均一に保つこともできます。
  • データストアをより効率的に使用する – 後でさらに詳しく説明します。
  • 複数の URL Fetch 呼び出しを並列化する
    • async URL Fetch API を使用する( Java, Python
    • 複数の URL Fetch 呼び出し(これらは個々のユーザー向けリクエスト内で行なっていたかもしれません)をオフラインの Task で ...

Posted on 25 August, 2011

App Engine Python2.7 runtime のトラステッドテスタープログラム が始まりました。

早速 The O-Kay-Blog を Python2.7 で動かしています。多少 Kay 自体に修正が必要なので、Kay 自体のリリースを分けた方が良いかもしれません。

ちなみに今は、threadsafe: yes で動かしています。Global 変数を使っている箇所で変な動きになりそうなのでおいおい修正していく予定です。

アプリケーション自体には何も手を入れなくても動いたので Python2.7 Runtime への移行はかなりスムースに行えそうな予感がしています。良かった良かった。

Posted on 29 March, 2011

TheOkayBlog を久々に update してみましたら、新しいテーマやなにやら増えていたのでこちらに移行してみました。

古いブログ も残しておきます。