Проблемы масштабирования кластера и Trino Gateway

Что такое Trino Gateway, зачем он нужен и как работает: для чего делить один большой кластер Trino на несколько маленьких и как к ним обращаться без изменений на стороне клиентов.

Проблемы бесконечного масштабирования кластера

Благодаря горизонтальному масштабированию, о котором мы говорили вчера, кластер Trino можно расширять, добавляя новые рабочие узлы. Хотя в документации движка не сказано об ограничениях максимального количества узлов в кластере, на практике чрезмерно большие кластера делят на несколько более мелких. Оптимальное количество узлов в кластере – это всегда компромисс между производительностью, управляемостью и затратами на инфраструктуру. Чем больше узлов, тем выше потенциал параллельной обработки данных, но при этом возрастает сложность администрирования и возможные проблемы с масштабируемостью. Например, следующие:

перегрузка координатора, который отвечает за планирование и распределение запросов между рабочими узлами. С ростом числа рабочих узлов возрастет количество запросов на координацию, что может привести к перегрузке координатора и снижению общей производительности системы.
снижение эффективности оптимизатора запросов – в крупных кластерах планировщик должен учитывать большее количество узлов и потенциальных маршрутов выполнения, что увеличивает время планирования и выполнения запросов.
увеличение сетевой нагрузки – большее количество узлов увеличивает объём HTTP-взаимодействия между узлами. Это может привести к увеличению сетевой задержки и снижению скорости передачи данных, что приведет к задержкам выполнения запросов.
сложное правление метаданными, включая информацию о расположении данных и состоянии узлов – чем больше узлом, тем больше таких данных надо хранить и управлять ими. Это может привести к задержкам при обработке запросов и ошибкам.
неравномерное распределение нагрузки – когда узлов много, эффективно распределять нагрузку между ними становится сложнее. Даже при наличии балансировщика есть риск неравномерного распределения нагрузки, что приводит к перегрузке одних узлов и простаиванию других, снижая общую эффективность кластера.
сложности в мониторинге и администрировании — большие кластеры требуют более сложных инструментов для мониторинга и управления. Растет вероятность появления ошибок конфигурации. Также снижается общая надежность системы: в больших кластерах вероятность выхода из строя отдельных узлов выше, чем в более мелких. Чтобы избежать сбоев, нужны более сложные и дорогие инструменты мониторинга и механизмы восстановления после сбоев.

Избежать этих проблем поможет разделение одного большого кластера Trino на несколько более мелких. А, чтобы не менять настройки клиентских подключений и по-прежнему работать с ними, как с единым кластером, можно использовать Trino Gateway — специальный балансировщик нагрузки, прокси-сервер и настраиваемый шлюз маршрутизации для нескольких кластеров Trino. Зачем он нужен и как работает, рассмотрим далее.

Trino для инженеров данных

Код курса

TRINO

Ближайшая дата курса

7 апреля, 2025

Продолжительность

16 ак.часов

Стоимость обучения

48 000 руб.

Что такое Trino Gateway

Основными вариантами применения Trino Gateway считаются следующие:

использование единого URL-адреса подключения для пользователей клиентских инструментов с распределением рабочей нагрузки по нескольким кластерам Trino;
автоматическая маршрутизация запросов в выделенные кластеры Trino для определенных рабочих нагрузок или запросов и источников данных;
бесперебойные обновления кластеров Trino при сине-зеленом или канареечном развертывании, о которых мы писали здесь и здесь.

Кроме того, Trino Gateway обеспечивает прозрачное изменение мощности кластеров Trino без прерывания работы пользователей.

Запросы к Trino Gateway из веб-GUI и программные вызовы к его RESTful API, а также запросы, которые необходимо перенаправить в кластера Trino, обслуживаются одним и тем же портом. Место назначения определяется HTTP URI в запросе. Маршрутизаторы Trino Gateway принимают решение о том, в какой кластер Trino отправить запрос, на основе нагрузки кластеров. Есть два базовых механизма маршрутизации:

StochasticRoutingManager – основной механизм маршрутизации, который использует простой децентрализованный подход, распределяя входящие запросы случайным образом без оптимизации.
QueryCountBasedRouterProvider — механизм маршрутизации на основе статистики нагрузки кластера на уровне пользователя. Он в реальном времени вычисляет количество запущенных запросов и длину очереди запросов, чтобы определить наиболее подходящий кластер для каждого отдельного пользователя. Затем запросы направляются в наименее загруженный кластер для этого пользователя, повышая вероятность их успешного выполнения.

