Наверх ▲

Впервые в рунете: сказ о 100М писем в день

Андрей Сас Андрей Сас Андрей заведует email-рассылками в Badoo, а также консультирует российские и зарубежные интернет-проекты по вопросам email-маркетинга. Ранее работал в «МедиаМире» (РБК).

Андрей Сас: Впервые в Рунете я буду рассказывать о ста миллионах электронных писем, которые отправляются каждый день. Этот доклад основан на практике, которую я приобрел в компании Badoo. Единственный сайт, который она разрабатывает – это badoo.com. Я руковожу разработкой всей почтовой структуры. Тема этого моего выступления абсолютно новая, ранее она не поднималась – я не хотел повторяться и специально искал, что уже было сказано по поводу отправки больших объёмов почты, и нашёл ровно ноль докладов на русскоязычных конференциях за последние 3-4 года. Возможно, в Рунете многие успокаиваются уже на том, что выполнена команда mail в PHP.

Теперь немного о том, чем мы можем похвастаться. Во-первых, наша почтовая инфраструктура стабильно работала на протяжении полугода точно, более ранние периоды просто сходу не вспомню.

Второе достижение:  97% нашей почты доставляется в папку для входящих сообщений (англ. Inbox). Учитывая, что мы рассылаем почту не по России (в основном, это почтовые сервисы «большой тройки» – Hotmail, Yahoo и Gmail), по-моему, это достаточно приличный результат. 

25 - таково среднее количество секунд, за которое пользователь получает от нас письмо. Изначально у меня в планах был показатель 42 секунды, но получилось даже лучше.

Если говорить о бизнес-задачах, то у меня их было три. 

Во-первых, мой отдел должен был предоставить интерфейс программирования приложений (API) разработчикам, которые делают функционал, чтобы с помощью него сгенерировать письмо, html-код, txt, присвоить сообщению какой-то заголовок и сообщить адрес доставки, а остальное было уже не их заботой. 

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

Отсюда две задачи.

1. Отправлять до ста миллионов писем каждый день, не опасаясь проблем со стороны архитектуры. 

2. Чтобы абсолютное большинство писем доставлялось в папки входящих сообщений (англ. inbox)  пользователей.

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

Вопрос не в том, чтобы определенным образом сконфигурировать сервер  MTA и получить подтверждение выполнения команды mail. Всё намного сложнее.

Во-первых,  во-первых на отправку каждого письма, требуется столько же вычислительных ресурсов, сколько понадобилось бы, чтобы обработать какой-нибудь динамический хит – например, главную страничку badoo.com.

Во-вторых, эти письма нужно ещё сгенерировать. Это тоже задача, которая требует вычислительных мощностей. 

Наконец, нужно набраться смелости и проверить, что происходит с этими письмами. 

Если вы захотите это сделать, то внезапно обнаружите, что каждое сотое письмо «битое», а в каждом десятом не работают ссылки. Или, к примеру, в письмах отсутствует возможность отписаться от рассылки или еще какая-то важная вещь, без которой не должен работать проект, использующий почту для привлечения пользователей. 

Постараюсь объяснить, откуда взялась цифра 100 миллионов в заголовке. 

Во-первых, в обычный день мы шлем 50 миллионов писем (меньше всего приходится на субботу и воскресенье). У нас были дни, когда мы организовывали рассылки, и количество писем доходило до 70 миллионов. Зная, какая у нас сейчас архитектура с точки зрения аппаратного обеспечения, я уверен, что мы выдержим и 100 миллионов писем в день. Наконец, у меня в планах расширение почтовых кластеров. Я уверен, что после реализации этих планов мы сможем отправлять и 150 миллионов писем в день.

Я постараюсь как можно больше говорить о практике, рассказать о том, как мы работаем в Badoo. Доклад будет носить прикладной характер.

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

Когда у вас маленький проект, скорее всего, используется один почтовый сервер. Нужно просто внести его IP-адрес в файл конфигурации вашего локального сервера Postfix, и все будет работать замечательно. 

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

Теперь подробнее остановимся на отдельных моментах. 

В Badoo порядок отправки письма выглядит следующим образом. 

Предположим, один пользователь отправил другому сообщение. Нужно уведомить адресата о новом сообщении. Соответственно, в этот момент в очередь на создание уведомления о новых сообщениях у нас просто откладывается какая-то заявка. Она там и остается. 

