リクエストの処理方法

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

サービスを利用するアプリケーションでは、特定のサービスに対するリクエストか、そのサービスの特定のバージョンに対するリクエストを扱うことができます。サービスをアドレス指定する方法の詳細は、リクエストをルーティングする方法をご覧ください。

リクエストの処理

ウェブサーバーを起動してリクエストを処理するのはアプリケーション側の役割です。使用するウェブ フレームワークは、開発言語が対応していれば、どれでもかまいません。

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

次のサンプルの JavaScript コードは、サーバーを起動し、ウェブ クライアントからルートパス('/')に送られてくるすべての GET リクエストに応答し、port 8080 で動いているサーバーを介して "Hello, world!" メッセージを表示します。

const express = require('express');

const app = express();

app.get('/', (req, res) => {
  res.status(200).send('Hello, world!').end();
});

// Start the server
const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
  console.log(`App listening on port ${PORT}`);
  console.log('Press Ctrl+C to quit.');
});

最後の数行に注意してください。ここでは、process.env.PORT 変数で指定されるポートをサーバーがリッスンするように設定しています。これは App Engine ランタイムが設定する環境変数です。サーバーは、このポートをリッスンしないとリクエストを受信できません。

割り当てと制限

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: 内部サーバーエラー)が返されます。Blobstore または Google Cloud Storage から送られてきたデータを処理するレスポンスには、この上限は適用されません。

リクエスト ヘッダー

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

詳細は、リクエスト ヘッダーをご覧ください。

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

こちらが生成するレスポンスにも制限があります。また、そのレスポンスはクライアントに返される前に変更される可能性があります。

詳細は、リクエストのレスポンスをご覧ください。

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

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

レスポンスの圧縮

クライアントから送られてきた HTTP ヘッダーに含まれている最初のリクエストに基づいて、それが圧縮(gzip 圧縮)コンテンツを受け入れるクライアントであると判断すると、App Engine はハンドラのレスポンス データを自動的に圧縮し、適切なレスポンス ヘッダーを付加します。また、リクエスト ヘッダー(Accept-EncodingUser-Agent)に基づいて、圧縮レスポンスをクライアントが確実に受信できるかどうかを判断します。

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

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

リクエスト期限の指定

リクエスト ハンドラがリクエストに対するレスポンスを生成して返すまでの時間には一定の制限があり、通常約 60 秒です。この期限に達すると、リクエスト ハンドラは中断されます。

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

DeadlineExceededError の一般的な原因と推奨されている回避方法については、期限と DeadlineExceededError をご覧ください。
このページは役立ちましたか?評価をお願いいたします。

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

Node.js 用 App Engine スタンダード環境に関するドキュメント