Облачные вычисления
Managed Databases: RDS, Cloud SQL
Стартап тратил 30% инженерного времени на поддержку PostgreSQL на EC2: мониторинг, бэкапы, патчинг, репликация. После миграции на RDS эти задачи заняли 2% времени. RDS, Aurora, Cloud SQL - это не просто «управляемый PostgreSQL», это другая операционная модель.
- **Netflix:** Aurora для метаданных - тысячи RPS с failover за секунды, не минуты
- **Airbnb:** RDS с read replicas - разделение read/write трафика при пиках бронирования
- **Shopify:** переключились на Aurora Serverless v2 для автомасштабирования в Black Friday
Amazon RDS: управляемые БД
2009 год. Amazon запустила RDS (Relational Database Service) с одним посылом: хватит тратить недели на установку PostgreSQL, настройку резервных копий и патчинг. RDS берёт на себя весь операционный слой - инстанс, хранилище, бэкапы, патчи, Multi-AZ failover. Инженер остаётся наедине только с SQL и схемой.
RDS поддерживает MySQL, PostgreSQL, MariaDB, Oracle, SQL Server и собственный движок Aurora. Под капотом - обычный EC2-инстанс с EBS-хранилищем, но AWS управляет им как сервисом. Доступ через стандартные порты, инстанс невидим пользователю.
| Функция | Self-managed EC2 | RDS |
|---|---|---|
| Установка БД | Вручную | Автоматически |
| Бэкапы | Скрипты / cron | Автоматически, point-in-time |
| Multi-AZ failover | HAProxy + Pacemaker | Встроен, ~60-120 сек |
| Патчинг ОС | Вручную | Управляемое окно |
| Мониторинг | CloudWatch + агент | Enhanced Monitoring встроен |
| Стоимость | Дешевле при экспертизе | Дороже, но проще |
RDS с опцией Multi-AZ создаёт standby-реплику. Что происходит при отказе primary?
Aurora: распределённое хранилище
2014 год. Amazon Aurora - ответ на вопрос «что если переписать хранилище MySQL/PostgreSQL с нуля для облака?». Ключевая идея: отделить compute (движок SQL) от storage (хранилище). Хранилище становится распределённым сервисом, compute - просто узлы над ним.
Aurora хранит 6 копий данных в 3 зонах доступности (2 копии на зону). Запись подтверждается после записи в 4 из 6 копий. Чтение требует 3 из 6. При отказе зоны (2 копии) - кворум сохраняется. Это радикально другая архитектура по сравнению с классическим RDS.
**Aurora vs RDS:** Aurora дороже на 20-30%, но даёт failover за секунды вместо минут, до 15 read replicas с минимальной задержкой репликации (<10ms), и авто-масштабирование хранилища. Оправдан для highload и критичных OLTP систем.
Почему Aurora Read Replicas переключаются в primary за секунды, а не минуты как в обычном RDS?
Cloud SQL vs AlloyDB
Google Cloud предлагает два уровня управляемых реляционных БД. **Cloud SQL** - аналог Amazon RDS: управляемые MySQL, PostgreSQL, SQL Server на стандартном хранилище. **AlloyDB** - ответ Google на Aurora: PostgreSQL-совместимый движок с колумнарным кэшем и распределённым хранилищем.
Cloud SQL проще в освоении и дешевле. AlloyDB позиционируется как «до 4x быстрее стандартного PostgreSQL для OLTP и до 100x для аналитических запросов» за счёт встроенного колумнарного движка рядом с row storage.
| Характеристика | Cloud SQL | AlloyDB |
|---|---|---|
| Движки | MySQL, PostgreSQL, SQL Server | PostgreSQL только |
| Хранилище | Стандартное (Persistent Disk) | Распределённое (6 копий) |
| Failover | ~60 сек | ~10 сек |
| Аналитика | Стандартный PostgreSQL | Встроенный columnar engine |
| Стоимость | Дешевле | Дороже (~2x) |
| Аналог AWS | RDS | Aurora |
Команда выбирает между Cloud SQL и AlloyDB для highload OLTP PostgreSQL с ~50k RPS. Что предпочесть?
Read Replicas и масштабирование чтений
Типичная OLTP нагрузка: 90% чтений, 10% записей. Primary-инстанс обрабатывает все записи и часть чтений. При росте трафика запросы SELECT становятся узким местом - primary не справляется. Решение: **Read Replicas** - асинхронные копии базы, принимающие только SELECT.
Асинхронная репликация означает небольшую задержку (replica lag): реплика отстаёт от primary на миллисекунды-секунды. Запись в primary и немедленное чтение с реплики может вернуть устаревшие данные. Приложение должно это учитывать: некритичные reads - на реплику, критичные (после записи) - на primary.
**Паттерн eventual consistency в БД:** после записи пользователю лучше читать с primary несколько секунд (или использовать сессионные токены), а потом переключаться на реплику. Иначе пользователь видит «исчезающие» только что созданные объекты.
Пользователь создаёт пост и сразу открывает список постов. Пост не появляется в списке. В чём причина?
Managed Databases
- RDS берёт на себя ОС, патчинг, бэкапы, Multi-AZ failover (~60-120 сек); клиент управляет схемой и запросами
- Aurora отделяет compute от storage (6 копий, 3 AZ); failover <30 сек, read replicas читают из общего storage
- Cloud SQL - аналог RDS для GCP; AlloyDB - аналог Aurora с колумнарным движком
- Read Replicas масштабируют чтения через асинхронную репликацию; replica lag требует учёта в приложении
Связанные темы
Управляемые БД - часть общей картины cloud storage и сетевой архитектуры.
- VPC и сетевая изоляция — RDS всегда размещается внутри VPC - security groups и subnets определяют доступ
- Auto Scaling — Aurora Serverless v2 автоматически масштабирует compute - аналог EC2 Auto Scaling
- Cloud Storage: S3, GCS, Blob — RDS бэкапы хранятся в S3; снэпшоты экспортируются в Parquet для аналитики
Вопросы для размышления
- В каких сценариях самостоятельная установка PostgreSQL на EC2 предпочтительнее RDS?
- Почему Aurora архитектурно превосходит RDS для Multi-AZ failover, если оба используют репликацию?
- Как правильно обрабатывать replica lag в приложении без усложнения кода?