Есть отдельно существующий скрипт, который в такого рода очереди генерирует письма-уведомления о новых сообщениях (для каждой заявки свое письмо). Он берет из этой очереди заявку, генерирует письмо, но сам он ничего не отсылает, команду "mail” не выполняет. 

Вместо этого данный скрипт откладывает уже сгенерированное письмо в некую очередь на отправку. Если, предположим, MTA долго отвечает на ваши запросы, скрипт, который генерирует письма, по-прежнему будет нормально работать.

Очередь писем на отправку «разбирает» отдельный скрипт, который для каждого из сгенерированных писем выполняет только команду “mail”. 

Первый момент. Очередь на отправку реализована очень просто – на файлах. Для отправки писем в этом случае не нужны никакие внешние сервисы. Ни MySQL, ни Mongo не используются. Есть только сервер MTA, на котором у вас лежат письма, и сеть между ними работает замечательно. После решения проблемы вы можете все их отправить. Даже если где-то остались ошибки, письма будут уходить.

Второй момент. Очень просто манипулировать письмами в виде файлов. Любой программист знает, как с ними работать. Существуют блокировки (англ. lock); вы можете переименовывать, перемещать, копировать файлы – все очень просто.

Наконец, при таком подходе не возникает никаких проблем со статистикой и log-файлами. Например, обнаружено проблемное письмо. Оно просто копируется в отдельную папку для проблемных писем.

Примерно так же реализованы операции многократных отправок. 

Если не удалась первая отправка, файл копируется в папку, из которой он будет взят для второй, третьей попытки отправки и так далее. 

Важно отметить, что мы не используем полноценный почтовый сервер MTA на тех машинах, которые генерируют почту. Вместо этого мы используем утилиту SMTP, которая может только пересылать почту в настоящий почтовый сервер MTA. Именно он осуществляет доставку; он не выполняет других операций.

Благодаря такому маленькому функционалу у него очень простой файл конфигурации, любой сможет разобраться.

Наконец, мы доработали его – нас не устраивало, что в нем не было лимита времени ожидания (time-out) и приема параметров через командную строку. Я действительно уверен, что нет никакого смысла ставить полноценный MTA, Postfix или sendmail на локальные машины, генерирующие письма. 

Необходимость балансировки нагрузки появляется в больших проектах. Расскажу про две версии распределения нагрузки, которые были у нас в Badoo.

Итак, первая версия. В начале этого года она была заменена на более совершенную. Она была сделана на базе аппаратного обеспечения – мы применили для нее сервер LTM (Local Traffic Manager) от компании F5.

Он осуществляет соединение с виртуальным IP-адресом, содержащим пул ресурсов нескольких серверов. LTM прозрачно проксирует ваш запрос к конечному, реальному MTA с учетом весов по алгоритму round robin. Что важно: он отслеживает в целом, функционирует ли сервер именно с точки зрения SMTP-протокола. Если ответ сервера свидетельствует о проблеме, сервер временно вычеркивается из списка, и на него не подается трафик, пока его ответ не сообщит о возобновлении работы в нормальном режиме.

Схема вроде бы хорошая и  интересная, но мы ее немного усовершенствовали. Теперь логика по подаче трафика у нас есть в PHP. При этом мы сохранили мониторинг отказов от LTM. Так что теперь мы осуществляем полный контроль над отправкой почты с той или иной машины.

Например, такую характеристику, как размер очереди на отдельной машине, LTM не сможет учесть. 

Мы отследили это с помощью PHP: проблемный IP-адрес просто закрывается. Трафик туда не идет – проблема решена. При этом не нужно делать отдельный интерфейс, можно обойтись уведомлениями по почте или sms.

Дополнительный плюс – администратор не тратит время на то, чтобы убрать какую-либо машину из списка, в котором ее быть не должно.

Есть ещё одна хитрость: нужно максимально автоматизировать выполнение текущих задач при отправке.

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

Приведу примеры того, что Badoo может сделать на таком участке:

• подстановка мониторящих параметров во все ссылки, чтобы понять, из какого письма был сделан клик;

• подстановка картинок, которые позволяют отслеживать открытие писем;

• выполнение проверки корректности и целостности писем,  а также наличия ссылки на отправку;

• автоматическая подстановка ссылок на отправку в случае их отсутствия;

• подстановка целого ряда необходимых технических заголовков.

