VPS и облачные провайдеры

01Четыре способа хостить приложение

Представьте хостинг как жильё. Shared-хостинг — это комната в общей квартире: дёшево и всё обслуживают за вас, но ресурсы вы делите с сотнями сайтов, не можете ставить своё ПО, а один шумный сосед тормозит всех. Подходит для простых PHP-сайтов. VPS — это своя квартира: виртуальная машина с гарантированными CPU, RAM и диском и полным root-доступом, где за всё внутри отвечаете вы. Управляемая платформа (PaaS) вроде Vercel, Render, Fly.io, Railway или Laravel Cloud — это сервисные апартаменты: вы пушите код, а она берёт на себя серверы, масштабирование и TLS — по более высокой цене за ресурс и с ограничениями платформы. Гипермасштабное облако (AWS, Google Cloud, Azure) — это целый город: виртуальные машины плюс управляемые базы данных, очереди, хранилище и сеть, очень гибко и очень сложно.

• Shared-хостинг: самый дешёвый, минимум контроля. Подходит для сайтов-визиток и небольших WordPress.
• VPS: полный контроль за небольшие деньги; безопасность, обновления и бэкапы — на вас.
• Управляемая платформа: быстрее всего выкатить, вы платите за удобство, контроль ограничен.
• Гипермасштабное облако: доступно всё, но стоимость и настройка требуют настоящей экспертизы.

02Выбор провайдера

Для VPS-хостинга популярны DigitalOcean (дроплеты, понятный интерфейс, хорошая документация, управляемые базы данных и объектное хранилище), Hetzner (очень сильное соотношение цены и производительности, дата-центры в Европе и США), Vultr, Linode (теперь Akamai) и OVHcloud. AWS Lightsail предлагает простые VPS-тарифы внутри AWS. Большие облака имеют смысл, когда нужны конкретные управляемые сервисы, сертификаты соответствия, много регионов или ваша компания уже там работает. При сравнении смотрите дальше месячной цены: расположение дата-центров, включённый трафик и цену сверх него, качество снапшотов и бэкапов, наличие облачного файрвола и частной сети, варианты управляемой БД и объектного хранилища, поддержку API и Terraform и то, как отвечает поддержка. Цены меняются, поэтому сравнивайте актуальные страницы с тарифами, а не старые статьи в блогах.

• Расположение: ближе к пользователям; учитывайте требования к хранению данных, например GDPR.
• Сеть: включённый трафик, цена исходящего трафика, IPv6, защита от DDoS.
• Дополнительно: облачный файрвол, частная сеть, снапшоты, бэкапы, объектное хранилище, управляемая БД.
• Эксплуатация: API, CLI, Terraform-провайдер, история статуса и качество поддержки.

03Размер и регион

Начинайте с малого и измеряйте; увеличить VPS позже легко, и большинство провайдеров позволяет масштабироваться вверх за минуты. Небольшой сайт с nginx и PHP или Node спокойно работает на 1–2 vCPU и 2 GB RAM. Если на той же машине ещё база данных, Redis и воркеры очередей, безопаснее начинать с 4 GB и больше. Обычно первым ограничением становится память, а не CPU. Тарифы с разделяемыми vCPU дешёвые и подходят большинству веб-приложений; тарифы с выделенными vCPU дают стабильную производительность для задач, нагружающих CPU. Выбирайте регион, ближайший к большинству пользователей, держите взаимодействующие серверы в одном регионе и помните, что CDN вроде Cloudflare может отдавать статику близко к пользователям где угодно. Несколько недель наблюдайте за нагрузкой, памятью и диском и меняйте размер на основе данных.

• На большинстве веб-серверов память заканчивается раньше CPU; закладывайте ресурсы на базу данных и воркеры.
• Диск SSD или NVMe; пользовательские загрузки и бэкапы храните в объектном хранилище, а не на огромном диске.
• Увеличить размер обычно легко, а вот уменьшить диск часто нельзя.

04Снапшоты, бэкапы и частная сеть

