リクエストの処理方法

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

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

リクエストの処理

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

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

次の例の PHP コードは、新しい Silex Application オブジェクトを作成し、サーバーを起動して、2 つの GET リクエストに応答します。

require_once __DIR__ . '/../vendor/autoload.php';

$app = new Silex\Application();

$app->get('/', function () {
    return 'Hello World';
});

$app->get('/goodbye', function () {
    return 'Goodbye World';
});

// @codeCoverageIgnoreStart
if (PHP_SAPI != 'cli') {
    $app->run();
}
// @codeCoverageIgnoreEnd

return $app;

このサンプルでは Silex を使用していますが、他の PHP ウェブ フレームワークも使用できます。

割り当てと制限

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

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

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

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

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

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

リクエストに関する制限

  • リクエスト ヘッダー内では最大 15 KB のサイズが許可されます。
  • リクエストの合計サイズは 32 MB までに制限されます。
  • すべての HTTP/2 リクエストは、アプリケーション サーバーに転送される際に HTTP/1.1 リクエストに変換されます。
  • SSL 接続はロードバランサで終端処理されます。ロードバランサからのトラフィックは、暗号化されたチャネル経由でインスタンスに送信された後、HTTP 経由でアプリケーション サーバーに転送されます。X-Forwarded-Proto ヘッダーを確認すると、元のリクエストが HTTP であったか HTTPS であったかがわかります。

レスポンスに関する制限

  • レスポンスは 64k ブロック単位でバッファリングされます。
  • レスポンス サイズに上限はありません。
  • レスポンス時間の上限は 1 時間です。

サポートされていない HTTP リクエスト

次に示す機能は、App Engine フレキシブル環境ではサポートされません。

  • バックエンド サービスへの HTTP/2 トラフィック
  • インスタンスに直接アクセスする HTTP リクエスト

リクエスト ヘッダー

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

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

リクエストのレスポンス

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

ここで生成したレスポンスになんらかの制限が適用され、それによって変更されたレスポンスがクライアントに返されることもあります。

バッファリングの無効化

App Engine からのすべてのレスポンスは、デフォルトでは 64k ブロック単位でバッファリングされます。場合によっては、バッファリングを無効にして、クライアントにバイトを直接ストリーミングする方が合理的なことがあります。一般的に、ハンギング GET または Server Sent Event(SSE)を使用しているときはこの方法が推奨されます。バッファリングを無効にするには、X-Accel-Buffering レスポンス ヘッダーを no に設定します。

X-Accel-Buffering: no

HTTPS 接続の強制

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

Strict-Transport-Security: max-age=31536000; includeSubDomains

このページは役立ちましたか?評価をお願いいたします。

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

PHP の App Engine フレキシブル環境に関するドキュメント