Привет, меня зовут Анатолий, я руковожу группой нагрузочного тестирования в ЮMoney. Началась осень, и не за горами сезон распродаж: магазины уже готовятся к пиковым нагрузкам, продумывают акции и спецпредложения, обновляют ассортимент, договариваются с поставщиками. ЮKassa, наш сервис электронных платежей, тоже в ожидании сезона скидок. В этой статье я расскажу, как мы к нему готовимся, что помогает нашей системе выдержать пиковые нагрузки и как сделать так, чтобы все клиенты остались довольны.

День холостяка, Чёрная пятница, предновогодние распродажи — для платёжного сервиса ЮKassa это не просто даты в календаре, а особенно важное время. Когда миллионы пользователей одновременно жмут кнопку «Оплатить» в интернет-магазинах и на маркетплейсах, нагрузка на сервисы возрастает в разы всего за несколько минут.

У нас нет права на ошибку: для каждого магазина успешный платёж — это не статистика, а реальная выручка и доверие покупателей. Любая лишняя секунда задержки может стоить клиенту продаж, а нам — репутации. Поэтому пиков нагрузки мы не боимся — мы к ним готовимся.

Как мы это делаем?

Проектируем архитектуру так, чтобы она умела жить под давлением больших нагрузок:

• Проводим нагрузочные тесты не только в стенде, но и на бою.

• Строим автоскейлинг (автоматическое масштабирование) так, чтобы он реагировал на аномалии быстрее, чем инженеры успевают открыть Grafana.

• И не боимся ломать продакшен сами, чтобы проверить, выдержит он или нет.

В одном из своих предыдущих текстов я подробно рассказывал, как мы в ЮKassa проводим нагрузочное тестирование.

Почему пиковые нагрузки — это серьёзно

В обычный день нагрузка на ЮKassa стабильная, предсказуемая. Но, когда начинается День холостяка или Чёрная пятница, график транзакций выглядит не как плавная кривая, а как вертикальная стена: в первые минуты акции нагрузка увеличивается в 10-12 раз. Покупатели делают множество транзакций, которые должны пройти без единой ошибки в заданное время.

Любой сбой, любая задержка  — это деньги, которые теряет клиент, поэтому очень важно обеспечить SLA на уровне доступности 99.99% («четыре девятки»). Такой высокий уровень — один из самых высоких — обещает максимальную непрерывность работы сервиса: максимум 4,4 минуты простоя в месяц.

Добавим к этому сложные интеграции: маркетплейсы, банки, платёжные системы. Каждая транзакция — это не один запрос, а целая цепочка взаимодействий между сервисами и внешними контрагентами. Даже если где-то в этой цепочке случится таймаут или отказ, пользователь всё равно будет ждать быстрый результат. И мы должны его обеспечить.

Kubernetes как фундамент: HPA, VPA и оркестрация под боевой трафик

Мы используем Kubernetes как базу для живого масштабирования. В пиках, когда нагрузка растёт лавинообразно, ручное управление бессмысленно. Всё должно работать автоматически.

Что даёт Kubernetes в бою:

• HPA (Horizontal Pod Autoscaler) — горизонтальное масштабирование сервисов на основе метрик (CPU, memory, кастомные показатели вроде RPS или latency).

• VPA (Vertical Pod Autoscaler) — вертикальная подстройка ресурсов контейнеров под реальную нагрузку.

• Node autoscaling — автоматическое добавление нод в кластере.

• PodDisruptionBudget и PriorityClasses — чтобы во время эвикций Kubernetes не убил критичные компоненты.

Боевые стрельбы: когда тестируем прод на прочность

Ни один стенд не повторит реальный продакшен с его интеграциями. Стенд — это всегда модель, а в пиках ошибки происходят именно на границах систем. Поэтому мы проводим стрельбы на бою — с реальными цепочками вызовов, но без реальных денег.

Как это выглядит:

• Генерируем синтетические платежи через те же API, через которые идёт живой трафик.

• Нагрузка проходит полный маршрут: магазин → наш шлюз → банк → маркетплейс → платёжная система.

• Трафик маркируется и исключается из биллинга, поэтому рисков для бизнеса нет.

• Стреляем контролируемо (сначала step load — ступенчатая нагрузка, потом bursts — внезапные, краткосрочные и интенсивные пики нагрузки), имитируя старт распродажи.

