Posted on 11 October, 2011

原文はこちらになります。App Engine 1.5.5 SDK Release

内容を要約しておきますと

  • プレミアアカウントの受付が始まりました。appengine_premier_requests@google.com 宛てにメールをしてください。
  • Python 2.7 が HRD アプリケーションで使用できるようになりました。2.5 との違いをまとめました ので、参考にしてください。
  • 複数の制限を大きく緩和しました。
    • Request の Deadline を 30 秒から 60 秒に
    • URL Fetch の Deadline も最大 10 秒から 60 秒に
    • デプロイできるファイルの総数を 3000 から 10000 に、最大のファイルサイズを 10MB から 32MB に
    • URL Fetch でポストのペイロードが 1MB から 5MB に
  • Limit preview と Trusted Tester
  • Cross Group(XG)Transaction が使用できるようになりました。複数のエンティティグループにまたがるトランザクション処理が可能になります。
  • 実験的機能として、 Files API のバックエンドに Google Cloud Storage を使用 できるようになりました。
  • Prediction API とのインテグレーションが簡単になりました。サンプル をご覧ください。

なお Google Cloud Storage と Prediction API は共に Labs から卒業しています。またその他にも細かい改善点がたくさんあります。詳しくはリリースノートを参照してください。

Posted on 06 October, 2011

この記事は Google Cloud SQL: Your database in the cloud の日本語訳です。

App Engine に対する最も要望が多かった機能は、伝統的なデータベースを使用してアプリケーションを簡単に開発する方法でした。このフィードバックに基づいて我々は、Google Cloud SQL を、限定的なプレビュー版として公開します。

みなさんは今や、完全に管理されたクラウド環境上で動作する、慣れ親しんだリレーショナルデータベースを使って App Engine のアプリケーションを作ることができるようになりました。つまり、リレーショナルデータベースの運用管理に関してまったく気にすることなく、アプリケーションとサービスの開発に専念することが可能になったのです。

Google Cloud SQL は App Engine の開発者にとって下記のような利点をもたらします:

  • 運用管理が必要ありません – 我々がみなさんのために運用管理します。
  • 高い安定性、高い可用性 – みなさんのデータは瞬時に複数のデータセンターへと同期されます。つまり特定のマシンやラック、データセンターでの障害は、自動的に処理され、ユーザーへのインパクトは最小限にとどまります。
  • 使い慣れた MySQL データベース環境 – Java のアプリケーションでは JDBC 経由、Python では DB-API 経由でアクセスできます。
  • データベースを管理するための統合されたユーザーインターフェース
  • Google App Engine との手軽でパワフルなインテグレーション

このサービスはデータベースのインポート、エクスポート機能が備わっているので、既存の MySQL データベースをクラウド上に移行して、App Engine で使用することができます。

Cloud SQL は現在のところ無料でお使いいただけます。少なくとも、サービスに課金を始める 30 日前には課金体系をアナウンスする予定です。プレビューの間は試行錯誤をしながら、進化を続けていく予定ですが、もし試してみたい方がいらっしゃればぜひお知らせください。

Posted on 10 September, 2011

このポストは A few adjustments to App Engine’s upcoming pricing changes の日本語訳です。

我々は先週、side-by-side billing を有効に して 5 月にアナウンスした新課金体系がどのように影響を与えるのかを詳しく見ることができるようにしました。たくさんのフィードバックを頂きまして、それを元にいくつかの重要な変更をしました。我々の意図としては、できるだけこの課金体系変更についてはオープン、透明でいたいと思っており、また皆さんに準備する時間を与えたいと思っています。こうした想いから、我々のエンジニアリングディレクターが 彼の個人的な考えを表明 しています。

我々は新しい料金体系が一部の方を驚かせていることを理解しています。我々は注意深くフィードバックに目を通し、新課金体系がアプリケーションに及ぼす影響を皆さんが正しく把握する助けとして行う、いくつかの変更についてアップデートをご紹介したいと思います。確かに価格は上がりますが、我々は皆さんが、App Engine は依然として高い価値を提供すると思ってくださることに自信を持っています。

