注: Python 2.7 は、2024 年 1 月 31 日にサポートが終了しました。既存の Python 2.7 アプリケーションは引き続き実行され、トラフィックを受信します。ただし、サポート終了日を過ぎると、ランタイムを使用するアプリケーションの再デプロイが App Engine によってブロックされることがあります。サポートされている最新バージョンの Python に移行することをおすすめします。

リクエストの処理方法

リージョン 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 要素を設定すると、インスタンスが同時に処理できるリクエストの数を変更できます。

App Engine がアプリケーションのウェブリクエストを受け取ると、アプリケーションの app.yaml 構成ファイルに記載されている URL に対応するハンドラスクリプトを呼び出します。Python 2.7 ランタイムは、下位互換性を維持するため、WSGI 標準と CGI 標準をサポートしますが、WSGI の方をおすすめします。これがないと Python 2.7 の一部の機能が動作しません。アプリケーションのスクリプトハンドラの構成に応じて、リクエストが WSGI と CGI のどちらを使用して処理されるかが決まります。

次の Python スクリプトはリクエストに対して、HTTP ヘッダーとメッセージ Hello, World! で応答します。

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        self.response.write("Hello, World!")


app = webapp2.WSGIApplication(
    [
        ("/", MainPage),
    ],
    debug=True,
)

複数のリクエストを各ウェブサーバーに並列でディスパッチするには、app.yaml ファイルに threadsafe: true を追加して、アプリケーションをスレッドセーフとしてマークします。スクリプトハンドラで CGI が使用されている場合は、同時リクエストを使用できません。

割り当てと制限

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

App Engine は、1 秒未満でリクエストに応答するレイテンシが短いアプリケーション向けに、自動スケーリングのための容量を予約しています。
また、CPU の制約を大きく受けるアプリケーションでも、同じサーバー上の他のアプリケーションとリソースを効率的に共有するために、追加のレイテンシが生じる場合があります。静的ファイルへのリクエストには、このようなレイテンシの制限は適用されません。

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

HTTP リクエストと HTTPS（セキュア）リクエストのどちらにも、[リクエスト数]、[受信帯域幅（課金対象）]、[送信帯域幅（課金対象）] の上限が適用されます。Google Cloud コンソールの割り当ての詳細ページでは、参考のために、[安全なリクエスト数]、[安全な受信帯域幅]、[安全な送信帯域幅] の値もそれぞれ報告されます。これらの値は、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 を示す空のレスポンスが返されます。以前の Blobstore または Cloud Storage からのデータを処理するレスポンスには、この上限は適用されません。
第 2 世代ランタイムでは、レスポンスヘッダーの上限は 8 KB です。この上限を超えるレスポンスヘッダーは HTTP 502 エラーを返し、ログに upstream sent too big header while reading response header from upstream が記録されます。

リクエストヘッダー

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

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

リクエストタイムアウトの処理

App Engine はリクエストの存続時間が短いアプリケーション（通常は数百ミリ秒程度）向けに最適化されています。効率的なアプリは、大部分のリクエストに短時間で応答します。そうでないアプリは、App Engine のインフラストラクチャに合わせて適切にスケールされません。このレベルのパフォーマンスを実現するには、システムによって要求される最大リクエストタイムアウト内に、すべてのアプリがレスポンスを返す必要があります。

アプリがこの期限を超過すると、App Engine はリクエストハンドラを中断します。Python ランタイム環境では、google.appengine.runtime から DeadlineExceededError 例外を発生させることでこの処理を行います。この例外がリクエストハンドラでキャッチされないと、すべてのキャッチされない例外と同様に、ランタイム環境からクライアントに HTTP 500 サーバーエラーが返されます。

リクエストハンドラは、このエラーをキャッチしてレスポンスをカスタマイズできます。例外発生後、ランタイム環境によりリクエストハンドラに対して、カスタムレスポンスを作成するためのわずかな時間（1 秒未満）が与えられます。

class TimerHandler(webapp2.RequestHandler):
    def get(self):
        from google.appengine.runtime import DeadlineExceededError

        try:
            time.sleep(70)
            self.response.write("Completed.")
        except DeadlineExceededError:
            self.response.clear()
            self.response.set_status(500)
            self.response.out.write("The request did not complete in time.")

2 度目の期限までにハンドラがレスポンスを返さないか、例外が発生しない場合、ハンドラは停止され、デフォルトのエラーレスポンスが返されます。

警告: DeadlineExceededError は、finally ブロックを含むプログラムのあらゆる場所で発生し、プログラムを無効な状態にする可能性があります。この状態では、ロックが解除されないことがあるため、スレッド化コード（組み込みの threading ライブラリを含む）でデッドロックや予期しないエラーが発生することがあります。Java とは異なり、ランタイムがプロセスを停止しないことがあるため、同じインスタンスに対する将来のリクエストで問題が生じる可能性があるので注意してください。安全のためには、DeadlineExceededError に依存せず、リクエストが制限時間前に余裕を持って完了するようにします。