При необходимости можно разработать и внедрить собственный механизм маршрутизации, добавив свои модуль и класс маршрутизатора.

Trino Gateway проверяет входящие запросы, чтобы узнать, связаны ли они с уже ранее обработанными. Если да, то Trino Gateway отправляет их на тот же бэкэнд, который обрабатывал предыдущие запросы, чтобы избежать смены контекста и дополнительной передачи данных. Если это новый запрос, Trino Gateway обращается к правилам маршрутизации, чтобы решить, какая группа бэкендов (группой маршрутизации), должна его обрабатывать. Затем он выбирает бэкенд из этой группы маршрутизации для обработки запроса, используя адаптивную или циклическую стратегию.

Алгоритм маршрутизации запросов к кластерам Trino в Trino Gateway

Как видно из алгоритма, когда новый запрос связан с текущим процессом или состоянием, поддерживаемым на одном бэкенд-кластере Trino, он снова направляется на него для надлежащей обработки. Для этого реализованы два механизма идентификации связанных запросов: маршрутизация на основе идентификатора запроса (по умолчанию) и на основе cookie-файлов, которые Trino Gateway устанавливает в качестве сервера для клиента, с которого пришел запрос.

Правила маршрутизации определяются в YAML-файле конфигурации или реализуются в отдельном пользовательском приложении сервиса. Подключение к отдельному сервису настраивается как URL. Чтобы направлять запросы в работающие кластера Trino, Trino Gateway отслеживает их текущее состояние, которое может принимать следующие значения:

PENDING — кластер Trino еще запускается и не готов к работе, запросы сюда не направляются;
HEALTHY — кластер Trino работоспособен и готов к работе, сюда можно отправлять запросы;
UNHEALTHY — кластер Trino неработоспособен и не готов к работе, запросы сюда не направляются.

Trino Gateway имеет собственные механизмы безопасности со своей аутентификацией и авторизацией, которые используются только для его пользовательского веб-GUI и API. Все запросы от Trino Gateway передаются в кластер Trino без дополнительных проверок.

Механизмы аутентификации и авторизации шлюза требуют настройки TLS в качестве базового уровня. Нужен предварительно настроенный балансировщик нагрузки или прокси-сервер, работающий с действительным, глобально доверенным сертификатом TLS. В этом случае можно настроить Trino Gateway за балансировщиком нагрузки или установить сквозное TLS-соединение. Для этого необходимо получить и установить сертификат TLS и настроить Trino Gateway для его использования для клиентских подключений, например, задав конфигурации сервера Trino Gateway следующим образом:

serverConfig:
    http-server.http.enabled: false
    http-server.https.enabled: true
    http-server.https.port: 8443
    http-server.https.keystore.path: certificate.pem
    http-server.https.keystore.key: changeme

Аутентификация в Trino Gateway происходит только по протоколу HTTPS. Следует добавить раздел authentication: в YAML-файл конфигурации и установить тип аутентификации в параметре defaultType:. Сейчас поддерживаются следующие типы аутентификации:

OAuth/OpenIDConnect. При этом для OAuth используется обратный вызов OIDC (oidc/callback), где Trino использует OAuth2-путь. Trino Gateway должен иметь собственный идентификатор клиента. Все внутренние кластеры Trino должны иметь один идентификатор клиента. Сейчас Trino Gateway может пропускать запросы с OAuth2-аутентификацией только к одному из кластеров Trino. Чтобы обойти это ограничение, надо настроить группы и правила маршрутизации в конфигурационном файле и реплицировать существующие записи одного и того же внутреннего сервера кластера с другим именем
базовая аутентификация пользователей по логину и паролю, определенных в YAML-файле конфигурации;
LDAP, для которой нужны случайная пара ключей и путь конфигурации.

RBAC-модель авторизации пользователей Trino Gateway включает администратора с доступом для настройки бэкэндов, обычного пользователя и API для выполнения HTTP-запросов.

Таким образом, Trino Gateway – довольно мощный инструмент масштабирования аналитического SQL-движка, который настраивать гибко настраивать и выполнять маршрутизацию запросов к нескольким кластерам, а также отслеживать ее выполнение в наглядном GUI. В частности, Trino Gateway записывает историю последних запросов и отображает ссылки на страницу проверки сведений о запросе в соответствующем кластере.

Мониторинг истории запросов в Trino Gateway