История об одном проекте, где неудачный выпуск мобильного приложения привел к ддосу от МП

Проект реализуется на базе стека OpenSIPS, который был выбран в качестве SIP-прокси-сервера, преимущественно из-за развитых возможностей кластеризации. В мобильном приложении используется Linphone SDK (не PJSIP), а также WebView для отображения интерфейсных элементов. Логика приложения включает как стандартные модули SDK, так и собственный код, написанный разработчиками.

Изначально приложение работало в режиме постоянной SIP-регистрации на Proxy-сервере, что для определённых задач было приемлемо. Однако впоследствии было принято решение перейти на модель «пробуждение по push-уведомлению» без постоянной регистрации, что соответствует современным практикам энергосбережения и оптимизации нагрузки.

Изменения и последствия

В новой версии приложения была внедрена поддержка push-уведомлений и нового API Google. По логике работы:

1. При поступлении push-сигнала приложение пробуждается.
2. Выполняется регистрация на Proxy.
3. Осуществляется приём звонка.

Однако при выпуске новой версии возникла аномальная нагрузка: вместо ожидаемого снижения количества регистраций их число стало расти. Анализ показал, что в свежей версии Linphone SDK в связке с используемой версией OpenSIPS при установке TLS-соединения клиент иногда не дожидался ответа сервера и инициировал повторное соединение. В результате одно приложение могло генерировать несколько TLS-коннектов в секунду, что при десятках тысяч клиентов создавало критическую нагрузку на инфраструктуру.

Влияние на систему

OpenSIPS обрабатывает каждое TLS-соединение через OpenSSL или WolfSSL, выполняя операции шифрования и дешифрования. При массовом создании сессий резко возросла нагрузка на CPU и потребление памяти. Периодически серверы OpenSIPS исчерпывали ресурсы и аварийно завершали работу.

Изначально в продакшене использовалась одна нода OpenSIPS, которая успешно обслуживала требуемое количество регистраций (десятки тысяч). Однако в условиях описанной проблемы одной ноды стало недостаточно.

Принятые меры

Для стабилизации работы были предприняты следующие шаги:

1. Переход на WolfSSL вместо OpenSSL, что позволило увеличить количество одновременно поддерживаемых соединений и снизить нагрузку.
2. Оптимизация Linux Kernel и системных параметров (увеличение числа воркеров и оптимизация сетевых настроек).
3. Развёртывание нескольких нод OpenSIPS с балансировкой нагрузки. Рассматривались схемы full-sharing и mid-register, однако в условиях высокой частоты установления TCP/TLS-сессий они не дали ожидаемого эффекта — нагрузка распределялась, но суммарно обрабатывался тот же объём трафика.
4. Использование нескольких A-записей в DNS для распределения клиентов между нодами.

Выводы по технической части

• Кластеризация OpenSIPS не всегда является панацеей для разгрузки — при передаче данных по бинарному протоколу нагрузка дублируется на все узлы.
• Проблема была временно стабилизирована только благодаря оптимизации SSL-стека и системных параметров, а также масштабированию количества серверов.
• Быстро внедрить сложные архитектурные изменения (mid-register, main-register) в условиях аварийного восстановления крайне сложно. На подготовку таких изменений требуется не менее одной-двух недель с полноценным тестированием.

Организационные выводы

1. Взаимодействие команд. Отсутствие чёткой координации между разработчиками мобильного приложения и администраторами инфраструктуры может привести к лавинообразному росту проблем.
2. Тестирование. Необходимо внедрять обязательное нагрузочное тестирование мобильных приложений в условиях, максимально приближённых к реальным (с использованием разных моделей устройств, версий ОС и сетевых условий).
3. Зоны ответственности. Должно быть чётко определено, кто отвечает за релизы, тестирование и устранение последствий. Отсутствие этого приводит к «итальянской забастовке», когда формально SLA выполнен, но сервис фактически недоступен.
4. Повышение квалификации. Сотрудники, даже не являющиеся профильными инженерами, должны иметь базовые навыки диагностики (анализ логов, базовые команды администрирования).