Сколько RAM нужно для Tyk Gateway

MAATRIX

Tyk Gateway — компилированный бинарник на Go, и первое желание — взять сервер минимальной конфигурации: раз нет JVM и тяжёлого рантайма, хватит и 512 МБ. На практике сам процесс tyk-gateway — только видимая часть стека. Рядом обязателен Redis, часто добавляются кастомные JSVM-плагины и встроенный портал разработчика, и именно они, а не голый гейтвей, чаще всего кладут маленький VPS в OOM. Разберём, из чего складывается память каждого компонента, как посчитать её под свою нагрузку и какую конфигурацию брать без переплаты.

Короткий ответ: сколько закладывать под Tyk

Из чего складывается память шлюза

Архитектурно у Tyk четыре источника потребления, и они очень разного размера.

• Сам процесс tyk-gateway. Компилированный Go-бинарник с горутиной на каждое активное соединение вместо тяжёлого пула потоков. В покое — самый лёгкий компонент всего стека, заметно легче связки JVM-based шлюзов или Dashboard-панели с веб-фронтендом. Под нагрузкой память растёт вместе с числом одновременных соединений: каждый активный запрос держит буферы тела и заголовков, пока не улетит ответ.
• API definitions в памяти. При файловом режиме (use_db_app_configs: false) все JSON-описания из app_path гейтвей держит целиком в памяти для маршрутизации. Одно определение — единицы-десятки килобайт, так что даже сотня API добавляет немного. Ощутимо это становится только на тысячах определений с длинными списками версий и политик.
• Redis — обязательная внешняя зависимость, не опция. Разбираем отдельно ниже: именно здесь чаще всего прячется неожиданный рост.
• Опциональные надстройки — JSVM-плагины, gRPC/Python-плагины, Tyk Pump, встроенный или полноценный портал разработчика. Каждая добавляет свой кусок, и об этом часто забывают при первом расчёте сервера.

Ключевой вывод: сам гейтвей редко становится причиной OOM на разумно подобранном сервере. Причина почти всегда — Redis без ограничений или недооценённые надстройки.

Redis — не опция, а обязательная часть стека

В открытой редакции Redis жёстко зашит в архитектуру: там живут сессии API-ключей, счётчики rate limiting и кэш конфигурации. Без него гейтвей либо не стартует, либо отвечает 500 на любой запрос.

Память Redis в связке с Tyk растёт по трём причинам, и только одна из них — рабочая нагрузка:

1. Активные ключи и сессии. Каждый выданный API-ключ и его счётчики — несколько структур в Redis, суммарно небольших, но линейно растущих с числом партнёров.
2. Счётчики rate limiting. Скользящие окна на уровне ключа, политики и API хранятся отдельными записями с TTL — при тысячах активных ключей это заметный, но предсказуемый объём.
3. Аналитика без ограничения. Если enable_analytics: true, а Tyk Pump, который должен вычитывать эти записи и отправлять в приёмник (Prometheus, Elasticsearch, StatsD, CSV), не запущен или отстаёт — записи копятся в Redis без верхней границы. Это самая частая причина, по которой Redis рядом с Tyk «внезапно» съедает несколько гигабайт.

Практическое правило — всегда явно ограничивать Redis, а не полагаться на дефолты:

requirepass длинный-случайный-пароль
maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru — разумный дефолт: под нехваткой памяти вытесняются самые старые записи, а не падает весь процесс. Если Pump работает штатно, аналитика не должна накапливаться вовсе. Проверить текущее потребление Redis:

redis-cli -a пароль info memory | grep -E "used_memory_human|maxmemory_human"

Если цифра растёт день ото дня без явного роста числа ключей — почти наверняка не сливается аналитика или где-то отключён TTL. Более широкий разбор поведения Redis под нагрузкой — в статье про высокое потребление памяти Redis.

Плагины и JSVM-middleware: где прячется лишняя память

Голая маршрутизация с ключами и лимитами редко покрывает всё, что нужно на проде — обычно добавляется своя логика: обогащение запроса, кастомная валидация, трансформация ответа. У Tyk для этого два механизма, и они по-разному влияют на память.

JSVM-middleware — JavaScript-код, который выполняется внутри самого процесса гейтвея через встроенный JS-движок. Включается полем enable_jsvm: true в tyk.conf, конкретные хуки (pre, post, auth_check) подключаются в custom_middleware API definition. Плюс — не нужен отдельный процесс; минус — каждый API с включённым JSVM держит собственный JS-контекст внутри процесса tyk-gateway, и это добавляет память и CPU сверх базового потребления. Чем больше API с нетривиальными скриптами и выше конкурентность запросов к ним, тем заметнее прибавка.

gRPC/внешние плагины (в том числе на Python) — отдельный процесс со своим рантаймом, который общается с гейтвеем по gRPC. Его память не входит в RSS tyk-gateway вообще — считайте и лимитируйте как самостоятельный сервис в docker-compose, со своим mem_limit.

Практический совет: тяжёлую логику (парсинг больших тел, вызовы наружу, сложные преобразования) выносите в gRPC-плагин, а не в JSVM — так проще ограничить ресурсы отдельно от ядра гейтвея и перезапустить плагин, не трогая маршрутизацию остальных API.

Портал разработчика: встроенный и отдельный — разная цена

Здесь легко перепутать два разных продукта с похожим названием.