レスポンス

App Engine は、Request を使用してハンドラスクリプトを呼び出し、スクリプトが制御を返すのを待ちます。標準出力ストリームに書き込まれたすべてのデータが HTTP レスポンスとして送信されます。

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

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

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

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-Control private または no-store ディレクティブを指定しなければ、Google フロントエンドによってキャッシュに保存されることもあります。app.yaml でこのヘッダーを設定しない場合、App Engine で静的ファイルまたはディレクトリハンドラによって処理されるすべてのレスポンスにこのヘッダーが自動的に追加されます。詳しくは、追加または置換されるヘッダーをご覧ください。
Vary: リクエストで送信されるヘッダーに基づいて、URL に対してさまざまなレスポンスがキャッシュから返されるようにするには、Accept、Accept-Encoding、Origin、X-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-Control と Expires の HTTP レスポンスヘッダーの設定に使用されます。

アプリキャッシング

Python ランタイム環境では、リクエスト間でインポートされたモジュールが単一のウェブサーバーにキャッシュされます。これは、スタンドアロン Python アプリケーションにおいて、モジュールが複数のファイルによってインポートされた場合でも、1 回しか読み込まれないのに似ています。WSGI ハンドラはモジュールのため、リクエスト間でキャッシュされます。CGI ハンドラスクリプトは、main() ルーチンを提供する場合のみキャッシュに保存されます。それ以外の場合、CGI ハンドラスクリプトはリクエストごとに読み込まれます。

アプリキャッシングにより、レスポンスの時間が大幅に短縮されます。後述するように、すべての CGI ハンドラスクリプトで main() ルーチンを使用することをおすすめします。

インポートのキャッシュ

効率を考えて、ウェブサーバーは、インポートしたモジュールをメモリに保持し、以降の同じサーバー上の同じアプリケーションに対するリクエストでそれらの再読み込みや再評価を行いません。ほとんどのモジュールは、インポート時にグローバルデータを初期化するなどの副次的な影響を及さないため、それらをキャッシュに保存してもアプリケーションの動作は変わりません。

アプリケーションでリクエストのたびに評価対象モジュールに依存するモジュールをインポートする場合は、アプリケーションでこのキャッシング動作に対応する必要があります。

CGI ハンドラのキャッシュ

インポートしたモジュールだけでなく、CGI ハンドラスクリプト自体をキャッシュに保存するように App Engine に指示できます。ハンドラスクリプトで main() という名前の関数を定義すると、インポートしたモジュールと同様に、スクリプトとそのグローバル環境がキャッシュに保存されます。特定のウェブサーバーでスクリプトを初めてリクエストした場合は、通常どおりスクリプトの評価が行われます。以降のリクエストでは、App Engine がキャッシュ環境内の main() 関数を呼び出します。

ハンドラスクリプトをキャッシュに保存するには、App Engine が引数なしで main() を呼び出すことができる必要があります。ハンドラスクリプトが main() 関数を定義しない場合または main() 関数に引数（デフォルトを持たない）が必要な場合は、App Engine がリクエストごとにスクリプト全体を読み込んで評価します。

解析済みの Python コードをメモリに保持することで時間が節約され、迅速なレスポンスが可能になります。グローバル環境のキャッシュには、他にも次の用途があります。

コンパイル済みの正規表現。すべての正規表現が解析され、コンパイル済みの形式で保存されます。コンパイル済みの正規表現をグローバル変数に保存しておくと、アプリキャッシングを使用して、コンパイル済みのオブジェクトをリクエスト間で再利用できます。
GqlQuery オブジェクト。GqlQuery オブジェクトの作成時に、GQL クエリ文字列が解析されます。パラメータバインディングを伴う GqlQuery オブジェクトと bind() メソッドの再利用の方が、毎回オブジェクトを再構築するより高速です。値のパラメータバインディングを伴う GqlQuery オブジェクトをグローバル変数に保存しておくと、リクエストのたびに新しいパラメータ値をバインドすることにより再利用できます。
構成ファイルとデータファイル。アプリケーションがファイルから構成データを読み込んで解析する場合は、解析済みデータをメモリに保持することで、リクエストごとにファイルを再読み込みする必要がなくなります。

ハンドラスクリプトは、インポート時に main() を呼び出す必要があります。App Engine は、スクリプトのインポート時に main() が呼び出されることを想定しているため、サーバーで初めてリクエストハンドラを読み込むときに、App Engine がこの関数を呼び出すことはありません。

