IT‑инфраструктура подобна зданию: в её фундаменте — вычислительные мощности, а выше — надстройки, включающие внутренние коммуникации, инженерные системы, резервные механизмы. И каждому проекту — свой дом. Кому‑то достаточного небольшого домика на одном виртуальном сервере, а для кого‑то приходится возводить целую девятиэтажку с распределёнными сервисами и оркестрацией.
И если в разработке проекта дома будущему владельцу помогает архитектурное бюро, то при создании облачной инфраструктуры клиент получает от провайдера набор компонентов, из которых сможет собрать систему под своё приложение и, при необходимости, менять её по мере роста бизнеса. Эти компоненты, подобно блокам Lego, совместимы и позволяют собирать комбинации под какие угодно задачи.
В статье разберём, что может входить в такой набор, почему в нашем «архитектурном бюро» не делают типовых проектов и где проходит граница ответственности между облачным провайдером и командой клиента.
Фундамент: с каких сервисов начинается инфраструктура
Что ж, для начала разберём по кирпичику фундамент и посмотрим, какие важные элементы инфраструктуры могут в него входить.
Вычислительные мощности — основа любого проекта. Обычно в этой роли выступают VPS (виртуальные частные серверы). На них можно разместить сайт, приложение, систему управления содержимым, сервис автоматизации или другие компоненты. Наша облачная платформа включает VPS/VDS, объектное хранилище S3, Managed Kubernetes, облачные базы данных и CDN — сеть доставки контента.
Надо сказать, что простой проект с небольшой нагрузкой и минималистичной структурой может нормально работать и на одном VPS: в этом случае приложение и базу данных размещают вместе, а файлы хранят на локальном диске. Это хорошее решение для небольшого бизнеса: запустить продукт без сложной архитектуры и затрат на ненужные пока сервисы, а если позже проект подрастёт или появится бюджет на масштабирование — тогда уже докупить компоненты и расшириться.
Объектное хранилище S3. Оно подходит для файлов, медиаконтента, а также резервных копий. Мы храним объекты в трёх экземплярах на независимых серверах в разных стойках, и для S3 заявлена доступность 99,98%.
База данных. В зависимости от проекта её можно разместить на одном VPS с приложением или вынести в DBaaS (Database as a Service, управляемую облачную БД) — тогда часть инфраструктурной работы перейдёт на сторону провайдера.
CDN. Позволяет отдавать кешируемый контент с географически распределённых узлов, тем самым снижая число запросов к основному серверу.
Managed Kubernetes — управляемая система оркестрации контейнеров. Нужна для проектов с контейнерной архитектурой.
Как CTO выбирают облако
Совсем универсального чек‑листа по выбору облака для СТО не существует — просто потому, что архитектура интернет‑магазина, внутренней корпоративной системы, SaaS‑платформы и вычислительного продукта очень разные. Но всё же несколько критериев повторяются почти всегда, ниже поговорим о каждом из них.
Доступность. Для кого‑то день недоступности сайта приемлем, а для кого‑то — катастрофа. Например, у нас есть клиент — крупный интернет‑магазин, для которого даже один час простоя может обернуться убытками в миллионы рублей. Так что СТО важно понимать как приемлемый для бизнеса уровень доступности и смотреть на SLA провайдера и прописанные в договоре условия компенсации при сбоях в его зоне ответственности.
Поддержка. Автоматизация — это, конечно, хорошо, но ещё лучше, если рядом будут и специалисты, которые могут помочь. Причём речь не просто о канале связи — поддержка должна быстро и компетентно реагировать и нести ответственность за свою работу.
Выбор сервисов. CTO обращают внимание на готовые решения для различных задач. Даже если прямо сейчас они неактуальны — могут понадобиться в ходе развития проекта, когда потребуется масштабирование или изменятся потребности.
Опыт других пользователей. Документация, отзывы, профессиональные сообщества и наличие кейсов — тоже важные критерии при выборе облачного провайдера.
Стоимость. Сравнивать нужно не просто цену виртуального процессора или гигабайта памяти в отрыве от всего остального — в инфраструктурном бюджете обязательно учитывают также затраты времени инженеров на обслуживание баз данных, резервное копирование, обновления и другие операции.
Почему типовой проект — это не универсальное решение
Казалось бы, инфраструктуру можно проектировать в зависимости от типа заказчика: вот архитектура для интернет‑магазина, вот — для SaaS, вот — для высоконагруженной системы… Но не всё так просто.
Систему делят на функциональные компоненты: серверную часть, базы данных, балансировку, кеширование, хранение файлов и другие уровни. Вместо универсального чертежа — несколько комбинаций компонентов. И вдобавок ко всему — понятный интерфейс, чтобы пользователь мог сам настроить проект под свои требования. Такой подход сейчас лучше, чем шаблонные проекты под каждый тип бизнеса, ведь продукты и бизнес‑задачи у клиентов разные.
Давайте теперь рассмотрим, как бизнес подбирает наиболее оптимальную архитектуру с учётом особенностей проекта.
Автоматизация на VPS
В Beget для таких проектов есть готовое решение с n8n и платформой автоматизации рабочих процессов. Пользователь получает сервер с уже предустановленным ПО, а дальше собирает сценарии интеграции разных сервисов. Надо сказать, что само приложение остаётся в зоне ответственности клиента. Например, обновлять n8n пользователь должен самостоятельно. Перед обновлением мы рекомендуем проверить резервную копию или сделать снимок сервера.
У нас был случай: в программу грантов Beget пришёл стартап, предоставляющий клиентам серверы вместе с личными кабинетами. Стартап в один клик создаёт серверы в панели для клиентов и пользуется встроенной функцией создания образов для быстрой интеграции нужного набора ПО и настроек — и выполняет за пару часов работу, которая в других условиях заняла бы несколько дней. Это ускорение позволяет стартапу быстро расти: на пике у проекта было более 800 VPS одновременно.
Архитектура интернет‑магазина
Для интернет‑магазина нужны иные компоненты: VPS с предустановленной CMS → база данных (на том же VPS, в DBaaS или отдельном VPS с предустановленной БД) → S3 → CDN.
Изображения товаров и резервные копии можно хранить в S3, а статический контент — раздавать через CDN. В таком варианте отдельные части системы масштабируются независимо: рост объёма файлов не требует увеличения диска основного сервера, а рост числа запросов к статическим ресурсам не означает пропорциональный рост нагрузки на приложение.
Это, кстати, только одна из возможных схем архитектуры для интернет‑магазина, но не единственная.
Если SaaS и высокая нагрузка
Для растущего SaaS‑проекта подойдёт комбинация: VPS или Kubernetes + DBaaS + S3 + CDN.
Изначально приложение может работать на нескольких VPS, но если команда переходит к контейнерам, а количество сервисов увеличивается, уже требуется оркестрация — и вычислительный слой стоит перенести в Managed Kubernetes. У нас есть два варианта: для разработки и тестирования — с одна управляющей нодой, а для рабочей среды — с тремя master‑нодами. Во втором случае состояние управляющего контура реплицируется, и при выходе одной ноды управление кластером продолжает работать.
Когда в проекте тысячи виртуальных машин
Для некоторых задач важно большое количество отдельных машин. Один из наших клиентов (извините, но NDA, так что без названия) использует около 2000 VPS. Такая конфигурация подходит продуктам, где отдельные экземпляры собственного решения запускаются для большого количества клиентов или вычислительных задач. В подобной архитектуре множество VPS можно дополнять DBaaS и Kubernetes.
Вот, кстати, живой пример того, что размер инфраструктуры не зависит от типа проекта: молодая компания с вычислительным продуктом потребляет больше облачных ресурсов, чем зрелый интернет‑магазин.
Как инфраструктура растёт вместе с бизнесом
В начале проекта главная задача — быстро запустить работающий продукт, поэтому клиенты обычно стартуют со схемы VPS → приложение + база данных. Если представить, что проект — дом, то такая схема — фундамент. С ростом нагрузки «дому» нужно надстраивать «этажи»: добавлять процессорные ядра, оперативную память или диск.
На следующем этапе компоненты разделяют: VPS → приложение, DBaaS → база данных, S3 → файлы и резервные данные, CDN → доставка контента. Если одного экземпляра приложения становится недостаточно, прибегают и к горизонтальному масштабированию: запускают несколько вычислительных узлов, а нагрузку распределяют между ними.
При контейнерной архитектуре следующим уровнем часто становится Kubernetes. Но это не всегда так: если два или три VPS с отдельной БД закрывают задачу, добавление оркестратора может лишь усложнить эксплуатацию.
За что отвечает провайдер и как мы обеспечиваем отказоустойчивость
Клиенты приходят к нам как с новыми проектами, так и с уже работающей инфраструктурой. В первом случае облако становится стартовой площадкой, архитектуру строят с нуля. Второй причиной миграции может быть несоответствие предыдущей платформы ожиданиям клиента — например, стоимости, удобства работы, доступности поддержки или каких‑то других аспектов.
На экономику проекта серьёзно влияет исходная инфраструктура. Если компания переносит собственное оборудование в облако, меняется структура капитальных расходов — часто бывает, что облачное решение будет обходиться дешевле сервера на своём железе и персонала для его обслуживания. Если проект уже работал у другого облачного провайдера, при переходе возможна экономия за счёт других, более выгодных тарифов, изменения архитектуры, сокращения количества ручных операций, а также в снижении времени простоя, если бизнес чувствителен даже к коротким периодам недоступности проекта. К слову, перенос инфраструктуры вовсе не всегда сопровождается радикальным изменением архитектуры: виртуальные серверы, базы данных и хранилища могут остаться концептуально теми же.
Модель облака подразумевает разделение ответственности. На стороне провайдера — развёртывание серверной инфраструктуры, настройка сети сервиса, обновления программного обеспечения, резервное копирование и восстановление данных, мониторинг и инфраструктурная безопасность. Клиент же, в свою очередь, проектирует приложение и определяет, как компоненты будут связаны между собой. Так же с Kubernetes: провайдер предоставляет доступ к control plane и инфраструктурной части сервиса, следит за её работоспособностью, но решения о количестве экземпляров приложения, взаимодействии микросервисов и сценариях восстановления — за разработчиками.
Также в нашей зоне ответственности:
Доступность. В нашем SLA для VPS она закреплена на уровне 99,98% времени в год, за исключением планового обслуживания. И столько же — для DBaaS.
Резервные копии. Для VPS мы автоматически создаём раз в несколько дней и храним на отдельных серверах в другом дата‑центре. S3 — с тройной репликацией: три копии объекта размещаются на независимых серверах в разных стойках. Пользователь может восстановить как сервер, так и отдельные файлы.
Сеть доставки контента. Сейчас у нас 200 точек присутствия CDN на пяти континентах, они обеспечивают глобальный охват — тяжёлый контент сайта или приложения загружается одинаково быстро в любой точке мира. Серверы кешируют файлы к себе, сокращая физическое расстояние до конечного пользователя.
Защита от DDoS‑атак. VPS защищены на сетевом и транспортном уровнях L3/L4;
Отказоустойчивость. Облачные базы данных размещены в ЦОД уровня Tier III. В Kubernetes три master‑ноды позволяют сохранить управление кластером при отказе одной из них.
Как видите, технических возможностей платформы достаточно, чтобы построить систему без многих очевидных точек отказа. Но нельзя забывать, что конечный результат зависит также и от архитектуры клиента. Например, можно иметь три master‑ноды Kubernetes — и при этом запустить критичное приложение в одном экземпляре. Или хранить данные в надёжной облачной базе, но написать приложение, которое прекращает работу при коротком сетевом сбое. Или использовать автоматические резервные копии, но не проверить процедуру восстановления до реального инцидента.
Так что провайдер отвечает за заявленную им доступность и работу собственных инфраструктурных сервисов, а команда проекта — за правильное использование этих возможностей. Пользователь должен сам решить, насколько критично его приложение, какие показатели времени восстановления нужны, сколько копий данных и какую стоимость дополнительной отказоустойчивости бизнес готов оплачивать.
Заключение. Облако — это конструктор, а не готовое здание
Самая важная особенность облачной инфраструктуры в том, что проект — это живая система, которая открыта к изменениям. По этой причине мы не даём пользователям универсальных советов в духе «подключите пять сервисов — и получите отказоустойчивую инфраструктуру». Требования невозможно стандартизировать. Если сегодня бизнесу достаточно одного VPS, это ещё не значит, что завтра ему не придётся переезжать в DBaaS, из‑за того что база данных стала слишком важной и её не стоит оставлять рядом с приложением. Вырос объём файлов? Возможно, пора переходить на S3. Увеличилась аудитория? Стоит задуматься о подключении CDN. Кому‑то станет нужен Kubernetes, потому что в приложении появились контейнеры и выросло число экземпляров, а кому‑то Kubernetes вообще никогда не потребуется.
В этом и заключается логика нашего облачного конструктора: начать с маленького «домика» — минимально необходимой инфраструктуры, а новые «этажи»‑компоненты добавлять уже по мере усложнения требований, под бизнес‑задачи или технические изменения.