Черная пятница: взгляд на нагрузку глазами разработчика

Разработчик Рома Ивонин пришел в нашу компанию в 2013 году. В свободное от написания кода время Рома пишет тексты: на его канал в Slack подписан каждый пятый сотрудник компании. Свою последнюю колонку, посвященную пиковым объемам нагрузки в Черную пятницу, Рома согласился опубликовать на Хабре. С разрешения автора перепечатываем материал в нашем блоге.
Прошлой весной мы начали каждую пятницу страдать от массовых рассылок: письма копились в очереди и уходили с большим опозданием. Это были обычные серые пятницы. Уже тогда, за полгода до черной пятницы, стало понятно, что осенью будет непросто. Пришлось масштабироваться. Рассказываю, как всё прошло.

Спойлер: всё получилось, и мы молодцы

Прошла ли черная пятница в Mindbox без дефектов? Нет, не прошла. Был ли хоть один дефект связан с отправкой рассылок? Нет, не был!
В течение нескольких недель мы переваривали пиковые объемы писем, и ничего нигде не копилось, не задерживалось, не мешало транзакционным, не двоилось и не билось.
Важно не забывать про то, что продукт воспринимается со стороны как единое целое, и недостаточно только стабильной отправки email. При этом важно обращать внимание как на слабые места, так и на то, что получилось хорошо. Очень утомляет быть дураком и учиться на своих ошибках, иногда приятно найти локальный успех и попытаться его растиражировать.
Если коротко, то:
  • отправили за месяц больше 1 300 000 000 писем (это один миллиард триста миллионов),
  • это 59 терабайт (без картинок),
  • за одни сутки — 71 миллион,
  • с пиковой скоростью в 200 000 в минуту.
Ниже несколько уроков на будущее, некоторые из них — с картинками.

Черной пятницы не существует, есть черная половина ноября

Это мы знали заранее, и это снова подтвердилось: черная пятница (29 ноября в 2019 году) — это не один день, а полторы-две недели жести. Черная пятница — даже не самый нагруженный день!
Картинка
Пиковая нагрузка всегда приходится на четверг накануне черной пятницы, что абсолютно логично, хотя и контринтуитивно.
График выше может сбивать с толку — в нем на один день приходится несколько точек, каждая точка показывает количество писем за какую-то часть суток. Пробитая планка в 40 миллионов — это не за день, а за несколько пиковых часов.
На самом деле за четверг 28 ноября мы отправили 69 миллионов писем с пиковой скоростью 175 тысяч в минуту.
Картинка

Декабрь хуже ноября

После черной пятницы наступает киберпонедельник, который в этом году выпал уже на декабрь, что сделало этот месяц самым нагруженным в рассылочной истории компании.
Те самые 1 300 000 000 писем — это декабрь, а не ноябрь:
Картинка
Самый сложный день (тот самый 71 миллион) — 26 декабря, и, конечно же, это четверг:
Картинка
Самый пик-пик — как всегда, в районе 18:00. Чуть-чуть не дотянули до 200 тысяч в минуту (разрешение на графике — 2 минуты):
Картинка
Что мы в итоге сделали? И можно ли из этого вынести что-то полезное за пределами email-рассылок? Я думаю, что можно.

Рецепт успеха № 1: изоляция фичей на уровне железа

Половина успеха связана с введением отдельных серверов для рассылок на стороне CDP (там, где вычисляются параметры и выдаются действия). До весны 2019 года письма формировались на тех же серверах, где происходили импорты продуктов, удаление действий, сегментация клиентов и еще несколько десятков других задач.
С 2017 года ответственный человек в районе черной пятницы садился смотреть на графики и играть в игру «найди, где можно запустить рассылки клиента, чтобы им ничего не мешало». Это происходило при участии менеджеров, заранее выяснявших у самых крупных клиентов ожидаемое время старта их рассылок.
В этом году мы впервые перенесли все рассылочные задачи на отдельные сервера, и ответственный человек не понадобился: все клиенты просто отправляли рассылки, а они просто отправлялись.

