Выбираем первый VPS: почему дорогой сервер ≠ успешный проект

Выбор первого VPS похож на покупку первой машины: хочется взять «что-то помощнее», но на практике часто оказывается, что скромный тариф с HDD и 1 ГБ RAM справляется лучше, чем топовый сервер за $100/мес. Разберёмся, как не переплатить за ненужные ресурсы и правильно оценить потребности Ruby-приложения.

🧩 vCPU, RAM, SSD: что на самом деле нужно вашему проекту?

1. vCPU — виртуальные ядра ≠ физическим

Миф: «4 vCPU сделают мой Rails-сайт быстрым!»
Реальность: vCPU — это доля физического ядра. 1 vCPU может быть:

25% реального ядра (если хостинг «жадный»)
или 100% (на выделенных серверах).

Для Ruby/Rails:

Базовый блог: 1 vCPU хватит (Puma в 1 поток + Sidekiq).
Средний SaaS: 2 vCPU (2-4 потока Puma + фоновая обработка).
Highload: 4+ vCPU + горизонтальное масштабирование.

# Проверка нагрузки в консоли (SSH)
`uptime` # 1.0 = 100% загрузки 1 ядра
# => "load average: 0.3, 0.2, 0.1" — всё ок

2. 1 ГБ RAM — мало или достаточно?

Антипаттерн: «Возьму 8 ГБ — чтобы точно хватило».
Правда:

Rails + PostgreSQL на минималках съедают ~600 МБ.
Swap-файл (на HDD) убивает производительность.
Лучший выбор: 1-2 ГБ для старта

Как проверить:

free -h
# Пример вывода:
# Mem:    total 1.0Gi / used 800Mi / free 200Mi

Вот улучшенный и более информативный раздел HDD vs SSD, с пояснением почему, в каких сценариях HDD ещё допустим, и что выигрывает от SSD:

⚙️ 3. HDD vs SSD: экономия или производительность?

Выбор между HDD и SSD на VPS — это компромисс между ценой и скоростью. Ниже — когда можно сэкономить, а когда это выйдет себе дороже.

🐢 Когда HDD — допустим:

🔧 Pet-проекты, демки, боты, Telegram-утилиты — когда важен бюджет, а не миллисекунды.
🚧 PoC/MVP — прототип, где нет прод-нагрузки и не жалко всё снести.
💤 Низконагруженные API или сайты — если трафик минимальный, и база данных почти не меняется.
📦 Хранилище архивов или логов — если контейнер просто сбрасывает бэкапы или файлы.

⚡ Когда SSD — must-have:

🧠 База данных > 1 ГБ (особенно PostgreSQL) SSD кардинально ускоряет INSERT, UPDATE, индексацию и VACUUM.
🧱 Production-приложения, где:
- важна отзывчивость API (< 100 мс)
- запускаются фоновые задания (Sidekiq, cron)
- есть CI/CD пайплайн прямо на сервере
🖼 Обработка файлов, медиа, генерация PDF/изображений HDD будет узким местом при интенсивной работе с диском.
🕵️ Мониторинг, алерты, аналитика — Prometheus, Elasticsearch, Grafana и прочие любят быструю IOPS.

📌 Чек-лист

Сценарий	HDD	SSD
Pet-проект	✅	✅
База > 1ГБ	❌	✅
CI/CD	⚠️	✅
Прод-приложение	❌	✅
Архив логов	✅	⚠️
PostgreSQL с частыми INSERT	❌	✅

SSD — это не про “быстрее”, а про “стабильнее под нагрузкой”

💸 Практика: подбираем тариф под типовые сценарии

Сценарий 1: Pet-проект на Rails

Цель: хостинг для портфолио.
Конфиг:
- 1 vCPU
- 1 ГБ RAM
- 20 ГБ HDD
- Без SLA

Сценарий 2: Стартап (MVP)

Цель: первый рабочий прототип.
Конфиг:
- 2 vCPU
- 2 ГБ RAM
- 50 ГБ SSD
- Лайфхак: лучше выбрать NVMe быстрее обычного SSD.

Сценарий 3: Production (SaaS)

Цель: стабильная работа 100+ пользователей.
Конфиг:
- 4 vCPU
- 8 ГБ RAM
- 100 ГБ SSD + отдельный сервер для PostgreSQL.
- Важно: мониторинг (New Relic) покажет, где узкие места.

🔥 Топ-3 ошибки при выборе VPS

«Нагрузка будет расти»
Арендуете сервер «на вырост» → переплачиваете 6 месяцев.
Решение: автоскейлинг.
«Возьму Windows — вдруг пригодится» Ну мало ли, вдруг и такие мысли бывают 😅
Лицензия + накладные расходы съедят 30% ресурсов.
Для Ruby — только Linux (Ubuntu LTS).
«Главное — процессор, остальное поставим потом»
Увеличить RAM можно не на всех тарифах.

🛠️ Оптимизация «малыша» (1 vCPU / 1 ГБ RAM)

Для Rails:

# config/puma.rb
workers 1 # 1 master процесс
threads 1, 2 # min/max потоков

Для PostgreSQL:

ALTER SYSTEM SET shared_buffers = '256MB';
ALTER SYSTEM SET effective_cache_size = '768MB';

Для системы:

sudo swapoff -a # Если swap на HDD — лучше отключить
sudo nano /etc/sysctl.conf
# Добавить:
vm.swappiness = 10

🎯 Вывод

Стартуйте с минимального тарифа — апгрейд дешевле, чем переплата за неиспользуемые ресурсы.
1 ГБ RAM — достаточно для пет-проектов, но мониторьте free -h.
SSD > HDD для баз данных, но статику можно и на HDD.
vCPU ≠ ядро — уточняйте у провайдера, сколько реальной мощности дают.

Главное правило: сервер должен быть «в меру упитанным» — как раз чтобы обрабатывать ваш текущий трафик, но с запасом 20-30% для пиков. Всё остальное — преждевременная оптимизация.