MongoDB на VPS: готовая к продакшену установка за 30 минут

MongoDB Atlas M20 (4GB RAM, 2 vCPU) стоит $158 в месяц. VPS с той же конфигурацией — $20-40. Разница в четыре раза. Звучит как очевидная экономия, правда? Проблема в том что "установить MongoDB" и "запустить готовый к продакшену MongoDB" — это разные вещи. Первое занимает пять минут, второе требует усиления безопасности, настройки резервного копирования, мониторинга и понимания что может сломаться.

Эта статья — практическое руководство по развёртыванию MongoDB на VPS для продакшена. Не "как установить и запустить", а "как сделать чтобы не проснуться в три ночи от уведомления о падении базы или взломе сервера". За 30 минут, с нуля до работающей конфигурации готовой к реальной нагрузке.

Когда MongoDB на VPS оправдан

Начнём с неудобного вопроса: а нужно ли вообще? MongoDB Atlas решает проблемы автоматически — бэкапы, мониторинг, патчи безопасности, автомасштабирование. Исследование показывает что для 1TB датасета с 10K запросами в секунду Atlas обходится примерно в $3,000-5,000 в месяц. Собственный хостинг на EC2 — около $800-1,200. Экономия существенная, но появляется ответственность за всё.

Вы хороший кандидат если

У вас есть кто-то кто понимает Linux и базы данных. Не обязательно сертифицированный DBA, но человек который знает что такое systemd, умеет читать логи, понимает основы сетевой безопасности. MongoDB на VPS не требует учёной степени, но требует готовности разбираться когда что-то идёт не так.

Ваш траффик предсказуем. Если нагрузка стабильная или растёт плавно, собственный хостинг экономит деньги. Если у вас резкие пики (вирусные события, сезонность), автомасштабирование Atlas окупает себя. Нельзя мгновенно добавить память в VPS когда нагрузка взлетела в три раза.

Вы готовы инвестировать время в настройку. Первичная установка занимает 30-60 минут. Но нужно время на понимание конфигурации, настройку бэкапов, установку мониторинга. Это не решение типа "настроил и забыл".

Бюджет критичен. Сравнение показывает что для типичной настройки для продакшена Atlas M20 (~$158/месяц) против трёх EC2 t3.medium ($82/месяц) даёт экономию почти в два раза. Для установки на одном сервере разница ещё больше — в 4-5 раз.

Вы плохой кандидат если

У вас нет DevOps ресурсов. Если в команде нет никого кто готов разбираться с серверами, взять дежурства по вызову, реагировать на проблемы — платите за Atlas. Ваше время дороже экономии на инфраструктуре.

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

Требования соответствия критичны. Если вам нужны HIPAA, SOC 2, ISO 27001 сертификаты — Atlas предоставляет это документально. Собственный хостинг означает что вы сами ответственны за соответствие требованиям, что дорого и сложно.

Данных мало. Если у вас 100MB данных и 10 запросов в минуту, возможно вообще не нужна отдельная база данных. SQLite или управляемый бесплатный уровень справятся. Оверинжиниринг дороже чем кажется.

Реальные затраты

Давайте честно. VPS за $20 в месяц это не полная стоимость владения.

Прямые расходы: VPS (4GB памяти, 2 vCPU, 80GB SSD) — $20-40/месяц в зависимости от провайдера. Хранилище для бэкапов — если храните бэкапы отдельно, добавьте $5-10/месяц за 100GB в S3/B2. Мониторинг — если используете платный (не обязательно), $10-20/месяц. Всего: $25-70/месяц реально против $158+ в Atlas.

Скрытые расходы: Время инженера. Первичная настройка 2-4 часа. Ежемесячное обслуживание (обновления, проверка бэкапов, проверка метрик) — 1-2 часа. Годовая нагрузка примерно 20-30 часов инженерного времени. Если час инженера стоит $50, это $1,000-1,500/год или $80-125/месяц.

Риски. Нет соглашения об уровне обслуживания. Если ваш VPS провайдер падает, вы без базы данных. Ответственность за безопасность на вас. Пропустили обновление безопасности — взломали сервер, проблема ваша.

Суммарно: ~$105-195/месяц против $158+ Atlas для базовой конфигурации. Экономия есть, но не такая драматическая как кажется на первый взгляд. Настоящая экономия начинается от M30+ уровней ($280+/месяц Atlas vs $50-80 VPS).

Подготовка: что нужно

VPS с минимум 4GB памяти. 2GB технически работает, но для продакшена некомфортно. MongoDB любит память для кеширования. Ubuntu 22.04 или 24.04 LTS — самый протестированный вариант, хотя работает на любом Linux.

Доступ с правами суперпользователя через SSH. Будем устанавливать пакеты, настраивать межсетевой экран, создавать службы systemd.