Рецепт успеха № 2: горизонтальное масштабирование и инстанцирование

Основная идея была такой: возьми то, что сейчас работает в единственном экземпляре, и сделай несколько экземпляров, чтобы нагрузка разделялась равномерно:
Картинка
То, что удалось так отмасштабировать, работает предсказуемо и хорошо. То немногое, что осталось в единственном экземпляре, продолжает приносить больше всего проблем. Команда рассылок смотрит на эти оставшиеся единые точки отказа с загадочной улыбкой и пилой в руке.
Это звучит проще, чем на самом деле: многие правила обязаны выполняться глобально, как будто рассылочный гейт один, и для пользователя продукта не должно быть видно, что под капотом.
Как сделать так, чтобы одно письмо не отправилось дважды или трижды из двух или трех гейтов? Когда человек хочет посмотреть на отправленное письмо — как системе узнать, откуда оно отправилось и где его искать?
Эти вопросы надо было решить, но мы справились.

Рецепт успеха № 3: классы обслуживания и изоляция по роду нагрузки

На картинке выше заметно, что мы отмасштабировали рассыльщик как-то странно: два MTA отправили за ноябрь миллиард писем, два других — сто миллионов. Никакой неправильной конфигурации здесь нет: просто некоторые письма непропорционально тяжелые.
Одна тяжелая рассылка замедляет отправку всех писем на сервере, даже очень легких (по ряду очень технических и очень интересных причин, которые я опущу). Мы выделили отдельные экземпляры MTA для тяжелых писем — тех, где сам шаблон рассылки больше 100 килобайт, где много параметров, где есть вложения, AMP-версия и другие отягчающие обстоятельства.
Как ни странно, так лучше всем: и тяжелым письмам (им выделен отдельный ресурс), и легким — им не мешают тяжелые соседи.

Легче не станет, будет становиться тяжелее

Одна картинка стоит миллионов рублей:
Картинка
На мой вопрос «Как думаешь, в следующем году снова удвоится?» наш CIO Игорь Кудрин после пятисекундного размышления ответил: «думаю, да». Значит, удвоится.
По опыту предыдущих лет можно ожидать, что прошлогодние «чернопятничные» нагрузки станут повседневными уже в марте–апреле и будут расти до конца года, где нас ждет ноябрьско-декабрьская кульминация.
Что это означает для нас, и готовы ли мы к этому? Планируя масштабирование рассылок, мы со стейкхолдерами договорились о таких критериях успеха:
  • на текущем железе мы должны справляться с нагрузкой 200–250 тысяч в минуту (и справились),
  • с добавлением серверов архитектура должна переваривать до 1 миллиона в минуту,
  • нагрузка больше 1 миллиона в минуту, скорее всего, потребует существенных доработок архитектуры.
Складывая предыдущие картинки в один вывод, получаем:
  • к лету 2020 года нам понадобятся новые сервера,
  • ноябрь–декабрь 2021 года мы при текущем тренде роста и на текущей архитектуре уже не проедем или проедем без запаса и с грустными перспективами на весну.
Все люди, которым нужно сделать какие-то выводы на эту тему, либо прочитают, либо пишут этот пост, так что будем надеяться на лучшее.

Уф, короче

В 2013 году, когда я пришел в компанию, мы могли отправлять не больше 5–15 тысяч писем в час. Когда я начал заниматься рассылками, мы умели 1 миллион.
Сейчас я перестал заниматься рассылками, мы умеем 8–10 миллионов писем в час. Наши стейкхолдеры и консультанты по продажам никогда не забудут в такую реплику вставить «…персонализированных, с подстановкой параметров, с циклами и условиями».
Следующий этап, конечно, пиковая скорость 100 миллионов писем в час! С удовольствием прочитаю про это, когда придет время.

Почитайте ещё: