Разработчики RWB делятся опытом: техническая экспертиза, полезные статьи и анонсы мероприятий.
Регистрация в Роскомнадзоре:
№ 4963508866
Post #791
6.06K
🟣 Привет!
На связи Андрей Аксёнов, QA Lead департамента защиты от DDoS-атак Wildberries & Russ. В мини-интервью он расскажет, как в компании проводят нагрузочное тестирование систем, выдерживающих огромный трафик.
❓ Что для вас является объектом нагрузочного тестирования: отдельный сервис, цепочка сервисов, целый пользовательский сценарий?
❓ Какие типы нагрузки проверяете?
❓ Какие метрики для вас ключевые?
❓ Какие инструменты используете?
❓ Как понимаете, что сервис выдержал нагрузку?
На связи Андрей Аксёнов, QA Lead департамента защиты от DDoS-атак Wildberries & Russ. В мини-интервью он расскажет, как в компании проводят нагрузочное тестирование систем, выдерживающих огромный трафик.
❓ Что для вас является объектом нагрузочного тестирования: отдельный сервис, цепочка сервисов, целый пользовательский сценарий?
Объект подбираем под конкретную задачу.
Отдельные сервисы тестируем, когда нужна изолированная проверка самых критичных функций без влияния интеграций.
Цепочку сервисов нагружаем, чтобы увидеть реальную картину движения трафика, выявить очереди, коллизии и узкие места на всём пути.
Сквозные (end-to-end, E2E) пользовательские сценарии запускаем, чтобы убедиться: готовый функционал ведёт себя под нагрузкой именно так, как ожидает пользователь — от фронтенда через бэкенд до всех внешних интеграций.
❓ Какие типы нагрузки проверяете?
Используем все классические паттерны:
— Steady (стационарная нагрузка) — убеждаемся, что сервис стабильно держит предельную повседневную мощность в течение 1–2 часов без деградации.
— Soak (длительная нагрузка) — ищем скрытые проблемы: утечки памяти, незакрытые соединения и другие эффекты, которые проявляются только через часы или сутки.
— Spike (всплеск) — смотрим, как система реагирует на резкий пик трафика и насколько быстро восстанавливается после его спада.
❓ Какие метрики для вас ключевые?
Следим за двумя группами показателей.
Технические метрики качества сервиса:
— RPS (Requests Per Second — запросы в секунду) — главная характеристика пропускной способности.
— Latency (время ответа) — обязательно анализируем перцентили p95 и p99, потому что именно «хвост» распределения показывает реальный пользовательский опыт. Среднее значение часто обманчиво.
— Error Rate (процент ошибок) — стремимся к нулю, хотя в реальных условиях допустимый уровень зависит от сценария.
Утилизация ресурсов:
— CPU (загрузка процессора),
— Memory (потребление оперативной памяти),
— Network I/O (сетевая нагрузка).
❓ Какие инструменты используете?
Для нагрузки на уровне L7 (прикладной уровень) разработали собственный инструмент. Это высокопроизводительная система генерации трафика, которая точно воспроизводит поведение реальных покупателей и позволяет создавать нагрузку в сотни тысяч RPS.
Для L4 (транспортный уровень) применяем проверенные решения: Cisco TRex и MoonGen. На этом уровне генерируем «сырой» TCP/UDP-трафик, чтобы проверить пропускную способность сети, количество соединений и устойчивость к объёмным атакам.
❓ Как понимаете, что сервис выдержал нагрузку?
Сервис считается прошедшим тест, если выполняются три условия одновременно:
— Функциональность сохранена: нет ошибок в ответах, бизнес-логика исполняется корректно.
— Скорость в пределах нормы: например, p95 времени ответа не превышает установленный порог (часто < 10 мс для внутренних сервисов).
— Стабильность ресурсов: потребление CPU, памяти и сети предсказуемо, после теста показатели возвращаются к базовым значениям без «залипания».
- 🔥 28
- ❤ 19
- 👍 9
