Настройка управляемых баз данных 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. Получите консультацию — пишите, мы оценим ваш проект и предложим оптимальное решение под ключ.