Базовое понимание Linux. Умение подключиться по SSH, редактировать файлы (nano/vim), перезапускать службы, читать логи через journalctl.

Резервный домен или адрес для доступа. Желательно не светить рабочий IP-адрес в коде — использовать домен с возможностью переключения DNS.

Полчаса непрерывного времени. Прерывание на половине установки создаёт полу-рабочую систему которую сложно отлаживать.

Установка и базовая конфигурация

Подключаемся к VPS и обновляем систему. Установка MongoDB 8.0 (последняя стабильная версия) занимает несколько команд через официальный репозиторий. После установки у нас запущен MongoDB на localhost:27017 без аутентификации.

Первый шаг конфигурации готовой к продакшену — включить аутентификацию. Подключаемся к оболочке MongoDB и создаём администратора. Не используйте простые пароли — MongoDB часто атакуют боты сканирующие интернет на открытые инстансы.

Редактируем конфигурацию /etc/mongod.conf. Включаем аутентификацию в секции безопасности. Настраиваем bindIp — по умолчанию 127.0.0.1 (только localhost). Для приложения на том же сервере оставляем localhost. Если приложение на другом сервере, указываем приватный IP-адрес.

Никогда не ставьте bindIp: 0.0.0.0 без межсетевого экрана. Это открывает MongoDB всему интернету. Недавнее уведомление безопасности MongoDB раскрыло CVE-2025-14847 — открытый порт 27017 без аутентификации это приглашение для атак.

Настраиваем параметры движка хранения. Кеш WiredTiger по умолчанию берёт 50% памяти минус 1GB. Для 4GB сервера это ~1GB кеша, что маловато. Увеличиваем до 2GB если других приложений на сервере нет.

Создаём отдельного пользователя для приложения. Не давайте приложению права суперпользователя. Создайте пользователя специфичного для базы данных с ролью чтения и записи только на нужной базе.

Перезапускаем MongoDB и проверяем что аутентификация работает. Попытка подключиться без учётных данных должна быть отклонена.

Усиление безопасности

Базовая установка с аутентификацией — это минимально приемлемая безопасность, не готовность к продакшену.

Межсетевой экран обязателен. UFW (Ubuntu) делает это простым. Разрешаем SSH (22) и MongoDB (27017) только с IP-адреса вашего приложения. Если приложение на том же сервере — порт MongoDB вообще не нужен во внешнем доступе.

Fail2ban для SSH. Атаки перебора паролей на SSH происходят постоянно. Fail2ban автоматически банит IP-адреса после нескольких неудачных попыток входа. Установка занимает две минуты, экономит нервы.

Регулярные обновления. MongoDB выпускает патчи безопасности. Настройте автоматические обновления для установки обновлений безопасности или вручную проверяйте раз в месяц.

TLS/SSL для продакшена. Если MongoDB и приложение на разных серверах, данные идут по сети незашифрованными. Для продакшена настройте TLS с сертификатами. Let's Encrypt даёт бесплатные сертификаты, но для MongoDB нужны некоторые дополнительные шаги.

Логирование. MongoDB по умолчанию логирует в /var/log/mongodb/mongod.log. Настройте ротацию чтобы логи не съели всё дисковое пространство. Logrotate делает это автоматически.

Мониторинг дискового пространства. WiredTiger хранит данные компактно, но логи, бэкапы, временные файлы могут расти. Когда диск заполняется, MongoDB падает. Настройте оповещения на 80% использования диска.

Стратегия резервного копирования

Бэкапы критичны. Официальная документация MongoDB подчёркивает что стратегия резервного копирования обязательна для продакшена.

mongodump — простой и эффективный. Создаёт снимок базы данных в BSON формате. Для небольших баз (до 100GB) это проще всего. Для больших баз рассмотрите снимки файловой системы.

Скрипт автоматического бэкапа запускается через cron. Ежедневные бэкапы в 2 часа ночи, сохраняем последние 7 дней локально. Старые бэкапы автоматически удаляются.

Храните бэкапы удалённо. Локальные бэкапы на том же сервере не защищают от аппаратных сбоев. Загружайте в S3, Backblaze B2, или другое объектное хранилище. AWS CLI или rclone автоматизируют это.

Тестируйте восстановление. Бэкап который не проверен на восстановление — это не бэкап, а ложное чувство безопасности. Раз в месяц делайте тестовое восстановление на отдельном сервере. Убедитесь что данные читаются корректно.

Восстановление на момент времени ограничено. mongodump даёт снимок на момент выполнения. Для восстановления на конкретную секунду нужен oplog tailing или непрерывное резервное копирование, что сложнее. Для большинства приложений ежедневных снимков достаточно.