Это очень неплохой способ упростить работу, мы им охотно пользуемся.

Возможно, вас также интересует наше аппаратное обеспечение. У Badoo две площадки: одна в Европе, другая – в Северной Америке. На каждой из площадок есть почтовый кластер: 10 серверов на первой, на второй чуть больше. В дальнейшем планируется сделать равным и увеличить количество машин. Соотношение отправляющих письма машин к принимающим и обрабатывающим их машинам составляет примерно восемь к двум.

Теперь несколько слов про то, какие машины, по нашему опыту, стоит брать и использовать. Использование ЦП на этих машинах почти нулевое – даже при том, что для всех наших писем мы задействуем DCIM, DOMAIN CASE и другую криптографию. Там даже такой двухъядерный процессор, как Core 2 Duo, используется всего на 2-3% в пике. В общем, процессор не важен. 

То же самое могу сказать про память. 2 ГБ (ну, 4 ГБ в пике)  реально потребляются MTA и системой в момент самой высокой загрузки.

Важным остается один параметр, который имеет значение, если нужно отправить много-много почты. Это ваша дисковая подсистема. Мы готовим ее следующим образом. На всех серверах у нас стоит собранный из четырех SAS-дисков (на 10 тысяч оборотов каждый) RAID 1+0. Он гарантирует, что мы не потеряем письма. Это одна из причин, по которым мы не перешли на решения класса in-memory. Этот подход также дает более высокую скорость работы. 

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

Зачем нужен аккумулятор? Это простейшая защита от ситуации, в которой было отключено питание, а информация не успела дозаписаться. Она может достаточно долго оставаться в этой плашке, а после возобновления работы сервера RAID-контроллер дозапишет на диски информацию.

К сожалению, вендор не доставил нам одну машину для тестов на четырех SSD-дисках (мы хотели собрать ее в RAID 5), поэтому я пока не смогу рассказать вам о ней, хотя изначально планировал.

Теперь пара слов о том, как мы добиваемся, чтобы наши почтовые сервера MTA рассылали максимальное число писем. Самое главное, с чего стоит начать, – это оптимизировать файловую систему, которую вы используете. Это единственное, что может создать серьёзные проблемы. Я бы порекомендовал обратить внимание на флажок no time и ещё как-то поэкспериментировать.

Теперь поговорим о настройке MTA. Есть разные параметры, которыми один почтовый сервер может отличаться от другого. Это, например, число обработчиков SMTP (англ. SMTP-worker). Грубо говоря, нужно знать, сколько вообще процессов (англ. threads) будет заниматься отправкой почты в сторонние почтовые сервисы, и число обработчиков DNS (англ. DNS -worker)  - такой термин есть в Communigate, у него отдельные потоки для получения записей MX. Надо представлять, во сколько потоков все это обрабатывается. Если у вас много DNS-запросов (а на почтовом сервере их много), то вам стоит предусмотреть наличие локального кэша их результатов. Мы используем сервер Unbound. 

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

Есть еще две вещи, которые зависят, скорее, от принимающей стороны (Hotmail, Gmail, Yahoo). У каждого из почтовых сервисов есть свое ограничения: сколько одновременных подключений к их записям MX можно установить или сколько писем они готовы принять в рамках одной SMTP-сессии. Эти цифры нужно узнать, понять и правильно проставить для каждого из важных сервисов, на которые отправляется ваша почта.

Перейдём от общих слов к конкретике. В компании Badoo мы используем два программных почтовых сервера. Это Communigate Pro, с которым мы работаем исторически. Он очень надежный и быстрый с точки зрения того, сколько писем в единицу времени он может отправить.

Наконец, у нас есть сервера Postfix, которые используются, чтобы доставлять почту в какие-то проблемные почтовые сервисы.  Сервер Postfix более конфигурируемый, и при возникновении проблем программисты С смогут что-то в нём доработать.

Почему мы выбираем Communigate Pro, когда есть Postfix, Exim, и недешевые специализированные MTA – Hurricane Systems, Zrinity или Celerity, используемый для Facebook? Наконец, можно было перейти на Exchange – это для людей, особо заинтересованных в трате денег.

Формально Communigate – это действительно сервер-трансформер, который может превратиться в любой из таких серверов, как Email, LDAP, VoIP, Jabber, – у него есть масса возможных конфигураций. 

