Производительные монолиты и ложные микросервисы. Как IT-инфраструктура влияет на эффективность монолитной архитектуры?

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

Но ситуация с выбором архитектуры не так однозначна, и ярким тому примером служит Amazon. С одной стороны, компания владеет облаком AWS и является адептом микросервисов. С другой — в 2023 году их стриминговый сервис Prime Video отказался от микросервисов и вернулся к монолиту, чем сократил стоимость инфраструктуры более чем на 90%.

Вывод простой: оба подхода имеют свои преимущества, и выбор между ними во многом зависит от конкретных потребностей вашего бизнеса.

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

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

Компания растёт, её монолит не справляется с нагрузками. Она принимает решение своими силами пилить монолит на микросервисы. Время идёт, но ситуация не становится лучше: компания не только не решила проблемы, но и столкнулась с новыми трудностями.

Причины может быть две: либо компании не хватает ресурсов, чтобы справиться с управлением микросервисами, либо под маской микросервисной архитектуры на самом деле скрывается распределённый монолит (Distributed Monolith).

Распределённый монолит — это архитектура, где приложение всё ещё считается единой системой, но его компоненты могут работать на разных серверах или в разных окружениях. Сейчас на подобной архитектуре держится ВКонтакте.

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

Ещё один недостаток такой архитектуры: код продукта превращается в плохо читаемый неструктурированный spaghetti code (по аналогии с миской спагетти). Ориентироваться в нём сложно, находить проблему внутри компонента и исправлять её без последствий для других компонентов — ещё сложнее.

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

Выявить микросервисы-самозванцев можно по следующим признакам:

Здесь важно усвоить урок: ни один монолит не может получить главного преимущества микросервисов — независимость и атомарность компонентов. Единственный способ получить все преимущества микросервисной архитектуры — грамотно распилить монолит. Это очень долгий и болезненный процесс, требующий включения как разработчиков, так и команды эксплуатации.

Но нужны ли вам абсолютно все плюсы микросервисной архитектуры? Или крупные проекты могут успешно функционировать и на монолитной архитектуре?

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

К примеру, в качестве альтернативы микросервисной архитектуре Shopify выбрал вариант модульного монолита (Modular Monolith). В отличие от однопроцессного монолита, где все компоненты жёстко связаны друг с другом, в модульном монолите всё строится на модулях — изолированных компонентах внутри исходного кода, каждый из которых имеет чёткие границы, отвечает за свой набор функций и явно зависим от других модулей.

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

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

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

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

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

Чтобы повышение производительности вашего монолита было максимально результативным, важно соблюсти три условия:

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

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

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

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

Если вам нужна помощь с улучшением показателей вашей инфраструктуры, миграцией в облако, внедрением DevOps, автоматизацией процессов CI/CD и поддержкой серверов, то наша команда — к вашим услугам.