Первую версию веб-приложения легко представить слишком сложной. Кажется, что современному проекту сразу нужны несколько облачных серверов, отдельная база данных, Redis, балансировщик нагрузки, контейнеры, объектное хранилище и резервный кластер. На практике молодой сервис с первыми пользователями нередко прекрасно работает на одной виртуальной машине. Главная задача на старте состоит не в том, чтобы построить инфраструктуру крупного интернет-сервиса заранее, а в том, чтобы выбрать облачный сервер, который соответствует сегодняшней нагрузке и не мешает проекту расти завтра.
Веб-приложение отличается от обычного сайта тем, что сервер обычно выполняет заметно больше работы. Пользователь не просто открывает готовую страницу. Он входит в аккаунт, сохраняет данные, загружает файлы, выполняет поиск, оформляет заказ, получает персональный результат или взаимодействует с другими пользователями. За интерфейсом работают backend, база данных, фоновые процессы и иногда дополнительные сервисы.
Поэтому вопрос какой облачный сервер выбрать для веб-приложения нельзя свести к размеру сайта на диске или количеству посетителей в месяц. Два проекта с одинаковой аудиторией способны создавать совершенно разную нагрузку. Сервис заметок выполняет относительно простые операции, а приложение для обработки изображений может нагружать процессор каждым запросом. Каталог читает данные из базы, а система аналитики постоянно записывает и пересчитывает большие массивы информации.
Преимущество облака здесь заключается в гибкости. Проект можно начать с небольшой конфигурации, посмотреть реальные показатели CPU, RAM, диска и базы, а затем увеличивать именно тот ресурс, которого стало не хватать. Но эта гибкость приносит пользу только тогда, когда архитектура приложения не превращена в набор зависимостей, которые невозможно разделить без полной переделки проекта.
С какой инфраструктуры начать веб-приложение
Для небольшого проекта наиболее рациональной архитектурой часто остаётся одна виртуальная машина. На ней могут одновременно работать веб-сервер, backend, база данных, фоновые процессы и кеш. Это не выглядит впечатляюще на архитектурной схеме, зато такую систему проще развернуть, обслуживать и восстанавливать.
Один сервер особенно удобен для MVP, внутреннего корпоративного приложения, небольшого личного сервиса или продукта, аудитория которого пока неизвестна. Вместо оплаты пяти облачных компонентов команда получает одну понятную точку управления и быстрее выводит продукт в работу.
У такой схемы есть очевидный недостаток: сервер становится единой точкой отказа. Если виртуальная машина перестала работать, одновременно недоступны приложение и база данных. Но на раннем этапе этот риск иногда экономически оправдан. Создавать дорогостоящую отказоустойчивую инфраструктуру для приложения с двадцатью пользователями может быть менее разумно, чем обеспечить хорошие резервные копии и понятное восстановление.
Frontend не всегда нужно размещать рядом с backend
Современное веб-приложение может состоять из нескольких довольно независимых частей. Frontend на React, Vue или другой технологии после сборки нередко представляет собой набор статических файлов. Их необязательно отдавать с того же сервера, где работает backend.
Статическую часть можно разместить на специализированной платформе, CDN или объектном хранилище с веб-доступом, а облачный сервер оставить только для API и бизнес-логики. Такая архитектура уменьшает нагрузку на основную виртуальную машину и позволяет независимо обновлять интерфейс.
Но разделять frontend и backend только ради модной схемы тоже необязательно. Если небольшое приложение целиком работает на одном сервере и никаких проблем с производительностью нет, дополнительная инфраструктура создаёт больше точек настройки, чем реальной пользы.
Для коммерческого проекта важнее возможность разделения в будущем. Код и конфигурация не должны быть устроены так, чтобы frontend, backend и база навсегда зависели от одного конкретного сервера.
Docker полезен, но не делает сервер быстрее сам по себе
Контейнеры хорошо подходят для веб-приложений, потому что позволяют описать окружение проекта вместе с его зависимостями. Разработчик может запускать одинаковую версию приложения локально, на тестовом сервере и в production.
Это упрощает перенос между облачными площадками и автоматизацию развёртывания. Но Docker не является обязательным условием хорошей инфраструктуры.
Если небольшое приложение нормально работает через обычный веб-сервер и systemd, добавление контейнеров не превращает его в более производительный сервис. Docker решает прежде всего вопросы упаковки, изоляции и воспроизводимости окружения.
Особенно полезным он становится, когда у проекта несколько компонентов. Backend, worker, Redis и другие службы можно разделить на контейнеры и запускать в предсказуемой конфигурации.
При этом не стоит путать Docker с Kubernetes. Для запуска нескольких контейнеров на одном облачном сервере полноценный Kubernetes обычно избыточен. Оркестрация начинает оправдываться, когда инфраструктура действительно состоит из множества экземпляров приложений и требует автоматического управления ими.
Базу данных сначала можно оставить на той же машине
Практически любому веб-приложению нужно где-то хранить пользователей, настройки, заказы, сообщения или другой уникальный контент. На старте MySQL, PostgreSQL или другая СУБД вполне может работать на том же облачном сервере, что и приложение.
Такая схема экономит деньги и не создаёт лишнего сетевого взаимодействия между компонентами. Но процессор и RAM становятся общими. Если база начинает активно использовать память или выполнять тяжёлые запросы, backend получает меньше ресурсов.
Поэтому перенос базы на отдельный сервер обычно должен происходить не потому, что так принято в больших проектах, а после появления практической причины.
Например, СУБД постоянно занимает большую часть RAM, её нагрузка мешает приложению, требуется независимое масштабирование или проекту нужна управляемая база данных с автоматическим резервированием.
При разделении компонентов важно соединять сервер приложения и базу через приватную сеть облака, а не публиковать порт СУБД в открытом интернете без необходимости.
Как подобрать CPU, RAM и диск под веб-приложение
Универсальной таблицы ресурсов для веб-приложений не существует. Язык программирования тоже не даёт готового ответа. Небольшое приложение на Java может потреблять меньше ресурсов, чем плохо оптимизированный проект на PHP, а аккуратный Python backend способен спокойно обслуживать тысячи простых запросов.
Поэтому стартовую конфигурацию лучше рассматривать как гипотезу. Вы выбираете разумный объём ресурсов, запускаете проект и затем смотрите метрики.
Для небольшого приложения обычно нет необходимости сразу покупать большое количество vCPU. Гораздо полезнее понять, что происходит при настоящей работе пользователей. Если процессор почти всегда свободен, увеличение числа ядер ничего не даст. Если загрузка стабильно держится около предела и растёт очередь запросов, вычислительные ресурсы уже становятся реальным ограничением.
Оперативная память часто становится первым ограничением
На одной виртуальной машине память одновременно используют операционная система, backend, база данных, кеш, веб-сервер, контейнеры и фоновые процессы.
Когда RAM заканчивается, сервер может начать активно использовать swap или завершать процессы. Для пользователя это проявляется как медленная работа, ошибки и периодическая недоступность приложения.
Особенно легко недооценить базу данных. СУБД использует память для кеширования часто запрашиваемых данных, поэтому дополнительная RAM иногда ускоряет приложение заметнее, чем новые процессорные ядра.
Но и здесь не нужно покупать огромный запас заранее. Если сервер использует четыре гигабайта из шестнадцати, оплачивать оставшиеся двенадцать только ради возможного будущего роста бессмысленно.
Одно из преимуществ облачного сервера как раз состоит в том, что конфигурацию можно увеличивать после запуска, когда появляются реальные данные.
Медленная база не лечится большим количеством vCPU
Пользователь нажал кнопку и ждёт три секунды. Самый очевидный вывод — сервер слабый. Но задержку мог создать совершенно не процессор.
Backend отправил запрос в базу, а та перебирает огромную таблицу без подходящего индекса. В такой ситуации переход с четырёх vCPU на восемь может почти ничего не изменить.
Похожая проблема возникает при десятках лишних запросов к базе на одну страницу, медленных обращениях к сторонним API или блокирующих операциях внутри приложения.
Перед увеличением сервера полезно определить, где именно тратится время. Метрики CPU и RAM, slow query log, профилирование приложения и время выполнения отдельных операций дают гораздо больше информации, чем субъективное приложение тормозит.
Облако упрощает покупку дополнительных ресурсов, но не отменяет оптимизацию кода.
NVMe полезен там, где приложение действительно работает с диском
Для базы данных и проектов с большим количеством операций чтения и записи производительность диска может быть критичной. В таких сценариях быстрый SSD или NVMe имеет реальную ценность.
Но если приложение большую часть времени выполняет вычисления в памяти, а диск используется только для операционной системы и журналов, покупка самого дорогого класса хранения может почти не повлиять на скорость.
Отдельная история — пользовательские файлы. Фотографии, видео, документы и другие загрузки не всегда стоит хранить на локальном диске виртуальной машины.
Пока проект маленький, это удобно. Пользователь загрузил изображение, backend сохранил его в папку, и задача решена. Проблема появляется позже, когда приложение запускается на двух серверах.
Файл, сохранённый на первой виртуальной машине, отсутствует на второй. Балансировщик отправляет следующий запрос на другой сервер, и приложение уже не видит данные.
Поэтому проекты, которые потенциально будут масштабироваться горизонтально, часто выносят пользовательские файлы в объектное хранилище или отдельный файловый сервис. Серверы приложения тогда становятся взаимозаменяемыми.
Фоновые задачи не должны задерживать пользователя
Некоторые операции веб-приложения выполняются долго: генерация отчёта, отправка большой рассылки, обработка изображения, импорт каталога или создание архива.
Если backend пытается выполнить всю работу непосредственно во время HTTP-запроса, пользователь вынужден ждать результата, а сервер держит соединение открытым.
По мере роста проекта такие операции обычно переносят в очередь. Приложение принимает запрос, создаёт задачу и быстро отвечает пользователю. Отдельный worker выполняет работу в фоне.
На старте worker может находиться на том же облачном сервере. Позднее его можно вынести на отдельную машину и масштабировать независимо.
Такая архитектура часто полезнее, чем простое увеличение мощности единственного backend-сервера.
Как подготовить приложение к росту без дорогой инфраструктуры заранее
Рост веб-приложения редко происходит так, как прогнозировалось до запуска. Иногда проект с ожидаемыми тысячами пользователей остаётся небольшим. Иногда один удачный рекламный канал приводит аудиторию значительно быстрее плана.
Поэтому правильная облачная архитектура должна позволять усложнять систему постепенно.
Первый этап может состоять из одной виртуальной машины и резервных копий. Затем база данных переезжает отдельно. После этого пользовательские файлы отправляются в объектное хранилище. Когда одного экземпляра приложения перестаёт хватать, появляется второй сервер и балансировщик.
Так инфраструктурные расходы растут вместе с настоящей потребностью бизнеса.
Вертикальное масштабирование проще горизонтального
Если серверу стало мало ресурсов, самый простой вариант — увеличить его конфигурацию. Добавить vCPU или RAM намного легче, чем запускать несколько экземпляров приложения.
Такое увеличение называют вертикальным масштабированием.
Для большинства молодых проектов это нормальный путь. Одна более мощная виртуальная машина позволяет довольно долго откладывать архитектурное усложнение.
Но у вертикального масштабирования есть предел. Нельзя бесконечно увеличивать один сервер, а его отказ всё равно остановит приложение.
Следующий этап — горизонтальное масштабирование. Вместо одного большого сервера запускаются несколько экземпляров приложения, а запросы распределяются между ними.
Именно здесь становится важна подготовка самого проекта.
Второй сервер бесполезен, если приложение не умеет работать в нескольких экземплярах
Представим, что создана копия backend и перед ней установлен балансировщик нагрузки. На схеме теперь два сервера, но это ещё не означает, что система действительно масштабируется.
Если пользовательская сессия хранится только в памяти первого сервера, следующий запрос на второй может неожиданно разлогинить человека. Если загруженные файлы лежат на локальном диске, второй экземпляр их не увидит. Если фоновая задача запускается каждым сервером независимо, она может выполниться два раза.
Поэтому горизонтальное масштабирование требует отделять общее состояние от конкретной виртуальной машины.
Сессии можно хранить в общей базе или Redis, файлы вынести во внешнее хранилище, а фоновые задания проводить через очередь. Тогда несколько экземпляров приложения действительно становятся взаимозаменяемыми.
Делать всё это в первый день необязательно. Но полезно не строить проект так, чтобы такое разделение в будущем потребовало полностью переписать систему.
Балансировщик нужен после появления нескольких серверов, а не заранее
Иногда облачный Load Balancer добавляют в инфраструктуру ещё до того, как появляется второй backend. Технически это возможно, но коммерческого смысла обычно мало.
Балансировщик раскрывает ценность тогда, когда есть несколько узлов, между которыми нужно распределять запросы, проверять их состояние и автоматически исключать недоступные экземпляры.
Для одного небольшого сервера он чаще становится ещё одной оплачиваемой услугой и дополнительной точкой настройки.
Когда проект действительно вырастет до нескольких экземпляров, балансировщик позволит распределять HTTP и HTTPS трафик, выполнять health checks и направлять запросы только на работающие серверы.
Это уже следующий уровень инфраструктуры, а не обязательная часть любого облачного приложения.
Staging экономит больше денег, чем кажется
Рабочий сервер не лучшее место для проверки новой версии приложения. Обновление зависимостей, миграция базы или изменение конфигурации могут пройти иначе, чем на компьютере разработчика.
Поэтому даже небольшому коммерческому проекту полезно иметь отдельное тестовое окружение.
В облаке его необязательно держать включённым круглосуточно. Виртуальную машину можно создавать перед тестированием новой версии и удалять после завершения работ.
Если инфраструктура описана через Docker Compose, Terraform или другие воспроизводимые конфигурации, такой процесс становится значительно проще.
Staging особенно полезен перед изменениями базы данных. Ошибка миграции production-базы способна остановить приложение значительно дольше, чем проблема в интерфейсе.
Резервная копия кода обычно менее важна, чем backup данных
Код приложения должен находиться в системе контроля версий и в большинстве случаев может быть заново развёрнут на чистом сервере. Настоящую ценность представляют данные, которые нельзя восстановить из репозитория.
Это база пользователей, заказы, сообщения, настройки, загруженные документы и другие результаты работы сервиса.
Поэтому резервное копирование нужно проектировать вокруг уникальных данных.
Снимок виртуальной машины удобен для быстрого возврата всего окружения, но он не всегда является лучшим способом резервирования активно работающей базы данных. Для СУБД стоит использовать предусмотренные для неё механизмы backup и проверять возможность восстановления.
Критичные резервные копии желательно хранить независимо от основного сервера. Если единственная копия находится на том же диске или удаляется вместе с облачным проектом, её практическая ценность невелика.
Мониторинг нужен раньше, чем второй сервер
Покупать ресурсы без метрик означает лечить инфраструктуру наугад. Даже небольшой production-проект стоит контролировать хотя бы по нескольким показателям.
Нужно видеть загрузку CPU, использование RAM и диска, свободное место, время ответа приложения и количество ошибок. Для базы полезны метрики соединений и медленных запросов.
Отдельный внешний мониторинг доступности сообщает, что приложение перестало отвечать, даже если сам сервер считает себя работающим.
Логи тоже лучше организовать до первой серьёзной аварии. Когда пользователь сообщает, что вчера вечером что-то не работало, отсутствие журналов превращает поиск причины в гадание.
Эти инструменты стоят дешевле преждевременного увеличения инфраструктуры и позволяют понять, что именно нужно улучшать.
Облачный счёт должен контролироваться так же внимательно, как нагрузка
У облачной модели есть особенность: создать ресурс намного легче, чем потом вспомнить о нём. Тестовый сервер, старый диск, снимок, резервный IP и забытое хранилище продолжают существовать после завершения эксперимента.
Поэтому для веб-приложения полезно регулярно проверять не только технические метрики, но и структуру расходов.
Особенно внимательно стоит смотреть на внешний трафик, объём дисков, резервные копии и дополнительные управляемые сервисы. Небольшая виртуальная машина может стоить недорого, а итоговый счёт формироваться совсем другими компонентами.
При росте проекта удобно считать инфраструктурные расходы относительно бизнеса. Например, стоимость на одного активного пользователя, один заказ или тысячу запросов. Тогда становится видно, увеличиваются ли расходы вместе с полезной нагрузкой или инфраструктура просто постепенно обрастает лишними ресурсами.
Выбирать облачный сервер для веб-приложения лучше с самой простой конфигурации, которая уверенно выполняет текущую работу. Не нужно заранее покупать архитектуру на миллион пользователей, если первые сто ещё не пришли.
Но простая инфраструктура не должна быть тупиковой. Код приложения желательно хранить независимо от сервера, пользовательские данные регулярно резервировать, конфигурацию документировать, а нагрузку измерять.
Тогда путь роста становится естественным. Сначала одна виртуальная машина, затем больше CPU и RAM, потом отдельная база или хранилище, при необходимости несколько экземпляров backend и балансировщик. Каждый новый компонент появляется не потому, что так выглядит современное облако, а потому, что проект уже способен извлечь из него пользу.
Именно такая модель обычно оказывается наиболее выгодной. Бизнес не переплачивает за инфраструктуру в начале, а разработчики сохраняют возможность масштабировать веб-приложение тогда, когда реальные пользователи и реальные метрики действительно этого потребуют.