Но главное, что первоначальным продуктом был именно почтовый сервер MTA. Он был написан очень качественно, его создали русские программисты. Он очень хорошо себя проявляет.

Communigate Pro действительно показывает впечатляющие результаты, в частности, у нас в Badoo. 

У нас использовалась откровенно старая машина с Communigate Pro, на которой был один SCSI диск на 10 тысяч оборотов. RAID не было и в помине. При этом старый сервер мог посылать 5 миллионов писем в сутки стабильно. В секунду в пике получалось 100 успешно отправленных на Hotmail, Yahoo и Gmail SMTP-сообщений, писем. По-моему, это классный результат.

Опишу свое общее впечатление от Communigate. Во-первых, он чрезвычайно стабилен. Даже при значении параметра LA (Load Average), равном 200, и очереди на один миллион писем он работает без отказов на четырех ядрах. Это практика того самого сервера, который я описал выше. Он функционирует и отсылает те самые 5 миллионов писем. Значение LA = 200 меня лично впечатляет всегда. 

Нетребовательность к объёму памяти и характеристикам процессора. Грубо говоря, я ни разу в жизни не видел, чтобы Communigate даже на самой нагруженной системе тратил больше, чем 2 ГБ памяти вместе с системой. На память вообще можно не обращать внимания. 

Кроме того, настроек у Communigate достаточно для того, чтобы решить проблему доставки в отдельные почтовые сервисы для абсолютного большинства проектов. Только если вы, как мы в Badoo, беспокоитесь, что у вас 1% писем куда-то не доходит, и вы готовы из-за этого установить какой-то другой тип MTA (в нашем случае Postfix), значит, вперед!

Я не обозначил пункт «платный» плюсом или минусом по одной простой причине. В случае с Communigate плата за лицензию рассчитывается исходя из числа пользователей веб-интерфейса, поскольку это корпоративный продукт. Соответственно, если вы хотите его использовать, подойдет и минимальная лицензия. Сколько вы ни отсылайте с него писем – 1 миллион в день, 5 миллионов или до 20 миллионов его разгоните – будет одна и та же маленькая стоимость лицензии.

Теперь про минусы системы Communigate. Во-первых, вы не сможете настроить ее по-разному для каждого почтового сервиса. Соответственно, проблемные «почтовики»  будут пользоваться теми же самыми правилами, что и суперпопулярные (Yahoo, Gmail, Hotmail). 

Нет возможности доработать Communigate самим. Просто нет исходников. Наконец, есть реальные проблемы с тем, как он отображает статистику в веб-интерфейсе. Он показывает первую тысячу пунктов без возможности сортировки. Все остальные 20-30 тысяч и вовсе никак не увидеть.

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

Расскажу, что у нас было вначале, два года назад, когда я начал заниматься почтой в “Badoo”. У нас было три вида статистики. Во-первых, были графики, которые показывали, сколько писем стоит на каждом конкретном сервере MTA: 200 тысяч на одном, 50 тысяч на другом и так далее.

Второй момент: у нас были графики, отображавшие, сколько отправлялось в сутки писем каждого типа (100 тысяч подтверждений регистрации в день, 500 тысяч писем про то, что новые есть сообщения или комментарии, и так далее).

Наконец, у нас был Zabbix-мониторинг, который показывал потребление ресурсов ЦП, памяти, какие-то операции по диску, их количество и так далее.

В результате, когда возникала проблема, происходило что-то странное: мы смотрели на эти графики и ничего не понимали. 

Мы посоветовались и сделали несколько вещей, которые нам помогли и до сих пор помогают больше всего.

Во-первых, я упоминал, что существует очередь писем на отправку… Есть машина, которая генерирует письма, и на ней сгенерированные письма «складываются» в файлы. В какой-то момент я понял, что вообще не представляю, сколько в нашей системе писем, еще не отправленных на наш HTML-сервер и оставшихся на дисках. Такую статистику решили сделать.

Второй момент. Надо было подсчитать, сколько ошибок при отправке с MTA у нас случается. Без этой информации картина тоже была бы не полной. Может быть, вместо одной отправки выполняется 10. 

Третий момент. Необходимо знать, сколько времени в среднем требуется на то, чтобы письмо сгенерировали, поместили в файл, и сколько времени пройдет до того, как оно попадет на наш сервер MTA, который будет его отправлять на почту Hotmail или еще куда-то.

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

Наконец, среднее время доставки. Я говорил, что хотел, чтобы оно составляло 42 секунды, но получилось круче – 25. Сколько времени требуется, чтобы доставить письмо пользователю Hotmail, Mail.Ru и так далее. Мы эти цифры получили и теперь имеем представление, что происходит.

Чтобы дать больше практики, которую я обещал, расскажу очень сложные вещи про то, как мы считаем. У нас есть статистика по тому, сколько файлов ожидает отправки в MTA. Мы просто считаем файлы. Статистика очень простая, сделать её легко.

Второй момент. Нас интересовало число ошибок в MTA. Чтобы определить его, достаточно просто сосчитать файлы, которые были переложены в папку для отправок с ошибками. Никаких проблем. 

В-третьих, нам потребовалась более сложная статистика, поскольку пришлось задействовать в ней MySQL. Мы стали собирать в MySQL информацию о том, какой сервер сколько отправил писем. Грубо говоря, сообщалось о каждом отправленном письме. На то, чтобы сделать эту статистику, ушло 5 часов.

Еще пара статистик, они несколько более сложные.

Во-первых, мы отслеживаем среднее время отправки письма в MTA. Грубо говоря, мы замеряем, как долго выполняется команда “mail”, которая задействует обработчик SMTP (о нем я вкратце рассказал). Фиксируем мы это время просто. У нас есть собственный сервис для мониторинга времени, он называется PINBA. Этот сервис открытый и общедоступный – устанавливайте и пользуйтесь. С помощью него мы измерили время, затрачиваемое на выполнение команды “mail”. Таким образом, мы узнали, как долго у нас отправляется одно письмо (по-моему, получилось 150 миллисекунд).

Наконец, последняя статистика. Чтобы начать собирать ее, нам пришлось научиться проверять с помощью парсеров log-файлы почтовых серверов – в нашем случае это Communigate и Postfix. Нужны были данные, чтобы понять, сколько секунд прошло с того момента, как письмо пришло в наш почтовый сервис, до того момента, как наш сервис отправил его, например, на Hotmail. Итак, мы проверили log-файлы с помощью парсеров и придумали интересную структуру, которая позволяет нам делать десятки миллионов добавлений строк и обновлений в день в одной таблице.

Графики у нас есть такие…

Такие…

Такие… Это какая-то малая часть.

Такие. Это все про почту.

Такие.

Даже такие, похоже. Ладно, немного больше, чем я ожидал. Это какие-то самые основные вещи.

Объясню, почему так много графиков и зачем все это нужно.

К тебе приходят люди и объясняют: «Мы тут письмо хотели отослать, сгенерировали, отправили два часа назад, а оно почему-то еще не пришло. Что происходит?» - и ты начинаешь понимать, что графиков недостаточно. Когда вводится новая метрика, можно в прямом смысле слова увидеть проблему: «Ага, вот на этой машине письма отправляются через два часа после генерации, потому что в очереди два миллиона файлов, и они не успевают сразу отправиться». 

После этого проблема устраняется, и выясняется, что еще какую-то область мы не контролируем – там тоже возникают сложности. Делается новый график, который показывает, в чем проблема, и контроль постепенно становится лучше и лучше.

Мы сделали много графиков и поняли, что их нужно объединять в панели мониторинга (англ. dashboard), которых у нас сейчас две. На одной собраны данные о том, как почта отправляется (там самые важные графики по отправке), а на второй панели мониторинга отображаются графики по приему и обработке почты. К сожалению, пока они довольно громоздкие. На них нужно постоянно смотреть, чтобы понять, что сейчас происходит с почтой. На это не всегда есть время, а посмотрев два раза в день, остальное время не знаешь, как обстоят дела. 

У нас, конечно, есть автоматический сервис мониторинга, который отправляет SMS при чрезвычайных ситуациях и специальные сотрудники, которые звонят, если что-то идет не так. Тем не менее, есть менее значимые величины, про которые тоже хочется знать больше.

Следующий шаг мы пока еще не сделали, но хотим сделать. Это будет автоматический мониторинг аномалий на графиках – как более, так и менее значимых. Будут сравниваться графики за неделю, за месяц, и как только появится отклонение от нормы, мы узнаем об этом. Таковы наши цели и планы.

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

