Архитектура вокруг бизнеса и бизнес вокруг успешной архитектуры

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

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

• Большой публичный сервис.

• Коробочное on-premise решение.

• Почта "при хостинге".

Ограничения "большого публичного сервиса"

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

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

• Давать техподдержке доступ к логам E-mail сервера крайне нежелательно и вообще проще отказать одному из тысячи клиентов в его запросе, чем заниматься отладкой багов своего сервиса. Если у 999 клиентов из 1000 работает - большой сервис в плюсе.

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

• Если большой сервис не может дать какую-то статистику (а бывает так, что действительно не может), то опять же через техподдержку решить это никак. Отпадают клиенты корп.сектора, ставят себе on-premise и в принципе довольны.

• Лимиты и тарифы. Тут всё однозначно сложно. Вообще посчитать юнит-экономику в большой структуре тяжело (иногда её там уже и нет из за потери прозрачности, есть только общая картина). Соответственно цена будет со страховочной наценкой сверху, а лимиты могут быть для клиента достаточно неожиданными и нелогичными (число писем в час, число входов по IMAP в час и так далее). Вроде бы не критично, но еще 2 клиента из тысячи в это упираются. В определенных нишах бизнеса в это упирается 100% клиентов.

Ограничения "коробочного on-premise решения"

У него картина обратная - можно всё, но часто бывает так что это сложно. Например с почтой при её минимальном использовании админу почти ничего не нужно знать об SMTP,IMAP и вообще читать RFC. При кейсах более интересных, начинается уже потребность в навыках: знать RFC и практически применять знания, знать как почтовка хранит письма и как устроена её БД, кластеризация и HA иногда становятся сложной и малоэффективно задачей и так далее. Всё упирается в:

• Люди in-house которые умеют почту (их сложно найти и долго учить).

• Ресурсы и сеть для обеспечения отказоустойчивости. Навыки работы с HA, опыт проведения испытаний.

• Издержки владения железом/vps - потребность в сервисе: резервное копирование, люди online готовые быстро починить и так далее.

• Трудности интеграции коробочных решений (API если и есть, то какое нибудь ОС-зависимое, которое мало кто умеет и вообще связываться не хочется)

Ограничения "почты при хостинге"

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

Решение для тех, кто ищет

А мы искали. В первую очередь для того, чтобы приютить десяток своих почтовок и несколько десятков почтовок наших клиентов.

SaaS модель оказалась удивительно преемственной для E-mail сервиса, её решились все проблемы публичного сервиса, on-premise решения и почты shared-хостинга:

• Нет никаких трудностей в том чтобы в SaaS развертке дать клиенту 100% функциональности в UI и API, в том числе прямо сразу и логи почтового сервера в некоторой переработке (уже для удобства прочтения).

• Статистика в API, а если её мало - то прямо в БД есть VIEW через которые клиент может забрать любые свои данные, в любом срезе и хоть в узел завязанные join-ами и пересчитанные.

• Лимиты и тарифы на SaaS очень прозрачные и всегда unit-экономика. Достаточно посчитать ресурсы на сервер. Нет нужды в ограничениях числа пользователей, числа писем в час и так далее. Если клиент хочет экономить и терпеть медленную почту - его выбор. Хочет шуструю - он всё видит в интерфейсе, всегда может держать рекомендуемый запас ресурсов. Ведь цена "per user" часто избыточна. Процентов 30% пользователей смотрят почту раз в неделю и письма получают еще реже.

• Поддержка и люди - уже решено SaaS-профайдером, все есть, почта работоспособна и HA к ней уже построен, проведены испытания и учебные аварии и так далее.

• Так же владение железом и интеграции на себя взял и переварил SaaS-провайдер превратив в JSON API и понятную цену поддержки решения.

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

Архитектура

Конечно микросервисы. Их сейчас 12 штук, часть работает в режиме on-demand уступая ресурсы самому важному - обработке SMTP и UI. С точки зрения деплоя сервисов и их оркестрации мы вообще наиболее простым и удобным путем: клиенту выделяется отдельная VPS, внутри docker + docker-compose. Это один инстанс почты, в нем есть все системы нужные для её работы, кроме хранения файлов и писем - файловое хранилище внешнее и монтируется к серверу.

Второй инстанс находится в hot-standby режиме и имеет в себе 1 запущенный сервис: SMTP-сервер ожидающий что в него полетят письма. Когда письма начинают в него лететь - запускаются остальные сервисы и инстанс переходит из режима hot-swap в active.

