Переезд из облака на выделенный сервер: чек-лист

MAATRIX

Счёт за облако в очередной раз вырос, а нагрузка на проект уже полгода не меняется — знакомая ситуация. Так называемый cloud repatriation, возврат с облака на собственную инфраструктуру, экономит ощутимые деньги при стабильной нагрузке, но требует явно заменить полдюжины вещей, которые раньше делались сами по себе. Ниже — рабочий чек-лист: что именно нужно поднять руками, прежде чем отключать managed-сервисы, и как понять, окупится ли это вообще.

Кому этот переезд подходит, а кому — нет

Сначала честно про ограничение, которое часто замалчивают в статьях про cloud repatriation. Выгода от собственного сервера строится на одном допущении: нагрузка предсказуема и относительно стабильна. Вы знаете, что в будний день у вас условно 200-400 одновременных пользователей, а не 50 или 5000 — цифра не скачет на порядок.

Если нагрузка действительно скачет — сезонный интернет-магазин с пиками на распродажах, стартап, который может завтра выстрелить в десять раз, продукт с вирусным трафиком — эластичность облака стоит своих денег. Вы платите премию за то, что при всплеске нагрузки не нужно среди ночи поднимать второй сервер руками. Заменить это на выделенном железе можно (запасные мощности, автоматизация через Ansible/Terraform, готовые к разворачиванию образы), но тогда сравнение идёт не «выделенный сервер против облака», а «выделенный сервер плюс своя автоматизация масштабирования против облака» — и экономика получается другой, часто менее выгодной.

Практическое правило: смотрите на график нагрузки за последние 3-6 месяцев. Если пиковая нагрузка отличается от средней не больше чем в 2-3 раза и вы примерно понимаете, откуда возьмётся рост — переезд обоснован. Если пики в 10-20 раз выше медианы и непредсказуемы по времени — сначала посчитайте, во сколько обойдётся резерв мощности на выделенном сервере под такие пики, и сравните именно эту цифру с облачным счётом, а не среднюю нагрузку.

База данных: managed-сервис становится вашей зоной ответственности

Managed СУБД (RDS-подобный сервис) незаметно закрывает три вещи: автоматические бэкапы с точкой восстановления, обновления минорных версий без даунтайма и failover при отказе. При переезде на свою PostgreSQL или MySQL все три задачи явно ложатся на вас.

Бэкапы. Недостаточно pg_dump раз в сутки по крону — нужна стратегия с точками восстановления (point-in-time recovery), которая покрывает время между полными копиями:

# Базовая копия
pg_basebackup -D /backup/base -Ft -z -P

# Непрерывная архивация WAL для PITR
# в postgresql.conf:
archive_mode = on
archive_command = 'test ! -f /backup/wal/%f && cp %p /backup/wal/%f'
wal_level = replica

Отдельно нужна репликация — хотя бы один реплика-сервер, чтобы не терять доступность при аппаратном отказе основного. Практическая настройка стриминговой репликации PostgreSQL разобрана в статье про репликацию PostgreSQL на VPS — процесс с pg_basebackup, primary_conninfo и проверкой лага репликации применим и к выделенному серверу.

Обновления версий СУБД без даунтайма облачный провайдер делал за вас в окно обслуживания. На своём сервере это ручная процедура: поднять реплику на новой версии, переключить трафик, откатить план, если что-то пошло не так. Заложите на это отдельный регламент и тестовый прогон на staging-копии перед боевым обновлением.

Отдельно — не путайте RAID и бэкап: зеркалирование дисков защищает от отказа диска, но не от случайного DROP TABLE или шифровальщика. Точка зрения разобрана в статье про миф о том, что RAID — это резервная копия, и она справедлива один в один для управляемой vs самостоятельной базы: managed-сервис в облаке обычно даёт и то и другое из коробки, а на своём сервере это два независимых пункта чек-листа.

Масштабирование и балансировка нагрузки без автоскейлинга

Облачный автоскейлинг решал задачу «добавить мощность, когда трафик растёт» без вашего участия. На выделенном сервере у вас по сути два пути.

Путь первый — запас по железу. Возьмите сервер с запасом 40-60% по CPU/RAM над реальным пиком, который вы увидели в метриках за последние месяцы. Это проще и часто дешевле, чем городить горизонтальную инфраструктуру, если пиковая нагрузка предсказуема (см. предыдущий раздел). Минус — резерв простаивает большую часть времени, и это тоже часть стоимости владения, просто она зашита в цену тарифа, а не выставляется отдельным счётом за автоскейлинг.

Путь второй — своя горизонтальная инфраструктура. Несколько серверов приложения за балансировщиком нагрузки. Здесь встаёт задача, которую в облаке закрывал managed load balancer: нужно поднять и поддерживать HAProxy или nginx самостоятельно.

Минимальная рабочая конфигурация HAProxy с проверкой здоровья бэкендов:

backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check
    server app3 10.0.0.13:8080 check

Выбор между HAProxy и nginx как балансировщиком — не тривиальный вопрос, у обоих есть свои сильные стороны по L4/L7-балансировке и по гибкости конфигурации; сравнение с конкретными сценариями — в статье HAProxy или nginx для балансировки. Отдельно учтите: сам балансировщик становится точкой отказа, если он один — понадобится либо резервный узел с keepalived и плавающим IP, либо DNS-балансировка на уровне двух точек входа.

Честно: горизонтальное масштабирование своими руками — это не «поставить nginx и забыть». Нужна общая сессия (Redis вместо sticky session на одном сервере), общая файловая часть или объектное хранилище вместо локального диска, и мониторинг за каждым узлом отдельно. Если приложение изначально писалось под один сервер с локальным состоянием, при переезде на несколько узлов часть архитектуры придётся переделывать — это стоит заложить в оценку трудозатрат заранее, а не выяснять постфактум.

Мониторинг, алерты и объектное хранилище без встроенных облачных сервисов

Встроенный мониторинг облака (метрики CPU/RAM/диска, алерты на пороги, дашборды из коробки) исчезает вместе с переездом. Замена — отдельный стек, который нужно поднять и поддерживать.

Практичный минимум — Prometheus для сбора метрик и Grafana для визуализации, с алертами через Alertmanager в Telegram или почту. Разворачивание пары в связке разобрано в статье про установку Grafana и Prometheus. Если нужен более лёгкий вариант без отдельной базы метрик — Netdata поднимается за несколько минут и сразу даёт живые графики по системе, но хуже подходит для долгого хранения истории и алертинга на сложных условиях; сравнение вариантов — в статье Netdata или Zabbix.

Отдельно — мониторинг доступности снаружи (не с самого сервера, а извне, чтобы видеть падение сети целиком): Uptime Kuma закрывает эту задачу за вечер настройки и не требует облачного SaaS для аптайм-мониторинга.

Объектное хранилище с автоматической межрегиональной репликацией (то, что в облаке работает по умолчанию у S3-подобных сервисов) на своей инфраструктуре тоже нужно строить осознанно. Рабочий вариант — MinIO как S3-совместимое хранилище, но без второго дата-центра репликация между регионами не появится сама, её нужно настраивать отдельно (bucket replication между двумя инсталляциями MinIO в разных локациях) или явно смириться с тем, что резервирование geo-уровня в первое время не покрыто. Базовая установка — в статье про установку MinIO на VPS.

И главное заблуждение, которое стоит развеять до переезда: «облако само делает бэкапы» в большинстве случаев означало снапшоты диска, а не консистентную резервную копию базы данных с проверкой восстановления — разбор мифа в статье облако само делает бэкапы. После переезда эта иллюзия пропадает вместе с облаком, и внезапно обнаруживается, что бэкапов на самом деле никогда толком не было — лучше выяснить это до миграции, а не после первого инцидента.

DDoS-защита: что теряется и чем закрывать

У крупных облачных провайдеров базовая защита от DDoS на уровне сети встроена и не обсуждается отдельно — трафик фильтруется до того, как долетит до вашего инстанса. На выделенном сервере этой защиты по умолчанию нет, и её нужно закрыть одним из двух способов.

Первый — специализированный провайдер защиты (обычно это прокси перед вашим сервером, который фильтрует трафик на уровне сети и L7 до того, как он дойдёт до вас). Второй — базовая самостоятельная защита на уровне сервера: iptables/nftables с ограничением скорости на новые соединения, fail2ban для повторяющихся паттернов, разумные таймауты в nginx. Это не остановит серьёзную волумную атаку, но снимает мелкий и средний шум, который иначе будет постоянно есть ресурсы сервера.

# Простое ограничение новых TCP-соединений в nftables
add rule inet filter input tcp dport 443 ct state new limit rate 50/second accept
add rule inet filter input tcp dport 443 ct state new drop

Разбор первых действий при реальной атаке и что вообще видно в графиках трафика во время неё — в статьях DDoS-атака: первые действия и защита от DDoS на выделенном сервере. Честно: если ваш проект — вероятная мишень (публичный сервис, конкурентная ниша, история атак), закладывайте бюджет на специализированную защиту сразу в расчёт окупаемости переезда, а не как опцию «подключим потом, если атакуют».

Как считать окупаемость переезда

Методика простая по формуле и неочевидная по содержанию статей расходов. Базовое сравнение:

Экономия/мес = (Счёт за облако) − (Аренда/владение сервером + трудозатраты на поддержку)

Проблема в том, что «трудозатраты на поддержку» почти всегда недооценивают. В эту статью входят пункты выше — не разово, а на регулярной основе:

Практическая методика расчёта ROI с конкретными шагами (как посчитать точку окупаемости в месяцах с учётом разовых затрат на перенос и регулярных трудозатрат) разобрана в статье как считать ROI переезда на свой сервер — там же ориентировочная вилка по срокам окупаемости для типичных нагрузок. Не берите оттуда цифры как гарантированные — это ориентир, у вас будет своя стоимость трудозатрат и свой облачный счёт для сравнения.

Отдельно посчитайте разовые затраты на перенос: миграция базы данных без длительного простоя, перенос DNS, тестовый период с параллельной работой обеих инфраструктур. Опыт «сколько реально стоит переезд, если считать по часам, а не только по счетам за инфраструктуру» — в статье реальная стоимость переезда за вечер. Хорошее эмпирическое правило: если экономия на инфраструктуре меньше 20-30% от старого облачного счёта после вычета всех трудозатрат — переезд, скорее всего, не стоит организационного риска, и правильнее оптимизировать использование облака, а не менять инфраструктуру целиком.

Частые вопросы