Например, у нас есть информация о том, какой уникальный идентификатор был у письма, с какого IP-адреса мы его отправили, какого он был типа. Нужны сведения о новых сообщениях, о регистрации и так далее. Нас интересует язык письма, то, на какой машине был сгенерирован файл письма (часто проблемы бывают со скриптовыми машинами, генерирующими почту). В конце концов, нужно знать время отправки.

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

Наконец, у нас имеется информация обо всех входящих письмах. Наверное, пятая часть всего трафика у нас – это входящие письма, возвращенные сообщения (англ. bounce messages) и еще много всего подобного. По ним тоже неплохо бы иметь все данные: от кого и когда оно пришло, какого типа было, и так далее. 

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

Перейдём к выводам.

Первое. Если вы достаточно большой и разумный проект, чтобы задаться вопросом о том, что вообще происходит с почтой, вам необязательно быть гуру, чтобы эти проблемы успешно найти и решить. Для этого должно быть желание и, конечно, необходимо выделить какие-то ресурсы.

Например, в Badoo, чтобы отладить, каким-то образом переделать архитектуру, было потрачено примерно полтора человеко-года. На основные вещи, о которых я здесь рассказывал, требуется значительно меньше времени.

Второе. Даже если вы все сделаете замечательно и правильно с точки зрения архитектуры, пока вы не научитесь это отслеживать и смотреть, что происходит внутри, вы никогда не сможете сказать, что у вас все хорошо с почтой.

Третье. Я пару раз обращал внимание на то, что это, в общем-то, высоконагруженный проект. Десятки миллионов писем в день – это весьма сложно с вычислительной точки зрения. Если вы это будете держать в голове и захотите качественно решать такие проблемы, то рано или поздно у вас все будет хорошо. 

Пользователи будут получать письма в любом объеме вовремя. Маркетинговые программы у вас будут длиться не одну неделю, и будут ситуации, когда вы скажете своей команде, работающей над продуктом: «Ой, ребята, вы знаете, тут вы можете 2 миллиона писем прибавить, и ваши 50 миллионов мы будем слать 3 с лишним недели». И будут ситуации, когда к вам приходят, а вы говорите: «Да ладно, за два дня отправим, все замечательно».

Вопросы и Ответы

Вопрос из зала: Как вы узнаете, что письмо открылось?

Андрей Сас: Очень просто. В каждое письмо, которое мы отправляем, вставляется специальная картинка с уникальным кодом. Если пользователь открывает это письмо, то его почтовый сервер или приложение, в котором он открывает сообщение, автоматически или каким-то еще образом подгружает эту картинку. Мы «ставим галочку» в базе и знаем, что письмо данного типа или даже конкретное письмо было открыто. Довольно популярная технология.

Вопрос из зала: Но большинство клиентов блокирует открытие таких картинок…

Андрей Сас:  Я не могу сказать, что большинство. Например, Mail.Ru не блокирует, там все классно. Отправляете, получаете. 

Вопрос из зала: Здравствуйте! У вас есть какая-нибудь логика для анализа возвращенных писем (bounce messages)? Например, у пользователя закончилось место в ящике, и в ближайшие пару дней ему нет смысла ничего посылать. Тем самым можно снизить нагрузку на систему. 

Андрей Сас: С первым я согласен, а со вторым нет. Bounce messages нужно обрабатывать, на них нужно обращать внимание. В основном, конечно, мы обрабатываем ошибки типа 550 (Unknown user). Если пользователя нет, писать ему второй раз в ближайшее время незачем. 

По поводу того, что у пользователя кончилось место в ящике, скажу следующее: нет, мы на это не реагируем так, как вы предложили. Мы просто перестаем пересылать это письмо, поскольку это код 500 (Hard bounce). Когда будет следующее письмо, мы снова попробуем отправить его. Это конкретно по вопросу «что делать, если кончилось место». 

Эти коды – 550, 500 – довольно редки. На Hotmail, Yahoo, Gmail (т.е. на основном нашем почтовом трафике) их сейчас редко можно увидеть просто потому, что там большие почтовые ящики. Поэтому это ничтожная, минорная проблема, и сам я не считаю, что реально нужно какое-то время не отсылать письма в переполненный ящик. Я же не знаю, когда пользователь почистит свою папку «Входящие».

Вопрос из зала: Второй вопрос по abuse. Есть ли у вас отдельная служба, сколько людей этим занимается?

Андрей Сас: Abuse-служба?

