Налаштування AWS Aurora для високодоступної бази даних

Aurora здається простою заміною RDS, поки не починаєш розбиратися, як вона насправді працює. Перший продакшн-інцидент трапляється не через падіння ноди, а тому що застосунок не вміє перемикатися між writer і reader при failover. AWS Aurora — це не MySQL у хмарі, а розподілене сховище зі спільним volume для всіх нод кластера, і без розуміння цієї різниці архітектурні рішення будуть неправильними. Економія на інстансах Aurora порівняно з RDS може сягати 30% за рахунок ефективного storage, але тільки за правильної конфігурації. Наприклад, один клієнт заощадив $12,000 на рік після міграції з RDS на Aurora. Вартість Aurora починається від $0.10 за годину для інстансу db.r7g.large, але повна конфігурація може коштувати $500-2000 на місяць залежно від параметрів.

Чому стандартний Multi-AZ RDS не вирішує задачу при серйозному навантаженні

Multi-AZ RDS дає failover за 30-120 секунд — прийнятно для більшості сценаріїв, але Aurora скорочує це до 20-30 секунд, тобто в кілька разів швидше. Додаємо Aurora Replicas (до 15 штук, що в 5 разів більше ніж у RDS) — і читаючий трафік горизонтально масштабується без копіювання даних між нодами. На реальному проєкті — 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.

Детальніше: Wikipedia — Amazon Aurora

Як налаштувати моніторинг і резервне копіювання?

Backtrack — фіча, яку часто ігнорують. Дозволяє відкотити кластер назад у часі без відновлення зі снапшота. Працює тільки для Aurora MySQL. Налаштовується при створенні кластера, вікно до 72 годин. Ціна — додаткові I/O за зберігання change records. Для Aurora PostgreSQL аналог — PITR (Point-in-Time Recovery) через automated backups. Резервне копіювання Aurora здійснюється автоматично через 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. Connection pooling дозволяє ефективно керувати з'єднаннями.

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

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

Зв'яжіться з нами для консультації щодо вашого проекту. Ми допоможемо спроєктувати відмовостійке рішення та уникнути типових помилок. Високодоступна база даних — це не просто кластер, а правильно налаштований комплекс із моніторингом, резервним копіюванням та технічною підтримкою.