Типичная стратегия: ежедневные полные бэкапы, срок хранения 7 дней локально + 30 дней в облачном хранилище. Для 50GB базы это ~350GB локального и ~1.5TB облачного хранилища в месяц ($15-20 на B2).

Мониторинг и оповещения

База данных в продакшене без мониторинга — это бомба замедленного действия. Нужно знать когда что-то идёт не так до того как пользователи заметят.

Основные метрики для отслеживания: Использование диска — MongoDB хранит данные и индексы на диске. 80% заполнения это предупреждение, 90% критическое значение. Использование памяти — кеш WiredTiger должен быть эффективен. Если процент попаданий в кеш низкий, нужно больше памяти. Количество соединений — MongoDB поддерживает ограниченное число соединений. Мониторинг помогает обнаружить утечки соединений. Производительность запросов — медленные запросы (100ms+) сигнализируют о проблемах с индексами. Задержка репликации — если настроен набор реплик, отставание реплик критично.

Инструменты мониторинга: Встроенные команды MongoDB типа db.serverStatus() дают детальные метрики. Можно писать скрипты на Python/Bash для сбора и отправки в Prometheus или другую систему мониторинга.

Percona Monitoring and Management (PMM) — решение с открытым кодом специально для MongoDB. Более сложен в настройке чем простые скрипты, но даёт профессиональную панель управления и аналитику запросов.

Облачные сервисы мониторинга типа Datadog, New Relic поддерживают агенты MongoDB. Если уже используете для приложения, добавить мониторинг MongoDB просто. Цена $15-30/месяц за хост.

Простейший self-hosted вариант: mongodb_exporter для Prometheus + Grafana dashboard. Требует отдельный сервер или контейнер для Prometheus/Grafana, но бесплатен. Сложность настройки средняя.

Система оповещений критична. Мониторинг без оповещений бесполезен. Настройте уведомления на диск >85%, память >90%, медленные запросы >500ms, соединения >80% лимита. Telegram bot или email достаточно для небольших проектов.

Настройка производительности

MongoDB из коробки настроен консервативно. Несколько твиков могут существенно улучшить производительность.

Размер кеша WiredTiger. По умолчанию 50% памяти - 1GB. На выделенном сервере MongoDB можно безопасно увеличить до 60-70% памяти. Для 4GB сервера это 2-2.5GB кеша вместо дефолтных 1GB.

Предпочтение чтения. Если используете набор реплик, правильная настройка предпочтения чтения балансирует нагрузку. Для приложений с преобладанием чтения, чтение с вторичных узлов снижает нагрузку на первичный узел.

Индексы критичны. Медленные запросы почти всегда результат отсутствующих индексов. MongoDB profiler помогает обнаружить медленные запросы. Создайте индексы на поля в WHERE, JOIN, операциях сортировки.

Пул соединений в приложении. Соединения MongoDB дороги. Используйте пул соединений в приложении вместо создания нового соединения на каждый запрос. Большинство драйверов делают это по умолчанию, но проверьте настройки.

Отключите Transparent Huge Pages. Linux THP может деградировать производительность MongoDB. Документация рекомендует отключать. Это делается через системные настройки и требует перезагрузки.

Настройте параметры ядра. Увеличение ulimit на файловые дескрипторы и процессы помогает при высокой нагрузке. Документация MongoDB содержит рекомендуемые значения.

Мониторинг паттернов запросов. Используйте MongoDB profiler для анализа медленных запросов. Порог 100ms обычно хороший базовый уровень. Всё что медленнее нужно оптимизировать — добавить индекс, переписать запрос, денормализовать данные.

Когда масштабировать

MongoDB на одном узле отлично работает до определённых пределов. Понимание когда нужно усложнять архитектуру критично.

Вертикальное масштабирование работает долго. Увеличение памяти с 4GB до 8GB, потом до 16GB, добавление более быстрого хранилища (NVMe), больше процессорных ядер. Для большинства приложений один узел до 32-64GB памяти справляется отлично.

Набор реплик нужен для высокой доступности. Если простой недопустим, нужны минимум три узла (первичный + 2 вторичных). Автоматическое переключение при отказе первичного узла. Это усложняет инфраструктуру втрое, но даёт ~99.95% времени бесперебойной работы.

Шардирование нужно редко. Распределение данных по нескольким серверам решает проблему данных которые не помещаются на одном диске. Но шардирование сложно, создаёт operational overhead, ограничивает некоторые операции. Большинство компаний никогда не доходят до нужды в шардировании.

Типичный путь: одиночный узел (4-8GB) → более мощный узел (16-32GB) → набор реплик из 3 узлов → более мощный набор реплик → шардирование (если действительно нужно, что редко).

