jsonscraper

Google Cloud API Gatewayがストリーミングに対応:移行前に確認すべきこと

パブリックプレビューではSSE、WebSockets、gRPC、HTTPレスポンスのストリーミングをサポート。チームにとっての主な変更点は、ゲートウェイを新規作成し、接続の有効期間を設定することです。

編集方針 誤りを報告する

ストリーミングバックエンドは接続を開いたままにし、データを順次送信します。たとえば、SSEではモデルが生成する回答テキストを逐次送信でき、WebSocketでは双方向の通信ができます。2026年10月22日、GoogleはCloud API Gatewayのストリーミング機能のパブリックプレビューを発表しました。ゲートウェイはこうしたレスポンスを通過させ、リクエストには従来の認証ルールや監視機能を適用できます。検証するには、ストリーミングを有効にした新しいゲートウェイを作成する必要があります。

記事:Google Cloud API Gatewayがストリーミングに対応:移行前に確認すべきこと
概要:2026年10月22日、GoogleはCloud API Gatewayのストリーミング機能のパブリックプレビューを発表しました。対応プロトコルやAPI設定で維持される機能、そして新しいゲートウェイでSSEやWebSocketを検証する方法を解説します。
画像の役割:カバー画像 — 中心的なテーマ
セクション:
ビジュアルの内容:Google Cloud API Gatewayが、段階的に送信されるSSEイベントパケットと双方向のWebSocket接続を中継する様子 b
© jsonscraper · AI生成イラスト

Googleの発表では、SSE、HTTPレスポンスストリーミングとchunked transfer encoding、WebSockets、さらにgRPCのサーバー側および双方向ストリーミングが挙げられています。NDJSONを含むHTTPレスポンスは、バックエンドから届いたデータが順次クライアントに送信されます。これにより、通常のリクエストを処理している同じAPI Gatewayの背後に、ストリーミング用のルートを配置できます。

APIとインフラにおける変更点

ストリーミング操作に別個のAPI定義や仕様の特別な拡張は必要ありません。プレビューでは、ゲートウェイの作成時に--enable-streamingフラグを指定してストリーミングモードを設定します。Googleによると、APIキーとJWTの検証、サービスアカウントを使ったバックエンド認証、ルーティング、Cloud LoggingおよびCloud Monitoringとの連携は引き続き利用できます。

プレビューでは、ゲートウェイID、プロジェクト番号、リージョンに基づく予測可能なホスト名も導入されます。たとえば、アドレス形式はGATEWAY_ID-PROJECT_NUMBER.REGION.gateway.devです。クライアントやCIの設定にあらかじめ指定できます。同じID、プロジェクト、リージョンでゲートウェイを再作成しても、アドレスは変わりません。

本番トラフィックを切り替えずに検証する

  1. 既存のバックエンドを選びます。すでにSSEまたはHTTPレスポンスのストリーミングを送信しているエンドポイントから始めると、アプリケーションの変更とゲートウェイの挙動を切り分けやすくなります。
  2. 専用のゲートウェイを作成します。ストリーミングの有効化は作成時に設定され、既存のゲートウェイではモードを変更できません。テスト用のIDと適切なリージョンを使用します。
  3. バックエンドのdeadlineを設定します。SSEとHTTPストリーミングのリクエスト期限は、デフォルトで15秒です。設定した期限に達するとストリームは終了します。OpenAPI設定で、用途に合ったdeadlineをバックエンドに指定します。ストリーミングゲートウェイでは、ドキュメント上、最大3600秒まで設定できます。バックエンド独自のタイムアウトも考慮してください。たとえばCloud Runでは、それより前に接続が閉じられる場合があります。
  4. バックエンドのプロトコルを確認します。gRPCにはHTTP/2(h2)、WebSocketsにはHTTP/1.1が必要です。SSEとHTTPストリーミングはHTTP/1.1またはHTTP/2で動作し、Googleはこれらの用途にHTTP/2を推奨しています。
  5. データが届くことを確認します。レスポンス全体の完了前に、クライアントが最初のイベントを受信することを確認します。WebSocketでは双方向の通信を検証し、接続終了後にクライアントが再接続できるようにします。
  6. ポリシーとメトリクスを確認します。ストリーミングルートで認証、ログ、リクエスト制限を検証します。request latencyメトリクスはストリーム全体の所要時間を示すため、最初のイベントまでの時間とイベント間隔はクライアント側で別途測定してください。

WebSocketsとgRPCでは、メッセージがない状態のタイムアウトはデフォルトで300秒です。WebSocketでは300秒未満の期間は適用されず、接続は遅くとも3600秒で終了します。SSEとHTTPストリーミングには、指定した実時間のdeadlineが適用されます。そのため、request latencyが長いことだけでは、ユーザーが最初のデータをどれだけ早く受け取ったかは分かりません。

パブリックプレビューの制限

現時点では、Cloud ConsoleやTerraformからストリーミングモードを有効にできません。また、ストリーミングを有効にしたゲートウェイはHTTP(S) Load BalancingおよびServerless NEGと互換性がないため、この構成に依存するカスタムドメインは利用できません。Googleは、これらの機能をプレビュー期間中に追加する予定の機能として挙げています。本番環境のルーティングや自動化を計画する前に、ストリーミング設定のドキュメントを確認してください。

まずは、新しいゲートウェイを既存のストリーミングバックエンドに向け、deadlineを明示的に設定し、直接接続した場合とゲートウェイ経由の場合を比較するのが実践的です。APIの契約や本番トラフィックを変更せずに、プロトコルの互換性、認証、最初のイベントが届くまでの実時間を検証できます。

People

No people listed for this article yet.

Keep readingGitHub CLIに有効期限付きOAuthトークンが追加:有効化と連携の確認方法
Read the next article

読んだ内容を実用的な連携へ

jsonscraperのソーシャルデータAPIを調べ、リクエストを試し、次のワークフローを構築しましょう。

APIを探す