«Хайлоад в рассылке почты: как спать спокойно»

56
Хайлоад в рассылке почты: как спать спокойно Сас Андрей, делаю почтовые рассылки в Badoo

Upload: natachurda

Post on 05-Jul-2015

250 views

Category:

Documents


0 download

DESCRIPTION

Андрей Сас, Email Product Manager, Badoo Выступление на hpc4.itmozg.ru (25 апреля, Санкт-Петербург)

TRANSCRIPT

Хайлоад в рассылке почты: как спать спокойно

Сас Андрей,

делаю почтовые рассылки в Badoo

А кто говорит?

А кто говорит?

Я:

•руковожу развитием почтовой рассылки, могу знать не все детали;

А кто говорит?

Я:

•руковожу развитием почтовой рассылки, могу знать не все детали;

•не админ (извините!).

А кто говорит?

Я:

•руковожу развитием почтовой рассылки, могу знать не все детали;

•не админ (извините!).

Хвастаюсь:

•год без пролёжек почтовой инфраструктуры;

А кто говорит?

Я:

•руковожу развитием почтовой рассылки, могу знать не все детали;

•не админ (извините!).

Хвастаюсь:

•год без пролёжек почтовой инфраструктуры;

•97% доставки в инбокс;

А кто говорит?

Я:

•руковожу развитием почтовой рассылки, могу знать не все детали;

•не админ (извините!).

Хвастаюсь:

•год без пролёжек почтовой инфраструктуры;

•97% доставки в инбокс;

•среднее время доставки почты – 15 с.

О чём буду рассказывать?

О чём буду рассказывать?

А как люди отправляют почту?

О чём буду рассказывать?

Как отправлять много-много писем,

быть уверенным в себе

и спать по ночам спокойно

Бизнес-задачи

1. Предоставить прозрачный API программистам.

2. Обеспечить отправку почты в объёмах до 150М писем в день.

3. Обеспечить доставку почты во «Входящие» в 95%+ случаев.

О чём НЕ буду рассказывать?

Как сделать так, чтобы ваши письма не попадали в Spam

А что в этом сложного?

Казалось бы:

•поднял MTA (mail transfer agent)

•сделал mail()

•...

•PROFIT!

А что в этом сложного?

Казалось бы:

•поднял MTA (mail transfer agent)

•сделал mail()

Однако:

•отправка 1 письма = обработка 1 динамического хита

А что в этом сложного?

Казалось бы:

•поднял MTA (mail transfer agent)

•сделал mail()

Однако:

•отправка 1 письма = обработка 1 динамического хита

•а ведь письма ещё нужно сгенерировать

А что в этом сложного?

Казалось бы:

•поднял MTA (mail transfer agent)

•сделал mail()

Однако:

•отправка 1 письма = обработка 1 динамического хита

•а ведь письма ещё нужно сгенерировать

•смелость пойти и узнать правду!!1111

Откуда взялась цифра 150М?

• 50М – каждый день

• 70М – в пике

• 100М – просто красивая цифра

• 150М – «пасаны ваще ребята. молодцы, могёте!»

Особенности больших проектов

Наши мантры:

• нужно отправлять письма асинхронно

Особенности больших проектов

Наши мантры:

• нужно отправлять письма асинхронно

• по-настоящему (вдвойне) асинхронно!

Особенности больших проектов

Наши мантры:

• нужно отправлять письма асинхронно

• по-настоящему (вдвойне) асинхронно!

• требуется балансировка между серверами

Порядок отправки письма

1.Появляется необходимость создать письмо.

2.Постановка в очередь на создание письма.

3.Генерация письма по задачам из очереди на создание.

4.Постановка в очередь на отправку.

5.Отсылка письма из очереди на отправку.

Очередь на отправку

Наша реализация – на файлах. Преимущества:

1.Возможна работа без внешних сервисов.

2.Простота манипулирования письмами.

3.Легко получить статистику / логи.

4.Просто реализуются многократные попытки отправки.

SSMTP вместо sendmail

Это SMTP-клиент, эмулирующий работу sendmail.

Нам он нравится, т.к.:

•ничего лишнего, только отсылает письмо в MTA (hub)

•супер простой конфиг