頂いたフィードバックに基づき、下記の変更を加えます:

  • レビュー期間を延長しました: 新しい課金体系を導入する前に、ほぼ 8 週間の時間を提供します。皆さんは、11 月 1 日までの時間を使って、コストを管理するためにアプリケーションの設定やチューニングをすることができます。
  • インスタンス時間の無料クオータを増やしました: インスタンス時間の無料クオータを 24 から 28 へ増やします。これは、App Engine を試すために無料アプリを使用する皆さんが、一日中ひとつのインスタンスを立ち上げっぱなしにした上で、何回かのアクセス集中があったとしても無料クオータに収まるようになったことを意味します。この変更はもうすぐ課金額の表に反映されます。
  • 半額の期間を延長しました: 我々は、インスタンスに対する 50% の値引きを 12 月 1 日まで延長します。またこの時までには、Python 2.7 が利用可能になっているべきです。Python 2.7 はコストをさらに下げるための、同時複数接続の機能を提供予定です。
  • 利用レポートの迅速な提供: 我々は、チューニングの結果をなるべく早く見られることが重要だと理解しており、本日から、利用レポートを以前の 3 日から、1 日遅れで提供することにしました。
  • より良い分析用ツール: 我々は、アプリケーションのコストを計るためのより良い方法を提供するために努力しています。アドミンコンソールのインスタンスグラフに “billing” の線を追加するつもりです。また、コードに施した変更がどのように課金額に影響するかを判断しやすくし、また実際に課金額を減らす助けにするために、開発用のコンソールにデータストアの課金情報を追加しようとしています。
  • プレミアアカウント: 本当に多くのお客様が、運用サポートや、請求書による支払い、無制限のアプリケーションと SLA を得るためにプレミアアカウントを待ち望んでいることを知っています。ですので、11 月 1 日を待たずに、なるべく早くプレミアアカウントをローンチする予定です。もしプレミアアカウントに興味があれば、appengine_premier_requests@google.com 宛に連絡してください。

我々はまた、課金額を減らし、App Engine の実際のコストがどれくらいなのか知るための、主な方法のうちいくつかを紹介したいと思います:

  • Max Idle Instances をセットする: Max Idle Instances の値を小さくすることで、アイドル状態のインスタンスに関しては、ここでセットした数までを課金対象としますので、コストを下げる助けになります。これはアプリケーションのパフォーマンスに影響を与える可能性がありますので、変更の結果について注意深く観察する価値はあるでしょう。
  • Always-On を考慮にいれた見積もり: 新しい課金体系が有効になる際に side-by-side bills は廃止される(min idle instances に置き換わります)にも関わらず、ここには現在でも、依然として always-on のコストを含んでいます。我々はこれを修正しようとしています。それまでは、単に 1 日あたり 48 インスタンス時間を見積もりから引いてしまって問題ありません。
  • Reserved instance hours: インスタンス時間への課金額を下げるための一番単純な方法は reserved instance hours の使用を検討することです。これらは普通のインスタンス時間より 37.5% 安いですが、予め一週間でどれだけ使うかをコミットする必要があります。
  • リソースを管理する: 効果的にリソースを管理しコストを下げるための役に立つアドバイスを紹介している この記事 を参考にしてください。

我々は 3 年前に、web アプリケーションを構築、保守、スケールすることを簡単にするために App Engine をプレビューという形でローンチしました。それ以降、Java や Go 言語対応などのいくつもの機能を追加し、High Replication Datastore を開発し、他にも沢山の API を追加してきました ...

Posted on 09 September, 2011

英文のメッセージ の日本語訳です。

長いポストなのでまず要約を: 新課金体系の適用は 11 月 1 日に延期しました。インスタンス時間の半額期間を 12 月 1 日まで延長しました。Python 2.7 は 12 月 1 日をターゲットにしています。新課金体系では、多くの場合課金額が上昇しますが、皆さんが恐れるほどではないはずです。それから App Engine が依然として魅力的なプラットフォームであることを説明します。