Перед двумя инстансами стоит балансировщик, который в себе достаточно прост - он принимает входящее письмо, буферизует его у себя, потом отправляет его в один из бакендов (тот, который сейчас active) и ждет получения логов от бакенда (или таймаута). Если в логах бакенда происходит какая то проблема - активный инстанс помечается как аварийный, а письмо переотправляется в hot-standby инстанс.

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

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

Такая схема помогает нам с переносом серверов между физическим размещением (между ЦОД в основном) - в нужный момент достаточно просто выключить активный инстанс и почта сама начнет работать на hot standby инстансе, заблаговременно утащенном в другой датацентр.

Архитектура по итогу прижилась: все почты были пересажены на неё. Кому-то сэкономили денег (да SaaS оказался дешевле публичного сервиса и выгоднее on-premise решения), кому то добавили живучести почты, кому-то (админам) упростили жизнь с группой почтовок.

Бизнес из архитектуры или архитектура из бизнеса

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

Конечно, когда техническое решение стало развиваться как продукт, проявились и его издержки и особенности:

• У нас ~40 продакшин сред с отдельными независимыми релизами, и их число будет расти. Ближайший план - рост на порядок несколько раз подряд. Для нас привычно (обслуживать свои и чужие SaaS-системы одно из направлений), но как всегда искать людей на это трудно. Особенно срывает башню у devops-процесса, который здесь не применим в принципе и сведет в процесс стандартного администрирования с обновлением софта на группе серверов.

• IaC должен быть настоящим. Для нас опять же привычно, у нас были периоды с обслуживанием 15000 серверов из которых 14000 отличались друг от друга очень многим. Но для рынка труда опять же сложная задача - часто в головах SRE примерно такое: "IaC это когда я комичу ansible в git", что далеко от действительности и в проектах с большим числом разных серверов вообще не помогает.

• Ну и конечно все серверы будут разными, это логично. Забыть об одной версии ОС, библиотек и прочем можно сразу. Для нас режим нормальный, рынок труда это закрывает достаточно хорошо.

• Нужны люди умеющие электронную почту, и нужно разрабатывать свои инструменты для её диагностики и обслуживания (ну мы уже начали).

Почему я не рассказываю о том как мы успешно внедрили A, B и C?

Да потому что как всегда нет готовых решений на ваши технические проблемы. Есть частично решающие кусочки пазла, а архитектор всего лишь собирает из пазлов картину.

У нас были муки выбора следующего формата:

• Kubernetes/docker-compose. Kubernetes пришлось бы сильно урезать. Прям вот до уровня docker-compose. docker-compose пришлось чуть-чуть надстроить снаружи (внешний балансировщик в итоге завязан на сетку). Решили достраивать, а не урезать.

• PostgreSQL/MySQL. PostgreSQL решал очень много задач прямо в БД. что удобно, но ест ресурсы, что в SaaS критично. MySQL простой и дешевый по ресурсам, объем влезает такой же, функциональность которую в него не засунуть - засунули в on-demand сервисы и с ресурсами всё хорошо. Экономим и деньги клиента и свои нервы на "логике в базе".

• База для хранений писем (файловые варианты, БД, прочее). Остановились на файловом варианте Maildir. Оптимально в обслуживании, дешево по ресурсам.

• Внешнее хранилище (масса вариантов). Остановились на NFS и репликации блочного устройства на резервное хранилище (режим active-hotstandby). NFS + Maildir дал максимальную скорость на банчмарке при минимальных потребляемых ресурсах. Под NFS на хранилке обычный ext4 с чуть-чуть хитрым форматированием.

• Входящий балансировщик был самым трудным выбором. Написали свой на базе postfix - наиболее просто отлаживать без остановки работы. По ресурсам приемлемо.

Как оказалось, сделав проект мы не внедрили вообще ничего нового, не нашли серебрянных пуль, и даже не стали использовать CI/CD на продакшины. Такие вот мы деградаты и динозавры, но всё ради стабильности.

Flow релизов достаточно простой - с dev сред на stage в режиме CI/CD. Далее - группа инсталляций с пониженными требованиями к SLA. Далее - группы серверов (по 10) со стандартным SLA. Предполагается и заложено, что будут группы серверов со специальным SLA и бесшовными релизами (требуется там, где на почту завязаны срочные уведомления от наших заказчиков их клиентам и доставка исходящего письма от нас внешнему серверу должна быть в течение <5 секунд в любое время дня и ночи).

P.S.

Окупилось? Архитектура - окупилась. Дальнейшая разработка продукта - окупиться, на это есть посчитанные ожидания.

Что не так в этой архитектуре? Хайпа почти нет. Всё просто, минималистично. Но вобщем-то это просто почтовый сервис для тех кто хочет чтобы почта работала и выполняла разные хотелки.