Снапшот — это полный образ диска сервера на определённый момент. Он идеален перед рискованными изменениями, потому что можно откатить всю машину. Бэкапы провайдера — это снапшоты по расписанию, обычно ежедневные или еженедельные, за небольшую доплату. Но и те, и другие живут у того же провайдера, а дисковый снапшот работающей базы данных может оказаться неконсистентным. Поэтому делайте и бэкапы на уровне приложения, например дамп базы данных, и копируйте их за пределы сервера, в идеале в объектное хранилище у другого провайдера или в другом регионе. Бэкап считается бэкапом только после того, как вы успешно из него восстановились. Частная сеть соединяет ваши серверы внутренней сетью, недоступной из интернета, так что сервер приложения может обращаться к базе данных, не открывая её публично.

• Снапшот перед обновлениями, миграциями и крупными изменениями конфигурации.
• Дампы базы данных плюс копии вне площадки; следуйте идее 3-2-1 (3 копии, 2 носителя, 1 вне площадки).
• Регулярно, по расписанию, проверяйте восстановление на свежем сервере.
• Используйте частную сеть для трафика базы данных и кэша между серверами.

05Держим расходы под контролем

Облачные счета растут незаметно. Обычные утечки — забытые серверы и тестовые окружения, старые снапшоты и неподключённые тома, завышенные инстансы, которые никто не уменьшил, неиспользуемые балансировщики и статические IP и прежде всего исходящий трафик (egress), который в больших облаках тарифицируется за гигабайт и может многократно превысить цену самого сервера. VPS-провайдер с щедрым включённым трафиком часто гораздо дешевле для сайтов с большим трафиком. Помогают простые привычки: настройте алерт по счёту, помечайте или называйте каждый ресурс по проекту, раз в месяц просматривайте счёт, удаляйте неиспользуемое и ставьте CDN перед статическими ресурсами. Объединение множества маленьких полупустых серверов в меньшее число правильно подобранных часто снижает и расходы, и трудозатраты на обслуживание одновременно.

• Алерты по счетам и бюджеты на каждом аккаунте.
• Ежемесячная уборка: старые снапшоты, тома, IP, тестовые серверы.
• Следите за ценой egress; кэшируйте статику на CDN.
• Берите reserved-инстансы или savings plans только под стабильные долгосрочные нагрузки.

06Первые 10 минут на новом сервере

Свежий публичный сервер начинают сканировать в течение нескольких минут, поэтому защитите его до того, как что-либо деплоить. Создайте сервер с добавленным SSH-ключом, войдите, обновите пакеты, создайте своего пользователя с sudo, во втором терминале убедитесь, что вход по ключу для него работает, и затем отключите вход по паролю и под root. Включите файрвол, разрешив только SSH, HTTP и HTTPS, и продублируйте это в облачном файрволе провайдера. Включите автоматические обновления безопасности, установите fail2ban, задайте часовой пояс и hostname, на маленьких инстансах добавьте swap-файл и сделайте первый снапшот чистой базы. Напоследок настройте мониторинг и алерт по диску. Команды для каждого шага разобраны в других уроках по Linux.

1ssh [email protected]                      # first login with your key
2apt update && apt full-upgrade -y
3adduser your_user && usermod -aG sudo your_user
4rsync -a --chown=your_user:your_user ~/.ssh /home/your_user/
5# New terminal: ssh [email protected] must work before continuing
6printf "PasswordAuthentication no\nPermitRootLogin no\n" > /etc/ssh/sshd_config.d/10-hardening.conf
7sshd -t && systemctl reload ssh
8ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
9apt install -y unattended-upgrades fail2ban
10dpkg-reconfigure -plow unattended-upgrades
11timedatectl set-timezone UTC && hostnamectl set-hostname web1

07Что такое vCPU на самом деле: гипервизоры, steal time и хранилище

VPS — это виртуальная машина на физическом хосте, общем с другими клиентами, под управлением гипервизора, например KVM. vCPU — обычно один аппаратный поток ядра хоста, который распределяется между многими гостевыми машинами. На тарифах с shared CPU провайдер рассчитывает, что не все заняты одновременно; когда соседи заняты, ваша VM ждёт, и это ожидание проявляется как steal time — значение st в top и vmstat. Стабильный steal выше нескольких процентов означает, что вы платите за CPU, которого не получаете, и это решает тариф с dedicated CPU или другой хост. Хранилище тоже различается: локальный NVMe быстрый и с низкой задержкой, но привязан к хосту, а сетевые блочные тома переживают отказы хоста и могут переноситься, но имеют более высокую задержку и лимиты IOPS в зависимости от размера тома. Понимание того, что у вас, объясняет результаты бенчмарков, которые иначе кажутся бессмысленными.

