リージョン ID
REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r が App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。
詳しくは、リージョン ID をご覧ください。
このドキュメントでは、App Engine アプリケーションがリクエストを受信してレスポンスを送信する方法を説明します。詳細については、リクエストのヘッダーとレスポンスのリファレンスをご覧ください。
アプリケーションでサービスを使用している場合は、特定のサービスまたはそのサービスの特定のバージョンへのリクエストを指定できます。サービスのアドレス指定の方法については、リクエストのルーティング方法をご覧ください。
リクエストの処理
アプリケーションは、ウェブサーバーの起動とリクエストの処理を行う役割を果たします。 使用する開発言語に対応している任意のウェブ フレームワークを使用できます。
App Engine はアプリケーションの複数のインスタンスを実行します。各インスタンスには、リクエストを処理するウェブサーバーがそれぞれ割り当てられます。リクエストがルーティングされるインスタンスは任意に決まるため、同じユーザーから連続して送信されたリクエストが同じインスタンスに届くとは限りません。インスタンスは、複数のリクエストを同時に処理できます。インスタンスの数は、トラフィック量の変化に応じて自動的に調整されます。また、app.yaml ファイルの max_concurrent_requests 要素を設定すると、インスタンスが同時に処理できるリクエストの数を変更できます。
サーバーでは、リクエストの URL とアプリの app.yaml 構成ファイル内で指定された URL パターンを比較して、実行する PHP ハンドラ スクリプトを決定します。続いて、リクエストのデータが入力されたスクリプトを実行します。サーバーによって、環境変数と標準入力ストリームにリクエストのデータが配置されます。このスクリプトでは、リクエストに適切なアクションを実行してから、レスポンスを準備して標準出力ストリームに配置します。
すべての HTTP リクエストに対してメッセージ「Hello World！」で応答する PHP スクリプトの例を以下に示します
割り当てと上限
App Engine は、トラフィックが増加すると、自動的にアプリケーションにリソースを割り当てます。ただし、次のような制限があります。
App Engine は、1 秒未満でリクエストに応答するレイテンシが短いアプリケーション向けに、自動スケーリングのための容量を予約しています。
また、CPU の制約を大きく受けるアプリケーションでも、同じサーバー上の他のアプリケーションとリソースを効率的に共有するために、追加のレイテンシが生じる場合があります。静的ファイルへのリクエストには、このようなレイテンシの制限は適用されません。
アプリケーションが受信する各リクエストには、リクエスト数の上限が適用されます。リクエストへのレスポンスとして送信されるデータは、[送信帯域幅（課金対象）] の上限の対象としてカウントされます。
HTTP リクエストと HTTPS（セキュア）リクエストのどちらにも、リクエスト数、受信帯域幅（課金対象）、送信帯域幅（課金対象）の制限が適用されます。コンソールの割り当ての詳細ページでは、参考のために、[安全なリクエスト数]、[安全な受信帯域幅]、[安全な送信帯域幅] の値もそれぞれ報告されます。これらの値は、HTTPS リクエストにのみ適用されます。詳細については、割り当てページをご覧ください。
リクエスト ハンドラの使用には、それぞれ次の上限や時間制限が適用されます。
| 上限と時間制限 | 量 |
|---|---|
| リクエスト サイズ | 32 MB |
| レスポンス サイズ | 32 MB |
| リクエストのタイムアウト | アプリが使用するスケーリングのタイプに依存 |
| 最大合計ファイル数（アプリファイルと静的ファイル） | 合計 10,000 ファイル 1 ディレクトリあたり 1,000 ファイル |
| アプリケーション ファイルの最大サイズ | 32 MB |
| 静的ファイルの最大サイズ | 32 MB |
| すべてのアプリケーション ファイルと静的ファイルの最大合計サイズ | 最初の 1 GB は無料 最初の 1 GB を超えると、以降は 1 GB あたり毎月 $ 0.026 |
| 保留中のリクエストのタイムアウト | 10 秒 |
| 1 つのリクエスト ヘッダー フィールドの最大サイズ | スタンダード環境の第 2 世代ランタイム用に 8 KB。これらのランタイムへのリクエストでヘッダー フィールドが 8 キロバイトを超えると、HTTP 400 エラーが返されます。 |
リクエストに関する上限
すべての HTTP/2 リクエストは、アプリケーション サーバーに転送される際に HTTP/1.1 リクエストに変換されます。
レスポンスに関する上限
動的レスポンスの上限は 32 MB です。スクリプト ハンドラが生成したレスポンスの大きさがこの上限を超える場合は、サーバーから内部サーバーエラー ステータス コード 500 を示す空のレスポンスが返されます。Cloud Storage からデータを返すレスポンスには、この上限が適用されません。
第 2 世代ランタイムでは、レスポンス ヘッダーの上限は 8 KB です。この上限を超えるレスポンス ヘッダーは HTTP 502 エラーを返し、ログに
upstream sent too big header while reading response header from upstreamが記録されます。
リクエスト ヘッダー
受信した HTTP リクエストには、クライアントから送信された HTTP ヘッダーが含まれています。セキュリティ上の理由から、一部のヘッダーは、アプリケーションに到達する前に中間プロキシによってサニタイズ（リスクのある部分などを削除）または修正されます。
詳細については、リクエスト ヘッダーのリファレンスをご覧ください。
リクエスト タイムアウトの処理
App Engine はリクエストの存続時間が短いアプリケーション（通常は数百ミリ秒程度）向けに最適化されています。効率的なアプリは、大部分のリクエストに短時間で応答します。そうでないアプリは、App Engine のインフラストラクチャに合わせて適切にスケールされません。このレベルのパフォーマンスを実現するには、システムによって要求される最大リクエスト タイムアウト内に、すべてのアプリがレスポンスを返す必要があります。
PHP スクリプトがこの期限を超過すると、接続ステータス ビットフィールドのTIMEOUT ビットが設定されます。このスクリプトには、長時間実行されているタスクをクリーンアップしてユーザーにレスポンスを返すまでの時間に対する短い別の制限もあります。
この制限時間までにスクリプトからレスポンスが返されないと、ハンドラが停止し、デフォルトのエラー レスポンスが返されます。
レスポンス
App Engine は、$_REQUEST 配列に所定の設定を行ってスクリプトを呼び出し、このスクリプトからの出力をバッファリングします。そしてスクリプトの実行が完了すると、バッファリングされた出力をエンドユーザーに送信します。生成するレスポンスにはサイズの上限があり、レスポンスはクライアントに返される前に変更される可能性があります。
詳細については、リクエストに対するレスポンスのリファレンスをご覧ください。レスポンスのストリーミング
App Engine は、レスポンスのストリーミングをサポートしていません。つまり、リクエスト 1 件のデータをチャンクに分けて順に送信することはできません。コードからのデータ全体が前述のように収集されて、単一の HTTP レスポンスとして送信されます。
レスポンスの圧縮
App Engine は、gzip をサポートするクライアントに gzip 圧縮されたコンテンツを可能な限り配信するように設計されています。コンテンツを圧縮する必要があるかどうかを判断するために、App Engine はリクエストを受信すると次の処理を行います。リクエスト内の
Accept-EncodingヘッダーとUser-Agentヘッダーの両方を確認して、クライアントが圧縮されたレスポンスを適切に受信できるかどうかを確認します。このアプローチにより、gzip 圧縮されたコンテンツを一般的なブラウザで利用する際に発生する、周知のバグを回避します。レスポンス ハンドラに構成した
Content-Typeヘッダーを表示して、コンテンツを圧縮することが適切であるかどうかを確認します。一般的に、テキストベースのコンテンツ タイプは圧縮に適していますが、バイナリ コンテンツ タイプは適していません。
次の点にご注意ください。
クライアントは
Accept-EncodingとUser-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-Controlをpublicに設定する必要があります。Cache-Controlprivateまたはno-storeディレクティブを指定しなければ、Google フロントエンドによってキャッシュに保存されることもあります。app.yamlでこのヘッダーを設定しない場合、App Engine で静的ファイルまたはディレクトリ ハンドラによって処理されるすべてのレスポンスにこのヘッダーが自動的に追加されます。詳しくは、追加または置換されるヘッダーをご覧ください。Vary: リクエストで送信されるヘッダーに基づいて、URL に対してさまざまなレスポンスがキャッシュから返されるようにするには、Accept、Accept-Encoding、Origin、X-Originのうち 1 つ以上をVaryレスポンス ヘッダーに設定します。カーディナリティが高い可能性があるため、他の
Vary値についてはデータがキャッシュに保存されません。例:
次のレスポンス ヘッダーを指定します。
Vary: Accept-Encodingアプリは
Accept-Encoding: gzipヘッダーを含むリクエストを受信します。App Engine は圧縮されたレスポンスを返し、Google フロントエンドはレスポンス データの gzip 圧縮されたバージョンをキャッシュに保存します。この URL に対するAccept-Encoding: gzipヘッダーを含む後続のすべてのリクエストは、キャッシュが無効になる（キャッシュの有効期限が切れた後にコンテンツが変更されたことによる）までキャッシュから gzip 圧縮されたデータを受信します。アプリは、
Accept-Encodingヘッダーが含まれていないリクエストを受信します。App Engine は圧縮されていないレスポンスを返し、Google フロントエンドはレスポンス データの圧縮されていないバージョンをキャッシュに保存します。この URL に対するAccept-Encodingヘッダーが含まれていない後続のすべてのリクエストは、キャッシュが無効になるまでキャッシュから圧縮されたデータを受信します。
Varyレスポンス ヘッダーを指定しない場合、Google フロントエンドは URL に対して 1 つのキャッシュ エントリを作成し、作成したエントリをリクエストのヘッダーにかかわらず、すべてのリクエストで使用します。例:Vary: Accept-Encodingレスポンス ヘッダーが指定されていません。- リクエストには
Accept-Encoding: gzipヘッダーが含まれ、レスポンス データの gzip 圧縮されたバージョンがキャッシュに保存されます。 - 2 番目のリクエストには
Accept-Encoding: gzipヘッダーが含まれていません。ただし、キャッシュにはレスポンス データの gzip 圧縮されたバージョンが含まれているため、クライアントが圧縮されていないデータをリクエストした場合でも、レスポンスは gzip 圧縮されます。
リクエスト内のヘッダーもキャッシュ保存に影響します。
- リクエストに
Authorizationヘッダーが含まれている場合、コンテンツは Google フロントエンドによってキャッシュに保存されません。
キャッシュの有効期限
デフォルトでは、App Engine の静的ファイルとディレクトリ ハンドラによってレスポンスに追加されるキャッシュ ヘッダーは、クライアントとウェブプロキシ（Google フロントエンドなど）が 10 分後にキャッシュを期限切れにするよう指示します。
任意の有効期限が設定された状態でファイルが転送された場合、一般的にユーザーは自身のブラウザ キャッシュを消去しても、ウェブプロキシのキャッシュからファイルを消去することはできません。アプリの新しいバージョンを再度デプロイしても、キャッシュはリセットされません。静的ファイルを変更する場合には、有効期限は短く（1 時間未満）設定してください。多くの場合、デフォルトの 10 分で十分です。
app.yaml ファイルで default_expiration 要素を指定すると、すべての静的ファイルとディレクトリ ハンドラのデフォルトの有効期限を変更できます。個別のハンドラに特定の有効期限を設定するには、app.yaml ファイルのハンドラ要素内で expiration 要素を指定します。
有効期限要素の時間で指定する値は、Cache-Control と Expires の HTTP レスポンス ヘッダーの設定に使用されます。
アプリ キャッシング
PHP のランタイム環境には、PHP の中間コードをキャッシュに保存してアプリケーションのレスポンス時間を大幅に改善できる OPcache が用意されています。OPcache によるキャッシングを無効にするには、アプリケーションの php.ini ファイルでopcache.enabled = "0" を設定します。
ロギング
App Engine ウェブサーバーは、ウェブ リクエストへのレスポンスとしてハンドラ スクリプトが標準出力ストリームに書き込むすべての内容をキャプチャします。また、ハンドラ スクリプトが標準エラー ストリームに書き込むすべての内容もキャプチャし、ログデータとして保存します。アプリケーションのログデータは、Cloud Logging を使用して、コンソールで表示できます。App Engine PHP ランタイム環境では、Logs API を呼び出す PHP の組み込み syslog() 関数を使用して、アプリケーションからの任意のメッセージをログに記録できます。
環境
HTTPS 接続の強制
セキュリティ上の理由から、すべてのアプリケーションは、https で接続するようクライアントに促すべきです。特定のページまたはドメイン全体で http よりも https を優先するようにブラウザに指示するには、レスポンスに Strict-Transport-Security ヘッダーを設定します。次に例を示します。
Strict-Transport-Security: max-age=31536000; includeSubDomains
非同期バックグラウンド作業の処理
バックグラウンド作業とは、HTTP レスポンスを配信した後、アプリがリクエストに対して行う作業です。バックグラウンド作業をアプリ内で実施することは避け、コードを見直して、レスポンスを配信する前にすべての非同期オペレーションが完了するようにしてください。
長時間実行ジョブには、Cloud Tasks の使用をおすすめします。Cloud Tasks では、HTTP リクエストが長時間継続し、非同期処理が終了した後にのみレスポンスを返します。