•мы его слегка допилили (таймауты + параметры)

Балансировка между MTA

Первая версия – на базе железки F5 LTM:

•weighted round robin

•SMTP мониторинг

Текущая реализация – скрипты на PHP + мониторинг от F5 LTM:

•автоматическое управление всей балансировкой

•красивый веб-интерфейс

•скрипач (админ) не нужен!

Автоматизация при отправке

Хорошее место, чтобы делать добрые дела:

•подставлять:

• параметры для авторизации в ссылки

• параметры для статистики в ссылки

• картинки для мониторинга открытий

• технические заголовки

•проверять целостность и корректность письма

•и даже тестировать работоспособность ссылок!

Железо почтового кластера

Как тюнить MTA?

• оптимизировать файловую систему (noatime)

• увеличить число SMTP воркеров

• увеличить число DNS воркеров

• поставить локальный кэшер DNS-запросов (unbound)

• раскладывать очередь по большому числу директорий

• увеличить лимиты на число соединений к одному MX серверу

• выставить лимиты на число писем в сессии

Наши MTA

Исторически – Communigate Pro:

•надёжный

•ОЧЕНЬ быстрый

Для «проблемных» почтовых сервисов – Postfix:

•более конфигурируемый

•есть возможность доработать напильником

Хм, Communigate Pro?..

Но ведь есть Postfix, Exim,

Hurricane, Message Systems, Zrinity

и даже Exchange!

Корпоративный комбайн

•Email – первоначальный, основной продукт

•Calendaring

•VoIP

•IM

•File storage

•IP PBX

•Presence

А кто им пользуется?

Однако, цифры

На старой машине с 1 диском SCSI 10k:

•5 миллионов писем в сутки

•до 100 писем в секунду в пике

Общее ощущение

+ чрезвычайно стабилен, вплоть до LA = 200 и очереди в 1М писем

+ высокая производительность отправки писем

+ не требователен к памяти и CPU

+ достаточно настроек для большинства проектов

* платный

– нет возможности менять настройки для разных почтовиков

– нет возможности допилить самим

– проблемы с выводом некоторых видов статистики

Статистика и мониторинг

Пока не измеряешь – не контролируешь.

Что было в начале?

•графики по числу писем в очереди на каждом почтовике

•сколько каких писем отправили за сутки

•статистика по LA / CPU usage / Memory usage в Zabbix

Чего не хватало больше всего?

1. Число файлов, ожидающих отправки в MTA

2. Среднее время отправки письма в MTA

3. Среднее время доставки почты во внешние почтовые сервисы

А также:

• число ошибок отправки писем в MTA

• самые загруженные отправкой почты скриптовые машины

Как реализовали?

Число файлов, ожидающих отправки в MTA:

• просто считаем файлы!

Число ошибок отправки в MTA:

• просто считаем файлы!

Самые загруженные отправкой почты скриптовые машины:

• лог в MySQL

Как реализовали?

Среднее время отправки в MTA:

• время отправки письма минус время создания

Среднее время доставки почты во внешние почтовые сервис:

• парсим логи MTA

• хитрая агрегационная структура (highload!!1111)

Зачем так много?

Dashboard нас спасёт?

1. Несколько dashboard’ов.

2. Даже dashboard’ы стали слишком сложными.

3. Детектировать аномалии даже на менее значимых графиках автоматически.

1984

И что же нового?

С осени 2011 года поменялось:

•Название!

•1 -> 2,5 года без пролёжек почтовой инфраструктуры;

•97% -> 98% inbox placement rate

•Мониторинг лендинга на мобильных версиях

•Лечение от single point of failure (SPoF)

И что же нового?

С осени 2011 года поменялось:

•тегирование ссылок для Google Analytics (легко!)

•выгрузка данных в систему business intelligence (BI)

•API для A/B тестирования

Выводы

1. Быть гуру не надо, достаточно хотеть разобраться.

2. Правильная архитектура без мониторинга не спасёт.

3. Внезапно: отправка почты – тоже highload!

4. Не стойте на месте, развивайте почту, если она для вас важна.

5. …

6. PROFIT!!!

Ваши вопросы *

* Кроме вопросов о том, как мы доставляемся в Inbox