私は App Engine 担当のエンジニアリングディレクターです。はじめまして!

我々は、App Engine がプレビューを卒業して Google の正式サービスになることをとても嬉しく思っています。新しい機能群、99.95% の SLA、改訂版の利用規約、有償サポートの提供、月額課金に加えて、価格体系を変更する予定でいます。先週、我々は “side-by-side” billing の機能と、それに伴う情報を記した e-mail を全ての App Engine 開発者の皆さんへお届けしました。この機能によって、新しい課金体系がみなさんのアプリケーションに及ぼす影響を確認できるようになりました。

このことで、みなさんを驚かせてしまったようですが、ここで 2 つのトピックについて詳しく説明したいと思います: これからのタイムラインと、値上げそれ自体のことについてです。

始めのトピック、タイムラインについてです。

多くのデベロッパーの皆さんは、新課金体系に向けてアプリケーションを適応させるための時間が少なすぎると感じています。我々は、5 月に新課金体系をアナウンスしました、そして side-by-side billing がチューニングの次の段階になると考えていました; 実際には、多くの(おそらく殆どの)デベロッパーの皆さんにとっては、side-by-side billing はチューニングの始まりに過ぎませんでした。

明らかに、我々は間違っていました: デベロッパーの皆さんが、アドミンコンソールに表示される情報を元に将来のコストを判断できると期待していたのですが、我々は鈍感に過ぎたようです。古典的な間違いをおかしてしまいました: 我々は自身のサービスについて慣れ過ぎていたのです。

そのことをお詫びしたいと思います。我々はこのことを理解しておくべきでした。また side-by-side billing をもっと早い段階でリリースするべきでした。とは言え、この問題は修正することができます: もっと時間的猶予を提供するつもりです。ですので、9 月後半に新課金体系を有効にする代わりに、その日付を 11 月 1 日に延期することで、デベロッパーの皆さんにアプリケーションをチューニングするための時間を提供するつもりです。

タイムラインについてもう 1 つ心配の元であったのは、Python 開発者の皆さんへ同時複数接続の機能(Java ではすでにご利用できます)を提供することになる Python 2.7 の提供時期がはっきりしないことです。この遅れを埋め合わせるために、インスタンス時間を半額にすることを決め、この値引きは 11 月 20 日に終了すると言って来ました。我々はこの値引きを Python 2.7 が使用可能であろう 12 月 1 日まで延長することに決めました。

2 番目のトピック、値上げについてです。

Google App Engine のビジョンは、Google のインフラ上で動くクラウドアプリケーションの開発環境を提供することです。具体的に言うと、App Engine で開発をするなら、それは以下のようであるべきです:

  • 始めるのは無料で、簡単に利用できる
  • 簡単にスケーラビリティを確保できる
  • メンテナンスが殆ど要らない

App Engine はプラットフォームコンピューティングにおけるトレードオフの典型的なケースです。何がお望みですか?高いスケーラビリティー、簡単に使用できること、メンテナンスが容易なこと、高可用性、セキュリティーですか?この中から 2 つを格安で提供することは誰でもできることです。ただしあなたがこれらのうち 3 つ、4 つ、又は全てをお望みなのであれば、簡単ではなくなります。我々はこれが、クラウドアプリケーションデベロッパーが最終的に望むことだと考えているので、App Engine では同時にこれらの 5 つ全てを実現することを目指しています。我々は、これがクラウドコンピューティングが行き着く将来の姿だと考えています。そこでこれらの全てをまとめて、無料プランと 2 種類の有料プランを提供することに決めました:

  • App Engine が提供してきた豊富な無料クオータは、この業界でも類まれなものでした。我々は無料クオータを提供し続けます: トラフィックが少ない小さな Web アプリケーションは App Engine で動かす限り無料であるべきです ...

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 :)