Зачем это нужно:

• Проверяем не только свои сервисы, но и реакцию партнёров:
  
  ✓ как банк ведёт себя при росте RPS (увеличение количества запросов, обрабатываемых системой),
  ✓ как маркетплейс отвечает на concurrency (конкурентность/многопоточность в системе),
  ✓ не сработают ли у платёжной системы rate limits (лимиты запросов).

• Отрабатываем алертинг (оповещения о событиях в системе) и runbook’и SRE (инструкции для реагирования на сбои и инциденты) в реальных условиях.

• Тестируем фолбэки (запасной механизм режима работы) и graceful degradation (изящная/плавная деградация): если внешний API падает, платёж всё равно должен завершиться.

Что нового интересует нас в исследованиях к распродажам 2025 года

• Dynamic autoscaling на базе HPA+VPA: рост горизонтальный и вертикальный одновременно. Это позволит достичь оптимальной утилизации ресурсов, когда нагрузка на приложение требует увеличить количество экземпляров и ресурсов на каждый экземпляр.

• Failover API Gateway с fallback-логикой. Нужен, чтобы в случаях, когда партнёр не отвечает, мы могли переключить маршрут за миллисекунды.

• Circuit breakers и smart retries. Circuit breaker — это автоматический выключатель, который предотвращает распространение ошибок от одного неисправного компонента к другим частям системы, экономит ресурсы на отправку запросов к неработающему сервису и ускоряет его восстановление. Smart retries нужен для временных сбоев, например, когда сеть или сервис перегружены. Оба паттерна используются вместе, чтобы обеспечить более устойчивую среду и не словить «шторм» при массовых ошибках.

• Chaos engineering в бою. Имитирует реальные сбои во время пиковых нагрузок и позволяет выявить уязвимости системы. Вот какие эксперименты мы проводим:
  
  ✓ убиваем ноды в Kubernetes,
  ✓ рвём сеть,
  ✓ симулируем отказ банка или маркетплейса в момент пика.

Метрики, по которым меньше переживаешь за SLA

• End-to-end latency, или сквозная задержка платежа (с учётом времени взаимодействия с банками и маркетплейсами). Это время с того момента, как пользователь инициировал платёж, до того, как он подтвердил успешность транзакции. Чтобы оценить это время и проверить работу системы, мы проводим специальные тесты, имитирующие действия пользователя.

• Error rate и распределение ошибок по типам. Коэффициент битовых ошибок, которые могут возникать из-за помех, шума и всяческих искажений.

• Очереди Kafka и брокеров. Нужны для асинхронного обмена сообщениями между разными приложениями без зависимости друг от друга.

• Lag реплик БД, или задержка репликации. Когда данные на сервере-реплике отстают от данных на мастер-сервере БД, потому что изменения на мастере не успели примениться на реплике. Задержка приводит к несогласованности данных и проблемам с производительностью при высоких нагрузках.

• Время масштабирования подов и нод. Это время, которое требуется Kubernetes на развёртывание или удаление новых подов на существующих узлах, а также новых нод (узлов) в кластер.

• ML-анализ аномалий. Когда анализируем отклонения от ожидаемого поведения в системе, например выброс временных рядов данных.

Мы любим хаос. Не тот, что ломает сервисы, а тот, который мы создаём сами, чтобы проверить систему на прочность. Например, тестируем:

• GameDay-сценарии: «А что будет, если в момент старта Чёрной пятницы отключится один дата-центр?»

• Traffic shifting через Istio. Сдвигаем трафик для поэтапного выкатывания новых версий приложений, направляем часть трафика на новую версию, наблюдая за её поведением. И только после этого переключаем трафик целиком.

• Chaos Monkey для Kubernetes. Убиваем поды и ноды.

Вывод: большие распродажи — не стресс, а челлендж для ЮKassa

Пиковые нагрузки — это испытание не только для нас, но и для всей экосистемы: маркетплейсов, банков, платёжных систем. Поэтому мы готовимся комплексно:

• проектируем архитектуру, которая умеет жить в хаосе;

• автоматизируем масштабирование;

• тестируем не в теории, а на практике — прямо в продакшене.

Мы не боимся пиков — мы их ждём. Потому что к тому моменту, когда они случаются, инфраструктура ЮKassa уже знает, как работать под нагрузкой миллионов транзакций.