Google Code が利用できる言語: English - Español - 日本語 - 한국어 - Português - Pусский - 中文(简体) - 中文(繁體)
Gmail ユーザーなどの通常の Google アカウントを使用して、次の URL にアクセスして App Engine アカウントにログインできます:
Google Apps のアカウントの場合は、次の URL にアクセスします:
<DOMAIN.COM> は、自分のアカウントが関連付けられているドメインです。
現在、Google App Engine では Python 2.5 でアプリケーションを作成できます。セキュリティ上の理由のため、C 言語で作成された一部の Python モジュールはシステムで無効にされています。また、Google App Engine ではディスクへの書き込みをサポートしていないため、この機能およびその他の機能をサポートする一部のライブラリは、部分的に有効になっています。デベロッパー向けのドキュメントで、Python のランタイム環境の概要を説明しています。無効または部分的に無効にされる Python ライブラリの説明とリファレンス全体は、こちらをご覧ください。
さらに、Web サイト テンプレートに HTML の他に Javascript を使用できます。特に、Ajax Web 開発テクニックを使用する Web サービスの作成が可能になります。
Google App Engine では、大半の Python Web フレームワークをアプリケーションと共にアップロードできます。これらの Web フレームワークをシステムで操作するには、修正はほとんど不要、またはまったく不要です。ユーザーの利便性を図るため、Django v0.96.1 を Google App Engine SDK に用意しました。
もちろん、開発できます。まだ Google App Engine アカウントを持っていなくても、いつでも SDK をダウンロードして開発を始められます。
デベロッパーは、各自の Google App Engine 管理者アカウントで 10 のアプリケーションを作成できます。現時点では、作成したアプリケーションを削除することはできません。
既存のアプリケーションを無効にする場合は、まずアプリケーションの app.yaml ファイルからハンドラを削除します。app.yaml ファイルに、存在しないファイルを参照するハンドラを追加します。appcfg.py を使用して空の app.yaml ファイルをアップロードします。新しい app.yaml ファイルがアップロードされると、アプリケーションは無効になります。
Google App Engine で許可されているコンテンツの種類について質問がある場合は、利用規約をご覧ください。
管理コンソールの Google App Engine ダッシュボードには 6 つのグラフがあり、システム使用量を簡単に視覚的に確認できます。これらのグラフに表示される情報は、1 秒当たりのリソース消費量の 6 時間分のスナップショットを示しています。以下は、管理コンソールに表示されるグラフのリストです。
現在の負荷は、アプリケーションから要求された各 URI ごとのリクエスト数の内訳、および URI の CPU 統計を示します。リクエスト パラメータはパスから省かれています。
左端の列には、URI パスがリクエストの合計数が最も多い順に並べられています。リクエスト数の合計は [Requests] 列にリストされます。リクエスト数は、毎日午前 0 時(PST)にリセットされます。[Req./Min.] 列は、各 URI の短期リクエスト レートを示します。負荷が高い場合は、この列は [リクエスト/秒] となります。
現在の負荷テーブルには、[Avg. CPU] と [% CPU] という 2 つのデータ ポイントで CPU の使用量が示されます。[Avg. CPU] には、この URI へのリクエストが過去 1 時間に使用した CPU の平均メガサイクル数が表示されます。[% CPU] 列には、該当する URI が午前 0 時(PST)以降に使用した、アプリケーションのその他の URI に対する CPU の割合が表示されます。
URI のロードの試行中にエラーが発生する場合、システムにこのエラーが記録されます。管理コンソールには、過去 24 時間で発生した大半のエラーを記録する URI が表示されます。エラーの合計数を表示する他に、URI で発生したエラーごとに、その URI のリクエストの合計数に対する割合をエラー率として表示します。
favicon.ico ファイルがアプリケーションにない場合、URI /favicon.ico がエラーのある URI のリストに表示されます。favicon.ico は、ページをロードするときにユーザーの Web ブラウザによってリクエストされるファイルです。favicon.ico は Web サイトのアイコンで、通常はユーザーのブラウザの URL バーに、サイトの Web アドレスの横に表示されます。
アプリケーションには favicon.ico を静的イメージとして扱うように指示すべきです。favicon.ico ファイルをアプリケーションと一緒にアップロードできます。app.yaml ファイルを、URL /favicon.ico がリクエストされたときにアプリケーションが画像を提供するように設定します。以下は、/favicon.ico の app.yaml ファイルのエントリの例です。ここでは、favicon.ico ファイルをディレクトリ パス static/images に配置していると仮定しています:
- url: /favicon.ico static_files: static/images/favicon.ico upload: static/images/favicon.ico
GQL は、Google App Engine データストアで使用されるクエリ言語です。GQL は SQL に類似した構文を使用してアプリケーションのデータストアからエンティティ全体を取得します。また、プロパティのフィルタ、結果の並び替えの指定、返されるエンティティ数の制限を行う機能を備えています。GQL 言語の完全なリファレンスは、こちらをご覧ください。
複数のエンティティ プロパティにフィルタを適用するクエリ、または複数のプロパティの結果を順序つけるクエリを実行する場合、このクエリにはインデックスが必要です。アプリケーションでこのような種類のクエリを実行する場合、各クエリにインデックスが必要です。クエリのデータストア インデックスは、キーのリストを保持し、更新します。このリストは、クエリが指定する順序で並べられ、データストア内のデータへの高速アクセスを可能にします。データストア インデックスの詳しい説明は、ドキュメントをご覧ください。
アプリケーションを Google App Engine SDK で開発する場合、実行するクエリには必要に応じて自動的にインデックスが付けられます。Web サイトにアップロードする前にアプリケーションを完全にテストする場合、アプリケーションに必要なすべてのインデックスは、アプリケーションの index.yaml ファイルに登録されます。開発テストの対象にならなかったクエリがある場合は、インデックスを index.yaml に手動で追加できます。このドキュメントでは、アプリケーションに対するインデックスを作成する方法について説明しています。
インデックスが急増している可能性があります。たまにですが、Google では、インデックスを手動で Error にする必要があります。通常、このような場合は直接ご連絡いたします。
これまで、この問題が発生する理由は通常、ワーカー シャードが大きすぎてリース期間内に完了しなかったためでした。当初は、リース期間を延長することでこの問題に対処しました。後に、個々のタブレットをシャードに分割することにしました。
Users API で、Google アカウントを持つユーザーを認証したり、自分の Google Apps ドメインのユーザー アカウントに対して認証したりすることができます。この 2 種類の認証を、同じアプリケーションで使用することはできません。Google Apps ドメインでアプリケーションの認証を設定する方法についての記事をご覧ください。
Users API を使用すると、アプリケーションがユーザー ログインをリクエストするときに Google ログイン ページが表示され、ユーザーはここに自分のユーザー名とパスワードを入力します。ユーザーは Web サイトに戻り、ユーザー認証情報が Users プロパティ経由でアプリケーションに通知されます。
少量のネイティブ C Python モジュールと、ネイティブ C Python モジュールのサブセットは、Google App Engine では使用できません。ネイティブ C Python モジュールのサポートの詳細情報については、こちらをご覧ください。無効にされるモジュールは、次のカテゴリに分類されます:
上記のいずれかの機能を使用するサードパーティ パッケージは、Google App Engine では動作しないことに注意してください(mysql や postgresql などのパッケージ)。
アプリケーションは、利用規約に違反した場合、無効にされることがあります。また、リソースを無駄に使用するバグまたはその他の問題により、アプリケーションが過度のシステム リソースを使用していると判明した場合、Google ではこのアプリケーションを無効にできます。デベロッパーは開発用 SDK を使用して開発上の問題を修正してから、アプリケーションを Google App Engine で再度有効にできます。
App Engine はアプリケーションが 1 日に使用できる各システム リソースの量について割り当て制限を設定します。すべてのアプリケーションにはデフォルトの割り当てが設定されており、無料です。この割り当てで、効率的なアプリケーションで 1 か月におよそ 500 万ページ ビューを処理できます。システム 割り当ての詳細は、割り当てのドキュメントをご覧ください。
アプリケーションが拡大すると、デフォルト 割り当て設定よりも多くのリソース割り当てが必要となることがあります。アプリケーションの課金を有効にして、コンピューティング リソースを追加購入できます。課金することで、デベロッパーはすべてのシステム リソースの限度を引き上げて増額した限度額までCPU、帯域幅、ストレージ、メール使用量について支払うことができます。
Google App Engine 利用規約に違反するアプリケーションを報告するには、Google までご連絡ください。アプリケーションが違反しているか判定し、必要に応じてアプリケーションのデベロッパーに違反について連絡します。
dev_appserver はローカル テスト用に設計されており、外部接続はデフォルトでは許可されません。実行するときに -a <hostname> フラグを使用して上書きできますが、このようにすると SDK のセキュリティが強化されず、脆弱性が生じることがあるため、推奨しません。
Google App Engine では、gzip で圧縮されたコンテンツを gzip に対応するブラウザで使用できるように処理します。このスキーマの利用は自動的に行われ、アプリケーションへの変更は不要です。
リクエスト ヘッダー(Accept-Encoding、User-Agent)と応答ヘッダー(Content-Type)の組み合わせを使用して、エンド ユーザーが gzip されたコンテンツを利用できるかどうかを判定します。このアプローチにより、一般的なブラウザでの gzip されたコンテンツの既知のバグの一部を回避できます。gzip されたコンテンツを強制的に提供するため、クライアントは「gzip」を Accept-Encoding と User-Agent リクエスト ヘッダーの両方に値として指定します。Accept-Encoding ヘッダーがない場合は、コンテンツは gzip で圧縮されません。
Google App Engine では、SSL(HTTPS)トラフィックを appspot.com ドメイン経由で使用できます。「secure」パラメータを、セキュアなトラフィックをサポートする URL の app.yaml ハンドラに追加するだけです。アプリケーションをセキュアなトラフィックに設定する方法については、ドキュメントをご覧ください
Google App Engine のすべてのセキュアなトラフィックは、appspot.com ドメイン(https://your-app-id.appspot.com)から提供される必要があります。アプリケーションを Google Apps ドメイン以外から提供している場合、すべてのセキュアなトラフィックをアプリケーションの appspot ドメイン経由で転送する必要があります。
最近適用された変更により、App Engine ではアプリケーションのネイキッド ドメインへのマッピングをサポートしなくなりました。お使いのドメインのレジストラが URL リダイレクトをサポートしている場合、http://yourdomain.com から、たとえば http://www.yourdomain.com や http://appid.yourdomain.com にリダイレクトできます。
Google Apps ドメインのリダイレクトの設定方法については、Google Apps FAQ on URL forwarding (redirection) をご覧ください。
アプリケーションに cron ジョブを定義する方法については、言語固有のドキュメントをご覧ください: Python の cron ジョブ、Java の cron ジョブ