サイトのトップへ戻る

Google App Engine ドキュメント日本語訳

リクエストを処理する

  1. リクエストとドメイン
  2. リクエストと HTTP
  3. リクエストヘッダ
  4. 応答
  5. リクエストタイマー
  6. SPDY
  7. ログ機能
  8. 環境
  9. 割り当て量と制限


リクエストとドメイン

App Engine はリクエストのドメイン名を使って、受信したリクエストがあなたのアプリケーション宛のものかを判断します。 http://your_app_id.appspot.comのドメイン名を持つリクエストは、 your_app_idの部分をIDに持つアプリケーションにルーティングされます。 全てのアプリケーションは無料でappspot.comドメイン名を取得します。

appspot.com ドメインはsubdomain-dot-your_app_id.appspot.com形式のサブドメインをサポートしており、 ドメイン名の一部のsubdomain部分には、(.を除く)任意の文字列が使用されます。 この形式のサブドメイン宛のリクエストは、あなたのアプリケーションにルーティングされます。

Google Appsを使って、カスタムトップレベルドメインを設定できます。 Google Appsでは、あなたのビジネス用ドメインのサブドメインをGoogle メールやGoogle サイトのような様々なアプリケーションに割り当てることができます。 また、App Engineアプリケーションをサブドメインに紐付けることもできます。 便宜上、Google AppsのドメインはアプリケーションIDを登録するタイミングで設定でき、それ以降は開発者コンソール上から設定できます。 詳細については Google Apps URLにあなたのアプリケーションを配置する を参照してください。

これらURL宛のリクエストは全て、あなたが開発者コンソール上で既定として選んだバージョンのアプリケーションへ送られます。 各バージョンのアプリケーションはそれぞれ独自のURLを持っているので、新しいバージョンのアプリを既定バージョンにはせずに配置したりテストしたりできます。 バージョン固有のURLは、appspot.comドメイン名に加えて、アプリの設定ファイルに書かれたバージョン識別子を使って生成されます。 このように: http://version_id-dot-latest-dot-your_app_id.appspot.com 。 また、バージョン固有URLの付いたサブドメインを使用することもできます。:http://subdomain-dot-version_id-dot-latest-dot-your_app_id.appspot.com

リクエストで使用されているドメイン名は、アプリケーションに渡されるリクエストデータ内に含まれています。 アプリへのアクセスに使用されているドメイン名に応じてアプリで異なる応答をさせたい場合は (特定のドメインへのアクセスを制限したり、公式のドメインへリダイレクトするような)、 アプリケーションコード内でのドメイン宛のリクエストデータ( Hostリクエストヘッダのような)を確認し、それに応じて応答することができます。

あなたのアプリが モジュールを使用している場合、リクエストを特定のモジュール(必要に応じてそのモジュールの特定のバージョン)に割り振ることができます。 モジュールのアドレス指定に関する詳細情報については、リクエストをモジュールへルーティングするを参照してください。

注意: 2013年4月以降から、 Google では appspot.com でホストされたダブルワイルドカードドメイン(すなわち、*.*.appspot.com)向けのSSL証明書は発行しません。 アプリケーションへのHTTPSアクセスにそうしたURLを使用している場合は、アプリケーションのロジックを"."ではなく"-dot-"を使ったものに変更してください。 例えば、アプリケーションmyapp のv1にアクセスするにはhttps://v1-dot-myapp.appspot.comを使用します。 https://v1.myapp.appspot.comを使用した場合は証明書が一致せず、URLと証明書が正確に一致することを想定しているUser-Agentではエラーが発生します。



リクエストと HTTP

Go ランタイムは、GoプログラミングとApp Engineサーバ間のインタフェースとして標準http packageを使用します。 App Engineがあなたのアプリケーション宛のリクエストを受け取った時、 リクエストされたURLに関連するhttp.Handler を実行します。 (このURLは、アプリケーションの app.yaml 設定ファイルでGo ハンドラとして指定されていなければなりません。)

App Engine はアプリケーションのインスタンスを複数実行し、各インスタンスはリクエストを処理するために独自のウェブサーバを持っています。 リクエストは任意のインスタンスにルーティングされ、同一ユーザーからリクエスト連続してきても、常に同じインスタンスに送られるとは限りません。 インスタンスは複数のリクエストを同時に処理できます。 インスタンスの数は、トラフィック数の変化に応じて自動的に調節されます。

以下は、ハードコードされたHTML文字列をユーザーへ出力するGOアプリの例です。


package hello

import (
    "fmt"
    "net/http"
)

func init() {
    http.HandleFunc("/", hello)
}

func hello(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "<h1>Hello, world</h1>")
}



