В hh.ru много пользователей, а уведомлений мы отправляем еще больше: о регистрации, о восстановлении пароля, об изменении статуса услуг, о новых сообщениях и т.д. Одних только email-уведомлений мы отправляем около 900 миллионов в месяц, а ведь есть еще пуши и смс.
Меня зовут Кирилл, я — тимлид команды Bonjour в hh.ru. Сегодня я расскажу как у нас устроены рассылки.
Исторически так сложилось, что в hh.ru своя система для отправки уведомлений. Мы думали о том, чтобы перейти на подрядчиков или использование внешних сервисов, но учитывая наши объемы, это было бы либо технически сложно для них, либо экономически невыгодно для нас.
В hh.ru сервисная архитектура, и во время работы многие сервисы отправляют свои email-уведомления. Нам хотелось отправлять все уведомления из одного конкретного места: чтобы в нем была унифицированная логика и чтобы нам было проще добавлять туда новую, общую функциональность.
За короткий период времени сервисы могут создать большое количество сообщений. Для распределения этой нагрузки мы используем Rabbit-очереди. В этих очередях подчас лежит по несколько миллионов сообщений, и это вполне нормальная для нас ситуация. Когда сервису нужно отправить письмо, он добавляет сообщение в эту очередь, используя переменные, которые специфичны для каждого конкретного письма.
Некоторые важные письма, вроде регистрации, восстановления пароля и документов, пользователи хотят получать мгновенно. Но если мы будем складывать эти сообщения в общую очередь, время доставки таких писем может достигать нескольких часов. Чтобы решить эту проблему мы используем несколько очередей с различными типами, которые обрабатываются параллельно и независимо друг от друга.
Эти очереди читают инстансы сервиса, который знает: как собрать письмо по сообщению из Rabbit, как получить его текст, верстку, отправителей etc.
Помимо этого он добавляет туда дополнительную техническую информацию, например, заголовки, которые в дальнейшем помогают разбирать инциденты пользователей. Еще пример дополнительной технической информации — это добавление пикселя в каждое письмо, с помощью которого мы в дальнейшем можем отследить каждое открытие письма.
Также мы бы хотели иметь статистику по отправкам писем, но писать каждую отправку письма в базу было бы довольно накладно, поэтому на этом этапе мы просто записываем все отправки в лог.
Итак, наше письмо готово. Нам осталось только отправить его пользователям. Для этого нам надо открыть SMTP соединение, передать данные, получить ответ, правильно его распарсить и переотправить письмо в случае неудачи. Все эти типовые задачи помогает решать софт, который называется MTA – Mail Transfer Agent.
Раньше мы использовали Exim, но в дальнейшем перешли на Postfix, поскольку он больше соответствует нашим требованиям к производительности. Далее мы получаем логи Postfix и заливаем их в Hadoop вместе с логами из предыдущего этапа, данными по отправкам и открытию пикселя. На основе всех этих данных мы в дальнейшем строим аналитику, а также выводим информацию для техподдержки по статусам отправок и открытий.
Итоговая схема выглядит приблизительно так:
Схема отправки пушей практически идентична со схемой отправки email-ов, за исключением того, что в качестве брокера сообщений мы используем Kafka. И здесь мы аналогично используем отдельную очередь для отправки важных уведомлений. Эту очередь слушает сервис, который хранит в себе информацию об устройствах пользователей, ключи отправки и непосредственно отправляет уведомления в нужные сервисы (Android/ios/web etc).
В какой-то момент мы столкнулись с проблемой дублирования уведомлений. Например, при каждом открытии резюме пользователю отправлялся пуш. Чтобы решить эту проблему, мы стали хранить историю последних отправок и проверять, было ли недавно отправлено подобное уведомление. Это помогло нам избежать дублей.
Получается, что нам необходимо хранить историю уведомлений, при этом довольно ограниченное количество времени, а также уметь быстро её читать. В качестве такого хранилища идеально подходит память, но поскольку у нас есть несколько инстансов одного и того же сервиса, им нужна общая память. И в качестве такого хранилища мы используем Redis.
SMS-уведомлений у нас гораздо меньше, чем email-ов и пушей. У нас есть специальный сервис, куда делают запрос по HTTP все сервисы, которые хотят отправить SMS, а внутри него уже у нас живет очередь на базе.
В какой-то момент мы столкнулись с проблемой – hh.ru представлен в разных странах, и отправка, например, из России в Казахстан стоит в несколько раз дороже, чем просто по России. Мы решили её так: заключаем договоры с локальными провайдерами, и в момент отправки по профилю пользователя определяем, кого из них нам лучше использовать.
Есть проблема, с которой вы можете столкнуться при самостоятельной отправке email без использования каких-то внешних сервисов — это борьба крупных провайдеров со спамом. Они могут закидывать ваши письма в спам, искусственно завышать время ответа (тем самым замедляя вашу очередь отправки), а могут и просто возвращать ошибки при отправках. Не всегда понятно, почему алгоритм решил, что вот конкретно это письмо являются спамом. Существуют разные причины, по которым это может произойти, и одна из них, с которой мы сталкиваемся довольно часто – это резкое увеличение количества отправок с нашей стороны.
Нам приходится следить за тем, чтобы наши сервера отправляли определенное количество писем с определенной скоростью и мы не можем добавить новый сервер с новым ip и рассылать по нему с такой же скоростью, поэтому нам приходится увеличивать скорость отправок постепенно. Для крупных сервисов, которые любят внезапно увеличивать время ответа, мы выделяем отдельные инстансы Postfix и благодаря этому вся очередь не замедляется.
Помимо траблов с крупными почтовыми провайдерами мы также сталкиваемся с проблемами отправок писем на корпоративных пользователей. Например, это может быть неправильно настроенный сервер на стороне получателя. В выявлении этих проблем нам помогает анализ логов, про которые я рассказывал ранее.
Многие компании используют публичные почтовые спам-листы и поэтому нам приходится самостоятельно управлять репутацией наших почтовых серверов. Мы мониторим наши попадания в них и стараемся своевременно из них выходить. В этом нам помогает в том числе бот, которого мы написали. Он вовремя уведомляет нас в Slack о том, что мы попали в новый спам-лист.
Многое может пойти не так. От момента, когда мы решили отправить письмо пользователю и до момента, когда он его действительно получил. Поэтому мы стараемся мониторить как можно больше, чтобы быстро определять проблемы. Мы мониторим:
Как видите, организовать и поддерживать свой сервис уведомлений — довольно сложная задача. Поэтому, если у вас есть возможность использовать готовый сервис, то я рекомендую вам не заморачиваться лишний раз. Но если нет, я надеюсь что наш опыт вам поможет.
Делитесь в комментах вашим опытом по управлению рассылками и уведомлениями, нам интересно!
Меня зовут Кирилл, я — тимлид команды Bonjour в hh.ru. Сегодня я расскажу как у нас устроены рассылки.
Исторически так сложилось, что в hh.ru своя система для отправки уведомлений. Мы думали о том, чтобы перейти на подрядчиков или использование внешних сервисов, но учитывая наши объемы, это было бы либо технически сложно для них, либо экономически невыгодно для нас.
Email-уведомления
В hh.ru сервисная архитектура, и во время работы многие сервисы отправляют свои email-уведомления. Нам хотелось отправлять все уведомления из одного конкретного места: чтобы в нем была унифицированная логика и чтобы нам было проще добавлять туда новую, общую функциональность.
За короткий период времени сервисы могут создать большое количество сообщений. Для распределения этой нагрузки мы используем Rabbit-очереди. В этих очередях подчас лежит по несколько миллионов сообщений, и это вполне нормальная для нас ситуация. Когда сервису нужно отправить письмо, он добавляет сообщение в эту очередь, используя переменные, которые специфичны для каждого конкретного письма.
Некоторые важные письма, вроде регистрации, восстановления пароля и документов, пользователи хотят получать мгновенно. Но если мы будем складывать эти сообщения в общую очередь, время доставки таких писем может достигать нескольких часов. Чтобы решить эту проблему мы используем несколько очередей с различными типами, которые обрабатываются параллельно и независимо друг от друга.
Эти очереди читают инстансы сервиса, который знает: как собрать письмо по сообщению из Rabbit, как получить его текст, верстку, отправителей etc.
Помимо этого он добавляет туда дополнительную техническую информацию, например, заголовки, которые в дальнейшем помогают разбирать инциденты пользователей. Еще пример дополнительной технической информации — это добавление пикселя в каждое письмо, с помощью которого мы в дальнейшем можем отследить каждое открытие письма.
Также мы бы хотели иметь статистику по отправкам писем, но писать каждую отправку письма в базу было бы довольно накладно, поэтому на этом этапе мы просто записываем все отправки в лог.
Итак, наше письмо готово. Нам осталось только отправить его пользователям. Для этого нам надо открыть SMTP соединение, передать данные, получить ответ, правильно его распарсить и переотправить письмо в случае неудачи. Все эти типовые задачи помогает решать софт, который называется MTA – Mail Transfer Agent.
Раньше мы использовали Exim, но в дальнейшем перешли на Postfix, поскольку он больше соответствует нашим требованиям к производительности. Далее мы получаем логи Postfix и заливаем их в Hadoop вместе с логами из предыдущего этапа, данными по отправкам и открытию пикселя. На основе всех этих данных мы в дальнейшем строим аналитику, а также выводим информацию для техподдержки по статусам отправок и открытий.
Итоговая схема выглядит приблизительно так:
Пуш-уведомления
Схема отправки пушей практически идентична со схемой отправки email-ов, за исключением того, что в качестве брокера сообщений мы используем Kafka. И здесь мы аналогично используем отдельную очередь для отправки важных уведомлений. Эту очередь слушает сервис, который хранит в себе информацию об устройствах пользователей, ключи отправки и непосредственно отправляет уведомления в нужные сервисы (Android/ios/web etc).
В какой-то момент мы столкнулись с проблемой дублирования уведомлений. Например, при каждом открытии резюме пользователю отправлялся пуш. Чтобы решить эту проблему, мы стали хранить историю последних отправок и проверять, было ли недавно отправлено подобное уведомление. Это помогло нам избежать дублей.
Получается, что нам необходимо хранить историю уведомлений, при этом довольно ограниченное количество времени, а также уметь быстро её читать. В качестве такого хранилища идеально подходит память, но поскольку у нас есть несколько инстансов одного и того же сервиса, им нужна общая память. И в качестве такого хранилища мы используем Redis.
SMS-ки
SMS-уведомлений у нас гораздо меньше, чем email-ов и пушей. У нас есть специальный сервис, куда делают запрос по HTTP все сервисы, которые хотят отправить SMS, а внутри него уже у нас живет очередь на базе.
В какой-то момент мы столкнулись с проблемой – hh.ru представлен в разных странах, и отправка, например, из России в Казахстан стоит в несколько раз дороже, чем просто по России. Мы решили её так: заключаем договоры с локальными провайдерами, и в момент отправки по профилю пользователя определяем, кого из них нам лучше использовать.
Некоторые из проблем, с которыми мы сталкиваемся
Борьба провайдеров со спамом
Есть проблема, с которой вы можете столкнуться при самостоятельной отправке email без использования каких-то внешних сервисов — это борьба крупных провайдеров со спамом. Они могут закидывать ваши письма в спам, искусственно завышать время ответа (тем самым замедляя вашу очередь отправки), а могут и просто возвращать ошибки при отправках. Не всегда понятно, почему алгоритм решил, что вот конкретно это письмо являются спамом. Существуют разные причины, по которым это может произойти, и одна из них, с которой мы сталкиваемся довольно часто – это резкое увеличение количества отправок с нашей стороны.
Нам приходится следить за тем, чтобы наши сервера отправляли определенное количество писем с определенной скоростью и мы не можем добавить новый сервер с новым ip и рассылать по нему с такой же скоростью, поэтому нам приходится увеличивать скорость отправок постепенно. Для крупных сервисов, которые любят внезапно увеличивать время ответа, мы выделяем отдельные инстансы Postfix и благодаря этому вся очередь не замедляется.
Проблемы на стороне получателя
Помимо траблов с крупными почтовыми провайдерами мы также сталкиваемся с проблемами отправок писем на корпоративных пользователей. Например, это может быть неправильно настроенный сервер на стороне получателя. В выявлении этих проблем нам помогает анализ логов, про которые я рассказывал ранее.
Публичные спам-листы
Многие компании используют публичные почтовые спам-листы и поэтому нам приходится самостоятельно управлять репутацией наших почтовых серверов. Мы мониторим наши попадания в них и стараемся своевременно из них выходить. В этом нам помогает в том числе бот, которого мы написали. Он вовремя уведомляет нас в Slack о том, что мы попали в новый спам-лист.
Многое может пойти не так. От момента, когда мы решили отправить письмо пользователю и до момента, когда он его действительно получил. Поэтому мы стараемся мониторить как можно больше, чтобы быстро определять проблемы. Мы мониторим:
Все наши сервисы на стандартные параметры – RPS, потребление памяти, CPU, количество тредов etc.
Размеры очередей. Если в очереди слишком много сообщений, это значит, что сервисы перестали справляться с нагрузкой и мы выпустили какое-то направление, которое их замедлило.
Каждый крон, который генерирует письма и разбиваем этот мониторинг на этапы, чтобы понимать, на каком из них произошла проблема.
Специфичные ответы от почтовых сервисов и время их ответа, чтобы понять, что нас не замедляют.
Время от момента, когда письмо было создано, до момента, когда это письмо было отправлено
Количество отправок в целом. Если отправок слишком мало, значит по какой-то причине письма перестали отправляться и это может стать проблемой. Если отправок слишком много — тоже беда. Как-то раз у нас в kafka-клиенте случился баг, из-за которого одно и то же письмо отправлялось бесконечное количество раз, а наши пользователи получили десятки и сотни тысяч одинаковых писем. Не надо так.
Заключение
Как видите, организовать и поддерживать свой сервис уведомлений — довольно сложная задача. Поэтому, если у вас есть возможность использовать готовый сервис, то я рекомендую вам не заморачиваться лишний раз. Но если нет, я надеюсь что наш опыт вам поможет.
Делитесь в комментах вашим опытом по управлению рассылками и уведомлениями, нам интересно!
