Масштабирование и балансировка нагрузки

01Вертикально или горизонтально и почему важен stateless

Вертикальное масштабирование — это машина помощнее: больше CPU, RAM, быстрее диски. Это просто, не требует изменений в коде и часто оказывается правильным первым шагом, но у него есть потолок, оно дорожает, и одна машина — всё равно одна точка отказа. Горизонтальное масштабирование — это больше машин, на которых крутятся одинаковые копии приложения за load balancer'ом. Оно масштабируется дальше и переживает потерю ноды, но только если любой инстанс может обслужить любой запрос. Для этого нужно stateless-приложение: сессии в Redis или подписанные токены, загрузки в объектном хранилище вместо локального диска, кэш в общем хранилище, задачи по расписанию, которые запускаются один раз, а не на каждой ноде, и никакого важного состояния в памяти. Делайте приложения stateless заранее, даже на одном сервере, — и горизонтальное масштабирование станет простым делом.

• Сессии и кэш: Redis, а не память процесса или локальные файлы.
• Файлы: S3-совместимое объектное хранилище, раздача через CDN.
• Cron: один планировщик или распределённая блокировка, чтобы задачи не выполнялись N раз.

02Балансировщики нагрузки: L4 и L7, алгоритмы, health check'и

Load balancer распределяет запросы между инстансами. Балансировщики уровня 4 работают с TCP/UDP-соединениями: очень быстрые, не зависят от протокола, но не видят URL и заголовков. Балансировщики уровня 7 понимают HTTP: терминируют TLS, маршрутизируют по хосту или пути, добавляют заголовки, повторяют упавшие запросы, сжимают и ограничивают частоту. nginx, HAProxy, Envoy, Traefik и облачные application load balancer'ы — распространённые L7-варианты. Среди алгоритмов — round robin (простой), least connections (лучше, когда запросы различаются по длительности), weighted (разное железо) и hashing (один и тот же клиент — на один и тот же сервер). Health check'и убирают сломанные инстансы: пассивные проверки следят за ошибками в реальном трафике, активные опрашивают health-эндпоинт. Sticky sessions привязывают пользователя к одному инстансу; они маскируют наличие состояния и разбалансируют нагрузку, поэтому предпочитайте общее хранилище сессий, а «липкость» оставьте для случаев вроде fallback'ов для WebSocket.

1upstream app {
2    least_conn;
3    server 10.0.0.11:3000 max_fails=3 fail_timeout=10s;
4    server 10.0.0.12:3000 max_fails=3 fail_timeout=10s;
5    keepalive 32;
6}
7 
8server {
9    listen 443 ssl;
10    server_name example.com;
11    # ssl_certificate / ssl_certificate_key lines go here
12    location / {
13        proxy_pass http://app;
14        proxy_http_version 1.1;
15        proxy_set_header Connection "";
16        proxy_set_header Host $host;
17        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
18        proxy_next_upstream error timeout http_502 http_503;
19    }
20}

03Слои кэширования: CDN, reverse proxy, приложение, база данных

Самый дешёвый запрос — тот, что никогда не доходит до вашего приложения. CDN кэширует статические ассеты и кэшируемые страницы в edge-точках рядом с пользователями, а заодно поглощает простой DDoS-трафик. Кэш reverse proxy (nginx, Varnish) может несколько секунд отдавать повторяющиеся ответы, сглаживая всплески на горячих страницах. В приложении кэш Redis по паттерну cache-aside хранит результаты дорогих запросов с TTL. У базы данных есть собственный буферный кэш, так что хорошие индексы держат горячие данные в памяти. Для каждого слоя нужна ясная история инвалидации: версионируйте имена файлов ассетов, для страниц используйте короткие TTL или очистку при изменении, а при изменении данных удаляйте или обновляйте ключи. Защищайтесь от cache stampede, когда истекает популярный ключ, — блокировками, объединением запросов или слегка рандомизированными TTL.

04Масштабирование базы: пулинг, реплики, партиционирование, шардинг