リクエストヘッダ

受信した HTTP リクエストには、クライアントによって送信された HTTP ヘッダが含まれています。 安全上の理由から、ヘッダによってはアプリケーションに届く前に中間プロキシによってサニタイズされたり修正されたりします。

以下のヘッダはリクエストから削除されます:

  • Accept-Encoding
  • Connection
  • Keep-Alive
  • Proxy-Authorization
  • TE
  • Trailer
  • Transfer-Encoding

また、appspot.com*.appspot.com以外のドメインへ送られるリクエストからはStrict-Transport-Securityヘッダが削除されます。

これらのヘッダはクライアントとサーバ間のHTTPデータ転送に関連し、アプリケーション側ではノータッチの領域です。 例えば、サーバはAccept-Encoding リクエストヘッダの値に従って、自動的にgzip圧縮された応答を送信することがあります。 アプリケーション自身は、ユーザー受信できるコンテンツエンコードが何なのかを知る必要はありません。



App Engine 固有のヘッダ

アプリを動作させるために、App Engine は全てのリクエストに対して以下のヘッダを追加します:

X-AppEngine-Country
リクエストが発生した国のISO 3166-1 alpha-2 国コード。 App Engine はクライアントのIPアドレスを基にしてこのコードを決定します。この国情報はWHOIS から引っ張ってきてはいないので注意してください;IPアドレスの WHOIS データベースでの国情報と、X-AppEngine-Countryヘッダに記載された国情報は異なる可能性もあります。 アプリケーションでは、特別な国コード ZZ (不明の国)も処理できるようにしてください。
X-AppEngine-Region
リクエストが発生した地域の名前。 この値は X-AppEngine-Countryの示す国と照らし合わせないと意味が分かりません。 例えば、国が"US"で地域が"ca"の場合は、 "ca"は"カリフォルニア"を意味します。カナダではありません。 有効な地域の値の全一覧は、ISO-3166-2標準にあります。
X-AppEngine-City
リクエストが発生した都市の名前。例えば、Mountain Viewの都市から発生したリクエストは、このヘッダの値はmountain viewとなるでしょう。 このヘッダについては、有効な値の一覧はありません。
X-AppEngine-CityLatLong
リクエストが発生した都市の経度と緯度。Mountain Viewから発生したリクエストの場合、この値は "37.386051,-122.083851" のようになります。

App Engineサービスでは必要に応じてリクエストヘッダを追加することもあります:

タスクキューサービスでは、リクエスト内のタスクとそれに関連するキューの詳細を伝えるために、リクエストに追加ヘッダ を追加します。

Cron サービスからのリクエストにも以下の HTTP ヘッダが含まれます:

X-AppEngine-Cron: true

詳細についてはcronのURLのセキュリティを保護する を参照してください。

他のApp Engine アプリケーションから来たリクエストには、リクエストを作成したアプリを識別するための以下ヘッダが含まれています。:

X-Appengine-Inbound-Appid

詳細については アプリ識別のドキュメントを参照してください。



応答

App Engine はRequestのハンドラと ResponseWriterのハンドラを呼び出し、ハンドラがResponseWriterへの書き込みを終了するまで待ちます。 ハンドラが終了すると、ResponseWriterの内部バッファ内のデータはユーザーへ送信されます。

これは事実上、http パッケージを使った普通のGoプログラミングを記述する時と何も変わりません。

以降で説明するように、応答を生成する際にはいくつかの制限が適用され、応答がクライアントへ返される前に変更されることもあります。



応答のサイズ制限

動的な応答のサイズは32MBに制限されています。 スクリプトハンドラーがこの制限以上の応答を生成した場合、サーバは500 Internal Server Error ステータスコードの空応答を返します。 この制限はBlobstore やGoogle クラウドストレージから届くデータの応答には適用されません。



ストリーミング応答

App Engine では、リクエストを処理しながらクライアントへ増加チャンクのデータを送信する、ストリーミング応答はサポートしていません。 あなたのコードから送信される全てのデータは上記で説明されている方法で収集され、単一のHTTP応答として送信されます。



応答の圧縮

クライアントが、圧縮(gzipped)コンテンツを受信できることを示すHTTPヘッダをリクエストに付けて送信した場合、 App Engine は自動的にハンドラー応答データを圧縮し、適切な応答ヘッダを付けます。 クライアントが圧縮応答を確実に受け取ることができるかを判別するために、Accept-EncodingリクエストヘッダとUser-Agentリクエストヘッダの両方を使用します。

