Професійне налаштування VK Cloud Managed Databases під high load та HA

Професійне налаштування VK Cloud Managed Databases

Команда запустила PostgreSQL на хмарі VK з дефолтними налаштуваннями — через тиждень БД впала під навантаженням. Це типова ситуація: дефолти Managed-сервісу розраховані на мінімальні ресурси, а production вимагає тонкого налаштування. Ми стикаємося з такими випадками регулярно і знаємо, як їх запобігти. Наш досвід роботи з VK Cloud — 5+ років, більше 50 успішних проєктів з налаштування та міграції баз даних. Компанія має 5+ років досвіду на ринку та реалізувала 50+ проєктів з базами даних.

Чому дефолтні налаштування Managed Databases вбивають продуктивність?

VK Cloud Managed Databases підтримує PostgreSQL, MySQL, Redis, ClickHouse, MongoDB, OpenSearch. Керовані сервіси беруть на себе реплікацію, автоматичний failover, бекапи та моніторинг базових метрик. Але «managed» не означає «не треба нічого налаштовувати» — конфігурація інстанса, параметри БД, мережевий доступ та бекап-політика потребують уваги. Без коригування ви отримуєте до 50% втрати продуктивності. Наприклад, PostgreSQL з дефолтами на інстансі 8 vCPU / 32 GB RAM буде використовувати всього 256 MB shared_buffers. Це призводить до частих читань з диска та зростання latency. Ми налаштовуємо до 50 параметрів, адаптуючи їх під ваше навантаження.

Згідно з документацією VK Cloud, managed-сервіс автоматично керує реплікацією та резервним копіюванням, але не оптимізує параметри СУБД. Тому без ручного налаштування продуктивність страждає.

Як ми налаштовуємо PostgreSQL для production на VK Cloud

Використовуємо Terraform з провайдером vkcs для декларативного керування. Resource кластера з реплікою:

data "vkcs_db_config_group" "pg16_tuned" {
  name = "pg16-production"
}

resource "vkcs_db_cluster" "postgres" {
  name = "prod-postgres"

  datastore {
    type    = "postgresql"
    version = "16"
  }

  cluster_size = 2 # primary + 1 replica
  flavor_id     = data.vkcs_compute_flavor.db_medium.id
  volume_size   = 100
  volume_type   = "ceph-ssd"
  availability_zone = "MS1"

  network {
    uuid = vkcs_networking_network.app.id
  }

  configuration_id = data.vkcs_db_config_group.pg16_tuned.id

  capabilities {
    name = "node_exporter"
  }
}

Параметри PostgreSQL задаються через Configuration Group. Для production обов’язково налаштовуємо:

max_connections = 200
shared_buffers = 25% від RAM
effective_cache_size = 75% від RAM
work_mem = 4MB-16MB (залежить від запитів)
maintenance_work_mem = 256MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1 # для SSD

Без цих параметрів PostgreSQL працює з дефолтами, розрахованими на 256 МБ RAM — продуктивність буде поганою навіть на потужному інстансі. Налаштований PostgreSQL на VK Cloud працює до 40% швидше, ніж з дефолтними параметрами.

Кейс: міграція з самописної інфраструктури

Один із клієнтів мав PostgreSQL на віртуальній машині з ручним бекапом. Ми перенесли базу 500 ГБ на VK Cloud Managed-кластер. Налаштували реплікацію, параметри під 5000 запитів/с, моніторинг через Prometheus та alerting. У результаті uptime піднявся до 99.95%, а час відповіді знизився на 40%. Клієнт економить 30% часу на адмініструванні, що зменшує витрати на $1000 на місяць.

Як налаштувати мережевий доступ та безпеку?

За замовчуванням Managed Database доступна лише всередині тієї ж мережі VK Cloud. Для доступу ззовні — floating IP або налаштування дозволених адрес:

openstack security group rule create \
    --ingress --protocol tcp \
    --dst-port 5432 \
    --remote-ip <your_ip>/32 \
    <db_security_group_id>

Відкривати PostgreSQL в інтернет напряму — лише через TLS і з явним списком дозволених IP. Краще — bastion або VPN. Ми також налаштовуємо NetworkPolicy для Kubernetes-підключень.

Бекапи та point-in-time recovery

VK Cloud робить автоматичні бекапи за розкладом. Налаштовуємо retention та час створення:

resource "vkcs_db_backup" "postgres_manual" {
  name = "before-migration"
  dbms_id = vkcs_db_cluster.postgres.id
}

Point-in-time recovery для PostgreSQL доступний через консоль VK Cloud — відновлення на конкретний момент часу. Для цього має бути включений WAL-архів, який VK Cloud включає автоматично за наявності бекапів. Ми налаштовуємо щоденні повні бекапи та WAL-архівацію кожні 5 хвилин. Це дозволяє відновити базу на будь-яку хвилину в межах retention періоду (зазвичай 30 днів). Середній час відновлення — 15 хвилин.

Redis: конфігурація та режими роботи

Для кешування — одиночний інстанс Redis з persistence. Для production з вимогою HA — кластер з реплікою:

resource "vkcs_db_cluster" "redis" {
  name = "prod-redis"
  datastore {
    type = "redis"
    version = "7"
  }
  cluster_size = 2 # master + replica
  flavor_id = data.vkcs_compute_flavor.cache_small.id
  volume_size = 10
  volume_type = "ceph-ssd"
  network {
    uuid = vkcs_networking_network.app.id
  }
}

Для Redis важливо налаштувати maxmemory та maxmemory-policy — без цього при заповненні пам’яті Redis почне відмовляти в записі або поводитися непередбачувано.

ClickHouse для аналітики

ClickHouse у VK Cloud — хороший вибір для аналітичних завдань за умови, що даних багато і потрібні швидкі агрегації. Managed ClickHouse знімає головний біль із шардуванням та реплікацією. Підключення через стандартний ClickHouse-клієнт або HTTP-інтерфейс. VK Cloud надає endpoint з TLS.

Моніторинг та observability

При створенні інстансів включаємо capabilities { name = "node_exporter" } — це розгортає node_exporter на хості БД. Підключаємо до Prometheus через ServiceMonitor або статичну конфігурацію. Для PostgreSQL додатково — postgres_exporter. Ключові метрики:

• pg_stat_activity — кількість активних з’єднань
• pg_stat_bgwriter_buffers_alloc — тиск на буферний пул
• pg_replication_lag_seconds — відставання репліки
• pg_locks_count — блокування (зростання = проблеми з транзакціями)

Ми налаштовуємо дашборди Grafana та alerting у Telegram/Slack. У результаті ви бачите реальний стан БД і можете швидко реагувати на аномалії.

Порівняння: одиночний інстанс vs кластер HA

Кластер з реплікою забезпечує автоматичний failover менш ніж за 30 секунд — це в 50 разів швидше ручного відновлення одиночного інстанса.

Що входить у нашу роботу?

Вартість налаштування одного інстанса — від 5000 грн, кластера — від 15000 грн. Підсумок: ви отримуєте production-ready бази даних з гарантією uptime 99.95%, автоматичним бекапом та моніторингом.

Як замовити налаштування?

Зв’яжіться з нами через форму на сайті або електронною поштою. Ми проводимо аудит вашої поточної конфігурації та навантаження за 1 день. Готуємо пропозицію з точними термінами та вартістю. Отримайте консультацію інженера та аудит поточної конфігурації баз даних. Ми гарантуємо прозорість та результат.