リクエストの処理方法

は、

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

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

リクエストの処理

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

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

サーバーでは、リクエストの URL とアプリの構成ファイル app.yaml で指定された URL パターンを比較することで、実行する PHP ハンドラ スクリプトを判断します。つづいて、リクエストのデータが入力されたスクリプトを実行します。サーバーによって、環境変数と標準入力ストリームにリクエストのデータが配置されます。このスクリプトでは、リクエストに適切なアクションを実行してから、レスポンスを準備して標準出力ストリームに配置します。

すべての HTTP リクエストに対してメッセージ「Hello World!」で応答する PHP スクリプトの例を以下に示します。

<?php

echo "hello world!";

割り当てと制限

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

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

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

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

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

リクエスト ハンドラの使用には、具体的に次の制限が適用されます。

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

レスポンスに関する制限事項

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

リクエスト ヘッダー

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

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

リクエストに対するレスポンス

App Engine は、$_REQUEST 配列が設定されたスクリプトを呼び出し、このスクリプトの出力をバッファリングします。スクリプトの実行が完了すると、バッファリングした出力をエンドユーザーに送信します。

ここで生成するレスポンスには制限があり、それに基づいて変更されたレスポンスがクライアントに返されることがあります。

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

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

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

レスポンスの圧縮

クライアントから送信された HTTP ヘッダーに記述された元のリクエストから、そのクライアントが圧縮(gzip 圧縮)コンテンツを受け入れ可能であることがわかると、App Engine はハンドラのレスポンス データを自動的に圧縮し、適切なレスポンス ヘッダーを付加します。圧縮されたレスポンスをクライアントが適切に受信できるかどうかを、Accept-EncodingUser-Agent の両方のリクエスト ヘッダーを使用して判断します。

カスタム クライアントが圧縮されたレスポンスを受信できることを示すには、Accept-EncodingUser-Agent の両方のヘッダーに値 gzip を指定します。レスポンスの Content-Type も、圧縮が適切かどうかを判断するために使用されます。一般に、テキストベースのコンテンツ タイプは圧縮されますが、バイナリ コンテンツ タイプは圧縮されません。

レスポンスが App Engine で自動的に圧縮された場合は、Content-Encoding ヘッダーがレスポンスに追加されます。

リクエスト期限の指定

PHP スクリプトでは、リクエストへのレスポンスを生成して返送するまでの時間に制限があり、多くの場合、この時間は約 60 秒に設定されています。この制限に達すると、接続ステータス ビットフィールドの TIMEOUT ビットが設定されます。このスクリプトには、長時間実行されているタスクをクリーンアップしてユーザーにレスポンスを返すまでの時間に対する短い別の制限もあります。

この制限時間までにスクリプトからレスポンスが返されないと、ハンドラが終了し、デフォルトのエラー レスポンスが返されます。

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

アプリ キャッシング

PHP のランタイム環境には、PHP の中間コードをキャッシュに保存してアプリケーションのレスポンス時間を大幅に改善できる OPcache が用意されています。OPcache によるキャッシングを無効にするには、アプリケーションの php.ini ファイルで opcache.enabled = "0" を設定します。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

App Engine standard environment for PHP 7.2 docs