С обычным хостингом все более-менее привычно, есть тариф, несколько характеристик и понятный набор ограничений, с VPS тоже можно быстро освоиться: выбираем процессор, память, диск, операционную систему и получаем виртуальную машину.
Облачный сервер сначала выглядит почти так же. В конфигураторе снова есть vCPU, RAM и диск. Но стоит открыть дополнительные настройки, и рядом появляются типы дисков, подсети, публичные IP, снимки, образы, группы виртуальных машин, зоны доступности, балансировщики и десятки других пунктов.
Покупатель легко попадает в одну из двух крайностей. Либо выбирает облачный сервер как обычный VPS и игнорирует возможности платформы, либо начинает подключать все подряд только потому, что это называется «облачной инфраструктурой».
Оба подхода могут привести к лишним расходам.
Если облако уже выбрано как модель размещения, начинать стоит с самого сайта и его архитектуры.
Сначала нарисуйте не сервер, а свой проект
Для небольшого сайта схема может состоять всего из одной виртуальной машины. На ней работают веб-сервер, PHP или другое приложение и база данных. В этом случае облачный сервер действительно очень похож на VPS.
У более крупного проекта картина другая. Приложение находится на нескольких виртуальных машинах, база вынесена отдельно, пользовательские файлы лежат в объектном хранилище, перед серверами работает балансировщик, а внутренняя связь идет через приватную сеть.
Требования этих двух проектов невозможно описать одним «рекомендуемым тарифом».
Поэтому перед открытием конфигуратора полезно выписать компоненты: приложение, база, кэш, файлы, фоновые задачи, резервные копии. Отметьте, что должно быть доступно из интернета, а что должно оставаться внутри инфраструктуры.
После этого характеристики облака начинают выглядеть намного понятнее.
vCPU нельзя сравнивать только по количеству
Два облачных провайдера могут предлагать виртуальные машины с четырьмя vCPU, но это не гарантирует одинаковую производительность.
Виртуальный процессор является долей вычислительных ресурсов физической инфраструктуры. На результат влияют поколение CPU, частота, политика распределения ресурсов и конкретная платформа.
Поэтому «8 vCPU лучше 4 vCPU» справедливо только внутри достаточно сопоставимых условий.
Для сайта важнее понять характер нагрузки. PHP-приложение, база данных, обработка изображений и фоновый worker используют процессор по-разному. Если проект уже работает, посмотрите реальную загрузку существующего сервера. Если CPU большую часть времени свободен, удваивать количество виртуальных ядер при переезде в облако только ради запаса не обязательно.
Для нового проекта полезнее возможность быстро изменить конфигурацию, чем попытка заранее купить сервер на несколько лет вперед.
С оперативной памятью облако не отменяет обычную математику
RAM нужна операционной системе, приложению, базе, кэшу и служебным процессам точно так же, как на любом другом сервере.
Если на одной виртуальной машине находится весь стек, складывайте потребление всех компонентов и оставляйте запас на пики. Если база вынесена отдельно, память можно оценивать для каждой машины независимо.
Последний вариант часто удобнее при росте проекта. Веб-серверам можно добавить CPU, не увеличивая одновременно ресурсы базы. Базе можно дать больше памяти, не меняя конфигурацию приложения.
В этом и проявляется одно из практических преимуществ облачной архитектуры: масштабировать можно не весь «сервер сайта», а отдельный компонент.
Но разделять маленький проект на пять машин только ради этого смысла нет. Дополнительные узлы увеличивают сложность, количество точек настройки и итоговый счет.
С дисками начинается настоящая облачная специфика
У классического VPS диск часто воспринимается как часть сервера: выбрали 80 ГБ NVMe и получили машину.
В облаке хранилище может существовать как отдельный ресурс. Диск создается независимо, подключается к виртуальной машине, увеличивается или используется для создания снимков. Конкретная модель зависит от платформы.
Поэтому одной цифры в гигабайтах недостаточно.
Посмотрите на тип хранилища, производительность, ограничения IOPS и пропускной способности. Для небольшого сайта разница может быть несущественной. Для активно работающей базы дисковая подсистема способна стать одним из главных ограничителей.
Есть еще вопрос жизненного цикла. Что произойдет с диском после удаления виртуальной машины? Удалится он вместе с ней или продолжит существовать и тарифицироваться? Можно ли подключить его к другой машине? Как создаются снимки?
Эти детали полезно выяснить до первого аварийного восстановления, а не во время него.
Публичный IP нужен далеко не каждому серверу
Если в инфраструктуре одна виртуальная машина с сайтом, ей обычно нужен адрес, по которому приходит внешний трафик.
Когда машин становится несколько, публичный IP на каждой уже не обязателен.
База данных, Redis, внутренний API и служебные узлы могут находиться в приватной сети. Из интернета к ним вообще не должно быть прямого доступа. Снаружи запросы принимает балансировщик или фронтовый сервер, а дальше трафик идет внутри облачной сети.
Это одновременно упрощает безопасность и делает архитектуру понятнее.
При сравнении платформ стоит посмотреть, как создаются приватные сети и подсети, можно ли управлять маршрутами и правилами доступа, есть ли сетевой firewall. Если позже проект вырастет до нескольких серверов, хорошие сетевые инструменты окажутся гораздо важнее красивой панели первой виртуальной машины.
Зона доступности не является кнопкой отказоустойчивости
В облачных платформах часто встречаются регионы и зоны доступности. На первый взгляд кажется, что достаточно выбрать две зоны, и сайт автоматически станет неуязвимым для отказов.
На практике приложение должно быть подготовлено к такой схеме.
Если существует только одна виртуальная машина, она остается единственным экземпляром приложения. Если база находится в одном месте без репликации, распределение веб-серверов не решает проблему базы. Если пользовательские файлы лежат на локальном диске одного узла, второй сервер может их не увидеть.
Отказоустойчивость появляется из архитектуры: несколько экземпляров там, где они нужны, балансировка, резервирование данных, мониторинг и понятный сценарий восстановления.
Облачная платформа предоставляет строительные блоки. Она не собирает надежную систему автоматически.
Снапшот удобен, но резервная копия нужна отдельно
Снимок виртуального диска особенно полезен перед обновлением. Что-то пошло не так — можно восстановить прежнее состояние или создать новый диск.
Но снимок и полноценная стратегия резервного копирования решают не совсем одинаковые задачи.
Подумайте, от чего должна защищать копия. Ошибка приложения? Повреждение базы? Случайное удаление виртуальной машины? Компрометация учетной записи? Проблема всей площадки?
Чем важнее проект, тем меньше хочется, чтобы рабочие данные и единственный способ их восстановления зависели от одного и того же ресурса.
При выборе облака посмотрите, как создаются автоматические копии, сколько версий можно хранить, куда они помещаются и как выглядит восстановление. Хороший бэкап ценен не фактом существования, а возможностью реально вернуть сервис в рабочее состояние.
Автоматическое масштабирование имеет смысл не для любого сайта
Облако особенно привлекательно возможностью создавать несколько виртуальных машин и менять их количество в зависимости от нагрузки.
Но обычный WordPress нельзя превратить в горизонтально масштабируемый проект одной галочкой.
Если приложение хранит загруженные файлы на локальном диске, сессии привязаны к одной машине, а база находится внутри того же сервера, появление второй копии создает новые вопросы.
Чтобы горизонтальное масштабирование действительно работало, приложение должно быть к нему подготовлено. Состояние выносится туда, где оно доступно всем экземплярам, трафик распределяется балансировщиком, а новые машины создаются из воспроизводимого образа или конфигурации.
Для небольшого сайта вертикальное масштабирование часто проще. Увеличили CPU или RAM одной машины и продолжили работу.
Облако ценно тем, что позволяет перейти к более сложной схеме тогда, когда она действительно понадобится.
Оплата требует отдельного внимания
В классическом хостинге пользователь привыкает к одной сумме за тариф. В облаке итоговый расход может складываться из нескольких ресурсов.
Виртуальная машина, диски, снимки, публичные адреса, исходящий трафик, балансировщик и другие сервисы могут учитываться отдельно. Конкретная модель зависит от провайдера.
Поэтому сравнивать две платформы только по стоимости виртуальной машины некорректно.
Соберите минимальную архитектуру целиком и посмотрите, какие компоненты тарифицируются. Затем выясните, что происходит после остановки машины. Вычислительные ресурсы могут перестать использоваться, а диск и зарезервированный адрес продолжат существовать.
Для облака особенно полезны бюджеты и уведомления о расходах. Они позволяют заметить неожиданный рост до того, как он превратится в неприятный счет.
Это не недостаток облачной модели. Гибкая тарификация позволяет не держать постоянно ресурсы, которые нужны лишь иногда. Но за гибкостью приходится следить.
API может оказаться важнее панели
Первую виртуальную машину почти каждый создает через веб-интерфейс. Если серверов станет много, ручное управление быстро надоест.
Хорошая облачная платформа предоставляет API и инструменты командной строки. Инфраструктуру можно описывать кодом, создавать одинаковые окружения для разработки и production, автоматически запускать временные машины и удалять их после выполнения задачи.
Для одного сайта это может быть совершенно не нужно.
Но если облако выбирается именно ради масштабирования и автоматизации, отсутствие удобного API сильно уменьшает его ценность. Поэтому оценивать нужно не только интерфейс панели, который вы видите сегодня, но и способы управления инфраструктурой завтра.
Как сравнить двух облачных провайдеров без огромной таблицы
Я бы не начинала со списка из пятидесяти функций. Сначала проверила бы пять вещей.
- Вычисления. Подходят ли доступные типы виртуальных машин и можно ли быстро менять конфигурацию.
- Хранилище. Какие есть диски, как они масштабируются, какие ограничения производительности и как устроены снимки.
- Сеть. Есть ли приватные сети, firewall, публичные адреса и балансировка.
- Надежность. Какие инструменты доступны для резервирования, копирования и размещения в нескольких зонах.
- Управление. Насколько понятна тарификация, есть ли мониторинг, API и контроль расходов.
После этого уже имеет смысл смотреть дополнительные сервисы.
Если проекту не нужны Kubernetes, объектное хранилище, управляемые базы и очереди сообщений, их наличие не должно автоматически делать платформу победителем. Выбирайте облако под свою архитектуру, а не архитектуру под каталог облака.
Когда можно взять самый простой облачный сервер
Очень часто.
Если задача состоит в размещении одного сайта, можно начать с одной виртуальной машины, одного системного диска, публичного IP и резервного копирования. Настроить мониторинг, запустить проект и посмотреть реальную нагрузку.
Не нужно с первого дня строить несколько зон доступности, кластер базы и автоматическое масштабирование для сайта, который посещают несколько сотен человек.
Смысл облака как раз в том, что инфраструктуру можно развивать постепенно.
Сайт вырос — увеличили ресурсы. База стала мешать приложению — вынесли ее отдельно. Появилась необходимость в нескольких веб-серверах — добавили балансировщик. Стало много пользовательских файлов — рассмотрели отдельное хранилище.
Так каждый новый компонент появляется потому, что решает конкретную проблему.
Что проверить непосредственно перед созданием сервера
Выберите регион, близкий к основной аудитории и подходящий требованиям проекта. Посмотрите доступные типы виртуальных машин и возможность последующего увеличения ресурсов. Уточните характеристики диска и правила его тарификации.
Проверьте резервное копирование. Создайте правила firewall до публикации ненужных сервисов в интернете. Настройте мониторинг CPU, памяти, диска и сети.
Если платформа позволяет установить бюджет или уведомление о расходах, сделайте это сразу.
И сохраните инфраструктурные настройки так, чтобы сервер можно было восстановить без воспоминаний о том, какие команды выполнялись полгода назад.
Главная ошибка при выборе облачного сервера — пытаться купить «самое облачное облако». Для сайта важнее другое: достаточно ли ресурсов, можно ли безопасно хранить данные, удобно ли масштабироваться и понятно ли, за что начисляется плата.
Если эти вопросы закрыты, дополнительные возможности платформы останутся запасом на будущее. И это гораздо полезнее, чем оплачивать сложную инфраструктуру только потому, что она красиво выглядит на схеме.