クライアントを改造する際には、Accept-EncodingヘッダとUser-Agentヘッダの両方にgzipの値を指定することで、クライアントが圧縮された応答を受信できることを相手に伝えることができます。 また、応答のContent-Typeは圧縮が適切かどうかは判別するために使用されます。;通常は、テキストベースのコンテンツは圧縮されますがバイナリのコンテンツは圧縮されません。

App Engineによって応答が自動的に圧縮された場合、応答には Content-Encoding ヘッダが追加されます。



ヘッダの削除

以下のヘッダは無視され、応答から削除されます:

  • Connection
  • Content-Encoding*
  • Content-Length
  • Date
  • Keep-Alive
  • Proxy-Authenticate
  • Server
  • Trailer
  • Transfer-Encoding
  • Upgrade

* App Engineによって応答が圧縮される場合は再び追加されます。

さらに、*.appspot.com以外のドメインが送信する応答からはStrict-Transport-Securityヘッダが削除されます。

名前や値にASCII ではない文字を含むヘッダも削除されます。



ヘッダの追加や書き換え

以下のヘッダは応答では追加や書き換えが行われます:

Cache-ControlExpiresVary

これらのヘッダでは、プロキシ(インターネットサービスプロバイダーのような)とブラウザを中間媒体とするキャッシュポリシーを設定します。 あなたのスクリプトがこれらのヘッダを設定した場合、応答にSet-Cookieヘッダが設定されるか管理者アカウントを使って署名したユーザー向けに応答が生成されない限りは、キャッシュは維持されたままになります。 静的ハンドラーは 設定ファイルに従ってこれらのヘッダを設定します。 あなたがCache-Controlを設定しない場合は、サーバでprivateの値を設定して、Vary: Accept-Encodingヘッダを追加します。

応答にSet-Cookieヘッダが設定されていた場合、Cache-Controlヘッダには privateの値が設定され(既にprivateよりも厳しいアクセス権が設定されていないのであれば)、 Expiresヘッダには現在の日時が設定されるでしょう (それが過去の日付でなければ)。 通常はこれでブラウザは応答をキャッシュできますが、プロキシサーバではキャッシュを行いません。これにはセキュリティ上の理由があります。応答のキャッシュを公に行うと、別のユーザーが同じリソースに続けざまにリクエストを送信して最初のユーザーのクッキーを取得できてしまうからです。

Content-Encoding
リクエストの ヘッダと応答の Content-Typeによっては、前述のようにサーバは応答の本文を自動的に圧縮します。 この場合は、Content-Encoding: gzipヘッダを追加すると本文が圧縮されることを表します。 詳細については応答の圧縮の項目を参照してください。
Content-LengthTransfer-Encoding
サーバは、アプリケーションによって返されたContent-Length ヘッダを常に無視します。 Content-Lengthには本文の長さ(圧縮が適用される場合は圧縮後の長さ)が設定されるか、もしくはContent-Lengthが削除されます。 チャンク転送エンコーディング を使用します(Content-Length ヘッダが追加されます)。
Content-Type

明示的にこのヘッダを設定しなかった場合は、http.ResponseWriterクラスが応答の本文からコンテンツタイプを特定し、それに応じてContent-Typeヘッダを設定します。

Date
現在の日付と時間が設定されます。
Server
Google Frontendの値が設定されます。 デベロップメントサーバではこれに Development/xの値が設定され、 x にはバージョンナンバーが入ります。

管理者アカウントでログインした状態であなたのサイトにアクセスした場合、App Engineは応答ヘッダ内にリクエストごとの統計情報を入れます:

X-AppEngine-Estimated-CPM-US-Dollars
このリクエストが1000回発生した場合に消費するコストを、USドル単位で表した推定値。
X-AppEngine-Resource-Usage
ミリ秒単位で表されたサーバー側での時間を含む、このリクエストによって使用されたリソース。

リソース消費統計情報を含んだ応答はキャッシュできません。

アプリケーションの応答に X-AppEngine-BlobKeyヘッダが設定されている場合、オプションのX-AppEngine-BlobRangeヘッダと合わせて、 blobstore blobのコンテンツの一部または全部で本文を書き換えるのに使われます。 アプリケーションでContent-Typeを設定しない場合、BLOB のMIME タイプが設定されます。 Range が必要な場合は、応答ステータスは 206 Partial Contentに変更され、 Content-Range ヘッダが追加されます。 X-AppEngine-BlobKeyヘッダと X-AppEngine-BlobRange ヘッダは応答から削除されます。 code>blobstore_handlers.BlobstoreDownloadHandlerクラスがそれらヘッダを設定するので、通常はあなたが自分で設定する必要はありません。 詳細については Blobを使用する を参照してください。



アプリケーション設定で応答ヘッダを設定する

