Прошло несколько месяцев с тех пор, как Почтовые фронты Mail.Ru стали 64-битными.
Лучше поздно, чем никогда, решили мы, и сегодня я расскажу вам, почему мы это сделали, через что мы прошли для этого и как нам это удалось.
И вот как это работает
Долгое время наша Почта работала на 32 битах на первом Apache и Perl 5.8 под управлением CentOS 5. Идея о переносе фронтенда на более современное ПО и 64-битную архитектуру блуждала в наших головах уже давно: всего полтора года назад нас было всего два человека — один админ и один разработчик — всего за неделю без сна мы настроили тестовый сервер, на котором крутилось наше светлое будущее.
Однако в те времена у нас были более срочные задачи, и о сервере удобно забыли.
Периодически к этой идее возвращались, но все происходило в рамках «А что, если так? «Ой, что-то сломалось!» и снова все откатили и положили на полку.
Время пришло Наконец пришло время перемен.
В какой-то момент мы поняли, что так продолжаться не может: полная поддержка CentOS 5 заканчивается в 2014 году, Perl 5.10 показывает прирост скорости на некоторых задачах на 30%, не говоря уже о том, что 32-битная архитектура в 21-м века несколько не соответствует желаемому.
Более того, после того, как мы переключил почту на HTTPS , средняя нагрузка на серверы переднего плана увеличилась, поэтому более производительный Perl стал актуален как никогда.
Трудности перехода В первую очередь нам пришлось разово переписать те части кода, которые напрямую взаимодействуют с Apache. Поскольку наша система мониторинга основана на ErrorLog Apache, нам пришлось научить новый сервер логировать ошибки так, как нам нужно.
В результате появился самописный модуль логирования ошибок Apache 2, доступный через связь .
Кроме того, нам пришлось разобраться с зависимостями: все используемые нами пакеты исторически были скомпилированы для архитектуры c5x32 и в таком виде были помещены в репозиторий.
В изменившихся реалиях всё, включая модули для nginx, пришлось пересобирать под c6x64. Модуль генерации капчи также был полностью переписан.
Однако больше всего хлопот нам доставили баннеры.
Весь наш макет построен на слотах, контент которых, включая баннеры, взят из шаблонизатора, написанного на C и глубоко интегрированного в Apache. Модуль, отвечающий за баннеры, собирает заголовки Apache и таргетирует их.
Чтобы все это взлететь под Apache 2, нам пришлось не только самим потрудиться, но и прокачать ребят из соответствующего отдела.
Бинарные протоколы В Почте Mail.Ru взаимодействие часто происходит через бинарные протоколы.
Прежде всего, это связь с нашим хранилищем данных Tarantool. Помимо базы данных, даже между нашими сервисами, например Perl-сервером и C-сервером, данные передаются в двоичном виде.
Это хорошо, быстро и удобно, пока не дойдет до изменения архитектуры.
Каждый раз, когда вам нужно зашифровать данные или сложить их по модулю, вероятность того, что результаты операции на x32 и x64 будут разными, становится ненулевой.
Все осложняется тем, что эти различия проявляются только в конкретных данных, поэтому поиск, вылов и учет этих случаев — задача нетривиальная.
Например, первая строка кода ниже будет работать совершенно по-разному на разных архитектурах.
мой $crypted_userid = $user-> {'ID'} ^ 41262125215; getpage('project_url_apiЭuser_id='.
$crypted_userid); Такая разница в поведении приводит к проблемам в совершенно неожиданных местах и даже на разных проектах.
Например, новые результаты выполнения кода с идентификатором пользователя привели к тому, что благодаря нашей общей системе авторизации смена пароля одним пользователем повлекла за собой выход совершенно другого пользователя из другого сервиса.
Такая же проблема с шифрованием обнаружилась и в самой Почте.
После отправки электронного письма пользователь попадает на URL-адрес, который, среди прочего, содержит зашифрованных получателей (никто не хочет, чтобы его электронное письмо было отправлено в адресную строку в виде открытого текста).
Несложно догадаться, что произошло после того, как мы начали генерировать URL-адреса на 64-битной архитектуре: вместо списка получателей появился случайный набор символов.
Конечно, сейчас эти проблемы решены, но их устранение заняло значительное время.
Только два Сам переход занял два месяца.
До того как это произошло, наша почта около полугода работала как на старых фронтах, так и на новых.
Мы внимательно следили за поведением этих двух систем: на нашем дашборде было два отдельных графика, по которым мы отслеживали, где ошибок было больше, а что работало быстрее.
С ними связана забавная история - однажды посреди ночи всех подняли, потому что на графиках производительности новых фронтов очереди были выше - оказалось, что они работают гораздо медленнее.
Потом, однако, оказалось, что мы были настолько оптимизированы, что масштаб новых фронтов автоматически менялся на порядок, а ведь они работают в 10 раз быстрее.
Тем не менее, нам удалось испугаться.
Кроме того, в условиях двух систем нельзя просто взять и обработать запрос Apache. Вам необходимо сделать следующее: суб GetApacheRequest { $ENV{MOD_PERL} =~ m{mod_perl/2}? Apache2::RequestUtil-> request(): Apache-> request(); } Сборка пакетов для Почты также стала изобиловать условиями типа %if 0%{Эcentos} == 6 … %if 0%{Эcentos} == 5 … И таких мест очень много.
Помимо мониторинга и внесения изменений сразу в две ветки, нам, конечно, приходилось тестировать новые итерации в два раза дольше, но наши тестировщики справились.
Награда за работу Итак, что же мы получили в результате этой кропотливой и порой нервной работы?
- Полная поддержка CentOS. 6 - новые патчи, текущее состояние системы
- Быстрое регулярное выражение в Perl 5.10. Скрипты, выполняющие анализ и парсинг, летают еще быстрее
- Apache 2 подхватывает новую конфигурацию и сценарии без перезапуска.
Выкладка кода и конфигов не приводит к 500-й ошибке (теоретически первый Апач это умел, но заставить его это делать нормально, не отключая фронт от нагрузки - задача из области фантастики)
- Тотальный рефакторинг.
Переход на новое ПО — отличный повод избавиться от ненужных зависимостей, ненужных сущностей и неиспользуемых модулей.
- Применение Кукольный .
Мы решили пойти погулять, а заодно переключились на Puppet. Теперь размещение новых функций и развертывание исправлений стали намного проще.
Объем памяти, выделяемой на один процесс, конечно, увеличился, от этого никуда не деться.
Однако все стало быстрее, поэтому задачи обрабатывает меньше процессов, поэтому общие затраты памяти не увеличились.
Прибыль кругом.
Perl 5.10, кстати, дает нам дополнительное преимущество, облегчая переход на 5.16 по сравнению с болезненным переходом с 5.8.8. Так что ждите новый Perl в нашей Почте.
Если у вас есть вопросы, приглашаю вас обсудить их в комментариях.
Илья Зарецкий, Руководитель группы разработки бэкенда Почты Теги: #Разработка сайтов #бэкенд #mail.ru #perl #64-bit
-
Неизвестные Родственники
19 Oct, 24 -
Заказывайте Обзоры И Не Пожалеете
19 Oct, 24 -
It-Мысли, Выпуск 6
19 Oct, 24 -
Страны И Языки При Запуске Windows Phone 7
19 Oct, 24 -
И Снова Скриншоты В Один Клик (C#)
19 Oct, 24