1top -bn1 | head -5            # look at 'st' in the %Cpu(s) line
2vmstat 1 10                   # last column 'st' = steal
3lscpu | grep -E 'Model name|Thread|Hypervisor'
4systemd-detect-virt           # kvm, xen, microsoft...
5# Quick disk benchmark (apt install fio), on a test file, not a live DB
6fio --name=randread --rw=randread --bs=4k --size=1G --runtime=30 \
7    --ioengine=libaio --direct=1 --filename=/var/tmp/fio.test

08Серверы как код: cloud-init и пересобираемые машины

Самый надёжный сервер — тот, который можно пересоздать за минуты. Почти все провайдеры поддерживают cloud-init: при создании VM вы передаёте документ user-data, и при первой загрузке он создаёт пользователей, добавляет SSH-ключи, устанавливает пакеты и выполняет команды. Это превращает первые десять минут харденинга в файл, который вы ревьюите и версионируете, так что каждый новый сервер стартует одинаково. Инструменты вроде Terraform или OpenTofu поднимаются уровнем выше и через API провайдера описывают сами серверы, файрволы, тома и DNS-записи, а инструменты конфигурации вроде Ansible управляют текущими изменениями внутри машины. Даже если вы никогда не автоматизируете всё полностью, наличие user-data и письменного runbook означает, что потерянный сервер — неудобство, а не кризис, потому что ничего важного не существует только в чьей-то памяти.

1#cloud-config
2users:
3  - name: your_user
4    groups: [sudo]
5    shell: /bin/bash
6    lock_passwd: true
7    ssh_authorized_keys:
8      - ssh-ed25519 AAAAC3...placeholder your_user@laptop
9ssh_pwauth: false
10disable_root: true
11package_update: true
12package_upgrade: true
13packages: [ufw, fail2ban, unattended-upgrades]
14runcmd:
15  - [ufw, allow, OpenSSH]
16  - [ufw, allow, 80/tcp]
17  - [ufw, allow, 443/tcp]
18  - [ufw, --force, enable]

09Доступность на небольшом бюджете: RPO, RTO и единые точки отказа

Два числа делают обсуждение доступности конкретным. RPO (recovery point objective) — сколько данных вы можете позволить себе потерять; это задаёт частоту бэкапов: ночные дампы означают потерю заказов вплоть до суток. RTO (recovery time objective) — сколько времени сервис может лежать; это задаёт, сколько всего должно быть автоматизировано. Один VPS — единая точка отказа, и это часто приемлемо, если RPO и RTO согласованы и проверены. Сначала идут дешёвые улучшения: более частые дампы или непрерывное архивирование binlog или WAL в объектное хранилище, зарезервированный или плавающий IP, который можно перенести на сервер-замену, умеренные DNS TTL и отрепетированное восстановление. Два сервера приложения за балансировщиком нагрузки помогают только тогда, когда база данных, сессии и загрузки уже не живут на одной машине.

• Согласуйте RPO и RTO с бизнесом до выбора архитектуры.
• Плавающий или зарезервированный IP позволяет заменить сервер, не дожидаясь DNS.
• Учения по восстановлению превращают записанный RTO в измеренный.

10Путь масштабирования от одного VPS

Масштабируйтесь поэтапно и только тогда, когда этого требуют измерения. Первый шаг — вертикальный: тариф побольше, что занимает минуты и ничего не меняет в приложении. Второй шаг — разделение: вынесите базу данных на собственный сервер или в управляемую базу данных в частной сети, чтобы приложение и данные перестали конкурировать за память, а загрузки перенесите в объектное хранилище. Третий шаг — горизонтальный: несколько одинаковых серверов приложения за балансировщиком нагрузки. Для этого нужны stateless-серверы приложения: сессии и кэш в Redis или базе данных, файлы в объектном хранилище, плановые задачи ровно на одной ноде и деплои, согласованно обновляющие все ноды. Четвёртый шаг — реплики для чтения, очереди для медленной работы и CDN для статики. Каждый шаг добавляет расходов и эксплуатационной работы, поэтому хорошо настроенный одиночный сервер часто тянет дальше, чем принято думать.

• Сначала вертикально, затем вынести базу данных, затем горизонтально.
• Горизонтальное масштабирование требует stateless-серверов приложения.
• Убедитесь, что cron и планировщики работают только на одной ноде.