Настройка AWS Aurora для высокодоступной базы данных

Aurora кажется простой заменой RDS, пока не начинаешь разбираться, как она на самом деле работает. Первый продакшн-инцидент случается не из-за падения ноды, а потому что приложение не умеет переключаться между writer и reader при failover. Aurora не MySQL в облаке — это распределённое хранилище с общим volume для всех нод кластера, и без понимания этой разницы архитектурные решения будут неверными. Экономия на инстансах Aurora по сравнению с RDS может достигать 30% за счёт эффективного storage, но только при правильной конфигурации.

Почему стандартный Multi-AZ RDS не решает задачу при серьёзной нагрузке

Multi-AZ RDS даёт failover за 30-120 секунд — приемлемо для большинства сценариев, но Aurora сокращает это до 20-30 секунд за счёт того, что standby — не просто реплика, а полноправный член кластера с тем же storage volume. Добавляем Aurora Replicas (до 15 штук) — и читающий трафик горизонтально масштабируется без копирования данных между нодами. На реальном проекте — e-commerce платформа с ~800 RPS в пике — мы столкнулись с тем, что writer инстанс уходил в CPU saturation при конкурентных транзакциях на checkout. Решение: reader endpoint для аналитики и отчётов, writer — только для мутаций. Это снизило CPU writer-ноды с 85% до 40% в пиковые часы без апгрейда инстанса.

Как проектируем Aurora кластер

Начинаем с выбора движка: Aurora MySQL 8.0-compatible или Aurora PostgreSQL 15-compatible. Это не просто совместимость API — у них разные ограничения по параметрам, разное поведение при autovacuum (PostgreSQL), разные возможности JSON-операций. Выбор зависит от existing workload, не от предпочтений. Наши сертифицированные инженеры AWS имеют 10+ лет опыта и реализовали 50+ проектов по миграции баз данных.

Структура кластера для production:

Primary (writer): db.r7g.xlarge или больше
Read Replica 1: db.r7g.large — тот же AZ, что и writer
Read Replica 2: db.r7g.large — второй AZ (failover candidate)

Parameter Group — первое, на что обращаем внимание. Aurora использует cluster-level и instance-level parameter groups. max_connections для r7g.xlarge Aurora PostgreSQL по умолчанию ~5000, но это не значит, что так и оставляем — при использовании PgBouncer поверх настройки меняются. shared_buffers Aurora PostgreSQL управляется отдельно от параметра в parameter group.

Aurora Auto Scaling для reader нод конфигурируем через aws application-autoscaling register-scalable-target с target tracking по RDSReaderAverageDatabaseConnections или RDSReaderAverageCPUUtilization. Важно: scale-in cooldown нужно ставить достаточно долгим (600+ секунд), иначе ноды будут флапать при колебаниях нагрузки.

Как правильно настроить Aurora Global Database?

Aurora Global Database — отдельная история. Репликация между регионами работает через dedicated replication network со lag обычно менее 1 секунды. Это не замена репликации внутри региона, это disaster recovery с RPO ~1s и RTO ~1 минута при regional failover. Настраивается через create-global-cluster, secondary region добавляется как add-region-to-global-cluster.

Подробнее: Amazon Aurora

Как настроить мониторинг и резервное копирование?

Backtrack — фича, которую часто игнорируют. Позволяет откатить кластер назад во времени без восстановления из снапшота. Работает только для Aurora MySQL. Настраивается при создании кластера, окно до 72 часов. Цена — дополнительные I/O за хранение change records. Для Aurora PostgreSQL аналог — PITR (Point-in-Time Recovery) через automated backups.

Enhanced Monitoring даёт метрики на уровне OS каждые 1–60 секунд: cpuUtilization, diskIO, loadAverageMinute. Включается через IAM role rds-monitoring-role с policy AmazonRDSEnhancedMonitoringRole. Performance Insights показывает db.load в единицах vCPU, разбивает нагрузку по ожиданиям (db.lock, db.io, db.cpu), позволяет дрелиться до конкретного SQL statement. Retention: 7 дней бесплатно, до 2 лет за доп. плату.

Сравнение Aurora MySQL и PostgreSQL

Сроки и объём работ

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

Что входит в работу

• Консультация и аудит текущей инфраструктуры БД
• Проектирование и развёртывание Aurora-кластера
• Настройка мониторинга и алертов
• Документация (runbook, backup/restore процедуры)
• Обучение вашей команды работе с Aurora
• Гарантированная отказоустойчивость с RTO < 1 мин

Частые ошибки при настройке Aurora

• Не настраивают Connection Pooling. Aurora хорошо держит соединения, но при Lambda-функциях или serverless-нагрузке с тысячами ephemeral connections база всё равно захлёбывается. Aurora Proxy — managed PgBouncer/ProxySQL от AWS, интегрируется с Secrets Manager для автоматической ротации credentials.

• Используют один endpoint для всего. Cluster endpoint всегда указывает на writer. Если читающие запросы идут туда же — теряется весь смысл read replicas. Reader endpoint балансирует между репликами с round-robin, кастомные endpoints позволяют выделить конкретные ноды под аналитику.

• Игнорируют Aurora-специфичные лимиты. Максимальный размер таблицы Aurora — 64 TiB на движок. Storage автоматически растёт с шагом 10 GiB, но не уменьшается автоматически. aurora_oom_response на MySQL — параметр, который стоит проверить, если ноды периодически рестартуют без очевидных причин.

Свяжитесь с нами для консультации по вашему проекту. Мы поможем спроектировать отказоустойчивое решение и избежать типичных ошибок.