В ноябре прошлого года МойОфис представила корпоративную почту нового поколения Mailion, разработанную при грантовой поддержке РФРИТ. Это тиражируемое решение для крупных организаций, которое разворачивается на собственных серверах клиента или на базе инфраструктуры доверенного партнера. Благодаря Cloud Native микросервисной архитектуре Mailion гарантирует высокую отказоустойчивость, быстрое самовосстановление и масштабируемость в период колебания нагрузок.

Инженеры компании TEGRUS, российского системного интегратора полного цикла, провели нагрузочное тестирование почты Mailion и подтвердили её применимость в структурах с 600 тысячами пользователей. В ходе тестирования проверялась корректность исполнения сценариев нагрузки, которые эмулируют рабочий день организации и описывают типовое поведение сотрудников крупного предприятия при работе с электронной почтой.

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

Определяем цели и готовимся к тесту

В ходе испытаний инженерам предстояло проверить гипотезу о стабильной работе системы под нагрузкой 6081 RPS (операций в секунду). Это эквивалентно действиям 600 тыс. пользователей, которые в течение дня отправляют и получают 1,14 млн писем.

Моделью бизнес-операций тестирования было предусмотрено, что пользователи могут:

• Входить в систему;
• Запускать программу-клиент электронной почты (при этом происходит подгрузка списка писем, отправка очереди писем и т.д.);
• Переходить на вторую и третью страницу списка писем;
• Отправлять новые письма;
• Открывать входящие письма;
• Переходить в календарь;
• Создавать новые события и реагировать на них.

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

Также, например, модель нагрузки предполагает, что 40% пользователей (240 тыс.) ежедневно назначают встречи, в которых участвует по 3 человека. При этом в календаре пользователей в среднем присутствует по 4 встречи в день. Таким образом, система должна обрабатывать более 2,8 млн событий ежедневно. Каждое событие может содержать вложения, которые создают дополнительную нагрузку на систему.

Создаваемая на стенд нагрузка не начиналась с требуемого RPS, а постепенно приближалась к нему, и тем самым эмулировала процесс реального появления пользователей в системе. Моделью нагрузки было предусмотрено, что от момента начала рабочего дня до выхода на максимальную нагрузку проходит 300 секунд, такой же интервал завершал тестирование. Инженеры хотели определить, как будет вести себя система при увеличении и снижении нагрузки, а также, что будет происходить в средней части графиков, т.е. как Mailion будет справляться с максимальной создаваемой нагрузкой.

В ходе проведения нагрузочных испытаний был использован сценарий масштабирования, который логически разбит не по бизнес-операциям, а по используемым в этих бизнес-операциях запросам. Логическое разбитие нагрузки по запросам вне бизнес-операций позволило получить максимально приближенное (с точностью вплоть до 98%) процентное соотношение конкретных запросов к общему количеству запросов. Целевая нагрузка взята с запасом в 100-150 RPS.

Приводим наш список тестируемых сервисных методов:
Согласно используемой модели загрузки по запросам, максимальный показатель частотности вызова задан для метода create_session (1450 RPS), минимальный — для метода save_event (13 RPS).

Подготовка к проведению нагрузочного сценария включала в себя следующие этапы:

1. Создание пользователей.
2. Создание сессии.
3. Генерация писем во входящих через отправку самому себе и пользователям.
4. Сохранение черновика с вложением.
5. Создание одиночного события с 3 участниками.

В сценарии использовался самописный сервис, который помогал автоматически создавать текст для писем/календарных событий. При подсчете результативного RPS далее в статье, запросы к данному сервису не учитываются.

Для тестирования использовали программу K6 компании Grafana Labs. Скрипты тестирования запускались на группировке из 46 серверов, которые суммарно были оснащены 636 процессорными ядрами, 2,8 ТБ оперативной памяти и накопителями емкостью более 135,4 ТБ.

Тестирование производили по публичному API, с применением HTTP-протокола. Небольшой блок отправки письма выполнялся напрямую в SMTP.

Проводим первую серию испытаний

Сначала производилась линейная нагрузка от 0 до ~ 6350 запросов в секунду, в течение 300 секунд. Затем — постоянная нагрузка величиной ~ 6350 запросов в секунду на сценарий в течение 8 часов. И, наконец, — нисходящая линейная нагрузка с ~ 6350 до 0 запросов в секунду в течение 300 секунд.

Использовалось свыше 6000 необходимых одновременных сопрограмм генератора для создания нагрузки. Время выхода на требуемое число сопрограмм генератора нагрузки — 600 секунд.



Общее количество запросов (Раунд 1). Здесь и далее в тексте, картинки кликабельны



Количество запросов по методам (Раунд 1)


Величина задержек по методам (Раунд 1)


Количество ошибок по методам (Раунд 1)

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

Проводим повторную серию испытаний

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


Общее количество запросов (Раунд 2)


Количество запросов по методам (Раунд 2)



Величина задержек по методам (Раунд 2)


Количество ошибок по методам (Раунд 2)

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

Согласно статистике испытаний, общее количество отправленных запросов к системе составило более 191 млн.

Вывод тестирования:

Достигнута и подтверждена стабильная и устойчивая работа системы Mailion при подаче нагрузки, эквивалентной наличию в системе 600 тыс. пользователей, при нагрузке свыше 6081 RPS в течение 8 часов. Средний уровень нагрузки был равен 6350 RPS, что эквивалентно 612 тыс. пользователям в системе.

«Тестирование показало, что Mailion корректно справляется с предложенной моделью нагрузки. В ходе испытаний была достигнута и подтверждена стабильная и устойчивая работа корпоративной почты при подаче среднедневной нагрузки, эквивалентной действиям 600 тысяч пользователей в течение 8 часов. Система обеспечивала достаточный уровень производительности и оставалась общедоступной даже при увеличении нагрузки до 6350 RPS. Поскольку ошибок в ходе тестирования не было выявлено, то можно сделать вывод о готовности Mailion к работе и с большим количеством пользователей», — отметил Максим Маковский, коммерческий директор компании TEGRUS.

«Отсутствие ошибок в тестах, которые проводились при нагрузке 6350 PRS говорит о готовности Mailion к реальному применению в организациях с численностью более 600 тысяч сотрудников», — заявил Петр Щеглов, директор по продуктовому маркетингу МойОфис.

***
Если вам интересны подробности создания почтовой системы Mailion, советуем изучить нашу серию статей о разработке продукта (ссылки ниже). В них мы детально раскрываем принципы архитектуры решения МойОфис, благодаря которым Mailion отличается высоким уровнем надежности и возможностями масштабируемости. Также будем рады уточнить для вас информацию о продукте, либо о его нагрузочном тестировании — задавайте ваши вопросы в комментариях.

• Первый взгляд: как устроена новая корпоративная почтовая система Mailion от МойОфис
  
• Как мы создаём отказоустойчивую почту для высоких нагрузок. Go, RethinkDB, Cloud Native архитектура и немного магии
  
• Как мы создаём почтовую систему нового поколения Mailion. Эффективное объектное хранилище для электронной почты
  
• Как мы создаём почтовую систему нового поколения Mailion. Принципы проектирования масштабируемых хранилищ данных
  
• Как мы создаём почтовую систему нового поколения Mailion. Архитектура кластера DOS