Пользователю корпоративная почта кажется простым инструментом: письмо пришло, ушло, календарь синхронизировался, поиск нашел нужное сообщение. Но что происходит с почтой в компании, где работает 100 тысяч человек, а количество IMAP-, SMTP-, MAPI- и WebMail-соединений измеряется десятками тысяч? При таком масштабе почта перестает быть «почтовым сервером» и превращается в одну из самых сложных распределенных корпоративных систем с высокой производительностью.

Сергей Чуприс

директор департамента эксплуатации программного обеспечения CommuniGate Pro

Екатерина Сафронова

руководитель отдела маркетинговых коммуникаций CommuniGate Pro

Представим: город N оторвался от Земли. Буквально. Огромный фрагмент земной поверхности вместе с высотками, метро, кофейнями, ЦОДами, самокатами и бесконечными ремонтами плитки медленно дрейфует куда-то в сторону пояса астероидов. По-прежнему работают энергетика и сети передачи данных, и даже сохраняется видимость нормальной жизни. Люди ходят в офисы, отправляют письма через электронную почту, созваниваются в корпоративных мессенджерах и ругаются в домовых чатах из-за парковки.  

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

Проблемы внеземной эксплуатации ИТ

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

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

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

SMTP - очередь сообщений - антивирусная проверка - запись в хранилище - обновление индексов - изменение метаданных - обновление IMAP - уведомление клиента.

Одно письмо – это десятки действий внутри системы. А теперь умножим их на десятки тысяч соединений и сотни тысяч пользователей. Вот так обычная корпоративная почта становится highload-почтой.

Почтовый highload

Высоконагруженная почтовая система чем-то напоминает автономную космическую станцию.

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

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

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

Поэтому при проектировании мы считаем:

·        пиковое число одновременных соединений;

·        количество операций записи в секунду;

·        долю автоматических сообщений;

·        размер и количество вложений;

·        частоту синхронизации клиентов;

·        интенсивность поиска;

·        нагрузку от антивируса и антиспама;

·        влияние резервного копирования;

·        допустимое время восстановления после отказа.

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

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

Так, один крупный стенд примерно на сто тысяч пользователей в какой-то момент уткнулся именно в производительность СХД. Формально инфраструктура работала, данные не терялись, серверы не падали, но само хранилище физически не успевало обрабатывать необходимое количество операций записи, потому что было выбрано недостаточно производительное железо под высоконагруженный сценарий.

Слепая стыковка

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

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

Далее всплывает специфическая схема резервного копирования, про которую никто не вспомнил на этапе обсуждения. Или выясняется, что ИБ-система, в теории «прозрачная для сервисов», на практике нарушает взаимодействие внутри кластера.

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

Highload-архитектура

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

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

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

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

·        горизонтально масштабироваться;

·        распределять нагрузку;

·        изолировать отказ отдельных компонентов;

·        выполнять обслуживание без полной остановки;

·        добавлять ресурсы по мере роста;

·        перераспределять нагрузку при деградации узла.

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

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

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

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

Критичный пилот

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

Проблемы после запуска

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

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

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

Антивирус и антиспам как отдельные сервисы

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

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

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

Final countdown

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

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

Хорошая инженерия в этот день почти незаметна. Пользователь просто открывает письмо, и оно открывается.

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