Python 3.8が一般提供になりました。

リクエストの処理方法

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。既存のアプリでは省略可能ですが、まもなく、新しいアプリのすべてにおいて App Engine の URL に REGION_ID.r を含めることが必須となる予定です。

移行がスムーズに行われるように、リージョン ID を使用するよう App Engine を徐々に更新しています。Google Cloud プロジェクトがまだ更新されていない場合、アプリにリージョン ID が表示されません。ID は既存のアプリでは省略可能なため、リージョン ID が既存のアプリで使用可能になったときに、URL の更新や他の変更を行う必要はありません。

詳しくは、リージョン ID をご覧ください。

このドキュメントでは、App Engine アプリケーションがリクエストを受信してレスポンスを送信する方法を説明します。詳細については、リクエストのヘッダーとレスポンスのリファレンスをご覧ください。

アプリケーションでサービスを使用している場合は、特定のサービスまたはそのサービスの特定のバージョンへのリクエストを指定できます。サービスのアドレス指定の方法については、リクエストのルーティング方法をご覧ください。

リクエストの処理

アプリケーションは、ウェブサーバーの起動とリクエストの処理を行う役割を果たします。 使用する開発言語に対応している任意のウェブ フレームワークを使用できます。

App Engine はアプリケーションの複数のインスタンスを実行します。各インスタンスには、リクエストを処理するウェブサーバーがそれぞれ割り当てられます。リクエストがルーティングされるインスタンスは任意に決まるため、同じユーザーから連続して送信されたリクエストが同じインスタンスに届くとは限りません。インスタンスは、複数のリクエストを同時に処理できます。インスタンスの数は、トラフィック量の変化に応じて自動的に調整されます。また、app.yaml ファイルの max_concurrent_requests 要素を設定すると、インスタンスが同時に処理できるリクエストの数を変更できます。

割り当てと上限

App Engine は、トラフィックが増加すると、自動的にアプリケーションにリソースを割り当てます。ただし、次のような制限があります。

  • App Engine は、1 秒未満でリクエストに応答するレイテンシが短いアプリケーション向けに、自動スケーリングのための容量を予約しています。多くのリクエストで 1 件につき 1 秒を超えるなど、レイテンシが大きく、スループットが高いアプリケーションでは、シルバー、ゴールド、またはプラチナのサポートが必要です。これらのレベルのサポートを契約済みの場合は、サポート担当者に連絡してスループットの上限を引き上げることができます。

  • また、CPU の制約を大きく受けるアプリケーションでも、同じサーバー上の他のアプリケーションとリソースを効率的に共有するために、追加のレイテンシが生じる場合があります。静的ファイルへのリクエストには、このようなレイテンシの制限は適用されません。

アプリケーションが受信する各リクエストには、リクエスト数の上限が適用されます。リクエストへのレスポンスとして送信されるデータは、送信帯域幅(課金対象)の上限対象としてカウントされます。

HTTP リクエストと HTTPS(セキュア)リクエストのどちらにも、リクエスト数受信帯域幅(課金対象)送信帯域幅(課金対象)の上限が適用されます。Cloud Console の割り当ての詳細ページでは、参考のために、[安全なリクエスト数]、[安全な受信帯域幅]、[安全な送信帯域幅] の値もそれぞれ報告されます。これらの値は、HTTPS リクエストにのみ適用されます。詳細については、割り当てページをご覧ください。

リクエスト ハンドラの使用には、それぞれ次の上限や時間制限が適用されます。

上限と時間制限
リクエスト サイズ 32 MB
レスポンス サイズ 32 MB
リクエスト タイムアウト アプリが使用するスケーリングのタイプに依存
最大合計ファイル数(アプリファイルと静的ファイル) 合計 10,000 ファイル
1 ディレクトリあたり 1,000 ファイル
アプリケーション ファイルの最大サイズ 32 MB
静的ファイルの最大サイズ 32 MB
すべてのアプリケーション ファイルと静的ファイルの最大合計サイズ 最初の 1 GB は無料
最初の 1 GB を超えると、以降は 1 GB あたり毎月 $ 0.026

レスポンスに関する上限

動的レスポンスの上限は 32 MB です。スクリプト ハンドラが生成したレスポンスの大きさがこの上限を超える場合は、サーバーから内部サーバーエラー ステータス コード 500 を示す空のレスポンスが返されます。Blobstore または Google Cloud Storage からのデータを処理するレスポンスには、この上限は適用されません。

リクエスト ヘッダー

