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 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 で ...