Прошлой весной мы начали каждую пятницу страдать от массовых рассылок: письма копились в очереди и уходили с большим опозданием. Это были обычные серые пятницы. Уже тогда, за полгода до черной пятницы, стало понятно, что осенью будет непросто. Пришлось масштабироваться. Рассказываю, как всё прошло. Прошла ли черная пятница в Mindbox без дефектов? Нет, не прошла. Был ли хоть один дефект связан с отправкой рассылок? Нет, не был! В течение нескольких недель мы переваривали пиковые объемы писем, и ничего нигде не копилось, не задерживалось, не мешало транзакционным, не двоилось и не билось. Важно не забывать про то, что продукт воспринимается со стороны как единое целое, и недостаточно только стабильной отправки email. При этом важно обращать внимание как на слабые места, так и на то, что получилось хорошо. Очень утомляет быть дураком и учиться на своих ошибках, иногда приятно найти локальный успех и попытаться его растиражировать. Если коротко, то: Ниже несколько уроков на будущее, некоторые из них — с картинками. Это мы знали заранее, и это снова подтвердилось: черная пятница (29 ноября в 2019 году) — это не один день, а полторы-две недели жести. Черная пятница — даже не самый нагруженный день!  Пиковая нагрузка всегда приходится на четверг накануне черной пятницы, что абсолютно логично, хотя и контринтуитивно. График выше может сбивать с толку — в нем на один день приходится несколько точек, каждая точка показывает количество писем за какую-то часть суток. Пробитая планка в 40 миллионов — это не за день, а за несколько пиковых часов. На самом деле за четверг 28 ноября мы отправили 69 миллионов писем с пиковой скоростью 175 тысяч в минуту.  После черной пятницы наступает киберпонедельник, который в этом году выпал уже на декабрь, что сделало этот месяц самым нагруженным в рассылочной истории компании. Те самые 1 300 000 000 писем — это декабрь, а не ноябрь:  Самый сложный день (тот самый 71 миллион) — 26 декабря, и, конечно же, это четверг:  Самый пик-пик — как всегда, в районе 18:00. Чуть-чуть не дотянули до 200 тысяч в минуту (разрешение на графике — 2 минуты):  Что мы в итоге сделали? И можно ли из этого вынести что-то полезное за пределами email-рассылок? Я думаю, что можно. Половина успеха связана с введением отдельных серверов для рассылок на стороне CDP (там, где вычисляются параметры и выдаются действия). До весны 2019 года письма формировались на тех же серверах, где происходили импорты продуктов, удаление действий, сегментация клиентов и еще несколько десятков других задач. С 2017 года ответственный человек в районе черной пятницы садился смотреть на графики и играть в игру «найди, где можно запустить рассылки клиента, чтобы им ничего не мешало». Это происходило при участии менеджеров, заранее выяснявших у самых крупных клиентов ожидаемое время старта их рассылок. В этом году мы впервые перенесли все рассылочные задачи на отдельные сервера, и ответственный человек не понадобился: все клиенты просто отправляли рассылки, а они просто отправлялись. Основная идея была такой: возьми то, что сейчас работает в единственном экземпляре, и сделай несколько экземпляров, чтобы нагрузка разделялась равномерно:  То, что удалось так отмасштабировать, работает предсказуемо и хорошо. То немногое, что осталось в единственном экземпляре, продолжает приносить больше всего проблем. Команда рассылок смотрит на эти оставшиеся единые точки отказа с загадочной улыбкой и пилой в руке. Это звучит проще, чем на самом деле: многие правила обязаны выполняться глобально, как будто рассылочный гейт один, и для пользователя продукта не должно быть видно, что под капотом. Как сделать так, чтобы одно письмо не отправилось дважды или трижды из двух или трех гейтов? Когда человек хочет посмотреть на отправленное письмо — как системе узнать, откуда оно отправилось и где его искать? Эти вопросы надо было решить, но мы справились. На картинке выше заметно, что мы отмасштабировали рассыльщик как-то странно: два MTA отправили за ноябрь миллиард писем, два других — сто миллионов. Никакой неправильной конфигурации здесь нет: просто некоторые письма непропорционально тяжелые. Одна тяжелая рассылка замедляет отправку всех писем на сервере, даже очень легких (по ряду очень технических и очень интересных причин, которые я опущу). Мы выделили отдельные экземпляры MTA для тяжелых писем — тех, где сам шаблон рассылки больше 100 килобайт, где много параметров, где есть вложения, AMP-версия и другие отягчающие обстоятельства. Как ни странно, так лучше всем: и тяжелым письмам (им выделен отдельный ресурс), и легким — им не мешают тяжелые соседи. Одна картинка стоит миллионов рублей:
 На мой вопрос «Как думаешь, в следующем году снова удвоится?» наш CIO Игорь Кудрин после пятисекундного размышления ответил: «думаю, да». Значит, удвоится. По опыту предыдущих лет можно ожидать, что прошлогодние «чернопятничные» нагрузки станут повседневными уже в марте-апреле и будут расти до конца года, где нас ждет ноябрьско-декабрьская кульминация. Что это означает для нас, и готовы ли мы к этому? Планируя масштабирование рассылок, мы со стейкхолдерами договорились о таких критериях успеха: Складывая предыдущие картинки в один вывод, получаем: Все люди, которым нужно сделать какие-то выводы на эту тему, либо прочитают, либо пишут этот пост, так что будем надеяться на лучшее. В 2013 году, когда я пришел в компанию, мы могли отправлять не больше 5–15 тысяч писем в час. Когда я начал заниматься рассылками, мы умели 1 миллион. Сейчас я перестал заниматься рассылками, мы умеем 8–10 миллионов писем в час. Наши стейкхолдеры и консультанты по продажам никогда не забудут в такую реплику вставить «… персонализированных, с подстановкой параметров, с циклами и условиями». Следующий этап, конечно, пиковая скорость 100 миллионов писем в час! С удовольствием прочитаю про это, когда придет время. Текст был написан для внутреннего блога и не только для программистов, поэтому про технику мало, а про бизнес много. Адаптировать для широкой аудитории помогла наша редактор Марианна Любарова, за что ей спасибо. Программист