受信した HTTP リクエストには、クライアントから送信された HTTP ヘッダーが含まれています。セキュリティ上の理由から、一部のヘッダーは、アプリケーションに到達する前に中間プロキシによってサニタイズ(リスクのある部分などを削除)または修正されます。

詳細については、リクエスト ヘッダーのリファレンスをご覧ください。

リクエスト期限の指定

App Engine はリクエストの存続時間が短いアプリケーション(通常は数百ミリ秒程度)向けに最適化されています。効率的なアプリは、大部分のリクエストに短時間で応答します。そうでないアプリは、App Engine のインフラストラクチャに合わせて適切にスケールされません。

アプリケーションへのすべてのリクエストは、最大リクエスト タイムアウト内にレスポンスを返す必要があります。アプリによってタイムアウトまでにレスポンスが返されなければ、App Engine はリクエスト ハンドラを中断します。

レスポンス

生成するレスポンスにはサイズの上限があり、レスポンスはクライアントに返される前に変更される可能性があります。

詳細については、リクエストに対するレスポンスのリファレンスをご覧ください。

レスポンスのストリーミング

App Engine は、レスポンスのストリーミングをサポートしていません。つまり、リクエスト 1 件のデータをチャンクに分けて順に送信することはできません。コードからのデータ全体が前述のように収集されて、単一の HTTP レスポンスとして送信されます。

レスポンスの圧縮

コードから返されるレスポンスで、以下の両方の条件が満たされる場合、App Engine はレスポンスのデータを圧縮します。

  • リクエストには、値として gzip をはじめとする Accept-Encoding ヘッダーが含まれます。
  • レスポンスには、HTML、CSS、JavaScript などのテキストベースのデータが含まれます。

App Engine の静的ファイルまたはディレクトリ ハンドラによって返されるレスポンスの場合、次の条件がすべて満たされると、レスポンス データが圧縮されます。

  • リクエストの値の 1 つとして、gzip が指定された Accept-Encoding が含まれています。
  • クライアントは、圧縮形式のレスポンス データを受信できます。Google フロントエンドでは、圧縮されたレスポンスに問題があることが分かっているクライアントのリストを保持します。これらのクライアントは、リクエスト ヘッダーに Accept-Encoding: gzip が含まれていても、アプリの静的ハンドラから圧縮データを受信することはありません。
  • レスポンスには、HTML、CSS、JavaScript などのテキストベースのデータが含まれます。

次の点にご注意ください。

  • クライアントは Accept-EncodingUser-Agent の両方のリクエスト ヘッダーを gzip に設定することにより、テキストベースのコンテンツ タイプの圧縮を強制できます。

  • リクエストで Accept-Encoding ヘッダーに gzip を指定しない場合、App Engine でレスポンス データが圧縮されません。

  • Google フロントエンドは、App Engine の静的ファイルとディレクトリ ハンドラからのレスポンスをキャッシュに保存します。最初にキャッシュに保存されるレスポンス データの種類、レスポンスに指定した Vary ヘッダー、リクエストに含まれるヘッダーなど、さまざまな要因によって、クライアントが圧縮データをリクエストしても圧縮されていないデータを受信する場合があります。また、その逆の場合もあります。詳細については、レスポンスのキャッシュ保存をご覧ください。

レスポンスのキャッシュ保存

Google フロントエンド、場合によってはユーザーのブラウザおよびその他の中間キャッシング プロキシ サーバーは、レスポンスに指定した標準キャッシング ヘッダーの指示に従って、アプリのレスポンスをキャッシュに保存します。これらのレスポンス ヘッダーは、フレームワークを介して、またはコード内で直接指定するか、App Engine の静的ファイルとディレクトリ ハンドラを使用して指定できます。

Google フロントエンドでは、キャッシュキーはリクエストの完全な URL です。

静的コンテンツのキャッシュ保存

更新された静的コンテンツが公開されるとクライアントが直ちに受信できるように、css/v1/styles.css などのバージョニングされたディレクトリから静的コンテンツを配信することをおすすめします。Google フロントエンドは、キャッシュが期限切れになるまで、キャッシュの検証(更新されたコンテンツの確認)を行いません。キャッシュが期限切れになった後でも、リクエスト URL のコンテンツが変更されるまでキャッシュは更新されません。

app.yaml で設定できる次のレスポンス ヘッダーは、Google フロントエンドがコンテンツをキャッシュに保存する方法とタイミングに影響します。

  • Google フロントエンドでコンテンツがキャッシュに保存されるようにするには、Cache-Controlpublic に設定する必要があります。app.yaml でこのヘッダーを設定しない場合、App Engine で静的ファイルまたはディレクトリ ハンドラによって処理されるすべてのレスポンスにこのヘッダーが自動的に追加されます。詳しくは、追加または置換されるヘッダーをご覧ください。

  • Vary: リクエストで送信されるヘッダーに基づいて、URL に対してさまざまなレスポンスがキャッシュから返されるようにするには、AcceptAccept-EncodingOriginX-Origin のうち 1 つ以上を Vary レスポンス ヘッダーに設定します。

    カーディナリティが高い可能性があるため、他の Vary 値についてはデータがキャッシュに保存されません。

    例:

    1. 次のレスポンス ヘッダーを指定します。

      Vary: Accept-Encoding

    2. アプリは Accept-Encoding: gzip ヘッダーを含むリクエストを受信します。App Engine は圧縮されたレスポンスを返し、Google フロントエンドはレスポンス データの gzip 圧縮されたバージョンをキャッシュに保存します。この URL に対する Accept-Encoding: gzip ヘッダーを含む後続のすべてのリクエストは、キャッシュが無効になる(キャッシュの有効期限が切れた後にコンテンツが変更されたことによる)までキャッシュから gzip 圧縮されたデータを受信します。

    3. アプリは、Accept-Encoding ヘッダーが含まれていないリクエストを受信します。App Engine は圧縮されていないレスポンスを返し、Google フロントエンドはレスポンス データの圧縮されていないバージョンをキャッシュに保存します。この URL に対する Accept-Encoding ヘッダーが含まれていない後続のすべてのリクエストは、キャッシュが無効になるまでキャッシュから圧縮されたデータを受信します。

    Vary レスポンス ヘッダーを指定しない場合、Google フロントエンドは URL に対して 1 つのキャッシュ エントリを作成し、作成したエントリをリクエストのヘッダーにかかわらず、すべてのリクエストで使用します。例:

    1. Vary: Accept-Encoding レスポンス ヘッダーが指定されていません。
    2. リクエストには Accept-Encoding: gzip ヘッダーが含まれ、レスポンス データの gzip 圧縮されたバージョンがキャッシュに保存されます。
    3. 2 番目のリクエストには Accept-Encoding: gzip ヘッダーが含まれていません。ただし、キャッシュには gzip 圧縮されたバージョンのレスポンス データが含まれているため、クライアントが非圧縮データをリクエストしたとしても、レスポンスは gzip されます。

リクエスト内のヘッダーもキャッシュ保存に影響します。

  • リクエストに Authorization ヘッダーが含まれている場合、コンテンツは Google フロントエンドによってキャッシュに保存されません。

キャッシュの有効期限

デフォルトでは、App Engine の静的ファイルとディレクトリ ハンドラによってレスポンスに追加されるキャッシュ ヘッダーは、クライアントとウェブプロキシ(Google フロントエンドなど)が 10 分後にキャッシュを期限切れにするよう指示します。

任意の有効期限が設定された状態でファイルが転送された場合、一般的にユーザーは自身のブラウザ キャッシュを消去しても、ウェブプロキシのキャッシュからファイルを消去することはできません。アプリケーションの新しいバージョンを再度デプロイしても、キャッシュはリセットされません。静的ファイルを変更する場合には、有効期限は短く(1 時間未満)設定してください。ほとんどの場合、デフォルトの 10 分間の有効期限で十分です。

app.yaml ファイルで default_expiration 要素を指定すると、すべての静的ファイルとディレクトリ ハンドラのデフォルトの有効期限を変更できます。個別のハンドラに特定の有効期限を設定するには、app.yaml ファイルのハンドラ要素内で expiration 要素を指定します。

有効期限要素の時間で指定する値は、Cache-ControlExpires の HTTP レスポンス ヘッダーの設定に使用されます。

HTTPS 接続の強制

セキュリティ上の理由から、すべてのアプリケーションは、https で接続するようクライアントに促すべきです。特定のページまたはドメイン全体で http よりも https を優先するようにブラウザに指示するには、レスポンスに Strict-Transport-Security ヘッダーを設定します。例:

Strict-Transport-Security: max-age=31536000; includeSubDomains
アプリによって配信される静的コンテンツにこのヘッダーを設定するには、アプリの静的ファイルとディレクトリ ハンドラにヘッダーを追加します。

コードから生成されるレスポンスに対してこのヘッダーを設定するには、flask-talisman ライブラリを使用します。