Облачный сервер: чем отличается от VPS и когда выбирают облако
Облачный сервер часто выглядит как привычный VPS: вы выбираете процессор, память и диск, получаете адрес и заходите по SSH. Разница становится заметной, когда нужно быстро добавить серверы, заменить сломавшийся экземпляр или подключить отдельное хранилище. Эти возможности стоит оценить перед переездом.
Настройка облачных серверов затрагивает сеть, права доступа и хранение данных. На платформе с отдельными сервисами это может потребовать больше работы, чем на привычном VPS. При этом единственная машина остаётся точкой отказа: если она недоступна, приложение тоже перестанет отвечать.
Чем облачный сервер отличается от VPS?
Облачный сервер обычно работает в составе платформы с программным управлением машинами, хранилищами и сетями. С её помощью проще создавать ресурсы и менять их количество вслед за нагрузкой. У VPS тоже бывают API (интерфейс программного управления) и почасовая оплата, поэтому различия нужно искать в условиях конкретных услуг.
Что скрывается за названиями VPS и облако
VPS называют виртуальную машину со своей операционной системой и назначенными ей ресурсами физического сервера. В облаке такую машину часто называют инстансом. Обе услуги могут использовать одну технологию виртуализации.
Облачная платформа объединяет вычисления, хранение и сеть под общим управлением. Пользователь сам запрашивает ресурсы и освобождает их, когда они больше не нужны. В определении NIST к признакам облака относятся самообслуживание по требованию, доступ по сети, общий пул ресурсов, быстрая эластичность и учёт потребления. Эластичность здесь означает возможность увеличивать и уменьшать выделенные ресурсы вслед за нагрузкой.
На практике граница между услугами размыта. Например, DigitalOcean предоставляет для своих виртуальных машин API и группы автоматического масштабирования. Полезно узнать, какие действия доступны через API – только перезагрузка или ещё и создание дисков, настройка сети и замена машин.
При редкой смене настроек автоматизация может остаться невостребованной, и настройка облачных серверов тогда мало отличается от работы с обычным VPS. Если команда ежедневно создаёт тестовые окружения, API избавляет её от повторения действий в панели.
Как настроить облачный сервер: образы, диски и доступы
Через API программа отправляет команды платформе: создать машину из образа, подключить диск, назначить адрес. Образ содержит подготовленную систему, а сценарий запуска устанавливает приложение и его зависимости. Образ и сценарий запуска делают настройку облачных серверов повторяемой. Пароли и другие секреты нужно хранить отдельно от общего образа и выдавать приложению с ограниченными правами доступа.
Доступом к ресурсам платформы управляет система IAM. Она задаёт права сотрудников и программ: например, скрипту резервного копирования незачем удалять рабочие серверы. Сами ресурсы обычно объединены в проекты, чтобы командам было проще ими управлять.
Перед выбором диска нужно выяснить, что останется после удаления машины. Локальный диск связан с физическим узлом, а подключаемый сетевой том может существовать отдельно от инстанса. Сохранится ли том, зависит в том числе от настроек удаления. Например, в облаке Amazon EC2 параметр DeleteOnTermination определяет, удалится ли сетевой том EBS вместе с машиной.
Для файлов пользователей часто подходит объектное хранилище. Приложение обращается к нему по API, а не как к обычному диску. Базу данных можно разместить на подходящем диске или поручить её обслуживание провайдеру, выбрав отдельный сервис БД.
Когда быстрое масштабирование действительно работает
Увеличение памяти и числа процессоров одной машины называют вертикальным масштабированием. Смена тарифа может требовать остановки, поэтому порядок изменения ресурсов лучше проверить заранее.
При горизонтальном масштабировании появляются дополнительные экземпляры приложения. Балансировщик распределяет между ними запросы пользователей. Любому экземпляру нужен доступ к общим данным: сведениям о входе пользователя, файлам и заказам. Если корзина магазина хранится только в памяти одной машины, второй сервер её не увидит.
Когда эластичность облака оправдывает сложность?
Эластичность полезна при заметных колебаниях нагрузки, когда дополнительные экземпляры приложения успевают запускаться и принимать работу до перегрузки. После спада лишние ресурсы можно освобождать и сокращать расходы. Если приложение нельзя разделить между машинами или пик заканчивается раньше их запуска, автоматическое масштабирование даст мало пользы.
После создания машины ей ещё нужны загрузка системы, запуск приложения и иногда заполнение кеша часто используемыми данными. В AWS настройка instance warmup задаёт время, в течение которого метрики новой машины не включаются в общие показатели для масштабирования. Готовность принимать запросы проверяется отдельно. Для этого балансировщику нужен health-check, проверка работоспособности приложения.
Метрика для масштабирования должна отражать нехватку мощности. Обработчикам фоновых заданий подходит число ожидающих заданий на один экземпляр, а вычислительной задаче может подойти загрузка процессора. Установка облачных серверов из готового образа ускоряет запуск, но не гарантирует его, поскольку даже с готовым образом старт может остановиться из-за квоты аккаунта или нехватки ресурсов в выбранной зоне. Предел числа машин ограничивает расходы, а заранее запущенный резерв помогает пережить короткий всплеск.
Почему одна машина всё ещё может отказать
Во время перезапуска после сбоя сервис может быть недоступен. Чтобы работа продолжалась при потере машины, запросы должны принимать другие экземпляры. Для защиты от сбоя площадки их размещают в разных зонах доступности. Зона объединяет один или несколько дата-центров, а независимость питания и сети нужно уточнять у провайдера.
Пример для веб-приложения: балансировщик принимает запросы и отправляет их на две копии приложения в разных зонах. У приложения общая БД: основной экземпляр в одной зоне, резервный в другой. Файлы пользователей находятся в объектном хранилище с копиями в нескольких зонах. Балансировщик тоже должен переживать отказ зоны, а исправная зона должна выдерживать всю нагрузку.
При выборе хранилища также нужно учитывать зоны, так как сетевой том может быть доступен лишь в одной из них. Для переноса работы БД в другую зону нужны репликация, то есть копирование изменений на резервный экземпляр, и переключение при сбое. Например, в Amazon RDS для этого предназначены варианты Multi-AZ. Резервные копии нужны и при наличии реплики, ведь ошибочное удаление данных может повториться на резервном экземпляре.
SLA, соглашение об уровне обслуживания, задаёт обязательства провайдера, в том числе по доступности ресурсов. Заявленный процент доступности инстанса нельзя автоматически переносить на весь сайт, поскольку ему ещё нужны служба доменных имён (DNS), сеть и БД. У Amazon EC2 обязательства для одного инстанса и размещения в нескольких зонах различаются. В условиях услуги проверьте компенсацию и обязанности вашей команды.
Как сравнить скорость и проверить восстановление
Даже с одинаковым числом виртуальных процессоров (vCPU) и объёмом памяти серверы могут работать с разной скоростью. На скорость влияют модель физического процессора, доля его времени, доступная виртуальной машине, диск и расстояние до клиентов. Для сравнения нужны одна версия приложения, одинаковые данные и запросы. Генератор нагрузки должен сам справляться с потоком запросов.
Сайт стоит оценивать по числу запросов в секунду, доле ошибок и времени ответа. Медиана p50 показывает время, в которое укладывается примерно половина ответов. В пределах p95 и p99 укладываются 95% и 99% запросов соответственно. Результаты при обычной и пиковой нагрузке стоит сопоставить с загрузкой процессора, диска и БД.
Короткий тест может пройти в режиме временного ускорения, burst. На некоторых тарифах оно доступно за счёт накопленного запаса, так называемых кредитов. После их расходования скорость может вернуться к базовому уровню. Диск ограничен и числом операций в секунду (IOPS), и объёмом данных в секунду. При крупных операциях лимит объёма данных может быть достигнут раньше лимита IOPS, пример есть в документации EBS. Если тариф допускает временное ускорение, тест должен продолжаться и после его окончания.
Дальше проверьте, сохраняются ли данные при замене машины. На тестовой копии сервиса запишите контрольные данные в БД и хранилище файлов. Проверка включает три отдельных действия: перезагрузку ОС, остановку с запуском и замену машины новой из образа. После каждого действия проверьте данные, адреса и доступность приложения. В EC2 локальное хранилище instance store переживает перезагрузку, но данные исчезают при остановке или замене машины.
Для проверки отказоустойчивости остановите одну тестовую копию приложения под нагрузкой и проверьте, принимает ли запросы вторая. В отчёте укажите время восстановления, ошибки клиентов и результат проверки данных. Потеря целой зоны требует отдельного испытания.
Из чего складывается счёт
Почасовая оплата удобна для временных задач. За работающую весь месяц машину начисляется полная месячная стоимость. К её цене добавляются диски и другие сервисы.
Месячный расчёт включает:
Виртуальные машины: часы каждого экземпляра × ставку, включая резерв
Диски и копии: объём, дополнительные IOPS, снимки и резервные копии
Сеть: исходящий трафик, обмен между зонами, платные адреса
Сервисы платформы: балансировщик, БД, хранение журналов и запросы к ним
Работа команды: миграция, поддержка, обновления и восстановление
Для иллюстрации возьмём условную ставку 10 ₽ в час. Одна машина за 30 дней, или 720 часов, стоит 7200 ₽. Если вторая нужна по четыре часа в течение 20 дней, она добавит 800 ₽, и общий расход на вычисления составит 8000 ₽. Два постоянно работающих экземпляра за тот же период обойдутся в 14 400 ₽. Ставка условная, а диски, трафик и остальные услуги в расчёт ещё не включены.
После остановки машины часть расходов сохраняется: например, в EC2 вычисления уже не оплачиваются, а за сохранённые тома EBS счёт продолжает идти. Условия для адресов, снимков и других ресурсов зависят от услуги. Ограничения на число ресурсов и автоматическое удаление ненужных нужно настроить отдельно.
Какие задачи лучше оставить на фиксированном VPS?
1. Небольшой сайт со стабильной посещаемостью, которому хватает выбранного тарифа и для которого допустим простой на время восстановления.
2. Бот или внутренний инструмент с предсказуемой нагрузкой и без требования непрерывной работы при отказе машины.
3. Приложение, которое пока не умеет работать на нескольких экземплярах, если ресурсов одного VPS достаточно.
Как выбрать вариант под свою задачу
Как создать свой облачный сервер, обычно понятно из документации провайдера. Сложнее другое: подготовка приложения к работе на нескольких машинах требует времени. Нужно наладить общее хранение файлов и данных о входе пользователей, настроить мониторинг. Затраты на эту работу тоже влияют на выбор.
В таблице сопоставлены типичный простой тариф VPS и облачная платформа. Возможности конкретного VPS могут быть шире.
Управление
Фиксированный VPS: панель; состав API зависит от услуги
Облачная платформа: создание связанных ресурсов через API
Рост нагрузки
Фиксированный VPS: более крупный тариф или дополнительные VPS
Облачная платформа: группы машин и правила масштабирования
Хранение
Фиксированный VPS: обычно диск в составе тарифа
Облачная платформа: отдельные тома, объектное хранилище, сервис БД
Сеть
Фиксированный VPS: адреса и доступные сетевые опции тарифа
Облачная платформа: частные сети, балансировщики, зоны
Доступность
Фиксированный VPS: восстановление по условиям услуги
Облачная платформа: несколько зон при подходящей архитектуре
Расходы
Фиксированный VPS: часто фиксированная сумма и доплаты
Облачная платформа: учёт нескольких ресурсов и их потребления
Магазину с редкими рекламными кампаниями может хватить временного увеличения VPS перед акцией. При частых, непредсказуемых колебаниях полезнее автоматическое добавление машин, если приложение к нему готово.
Облако бывает полезно и при постоянной нагрузке, если команде нужны управляемая БД и удобное восстановление. Несколько VPS с балансировкой также способны обслуживать распределённый сервис. И облачная платформа, и связка из нескольких VPS требуют обслуживания.
Как проверить идею до полного переезда
Пробный переезд, или пилот, проще начать с части приложения без уникальных локальных данных. Подойдёт обработчик изображений, который читает исходники и сохраняет результат в отдельном хранилище. Его проще пересоздать в облаке или вернуть на VPS. Перенос базы на первом шаге усложнит откат.
До запуска задайте пределы времени ответа, доли ошибок, срока восстановления и месячного бюджета. Сравнение p95 с заданным пределом покажет, годится ли конфигурация при рабочей нагрузке. Стоимость нужно рассчитать на полный месяц с пиками, даже если пилот длится неделю.
В плане пилота нужны регион и зоны, тарифы, типы дисков, версии ОС и приложения, образ и сценарий запуска. Журналы создания и удаления ресурсов, результаты запросов и выгрузка расходов помогут повторить проверку. Напишите коллеге инструкцию: как подключиться к облачному серверу, у кого запросить доступ и как восстановить компонент без вас.
В конце испытания верните приложение к прежнему размещению. Приложение должно сохранить нужные данные и продолжить работу. Обработчик может получить задание повторно после сбоя, поэтому повтор не должен создавать лишние записи или другие дубликаты результата. Эксперимент стоит остановить при потере данных, выходе за бюджет или постоянных ручных исправлениях. После пилота удалите ненужные диски, адреса и копии, за которые продолжаются начисления.
После пробного запуска сравните выигрыш со стоимостью переезда и обслуживания. Облако окупается, когда команда пользуется им как платформой: создаёт ресурсы через API, держит приложение в нескольких зонах, отдаёт часть работы управляемым сервисам и умеет восстанавливаться по написанной процедуре. Одна виртуальная машина, купленная в облаке вместо VPS, остаётся одной машиной с той же точкой отказа и обычно даёт только более сложный счёт. Если облачный сервер пока не решает ни одной текущей задачи, работающий VPS можно оставить на месте, а к переезду вернуться, когда появится конкретная причина: рост нагрузки, требование по доступности или нехватка рук на ручные операции.


