Встроенный портал в Tyk Gateway CE (появился в относительно свежих версиях) работает внутри процесса гейтвея: каталог опубликованных API, документация и форма самостоятельной выдачи ключа собираются из тех же API definitions на лету. Отдельного процесса и базы под него не требуется — прибавка к памяти гейтвея сравнима с добавлением ещё нескольких HTTP-маршрутов, заметно меньше, чем отдельный сервис, но не нулевая под нагрузкой от внешних посетителей.

Tyk Enterprise Developer Portal — отдельный открытый продукт: своя база (Postgres, для небольших нагрузок годится SQLite), свой веб-фронтенд, свой процесс. Его нужно закладывать в расчёт сервера отдельной строкой, а не как опцию внутри tyk.conf. Если задача — просто показать партнёрам список API и выдать им ключи без биллинга и брендирования, встроенного портала CE обычно достаточно.

Для большинства сценариев этой статьи (VPS под гейтвей+Redis, без коммерческой Dashboard) речь именно о встроенном варианте — это тот самый портал, который включается прямо в конфиге гейтвея при базовой установке.

Как посчитать RAM под свою нагрузку

RAM ≈ база гейтвея (100–200 МБ на низкой конкурентности) + рост от активных соединений + Redis по числу ключей и глубине аналитики + JSVM/плагины + портал, если отдельный

Три сценария:

• Внутренний API, один потребитель. Десяток API definitions, без JSVM, аналитика с рабочим Pump. Гейтвей и Redis суммарно держатся в единицах сотен мегабайт: 2 ГБ — рабочий минимум с запасом, 1 ГБ реален только под тест без пиков трафика.
• Несколько внешних партнёров, встроенный портал, лёгкие JSVM-проверки на паре API. Portal добавляет обращения от посторонних посетителей, JSVM — постоянный расход на конкурентных запросах. 4 ГБ снимает большинство вопросов на этом масштабе — 2 ГБ формально работают, но всплеск активности партнёров съедает запас быстро.
• Публичный API, сотни партнёров, отдельный Tyk Enterprise Developer Portal, Pump с экспортом в Elasticsearch. Портал и Pump — уже самостоятельные сервисы каждый со своими 512 МБ–1 ГБ, плюс Redis под серьёзной нагрузкой ключей и аналитики. Разумнее развести компоненты по ролям — гейтвей отдельно (несколько нод за балансировщиком), Redis отдельно, портал отдельно — 8+ ГБ на роль, а не на всё сразу.

Особенность Tyk — он стейтлес: всё изменяемое состояние живёт в Redis, а не в памяти гейтвея. Поэтому горизонтальное масштабирование (несколько инстансов tyk-gateway за балансировщиком с общим Redis) даёт почти линейный рост пропускной способности, а одна упавшая нода не роняет весь API-слой. Между «сервер в 4 раза больше» и «четыре сервера по минимуму» для Tyk почти всегда выгоднее второе.

Проверить текущее потребление своего стека:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

Если гейтвей внезапно упал — сначала проверьте, не OOM ли это:

docker inspect tyk-gateway --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
dmesg -T | grep -i "killed process"

Если гейтвей уже работает, но со временем ест всё больше памяти без роста трафика, — в первую очередь смотрите на Redis и Pump, а не на утечку в самом Go-процессе: этот и другие похожие сценарии разобраны в статье про частые ошибки Tyk Gateway на сервере.

Какой сервер взять под Tyk в MAATRIX

Начинать стоит не с объёма RAM, а с того, где живут ваши потребители API. Внутренние сервисы и клиенты из России и СНГ — логичная площадка RU. Интеграции с зарубежными сервисами или партнёрами из Европы и США — UK или US дадут короче маршрут и меньше сетевых сюрпризов.

По конфигурации:

Старт — 2 vCPU / 2 ГБ / 40 ГБ NVMe. Gateway и Redis на одной машине, встроенный портал, без тяжёлых JSVM-скриптов. Хватает для внутреннего API или небольшого числа внешних потребителей. Обязательно выставьте requirepass и maxmemory у Redis с первого дня — на этом объёме памяти запас минимальный, и накопившаяся без лимита аналитика способна положить машину тихо, без явной ошибки в логах гейтвея.

Комфорт — 4 vCPU / 4 ГБ / 80 ГБ NVMe. Здесь можно спокойно держать JSVM-middleware на части API, Tyk Pump с экспортом метрик и не следить за памятью ежедневно. Разница в цене с 2 ГБ небольшая, а нервов экономит заметно больше.

Прод с ростом — несколько нод по 2–4 vCPU / 2–4 ГБ каждая за балансировщиком, плюс отдельный Redis (и отдельно вынесенный Tyk Enterprise Developer Portal, если он нужен). Добавление ноды не требует синхронизации — она просто подключается к тому же Redis и сразу обрабатывает трафик. Практически всегда это дешевле и надёжнее одной большой машины на 16 ГБ.

Установка с нуля — в статье как установить и настроить Tyk Gateway на VPS. Ресурсные лимиты на контейнеры удобно выставлять сразу через mem_limit в compose-файле — разобрано в статье про лимиты ресурсов Docker по CPU и памяти. Оплата — картой российского банка, через СБП или криптовалютой, привязывать инфраструктуру к иностранному платёжному методу не придётся ни для одной из локаций.

Частые вопросы