High-load бэкенд на Elixir Phoenix: real-time, отказоустойчивость, кейсы

Разработка на Elixir: где бэкенд упирается в потолок

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

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

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

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

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

Устойчивость под нагрузкой: соединения, очереди, повторы

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

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

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

Повторные попытки запросов делаем идемпотентными: один ключ операции, растущая пауза, случайный разброс, потолок на число попыток. Так уходят три класса отказов — исчерпание пула, каскадные таймауты и «стадо» синхронных повторов, усиливающее пик. На Elixir эти механизмы лежат в основе платформы, а не прикручиваются поверх приложения.

Результат замеряем по трём метрикам: хвостовая задержка на пике, доля отклонённых запросов и время до полного восстановления после падения отдельного узла. Их динамика до и после изменений показывает реальную устойчивость — в отличие от обещаний «выдержит любую нагрузку».

Варианты реализации: постоянные процессы, гибрид, готовые сервисы

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

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

Как идёт разработка на Elixir: этапы инженерной работы

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

1. Аудит нагрузки. Снимаем профиль: доля операций чтения и записи, длительность запросов на разных участках, поведение в пиковые часы, лимиты внешних систем. На выходе — карта узких мест и список того, что обязано переживать отказ.
2. Схема распределения процессов. Разбиваем домен на изолированные процессы под супервизорами: где держать состояние в памяти, где в общем хранилище, где обращаться к базе напрямую. Так падение одного участка не тянет за собой остальные.
3. Кластер и очереди. Настраиваем распределённый кластер и фоновую обработку: повторные попытки, ограничение параллелизма, защита от дублирующих задач, порядок сообщений.
4. Проверка на отказах. Намеренно выводим из строя узел, связь и внешнюю зависимость, смотрим, поднимается ли сервис сам, сколько запросов теряется и за какое время восстанавливается обслуживание.
5. Приёмка по метрикам. Сверяем результат с порогами, согласованными до старта: доля успешных запросов, время отклика в пике, потребление памяти, скорость обработки фоновой очереди.
6. Передача эксплуатации. Отдаём документацию, схемы супервизии, регламенты дежурства, настроенные метрики и оповещения, проводим обучение команды заказчика.

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

Что передаём на руки: схемы, регламенты и документация

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

• Конфигурации окружений: параметры кластера, лимиты соединений, таймауты, репликация, работа с секретами — с пояснением, почему значение именно такое.
• Схемы потоков данных: путь запроса от балансировщика до хранилищ, очереди, фоновые задания и места, где событие может потеряться или продублироваться.
• Схемы отказоустойчивости: поведение при падении узла, потере базы, недоступности внешнего сервиса, порядок переключения и время возврата в строй.
• Политики доступа и роли: матрица «роль — действие — ресурс», права на логи, изменение конфигурации, доступ к продуктивному контуру, ротация ключей.
• Документация бэкенда: структура модулей, контракты интерфейсов, миграции данных, поведение при повторной доставке, пределы по нагрузке.
• Регламенты эксплуатации: дежурство, реакция на сигналы мониторинга, эскалация, порядок релиза и отката, плановые работы.
• План восстановления: сценарии типовых аварий, точки резервных копий, целевое время восстановления, проверка на учениях.

Кейс: пятикратный пик без обрывов и потерянных заявок

Сервис принимал поток заявок из нескольких каналов — форма на сайте, мобильный клиент, партнёрские интеграции. На пике соединения рвались: клиент не получал подтверждения приёма и отправлял заявку повторно, а часть обращений терялась между приёмом и записью. Доля потерянных заявок доходила до нескольких процентов, ответ растягивался с десятых долей секунды до нескольких секунд, расхождения операторы разбирали вручную.

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

Что стало на пике

Аварийные разборы ушли из постоянной работы: операторы занимаются заявками, а не сверкой пропавших обращений.

Что делать, если часть системы уже работает на другом стеке?

Да — часть системы можно перевести на Elixir, не останавливая продукт, но границу режут не по слоям, а по владению данными. Сначала фиксируем, какая сущность кому принадлежит: у каждой таблицы и каждого сценария записи должен быть ровно один сервис-владелец. Остальные обращаются к нему по контракту, а не к его базе напрямую. Без этого условия смешанный стек быстро превращается в расхождение данных, которое ищут неделями.

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

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

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

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

Технические сомнения: отказоустойчивость, найм, поддержка

Технические сомнения вокруг real-time-бэкенда обычно одни и те же: как система ведёт себя при отказе узла, кто сопровождает код после запуска и где брать инженеров под узкий стек. Ниже — короткие ответы на то, что чаще всего обсуждаем до старта.

Как ищете инженеров под этот стек?

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

Как устроена поддержка после запуска?

Дежурная смена по расписанию, каналы оповещений и регламент эскалации. Наблюдаемость строим на предвестниках отказа, а не на факте падения: рост очередей сообщений, задержка обработки, частота перезапусков процессов. Изменения выходят в окно низкой нагрузки, релиз откатывается одной командой.

Обсудим задачу: разберём профиль нагрузки и риски

Прежде чем называть сроки, мы смотрим на профиль нагрузки: сколько одновременных подключений держит система, как распределён трафик между обычными запросами и постоянными каналами, где возникают пики. Без этих цифр оценка и план работ превращаются в гадание, а риски внедрения всплывают уже на первом релизе. Чтобы обсудить задачу предметно, достаточно пяти сведений:

• Профиль нагрузки — пиковые значения одновременных подключений и запросов в секунду, доля real-time трафика, суточные и сезонные всплески, требования к времени отклика.
• Текущий стек — на чём работает бэкенд, актуальная ветка OTP, библиотеки и брокеры сообщений, что уже перенесено, а что держится на старом коде.
• Данные и хранилища — схемы, объёмы, требования к консистентности, горячие таблицы, регламент резервных копий и проверенный сценарий восстановления.
• Сценарии отказа — что уже падало и как восстанавливались, какие узлы без резерва, где теряются сообщения, как быстро система деградирует под перегрузкой.
• Инфраструктура и процессы — где разворачивается сервис, как устроены выпуск версий и откат, есть ли наблюдаемость, кто принимает решения по приоритетам.

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