База данных — обычное узкое место, потому что она хранит состояние и её трудно размножить. Действуйте по возрастанию стоимости. Сначала — индексы и исправление запросов, которые находятся через slow query log и EXPLAIN. Затем — пулинг соединений: PostgreSQL создаёт процесс на каждое соединение, так что десятки инстансов приложения могут его исчерпать; PgBouncer в режиме transaction позволяет тысячам клиентских соединений делить небольшой пул. Дальше — read-реплики для нагрузки с преобладанием чтения; помните, что реплики отстают, поэтому сценарии «прочитать только что записанное» должны идти в primary. Потом — партиционирование больших таблиц (по дате или tenant'у) внутри одной базы, чтобы индексы оставались маленькими, а старые данные удалялись дёшево. И последним — шардинг: разделение данных между несколькими базами по ключу шардирования, например ID tenant'а. Шардинг масштабирует запись, но делает трудными запросы между шардами, транзакции и ребалансировку, поэтому откладывайте его, пока не измерили реальную потребность.

1; /etc/pgbouncer/pgbouncer.ini
2[databases]
3app = host=127.0.0.1 port=5432 dbname=app
4 
5[pgbouncer]
6listen_addr = 127.0.0.1
7listen_port = 6432
8auth_type = scram-sha-256
9auth_file = /etc/pgbouncer/userlist.txt
10pool_mode = transaction
11max_client_conn = 1000
12default_pool_size = 20

05Очереди, back-pressure и планирование мощностей

Не всё обязано происходить внутри запроса. Отправка писем, генерация отчётов, ресайз изображений, синхронизация с ERP — отправьте это в очередь, и пусть воркеры обрабатывают задачи в ровном темпе. Очереди поглощают всплески, изолируют медленных внешних партнёров и позволяют масштабировать воркеры отдельно от веб-серверов. Добавьте и back-pressure: rate limit на каждого клиента, таймауты на каждый исходящий вызов, circuit breaker'ы для падающих зависимостей и плавную деградацию при перегрузке (отдавать кэшированные данные, скрывать необязательные виджеты). Всё это связывает воедино планирование мощностей. Измерьте текущую пропускную способность, перцентили задержки (p95, p99) и использование ресурсов; проведите нагрузочное тестирование инструментами вроде k6, чтобы найти точку отказа; определите, какой ресурс насыщается первым; затем держите запас (часто 30–50 процентов) на всплески и отказы нод. Повторяйте после крупных фич, потому что узкие места перемещаются.

• Смотрите на задержку p95/p99, а не на средние: средние скрывают медленных пользователей.
• Нагружайте копию staging с реалистичными объёмами данных.
• Планируйте потерю одной ноды в пик (мощность N+1).

06Теория очередей, которую можно применять: закон Литтла и утилизация

Закон Литтла связывает три числа: запросов в обработке = скорость поступления x среднее время в системе. При 200 запросах в секунду и 250 ms на запрос в любой момент в работе около 50 запросов — это говорит, сколько нужно воркеров, потоков или соединений с базой. Второй урок нелинеен: когда ресурс приближается к полной загрузке, время ожидания не растёт плавно, а взрывается. У сервера, занятого на 50 процентов, очереди короткие; на 90 процентах небольшие всплески создают длинные очереди, и p99 latency подскакивает. Вот почему важен запас и почему средние значения обманывают. Это же объясняет, почему добавление соединений к перегруженной базе делает её медленнее: больше параллельной работы — больше конкуренции, а не больше пропускной способности. Считайте размер пулов по закону Литтла с запасом и ограничивайте параллелизм, чтобы лишняя нагрузка ждала в очереди, которую вы контролируете.

• В обработке = скорость x latency; используйте это для расчёта пулов и воркеров.
• Планируйте, чтобы в пик ключевые ресурсы работали заметно ниже насыщения.
• Ограничивайте параллелизм на краю, а не позволяйте ему копиться в базе.

07Шторм ретраев, бюджеты таймаутов и load shedding

Ретраи помогают при коротких сбоях и вредят при перегрузке. Если каждый из трёх слоёв ретраит по три раза, один пользовательский запрос может превратиться в 27 вызовов к нижнему сервису — ровно тогда, когда ему и так тяжело. Ретрайте только на одном слое, только идемпотентные операции, с exponential backoff и full jitter, и ограничивайте ретраи бюджетом (например, ретраи могут добавить не более 10 процентов нагрузки). Давайте каждому запросу дедлайн и передавайте оставшееся время вниз по цепочке, чтобы внутренние вызовы никогда не переживали терпение пользователя. При перегрузке отказывайте рано — 429 или 503 с Retry-After, вместо бесконечного ожидания в очереди: быстрый отказ дешевле медленного. Расставьте приоритеты трафика: отбрасывайте аналитику и рекомендации раньше, чем checkout. Circuit breaker прекращает вызывать зависимость, которая постоянно падает, и периодически её проверяет, давая время восстановиться.

1# nginx: per-IP rate limit with a small burst, reject the rest fast
2limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
3limit_req_status 429;
4 
5server {
6    location /api/ {
7        limit_req zone=api burst=40 nodelay;
8        proxy_connect_timeout 2s;
9        proxy_read_timeout 10s;
10        proxy_pass http://app;
11    }
12}

08Consistent hashing и масштабирование кэша

Если распределять ключи по N узлам кэша или шардам через hash(key) mod N, добавление одного узла переназначает почти все ключи: кэш пустеет, и база разом получает всю нагрузку. Consistent hashing размещает узлы и ключи на кольце; каждый ключ принадлежит следующему узлу по часовой стрелке, поэтому добавление или удаление узла перемещает лишь около 1/N ключей. Виртуальные узлы (много точек на один сервер) выравнивают распределение. Redis Cluster использует родственную идею: 16,384 hash-слота, распределённых по узлам и переносимых порциями при решардинге, а hash tag вроде {tenant:42} держат связанные ключи в одном слоте. В балансировщиках директива hash в nginx с параметром consistent делает то же самое при выборе upstream. Для горячих ключей, которые один узел не вытягивает, добавьте перед общим кэшем небольшой in-process кэш с коротким TTL.

09Tail latency и fan-out

Когда один запрос расходится на множество бэкендов, время ответа определяет самый медленный. Если у каждого бэкенда 1 процент вероятности медленного ответа, запрос, затрагивающий 100 из них, медленный большую часть времени. Tail latency возникает из-за пауз сборки мусора, холодных кэшей, шумных соседей, конкуренции за блокировки и очередей. Защита: уменьшайте fan-out за счёт предрасчёта или денормализации; ставьте таймауты на каждый вызов и возвращайте частичный результат, когда второстепенные части опаздывают; используйте hedged requests — отправку второй копии на другую реплику, если вызов превысил p95, только для идемпотентных чтений; держите размеры инстансов и настройки рантайма одинаковыми, чтобы один слабый узел не тянул вниз весь пул. Для ключевых эндпоинтов всегда показывайте p99 и p99.9 рядом с p50 и разбирайте самые медленные трейсы, а не только средние.