Налаштування керованих баз даних AWS RDS / Aurora

Налаштування керованих баз даних AWS RDS / Aurora

Ми налаштовуємо RDS та Aurora так, щоб вони працювали на вас, а не ви на них. RDS і Aurora беруть на себе операційне навантаження: патчінг ОС, бекапи, failover, реплікацію. Але «керована» не означає «налаштовується сама». Дефолтна конфігурація RDS — для сумісності, не для продуктивності. Без правильного налаштування Parameter Groups, правильного вибору типу інстансу та архітектури Multi-AZ ви отримаєте керовану базу з некерованими проблемами. Ми гарантуємо, що після нашого налаштування ви забудете про «гальма» та раптові відмови.

RDS vs Aurora: коли що

RDS — коли потрібна конкретна версія PostgreSQL або MySQL з передбачуваною поведінкою. Простіше в розумінні, менше сюрпризів. Сховище зростає з кроком 5-10 GB через autoscaling.

Aurora PostgreSQL / MySQL — кластерна архітектура з розділеним сховищем. Сховище автоматично масштабується до 128 TB, failover відбувається за 30 секунд (RDS — 1–2 хвилини). Aurora Global Database для cross-region реплікації з RPO < 1 секунди.

Але Aurora дорожча на 20–30% при порівнянних інстансах. Для невеликих баз або dev-середовищ — звичайний RDS. Для production з вимогами до availability та масштабування reads — Aurora.

Що обов'язково змінити в Parameter Groups?

Дефолтні parameter groups не можна змінити — потрібна кастомна копія. Для PostgreSQL критичні параметри:

shared_buffers = {DBInstanceClassMemory/4} # 25% RAM
work_mem = 16384 # 16 MB (обережно: множиться на max_connections)
maintenance_work_mem = 524288 # 512 MB для autovacuum
effective_cache_size = {DBInstanceClassMemory*3/4} # 75% RAM
wal_buffers = 16384 # 16 MB
checkpoint_completion_target = 0.9
max_connections = 200 # залежить від інстансу
log_min_duration_statement = 1000 # логувати запити > 1с
log_lock_waits = 1
auto_explain.log_min_duration = 3000 # explain для довгих запитів

work_mem — особливо обережно. Якщо 200 connections кожна виконує sort/hash join, реальне споживання пам'яті = work_mem × connections × операцій на запит. Для m5.xlarge (16 GB) при 200 з'єднаннях — work_mem > 32 MB вже ризиковано.

Multi-AZ та Read Replicas: як налаштувати?

Multi-AZ — синхронна реплікація в standby інстанс в іншій Availability Zone. При збої primary — автоматичний failover, DNS оновлюється на standby. Це про availability, не про read performance.

Read Replicas — асинхронна реплікація, до 5 реплік для RDS, до 15 для Aurora. Для розвантаження primary від read-heavy запитів (аналітика, репортинг). Replica lag моніторимо через ReplicaLag метрику в CloudWatch.

Часта помилка — направляти аналітичні запити прямо на primary, не використовуючи read replicas. Один важкий SELECT COUNT(*) FROM orders WHERE ... з full table scan може деградувати OLTP продуктивність на хвилини.

В Aurora — Reader Endpoint автоматично балансує між усіма read replicas. Писати в Writer Endpoint, читати в Reader Endpoint — базове правило.

Бекапи та Point-in-Time Recovery

Automated backups з retention 7–35 днів — обов'язково. Це дає Point-in-Time Recovery: відновлення на будь-який момент часу в рамках retention period з точністю до 5 хвилин.

Snapshot перед значними змінами (міграція схеми, оновлення major версії) — не опція, а обов'язкова процедура. Snapshot робиться без даунтайму.

Для Aurora — Backtrack: можливість «перемотати» кластер на кілька годин назад без відновлення з бекапу. Швидше PITR, але обмежене вікно (до 72 годин).

resource "aws_rds_cluster" "aurora" {
  cluster_identifier = "myapp-aurora"
  engine = "aurora-postgresql"
  engine_version = "15.4"
  database_name = "myapp"
  master_username = "myapp_admin"
  master_password = var.db_password # з Secrets Manager
  backup_retention_period = 14
  preferred_backup_window = "03:00-04:00" # UTC, коли навантаження мінімальне
  backtrack_window = 259200 # 72 години
  db_subnet_group_name = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.rds.id]
  deletion_protection = true # захист від випадкового видалення
  enabled_cloudwatch_logs_exports = ["postgresql"]
}

Secrets Manager інтеграція

Пароль бази даних не повинен зберігатися в Terraform state або в змінних середовища додатку. Правильний підхід:

1. RDS генерує майстер-пароль через Secrets Manager (опція manage_master_user_password в Terraform провайдері)
2. Секрет ротується автоматично за розкладом
3. Додаток отримує credentials через Secrets Manager API або через RDS Proxy

RDS Proxy — рекомендовано для Lambda та інших serverless/висококонкурентних середовищ. Proxy пулить з'єднання до RDS, що критично: Lambda при 1000 одночасних викликів спробує відкрити 1000 з'єднань до RDS — база впаде від max_connections exceeded. Proxy тримає обмежений пул та мультиплексує з'єднання.

Моніторинг: що дивимося

Enhanced Monitoring (1-секундна деталізація) та Performance Insights — вмикаємо для production. Performance Insights показує топ SQL запитів за навантаженням, wait events, з'єднання — незамінно для налагодження продуктивності.

CloudWatch метрики першого пріоритету:

Що входить в роботу

• Аудит поточної конфігурації RDS/Aurora
• Налаштування кастомних Parameter Groups під навантаження
• Конфігурація Multi-AZ та Read Replicas
• Налаштування автоматичних бекапів та PITR
• Інтеграція з Secrets Manager та RDS Proxy (опціонально)
• Налаштування моніторингу та алертів в CloudWatch
• Документація з архітектури та runbook
• Навчання вашої команди базовим операціям

Терміни та вартість

Базовий інстанс RDS / Aurora з Multi-AZ, Parameter Group, бекапами та CloudWatch моніторингом — 1–2 дні. Повне налаштування з RDS Proxy, Secrets Manager ротацією, Read Replicas, Performance Insights та Terraform-модулем — 3–5 днів. Вартість проєкту — від $500–1.5kів залежно від складності. За 5 років роботи ми реалізували понад 50 успішних проєктів з DevOps. Офіційна документація AWS RDS. Отримайте консультацію — пишіть, ми оцінимо ваш проєкт і запропонуємо оптимальне рішення під ключ.