main() を使用したアプリキャッシングにより、CGI ハンドラのレスポンスタイムが大幅に短縮されます。CGI を使用するすべてのアプリケーションでこの方法を採用することをおすすめします。

ロギング

App Engine ウェブサーバーは、ウェブリクエストへのレスポンスとしてハンドラスクリプトが標準出力ストリームに書き込むすべての内容をキャプチャします。また、ハンドラスクリプトが標準エラーストリームに書き込むすべての内容もキャプチャし、ログデータとして保存します。各リクエストには request_id が割り当てられます。これは、リクエストの開始時刻に基づく、グローバルで一意の識別子です。アプリケーションのログデータは、Cloud Logging を使用して、Google Cloud コンソールで表示できます。

App Engine Python ランタイム環境には、ログレベル（「debug」、「info」、「warning」、「error」、「critical」）などのロギングのコンセプトを理解するために、Python 標準ライブラリからのロギングモジュールに対する特別なサポートが含まれています。

import logging

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        logging.debug("This is a debug message")
        logging.info("This is an info message")
        logging.warning("This is a warning message")
        logging.error("This is an error message")
        logging.critical("This is a critical message")

        try:
            raise ValueError("This is a sample value error.")
        except ValueError:
            logging.exception("A example exception log.")

        self.response.out.write("Logging example.")


app = webapp2.WSGIApplication([("/", MainPage)], debug=True)

環境

実行環境は、自動的にいくつかの環境変数を設定します。他の環境変数は app.yaml で設定できます。自動的に設定される変数の中には、App Engine 専用のものや、WSGI 標準や CGI 標準に含まれるものがあります。Python コードは、os.environ ディクショナリを使用して、これらの変数にアクセスできます。

次の環境変数は App Engine に固有のものです。

CURRENT_VERSION_ID: 「X.Y」のような現在実行中のアプリケーションのメジャーバージョンとマイナーバージョン。メジャーバージョン番号（X）は、アプリの app.yaml ファイルに指定されています。マイナーバージョン番号（Y）は、アプリの各バージョンが App Engine にアップロードされたときに自動的に設定されます。開発用ウェブサーバーでは、マイナーバージョンは常に「1」です。
AUTH_DOMAIN: Users API でユーザーを認証するために使用されるドメイン。appspot.com 上でホストされているアプリには gmail.com の AUTH_DOMAIN が割り当てられ、すべての Google アカウントを受け入れます。カスタムドメイン上でホストされているアプリには、カスタムドメインと同じ AUTH_DOMAIN が割り当てられます。
INSTANCE_ID: リクエストを処理するフロントエンドインスタンスのインスタンス ID が含まれています。この ID は 16 進文字列（00c61b117c7f7fd0ce9e1325a04b8f0df30deaaf など）です。ログインしている管理者は、URL https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com でこの ID を使用できます。リクエストはこの特定のフロントエンドインスタンスにルーティングされます。リクエストを処理できない場合、そのインスタンスはすぐに 503 を返します。

次の環境変数は WSGI 標準と CGI 標準に含まれており、App Engine では特殊な動作をします。

SERVER_SOFTWARE: 開発用ウェブサーバーでは、この値は「Development/X.Y」です。ここで、「X.Y」はランタイムのバージョンです。App Engine 上で動作している場合、この値は「Google App Engine/X.Y.Z」です。

他の環境変数は、WSGI 標準や CGI 標準に従って設定されます。これらの変数の詳細については、必要に応じて WSGI 標準または CGI 標準をご覧ください。

app.yaml ファイルで環境変数を設定することもできます。

env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'

次の webapp2 リクエストハンドラは、アプリケーションが認識できるすべての環境変数をブラウザに表示します。

class PrintEnvironmentHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        for key, value in os.environ.iteritems():
            self.response.out.write("{} = {}\n".format(key, value))

リクエスト ID

リクエストのときに、そのリクエストに固有のリクエスト ID を保存できます。リクエスト ID は、Cloud Logging でそのリクエストをログから検索する場合に使用できます。

次のサンプルコードは、リクエストのコンテキストでリクエスト ID を取得する方法を示しています。

class RequestIdHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        request_id = os.environ.get("REQUEST_LOG_ID")
        self.response.write("REQUEST_LOG_ID={}".format(request_id))

HTTPS 接続の強制

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

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

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

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

非同期バックグラウンド作業の処理

バックグラウンド作業とは、HTTP レスポンスを配信した後、アプリがリクエストに対して行う作業です。バックグラウンド作業をアプリ内で実施することは避け、コードを見直して、レスポンスを配信する前にすべての非同期オペレーションが完了するようにしてください。

長時間実行ジョブには、Cloud Tasks の使用をおすすめします。Cloud Tasks では、HTTP リクエストが長時間継続し、非同期処理が終了した後にのみレスポンスを返します。