Пример бессерверной инфраструктуры с обработкой входящих запросов с помощью API Gateway

Распределяем нагрузку: Yandex API Gateway и другие инструменты балансировки
Рассказываем о распределении нагрузки между сервисами с помощью Yandex API Gateway, Yandex Application Load Balancer и Network Load Balancer. Объясняем, для каких задач подходит каждый из инструментов и как настроить API Gateway для эффективной работы.
Для высоконагруженных сервисов важно использовать инструменты обеспечения отказоустойчивости, чтобы приложения продолжали стабильно работать с ростом числа пользователей. Когда бэкенд приложения размещён на нескольких виртуальных машинах с legacy или микросервисной архитектурой — пригодятся инструменты распределения и балансировки нагрузки. В экосистеме Yandex Cloud есть несколько инструментов для решения этих задач: Yandex Network Load Balancer или Yandex Application Load Balancer.
Если вам необходимо распределять нагрузку между ресурсами и делать это с минимальной задержкой, то выбирайте Yandex Network Load Balancer.
Сетевой балансировщик нагрузки (Yandex Network Load Balancer) работает на 4-м уровне модели OSI
Если вам важны гибкость и инструменты тонкой настройки распределяемого трафика, то выбирайте Yandex Application Load Balancer.
Yandex Application Load Balancer работает на 7-м уровне модели OSI
Оба инструмента хорошо подходят как для создания отказоустойчивой инфраструктуры, в которой у вас одно legacy-приложение, развёрнутое на нескольких виртуальных машинах, так и могут применяться для микросервисной архитектуры. Однако если вы планируете использовать другие сервисы платформы Yandex Cloud для разработки собственных приложений, в том числе при работе с бессерверными (serverless) вычислениями, тогда вам будет полезен сервис для создания API-шлюзов Yandex API Gateway.
Возможности Yandex API Gateway
Сервис Yandex API Gateway предназначен для создания API-шлюзов с использованием спецификации OpenAPI 3.0 и встроенных интеграций с другими облачными сервисами. Он может стать единой точкой входа для различных типов приложений, как legacy, так и микросервисных.

Использование API Gateway в миркосервисной архитектуре, где каждая служба выполняет определённую функцию и развёрнута отдельно, позволяет объединить их в единый, доступный из интернета URL или точку входа, и выполнять централизованное управление. Таким образом, администратор получает следующие преимущества:
-
Взаимодействие со всеми микросервисами осуществляется через один API Gateway URL.
-
С помощью API Gateway производится управление трафиком для всех версий и экземпляров микросервисов, что упрощает развёртывание изменений.
-
Для всех микросервисов можно применять общие методы аутентификации и авторизации.
-
Встроенные в API Gateway инструменты мониторинга позволяют выполнять анализ работы микросервисов.
-
API Gateway предоставляет возможность ограничения количества запросов в секунду (rate limiting), а также выполнения канареечных релизов.
-
Управление CORS и валидация HTTP параметров, заголовков, тела запроса и ответа может быть гибко настроено и выполняться самим API-шлюзом.
-
Доступно подключение своего домена к API Gateway через сертификат в Yandex Certificate Manager.
В случае если legacy-приложения развёрнуты на виртуальных машинах, API Gateway также может предоставить ряд преимуществ. Расскажем о них дальше.
1. API Gateway может проĸсировать запросы ĸ legacy-приложению и перенаправлять трафик на определённый адрес и порт виртуальной машины
Параметры настройки взаимодействия API Gateway с HTTP-сервисами внутри Yandex Cloud можно найти в документации. Например, конфигурация, которая проксирует запросы ĸ сервису my-service будет выглядеть следующим образом:
openapi: 3.0.0
info:
title: Sample API
version: 1.0.0
paths:
/{path+}:
x-yc-apigateway-any-method:
x-yc-apigateway-integration:
type: http
url: https://my-service.com/{path}
query:
'*': '*'
headers:
'*': '*'
omitEmptyHeaders: true
omitEmptyQueryParameters: true
parameters:
- name: path
in: path
required: false
schema:
type: string
В этом примере «звёздочки» указывают на то, что проксирование параметров запроса и заголовков будет осуществляться без изменений.
Если вы не хотите, чтобы сервис my-service был напрямую виден из сети Интернет, то вы можете предоставлять к нему доступ через API Gateway.
Также в API Gateway вы можете использовать сертификаты для HTTPS из Yandex Certificate Manager. Это избавит от создания дополнительного способа доставки содержимого сертификата на виртуальную машину и автоматического обновления сертификата.
Однако API Gateway имеет ряд ограничений, которые необходимо учитывать при построении архитектуры проекта:
-
Недопустимо использование протоколов отличных от HTTPS, например, gRPC или WebRTC.
-
API Gateway терминирует WebSocket-соединения на своей стороне и не пробрасывает их дальше, поэтому потребуется доработка исходного кода бэкенда для обработки сообщений, приходящих по протоколу WebSocket.
-
API Gateway не может преобразовывать данные «на лету», если их формат отличается от того, который использует legacy-приложение.
Для преобразования данных в режиме реального времени необходимо создать дополнительную функцию в сервисе Yandex Cloud Functions. Например, вот так выглядит код функции, которая преобразует данные из формата XML в формат JSON:
main.py
import json
import xmltodict
import requests
def handler(event, context):
body = requests.get('https://my-service.com').text
json_body = json.dumps(xmltodict.parse(body))
return {
'statusCode': 200,
'headers': {
'Content-Type': 'application/json'
},
'body': json_body
}
requirements.txt
requests
xmltodict
2. API Gateway выступает в роли дополнительного слоя безопасности, осуществляя собственную аутентификацию и авторизацию.
В API Gateway можно для каждого пути задать авторизацию с помощью написания дополнительной функции. Однако надо учитывать, что результат выполнения этой функции будет проброшен только в авторизационный ĸонтеĸст другой функции и не сможет быть использован внутри самого API Gateway.
Также доступен JWT-авторайзер, который может самостоятельно авторизовывать запросы с jwt-токенами и даже сопоставлять scope и пробрасывать claims.
3. Сам API Gateway масштабируется автоматически, но не умеет балансировать нагрузку на legacy-приложение.
Так как API Gateway — облачный сервис платформы Yandex Cloud, его производительность масштабируется автоматически.
Но чтобы реализовать масштабируемость самих приложений, необходимо воспользоваться инструментами балансировки нагрузки L4 (L3) и L7 уровней, которые мы описывали в начале этой статьи. Их можно использовать как отдельно, так и совместно с API Gateway.
Заключение: для каждой задачи свой инструмент
Yandex API Gateway будет полезен для организации единой точки входа в микросервисную архитектуру внутри экосистемы Yandex Cloud с применением возможностей serverless-технологий. Также он поможет без написания кода реализовать поставку данных в хранилища, так как имеет готовые интеграции с такими сервисами, как Yandex Data Streams и Yandex Message Queue. Или упростит развёртывание сайта, содержащего как статическую информацию, размещённую в бакете Object Storage, так и логику, реализованную в виде классического бэкенда на виртуальных машинах или в serverless-приложениях.
Для обеспечения отказоустойчивости и масштабируемости legacy-приложений, развёрнутых на нескольких виртуальных машинах, рекомендуем использовать Yandex Network Load Balancer или Yandex Application Load Balancer в зависимости требуемой скорости распределения нагрузки между ресурсами и необходимых настроек распределяемого трафика. Но если вы решите переписывать их на новые технологии или «распиливать» на микросервисы, то API Gateway поможет выполнить эту процедуру безопасно и бесшовно с помощью канареечных релизов.