Момент перехода: переход на набор реплик когда простой начинает стоить денег. Переход на шардирование когда данные не помещаются на максимальных доступных дисках (обычно несколько терабайт).

Миграция с Atlas

Если решили мигрировать с Atlas на собственный хостинг, процесс прямолинейный но требует планирования.

mongodump/mongorestore — простейший путь. Создаёте дамп Atlas базы, загружаете на ваш VPS, восстанавливаете. Для небольших баз (<100GB) это занимает часы. Время простоя зависит от размера данных.

Change streams для live миграции. Для минимизации простоя используйте двухфазную миграцию: начальная синхронизация через mongodump, потом live репликация изменений через change streams. Сложнее в реализации, но простой минуты вместо часов.

Тестирование критично. Не переключайте рабочий траффик на новую базу без тщательного тестирования. Проверьте производительность на реалистичной нагрузке, убедитесь что все индексы на месте, бэкапы работают.

План отката обязателен. Если что-то идёт не так, нужна возможность быстро вернуться на Atlas. Держите инстанс Atlas живым несколько дней после миграции.

Обновления строки подключения. Все приложения нужно переконфигурировать на новую строку подключения. Используйте переменные окружения вместо жёстко закодированных строк — упрощает миграцию.

Типичная хронология: подготовка VPS и тестирование (1 день), начальная синхронизация (несколько часов для 50-100GB), финальная синхронизация и переключение (1-2 часа окна обслуживания), мониторинг после миграции (неделя).

Чего НЕ делать

Из опыта — типичные ошибки собственного хостинга MongoDB.

Не игнорируйте бэкапы. "Это только dev/staging" → через месяц там критичные данные. Настройте бэкапы сразу, не откладывайте.

Не открывайте порт 27017 интернету. Даже с аутентификацией. Боты сканируют постоянно, ищут слабые пароли, старые уязвимости. Межсетевой экран + приватный доступ обязательны.

Не пропускайте обновления безопасности. CVE-2025-14847 (Mongobleed) показал что уязвимости случаются. Проверяйте обновления ежемесячно минимум.

Не надейтесь на бэкапы сервера от провайдера. Снимок VPS от провайдера полезен, но не заменяет правильное резервное копирование базы данных. Используйте mongodump/restore для консистентных бэкапов приложения.

Не забывайте про мониторинг. "Всё работает, зачем мониторить?" → диск заполняется, база падает в пятницу вечером. Оповещения спасают выходные.

Не недооценивайте operational overhead. MongoDB не требует ежедневного внимания, но требует регулярного. Обновления, проверка бэкапов, проверка метрик, планирование мощностей. Бюджетируйте время.

Чеклист готовности к продакшену

Перед тем как считать настройку готовой к продакшену, проверьте:

1. Аутентификация включена и настроены пользователи с минимальными необходимыми правами
2. Межсетевой экран настроен, порт 27017 не открыт публично
3. Автоматические бэкапы настроены и хранятся удалённо
4. Тестовое восстановление выполнено и успешно
5. Мониторинг настроен с оповещениями на критичные метрики
6. Логи ротируются автоматически
7. Обновления безопасности настроены (вручную или автоматически)
8. Настройка производительности применена (размер кеша, THP отключен, ulimits)
9. Строка подключения использует приватный адрес или домен, не публичный адрес
10. Документация создана — как подключиться, как восстановить бэкап, контакты дежурных

Если все пункты отмечены — ваша установка MongoDB готова к продакшену.

Главные выводы

MongoDB на VPS экономит деньги — в 2-4 раза дешевле Atlas для типичных конфигураций. Но требует знаний Linux, понимания баз данных, готовности брать operational ответственность.

Настройка готовая к продакшену за 30-60 минут реальна. Установка + базовая конфигурация + усиление безопасности + бэкапы + минимальный мониторинг. Не тысячи строк кода, простые практичные шаги.

Скрытые расходы существуют. Время инженера на настройку и обслуживание, риски от отсутствия соглашения об уровне обслуживания, ответственность за безопасность. Экономия всё равно есть, но не такая драматическая как "VPS $20 vs Atlas $158".

Не для всех. Если нет DevOps ресурсов, нужны требования соответствия, критична высокая доступность из коробки — платите за Atlas. Это легитимный выбор. Собственный хостинг оправдан когда есть ресурсы и желание управлять инфраструктурой.

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

Бэкапы, мониторинг, безопасность — не опциональны. Это минимум для продакшена. Пропустить любое из трёх значит рисковать данными или доступностью.

Собственный хостинг MongoDB на VPS это хороший выбор для команд готовых управлять инфраструктурой. Экономит деньги, даёт контроль, работает надёжно при правильной настройке. Главное — понимать что берёте ответственность за operational excellence. Если готовы — 30 минут до MongoDB готовой к продакшену.