Вопрос из зала: Да.

Андрей Сас: У нас есть служба поддержки, в которую можно всегда написать. Если вы говорите об адресе abuse, на который можно написать письма, да, такая служба есть. Туда приходит очень мало писем. Эта служба – буквально я. 

Вопрос из зала: Я имел в виду, что если письма не доходят, нужно с этим разбираться – почему не дошли.

Андрей Сас: Понятно. У нас для этого выстроен специальный процесс, в котором участвует команда службы поддержки. Грубо говоря, им приходит заявка: «Я такой-то пользователь. Вот мой адрес почты. Я трижды заказывал себе письмо восстановления пароля. Пожалуйста, разберитесь, почему оно мне не приходит».

Тут нам очень помогает информация о том, кому что мы слали, какие мы слали письма, заказывал ли пользователь такое письмо, было ли оно ему отправлено. Мы даже видим, открывал он письмо или нет. Когда мы видим, что письмо вроде бы послали, а открытия не было, то делаем вывод, что есть проблема. Мы смотрим, на каком сервисе возникла такая проблема. Если это крупный сервис, то мы связываемся с его командой и спрашиваем, что происходит, не внесли ли нас в какой-то список (естественно, предварительно проанализировав log-файлы почтового сервера, который занимается отправкой). Даем пользователю рекомендации: «Посмотрите в папке «Спам», посмотрите там-то».

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

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

Андрей Сас: Никак не боремся.

Вопрос из зала: Не проблема?

Андрей Сас: Да, это не проблема. Никогда с ней не сталкивались.

Вопрос из зала: Скажите, пожалуйста. Вы рассказывали о системе распределения нагрузки по вашим MTA-серверам. Не скажете, какую примерно нагрузку распределяет аппаратное обеспечение? Интересно именно количество трафика в секунду. Не по количеству писем, а по объему трафика.

Андрей Сас: Сложный вопрос. Я не знаю. Мы никогда не сталкивались с проблемами на машине, которая распределяет нагрузку. Но, как я представляю, через нее осуществляются миллионы одновременных соединений. Естественно, такое оборудование стоит хороших денег.

Вопрос из зала: Понятно. 

Андрей Сас: В общем, я про это почти ничего не могу сказать. Работая с почтой, мы никогда напрямую с этим не сталкивались. Где-то в переписке администраторов я видел упоминание о миллионах одновременных подключений через этот физический сервер. Он занят не только почтой, но и локальным распределением трафика в целом, что, в принципе, следует из названия.

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

Андрей Сас: Я уже упоминал, что это наше конкурентное преимущество, которое мы не разглашаем. Я про это не могу говорить и не буду.

Вопрос из зала: У меня как раз с этим был связан вопрос. Основное узкое место – это прием писем другой стороной.

Андрей Сас: По поводу всех вопросов относительно успешности доставки… (Что-то мне надоело говорить durability, и в начале этого года я его перевел на русский язык как «доставляемость» или «успешность доставки».) Проблема не в качестве сторонних почтовых сервисов. Вся проблема исключительно в том, что вы шлете пользователям. У нас, например, одна жалоба на 400 отправляемых писем. Когда у вас будет такой результат, у вас не будет проблем с доставкой никуда, кроме нескольких тормозных «почтовиков» Восточной Европы и Латинской Америки, которые до сих пор используют технологии прошлого десятилетия.

Комментарии

0
# 20 мая 2013 16:52
Отличный доклад

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Ярослав Городецкий

Ярослав Городецкий

Генеральный директор CDNvideo. В Интернете и телекоме с 1996 года. Обожает придумывать и запускать новые продукты и услуги.

Ярослав Городецкий (CDNvideo) делится своим опытом построения сети доставки контента, работающей в России, СНГ и Западной Европе.

Андрей Гулин

Андрей Гулин

Ведущий разработчик в Яндекс.

Представители крупнейших ИТ-компаний Рунета и мирового Интернета обсуждают вопросы использования потоков и особенности применения многоядерных процессоров.

Сэнди Гупта (Sandy Gupta)

Сэнди Гупта (Sandy Gupta)

Главный руководитель Open Solutions Group (OSG) в Microsoft.

Сэнди Гупта (Microsoft) расскажет о стратегии Microsoft по упрощению разработки "облаков" и по созданию возможностей для ПО с открытым исходным кодом.