カスタムHTTP 応答ヘッダは、アプリケーションの設定ファイルにて、動的および静的なURLごとに設定できます。 詳細については 設定ドキュメント にあるhttp_headersの項目を参照してください。



リクエストタイマー

リクエストハンドラーには、リクエストに対して応答を生成したり返したりする際に時間制限があります。 一般的にはだいたい60秒です。期限を超過すると、リクエストハンドラーは中断されます。

Go のリクエストハンドラがこの期限を超過した時、処理が終了されてランタイム環境はクライアントへHTTP 500 Internal Server Errorを返します。

リクエストが応答を返すまでには60秒の猶予時間がありますが、App Engineはリクエストの生存時間が短いアプリケーション(通常は数百ミリ秒)向けに最適化されています。 効率的なアプリは、ほとんどのリクエストに対して迅速に応答します。 迅速に応答しないアプリは、App Engineのインフラ上で上手く拡張できません。

一般的なDeadlineExceededError の原因と推奨される対処方法についてはDeadlineExceededErrorsに対処するを参照してください。

バックエンドを使用することで、このリクエストタイマーを回避できます。; バックエンドではリクエストの生成や応答について時間制限がありません。



SPDY

SPDYをサポートしているブラウザがSSL経由でアクセスした場合、App Engineアプリケーションは自動的に SPDY プロトコルを使用します。 これはHTTP の代わりとしてGoogleがデザインしたもので、ウェブページのダウンロードの待ち時間を減らすためのものです。 SPDY を使用しても、アプリケーションとユーザーの両方でそのことを意識する必要はありません(普通のHTTPを使っているかのように、アプリケーションを記述できます)。 詳細情報については SPDY プロジェクトのページを参照してください。



ログ機能

Context メソッドのDebugfInfofWarningfErrorfCriticalf で、あなたのアプリケーションログにメッセージを出力します。 開発者コンソールのログページでログの閲覧や分析ができ、appcfg.py request_logsを使ってログのダウンロードができます。

以下では、*http.Requestからappengine.Context を構築し、リクエストされた URLをログに記録するHTTPハンドラを例示します。


package hello

import (
    "appengine"
    "net/http"
)

func init() {
    http.HandleFunc("/", Logger)
}

func Logger(w http.ResponseWriter, r *http.Request) {
    c := appengine.NewContext(r)
    c.Infof("Requested URL: %v", r.URL)
}



環境

Go ランタイムではappengine.Context インタフェースを介して環境情報にアクセスできます。 詳細については appengine パッケージリファレンスを参照してください。



割り当て量と制限

Google App Engine ではトラフィックの増加に応じてあなたのアプリケーションに自動的にリソースを割り当てます。 しかし、それには以下の制限があります。:

  • 待ち時間が少ない場合は(アプリケーションのリクエストへの応答が1秒未満)、App Engineは自動スケーリングを行いません。 待ち時間が長く(多くのリクエストで応答に1秒以上かかる)高いスループットが必要なのアプリケーションではシルバーやゴールドやプレミアムでのサポートをお勧めします。 このサポートレベルのお客様であれば、サポート担当に連絡してより高いスループットを要求できます。
  • 同じサーバ上の他のアプリケーションと効率よくリソースを共有するために、CPU負荷が重いアプリケーションでは追加の待ち時間が発生する場合もあります。 静的ファイルへのリクエストは、この待ち時間の制限を受けません。

アプリケーションが受信した各リクエストは、リクエスト制限にカウントされます。 リクエストに対する応答で送信されたデータは送信帯域幅 (課金可能)制限にカウントされます。

HTTPリクエスト とHTTPS (安全な)リクエストは両方とも リクエスト制限と受信帯域幅 (課金可能)制限と 送信帯域幅 (課金可能) 制限にカウントされます。 開発者コンソールの割り当て量の詳細ページでも情報提供のために別の値として セキュアリクエストセキュア受信帯域幅セキュア送信帯域幅を報告します。 HTTPSリクエストのみがこれらの値にカウントされます。詳細情報については割り当て量ページを参照してください。

システム全体の安全制限に加えて、以下の制限がリクエストハンドラの使用時に適用されます。:

制限 制限値
リクエストサイズ 32 メガバイト
応答サイズ 32 メガバイト
リクエスト時間 60 秒
ファイル(アプリケーションファイルと静的ファイル)の最大数 合計10,000
ディレクトリごとに1,000
アプリケーションファイルの最大サイズ 32 メガバイト
静的ファイルの最大サイズ 32 メガバイト
全てのアプリケーションファイルと静的ファイルの最大合計サイズ 最初の1ギガバイトは無料
それを超えると1ギガバイトあたり月額 $ 0.026