Нагрузочное тестирование SMS-интеграции без лишних отправок

Нагрузочное тестирование SMS-интеграции не должно отправлять тысячи реальных сообщений. Основную часть производительности проверяют на контролируемой заглушке SMS API и симуляторе DLR. Реальный провайдер подключают в конце для малого canary на разрешённые номера и в согласованном лимите.

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

Что именно нагружать

Разделите контур на этапы:

1. Создание бизнес-события и постановка задачи.
2. Чтение и подтверждение очереди.
3. Ограничение скорости и вызов SMS API.
4. Сохранение message ID и результата попытки.
5. Приём webhook и изменение статуса.
6. Метрики, логи и действия бизнес-системы.

Каждый этап имеет свой предел. Быстрый mock API не поможет, если база блокируется на уникальном ключе. Медленный webhook может создать волну повторных callbacks даже при стабильной отправке.

Архитектура очереди SMS-сообщений должна тестироваться как единый поток и по компонентам.

Заглушка провайдера

Mock должен повторять контракт, а не всегда возвращать 200. Настройте сценарии:

• успешный ответ с уникальным message ID;
• задержка ответа и таймаут;
• 429 с Retry-After;
• временные 5xx;
• постоянный 4xx;
• принятие запроса с потерей ответа;
• повтор одного idempotency key;
• асинхронные DLR в разном порядке;
• дубли webhook и неизвестные статусы.

Полезно управлять долями ошибок и задержкой через конфигурацию. Тогда один и тот же тест воспроизводится после изменений.

Модель нагрузки

Средняя скорость не описывает реальную систему. Создайте несколько профилей:

• постоянный обычный поток;
• короткий пик после массового события;
• ступенчатый рост до предела;
• длительная нагрузка для поиска утечек;
• восстановление после остановки провайдера;
• одновременный критичный и массовый трафик.

Объём должен основываться на текущем пике и ожидаемом росте с запасом. Миллион задач ради красивой цифры не полезен, если production-процесс имеет другой профиль и ограничения.

Данные теста

Используйте синтетические номера и тексты, которые нельзя перепутать с реальными. Запрещайте production-ключи и маршруты на уровне окружения. Тестовая конфигурация должна иметь allowlist получателей; даже ошибочное переключение endpoint не должно отправить сообщения произвольным людям.

OTP и персональные данные из production не копируют. Для связности генерируйте event ID, idempotency key и message ID по тем же правилам, но на искусственных сущностях.

Метрики во время теста

Смотрите не только запросы в секунду:

• скорость создания и обработки задач;
• возраст самой старой задачи;
• глубину очереди и время дренирования;
• занятость воркеров и соединений;
• задержку и ошибки базы;
• долю повторов и конфликтов ключей;
• p50/p95/p99 времени этапов;
• число просроченных задач;
• использование памяти, CPU и диска;
• время ответа webhook статусов.

Успешный тест — не максимальный throughput любой ценой. Система должна соблюдать лимит внешнего API, сохранять критичный SLO и восстанавливаться без дублей.

Проверка backpressure

Когда внешний сервис медленнее входящего потока, очередь закономерно растёт. Backpressure ограничивает приём или замедляет необязательный источник до исчерпания ресурсов. Проверьте, что система не открывает бесконечно соединения и не выгружает всю очередь в память.

При достижении порога массовая кампания должна замедлиться или остановиться, а критичный поток — получить резерв мощности. Это проверка не только производительности, но и приоритетов SMS-трафика.

Сбои и восстановление

Отключите mock API после того, как очередь начала работать. Проверьте circuit breaker, политику повторов и рост backlog. Затем восстановите сервис и убедитесь, что поток открывается постепенно.

Перед дренированием должны отсеяться задачи с истёкшим TTL. Одна логическая операция сохраняет один idempotency key, поэтому повтор после разрыва не создаёт вторую отправку. Dead-letter queue остаётся доступной для разбора и не возвращается целиком одной кнопкой.

Тест webhook

Симулятор создаёт DLR с регулируемой скоростью, повторяет события и меняет их порядок. Endpoint должен быстро сохранять вход, отвечать 2xx после фиксации и переносить тяжёлую работу в фон.

Проверьте, что DELIVERED не откатывается старым SENT, один delivery ID не запускает побочное действие дважды, неверная подпись отклоняется, а 500 приводит к контролируемому redelivery.

Небольшой реальный canary

После mock-тестов согласуйте с провайдером ограниченную проверку. Используйте несколько принадлежащих команде номеров разных операторов, отдельный ключ с низким лимитом и явный префикс тестового шаблона. Проверьте реальную кодировку, Sender ID, сегменты, DLR и время доставки.

Не превращайте canary в нагрузочный тест внешней сети. Его задача — подтвердить соответствие симулятора и реального контракта. Лимиты и разрешённые номера защищают от ошибки сценария.

Критерии выхода

До запуска запишите условия успеха: целевая скорость, максимальный возраст очереди, допустимая доля ошибок, отсутствие дублей, время восстановления и лимит ресурсов. Без критериев команда легко объявит успешным тест, который просто «не упал».

Также задайте стоп-условия: риск реальной отправки, расход выше нуля в mock-контуре, неконтролируемый рост очереди, потеря наблюдаемости или влияние на production.

Повторяемость результата

Тест полезен только тогда, когда его можно повторить после изменения. Храните версию сценария, конфигурацию лимитов, объём данных, параметры mock и commit приложения. График без этих сведений нельзя честно сравнить с новым прогоном.

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

Запускайте хотя бы один контрольный профиль при каждом значимом изменении очереди, retry-логики или webhook. Полный предельный тест нужен реже, но короткая регрессия быстро обнаружит падение производительности.

Проверка целостности после нагрузки

После завершения недостаточно увидеть пустую очередь. Сведите количество созданных бизнес-событий, уникальных idempotency key, вызовов mock API, message ID и финальных состояний. Каждая разница должна иметь объяснение: просрочка, постоянная ошибка или намеренная отмена.

Проверьте, что одна операция не получила два message ID, а успешный mock-вызов не остался без сохранённого результата. Дубли и потери могут составлять доли процента и не быть заметны на графике throughput, но на большом production-объёме становятся системной проблемой.

Ограничение тестовых прав

Тестовый сервис не должен уметь менять production-маршрут, баланс и список разрешённых получателей. Секреты окружений разделяются, а сетевые правила блокируют случайный вызов боевого API. Если необходим реальный canary, его выполняет отдельная роль с малым жёстким лимитом.

Логи теста тоже проверяют на отсутствие сгенерированных секретов и открытых телефонов. Синтетическое окружение не отменяет обычные правила безопасности.

Итог

Безопасный нагрузочный тест воспроизводит контракт SMS-провайдера, ошибки, DLR и реальные пики внутри изолированного контура. Он проверяет очередь, лимиты, идемпотентность, TTL и восстановление, а внешний маршрут получает лишь небольшой canary на разрешённые номера. Так команда находит предел системы без нежелательных сообщений и неожиданного счёта.