Не каждое программное обеспечение должно быть распределённой системой, работающей на Kubernetes на трёх континентах. Я знаю, знаю — в 2025 году это звучит почти как ересь. Но выслушайте меня.
Я видел, как слишком многие талантливые инженеры тратили месяцы на проектирование сложных инфраструктур микросервисов для приложений, которые обслуживают 500 активных пользователей в день. Я видел, как стартапы сжигали деньги на решениях для горизонтального масштабирования, когда бы хватило мощного вертикального масштабирования на год. И я точно был виноват в этом сам. В 2019 году я убедил свою команду перейти на микросервисы для побочного проекта, у которого было всего три пользователя (двое из них — я и мой соучредитель, тестировавшие его). Мы потратили шесть месяцев на инфраструктуру, которая нам никогда не была нужна.
В технологической индустрии романтизировали масштабируемость. Каждый доклад на конференции, каждый пост в блоге, каждая инженерная легенда говорят вам «проектируйте с учётом масштабируемости с первого дня». Это настолько укоренилось в культуре стартапов, что подвергать это сомнению кажется почти предательством. Но вот грязный секрет? Большинству программ вообще не нужно масштабирование, и принуждение к нему — один из самых быстрых способов саботировать свой проект.
Реальная стоимость преждевременного масштабирования
Вот что вам никто не говорит о масштабировании: оно не бесплатное. И я говорю не только о деньгах, хотя это тоже важно. Я говорю о когнитивной нагрузке, сложности развёртывания, кошмарах отладки и альтернативных издержках.
Когда вы выбираете масштабируемую архитектуру, вы подписываетесь на целую экосистему проблем:
Увеличение операционной сложности означает больше вещей, за которыми нужно следить, больше точек отказа, о которых нужно беспокоиться, и больше пробуждений в 3 часа ночи, когда ваша очередь сообщений ведёт себя странно. Сетевая коммуникация между службами вводит задержку. Поиск сервисов становится загадкой. Согласованность баз данных становится философским спором.
Более длинные циклы разработки, потому что вы не можете просто развернуть монолит и начать отправку. Вам нужно продумать границы сервисов, контракты API, стратегии версионирования. Простая функция, которая заняла бы два часа в монолите, может занять два дня, когда нужно координировать действия между пятью сервисами.
Более высокие затраты на инфраструктуру (по крайней мере, изначально). Вам нужны инструменты оркестрации, решения для мониторинга, агрегация журналов, распределённое отслеживание. Этот кластер Kubernetes? Он стоит денег, даже когда вы его не используете. Те управляемые базы данных? Они дешевле, чем запуск собственных, но они не бесплатные.
Больше разработчиков требуется. Монолитное приложение могут поддерживать два человека. Вашей красиво спроектированной платформе микросервисов нужно как минимум пять инженеров, чтобы она работала.
И вот что самое интересное: если вам на самом деле не нужно масштабирование, вы платите все эти расходы без какой-либо пользы. Вы покупаете Ferrari, чтобы проехать два километра до магазина.
Когда монолитная архитектура имеет смысл
Позвольте мне быть противоречивым самым практичным образом: если ваше приложение ещё не доказало, что ему нужно масштабирование, постройте его как монолит. Да, большое М-слово. То, чего мы все боялись.
Хорошо спроектированное монолитное приложение может выдержать огромный трафик. Современные базы данных могут обрабатывать миллионы запросов в секунду. Один сервер с 32 ядрами ЦП и 256 ГБ ОЗУ обладает огромной мощностью. Облачная инфраструктура означает, что вы можете масштабироваться вертикально без перестройки всей архитектуры.
Подумайте об этом с первых принципов: какую проблему вы на самом деле решаете?
- Если вам нужно обслуживать 10 000 одновременных пользователей в среду вечером: вертикальное масштабирование работает нормально.
- Если ваша база данных помещается в памяти: вам не нужны распределённые данные.
- Если вся ваша команда помещается в один канал Slack: вам, вероятно, ещё не нужны границы сервисов.
- Если вы создаёте MVP: монолит быстрее выходит на рынок.
Есть причина, по которой Rails остаётся актуальным уже 20 лет. Дело не в том, что он масштабируется лучше всего. Дело в том, что для большинства задач он решает их достаточно быстро, не требуя армии DevOps-инженеров.
Дерево решений для масштабирования
Позвольте мне дать вам практическую основу для размышлений об этом:
Ключевой вывод здесь заключается в том, что на каждом уровне есть решение, прежде чем вам понадобятся распределённые системы. Запросы к базе данных можно оптимизировать. Кэширование может увеличить вашу пропускную способность. Более мощный сервер может купить вам 6–12 месяцев. Только когда всё это не сработает, следует рассмотреть фундаментальные изменения архитектуры.
Серьёзный разговор: когда масштабирование действительно важно
Очевидно, что иногда масштабирование имеет значение. Я не выступаю за хаос. Позвольте мне прояснить, когда вам действительно стоит об этом задуматься:
Вы создаёте инфраструктуру (например, базу данных, очередь сообщений, API-платформу), от которой будут зависеть несколько команд. Их нужно проектировать с учётом масштабируемости с первого дня, потому что добавить масштабируемость здесь впоследствии действительно сложно.
Вы уже работаете в значительном масштабе (мы говорим о миллионах пользователей, миллиардах транзакций). Ваша монолитная архитектура доказала, что не справляется, и вы исчерпали другие варианты.
Ваша бизнес-модель зависит от эффективности (например, платформа или SaaS-бизнес, где важна маржа). Улучшение использования ресурсов на 10% на тысячах серверов действительно влияет на вашу прибыль.
У вас есть специфические нормативные или надёжные требования, которые требуют географического распределения или отказоустойчивости в нескольких регионах.
Это реальные сценарии. Они существуют. Но это не ваша проблема сегодня и, вероятно, не будет вашей проблемой и завтра.
Давайте посмотрим на реальные цифры
Вот что даёт вертикальное масштабирование на современном оборудовании:
Стандартный облачный инстанс (скажем, AWS r5.2xlarge: 8 vCPUs, 64 ГБ ОЗУ) стоит около 0,50 доллара в час. Это примерно 3600 долларов в месяц. Этот одиночный инстанс может обрабатывать:
- PostgreSQL: более 50 000 транзакций в секунду (с разумным индексированием).
- Node.js: более 100 000 запросов в секунду (в зависимости от бизнес-логики).
- Python/Django: более 50 000 запросов в секунду.
- Go/Gin: более 200 000 запросов в секунду.
Для большинства бизнес-приложений, обрабатывающих запросы, которые включают реальную работу (запросы к базе данных, вычисления, ввод-вывод), вы смотрите на обслуживание 1000–5000 запросов в секунду на одном инстансе. Это 86–432 миллиона запросов в день на одном сервере. В месяц: 2,5–13 триллионов запросов.
Сколько продакшн-приложений на самом деле нужно обслуживать больше? Согласно большинству инженерных блогов и отчётов об инцидентах, которые я читал, ответ: гораздо меньше, чем количество тех, кто сейчас использует микросервисы.
Практический пример: когда мы остались монолитными
Позвольте мне привести вам реальный пример из проекта, над которым я работал. Мы создали платформу для аналитики данных, которая должна была собирать, обрабатывать и обслуживать запросы для маркетинговых данных. Все предсказывали, что нам понадобятся Spark, Kafka, микросервисы, весь кошмар облачной нативности.
Мы начали с монолитной архитектуры. Rails + PostgreSQL + Redis-кэш. Ничего сложного.
Первый год мы обслуживали 10 миллионов событий ежедневно. Всё ещё на одном приложении-сервере плюс выделенная база данных. Мы добавили кэширование для наиболее распространённых запросов.
Второй год — 100 миллионов событий ежедневно. Мы обновили базу данных до большего инстанса. Добавили реплики для распределения запросов. Всё ещё без микросервисов.
На третий год мы наконец разделили поток данных на отдельный сервис, потому что логике обработки действительно требовались разные характеристики ресурсов, чем веб-сервису. Но нам не нужно было 47 сервисов. Нам нужно было две системы, хорошо работающие вместе.
Общие затраты на инфраструктуру, чтобы достичь этого: 50 тысяч долларов в год. Если бы мы построили это сразу как микросервисы с первого дня, мы бы потратили более 500 тысяч долларов на инфраструктуру и инженерное время и выпустили бы продукт на 6 месяцев позже. Мы бы вообще не выпустили его, потому что всё ещё спорили бы о границах сервисов.
Тест: ответьте на эти вопросы честно
Прежде чем проектировать архитектуру с учётом масштабируемости, ответьте на следующие вопросы: