Андрій Сас: Вперше в Рунеті я буду розповідати про сто мільйонів електронних листів, які відправляються кожен день. Ця доповідь заснований на практиці, яку я придбав в компанії 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 листів, що відправляються. Коли у вас буде такий результат, у вас не буде проблем з доставкою нікуди, крім декількох гальмівних «поштовиків» Східної Європи і Латинської Америки, які до сих пір використовують технології минулого десятиліття.