У Google Cloud API Gateway з’явилася потокова передача: що перевірити перед міграцією

Потоковий backend підтримує з’єднання відкритим і передає дані частинами: наприклад, SSE може надсилати текст відповіді моделі в міру генерації, а WebSocket — забезпечувати двосторонній обмін. 22 жовтня 2026 року Google оголосила публічний попередній перегляд потокової передачі в Cloud API Gateway. Шлюз може пропускати такі відповіді й застосовувати до запитів звичні правила автентифікації та засоби спостережуваності; для перевірки потрібно створити новий шлюз із увімкненим потоковим режимом.

У анонсі Google перелічено SSE, потокову передачу HTTP-відповідей і chunked transfer encoding, WebSockets, а також серверну й двосторонню потокову передачу gRPC. HTTP-відповіді передаються клієнту в міру надходження від backend, зокрема у форматі NDJSON. Це дає змогу залишити потокові маршрути за тим самим API Gateway, який уже обробляє звичайні запити.

Що змінюється в API та інфраструктурі

Для потокових операцій не потрібен окремий опис API чи спеціальні розширення у специфікації. У попередньому перегляді потоковий режим задається під час створення шлюзу прапорцем --enable-streaming. Google зазначає, що зберігаються перевірки API key і JWT, автентифікація backend за допомогою service account, маршрутизація та інтеграція з Cloud Logging і Cloud Monitoring.

Попередній перегляд також запроваджує передбачуване ім’я хоста на основі ідентифікатора шлюзу, номера проєкту та регіону. Наприклад, адреса має формат GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Її можна заздалегідь додати до конфігурації клієнта або CI. Повторне створення шлюзу з тими самими ідентифікатором, проєктом і регіоном зберігає цю адресу.

Перевірка без перемикання production-трафіку

1. Виберіть наявний backend. Почніть з endpoint, який уже надсилає SSE або потокову HTTP-відповідь: так буде легше відокремити поведінку шлюзу від змін у застосунку.
2. Створіть окремий шлюз. Потоковий режим фіксується під час створення; змінити режим наявного шлюзу не можна. Використайте тестовий ідентифікатор і відповідний регіон.
3. Налаштуйте граничний час backend. Для SSE і потокової передачі HTTP стандартний час очікування запиту становить 15 секунд; потік закривається, коли минає заданий час. У конфігурації OpenAPI задайте для backend параметр deadline, який відповідає вашому сценарію: для потокового шлюзу документація допускає значення до 3600 секунд. Враховуйте також власний timeout backend — наприклад, Cloud Run може закрити з’єднання раніше.
4. Перевірте протокол backend. Для 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 діє заданий wall-clock deadline. Тому тривалий графік request latency сам по собі не показує, наскільки швидко користувач побачив перший фрагмент.

Обмеження публічного попереднього перегляду

На момент запуску потоковий режим не можна ввімкнути через Cloud Console або Terraform. Також шлюзи з увімкненою потоковою передачею несумісні з HTTP(S) Load Balancing і Serverless NEG, тому власні домени, що залежать від цієї схеми, недоступні. Google зазначає, що ці можливості можуть з’явитися пізніше протягом періоду попереднього перегляду. Перш ніж планувати production-маршрутизацію та автоматизацію, звіртеся з документацією з налаштування потокової передачі.

Практичний перший крок — спрямувати новий шлюз на наявний потоковий backend, явно налаштувати deadline і порівняти пряме підключення з маршрутом через шлюз. Так команда перевірить сумісність протоколу, автентифікацію та фактичний час до першої події, не змінюючи контракт API і production-трафік.