Пулы на serverless: проблема умножения, transaction mode в pgbouncer и размер пула на инстанс

Проблема умножения

На serverful-деплое мудрость пулинга устоялась: три app-сервера с пулом по 20 держат 60 тёплых соединений и стабильны годами. Serverless ломает допущение, спрятанное в этой арифметике, — что владельцев пула мало и их число фиксировано. Инстанс в духе lambda обслуживает один запрос за раз, а платформа масштабируется добавлением инстансов; пул живёт на процесс, и процессы не могут делить сокеты. Так что пул из 5 на инстанс не покупает почти ничего — один запрос редко использует пять соединений сразу, — но каждый инстанс всё равно держит пять слотов. Арифметика для доски: пиковые конкурентные инстансы × размер пула на инстанс должны оставаться меньше max_connections минус зарезервированные слоты. С дефолтами Postgres потолок — 100, минус superuser_reserved_connections (3) и всё, что держат миграции, крон-джобы и дашборды. 100 конкурентных инвокаций × пул 5 = 500 затребованных; инцидент дня запуска — не невезение, а умножение.

Почему просто не поднять max_connections до 5000? Потому что соединения Postgres дороги по построению: каждое — это форкнутый backend-процесс с памятью на бэкенд (work_mem выделяется на операцию сортировки/хеша и умножается со сложностью) и накладными расходами планировщика. После нескольких сотен активных бэкендов пропускная способность деградирует, даже когда большинство простаивает. Поэтому мудрость и переворачивается: на serverless пул на инстанс должен быть 1–2. Дефолтный размер пула Prisma — num_physical_cpus × 2 + 1 — рассчитан на сервер и неверен для lambda; поставьте connection_limit=1 в строке подключения, и пусть конкурентность приходит из инстансов, а не из потоков внутри одного.

Лестница лечений

Каждая ступень ниже жертвует какой-то возможностью ради меньшего числа соединений на функцию — разберитесь, что теряете, прежде чем прыгать на следующую.

Ступень первая: внешний пулер — pgbouncer в transaction mode. Клиенты подключаются к pgbouncer, где соединение дёшево (килобайты состояния, без форка процесса), а pgbouncer держит маленький пул настоящих серверных соединений — скажем, default_pool_size = 20. В transaction mode серверное соединение выдаётся клиенту только на время одной транзакции и возвращается; 500 клиентских соединений мультиплексируются через 20 бэкендов, и Postgres не чувствует стада. Цена реальна и конкретна. Ломается всё, что живёт на уровне сессии: настройки SET молча применяются к тому бэкенду, который достанется следующим, сессионные advisory-локи и временные таблицы испаряются, LISTEN/NOTIFY не работает. И prepared statements уровня протокола по умолчанию ломаются — стейтмент, подготовленный на одном бэкенде, не существует на следующем, — классическая мина для ORM: Prisma нужен ?pgbouncer=true в URL, чтобы перестать на них полагаться, postgres.js — prepare: false. (Свежий pgbouncer, 1.21+, умеет отслеживать prepared statements в transaction mode через max_prepared_statements — проверьте, прежде чем предполагать в любую сторону.)

Ступень вторая: управляемые прокси — RDS Proxy и родня. Та же идея мультиплексирования, запущенная как сервис, с IAM-аутентификацией и обработкой failover. Подвох, который надо знать: сессионное состояние вызывает pinning — соединение, выполнившее SET или другую сессионную вещь, прикрепляется к одному клиенту, тихо превращая ваш мультиплексор обратно в маппер 1:1 ровно на тех нагрузках, которые шалят.

Ступень третья: HTTP/WebSocket serverless-драйверы — стиль Neon и PlanetScale. Драйвер говорит по HTTP или WebSocket со шлюзом на стороне провайдера, который владеет настоящим пулом; ваша функция вообще не держит TCP-соединение к базе. Это обходит умножение целиком и работает в edge-рантаймах, где сырой TCP недоступен. Компромиссы: задержка шлюза на запрос, привязка к провайдеру, а интерактивным транзакциям нужен WebSocket-вариант — простой HTTP-раундтрип на стейтмент не может держать транзакцию открытой.

Арифметика размеров — вместе со стадом

Прогоните числа, как на дизайн-ревью. Управляемый Postgres, max_connections = 100, 3 зарезервированы: 97 доступных, и другие потребители — миграции, крон-воркер, аналитический читатель — реалистично держат 10–15, оставляя приложению ~85. Прямые соединения с connection_limit=1 ограничивают вас 85 конкурентными инвокациями до FATAL; с дефолтным пулом 5 потолок — 17. Через pgbouncer в transaction mode та же база обслуживает тысячи клиентских соединений поверх default_pool_size = 20 бэкендов, и вашим реальным пределом становится пропускная способность транзакций — 20 бэкендов при 5 мс на транзакцию — это примерно 4 000 транзакций в секунду, далеко за исходной стеной.

Теперь добавьте режим отказа, который таблицы размеров пропускают: стадо холодных стартов. Деплой заменяет все инстансы разом; следующую минуту трафик обслуживают только холодные старты, и каждый одновременно набирает TCP + TLS + auth. Напрямую в Postgres это шторм подключений в фиксированный потолок — преходящие FATAL, даже когда арифметика устоявшегося режима сходилась. За пулером шторм приземляется на pgbouncer, который поглощает его очередью (всплеск задержки, а не ошибки). Вторая serverless-морщина: замороженный инстанс держит соединение без keepalive, пока платформа не разморозит или не пожнёт его, — база копит idle-соединения процессов, которые могут никогда не проснуться. Ставьте агрессивные idle-таймауты с обеих сторон и предпочитайте пулеры или HTTP-драйверы, делающие смерть инстанса невидимой.