Администрирование БД в облаке

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Вступление

Фраза «мы переехали в облако — DBA больше не нужен» звучит привлекательно, но на практике ломается в первую пятницу с пиковой нагрузкой: диск забит, реплика отстаёт, миграция держит блокировку. Managed database (управляемая СУБД от провайдера) забирает рутину: патчи ОС, установка бинарников, базовый мониторинг, автоматические снимки. Схема, запросы, права, RPO/RTO, стоимость и безопасность данных остаются зоной ответственности вашей команды.

Эта глава для тех, кто видел PostgreSQL на своей VM, но впервые получает endpoint вида mydb.xxxx.rds.amazonaws.com:5432 и кнопку «Create snapshot» в консоли.

Что изменится в голове после чтения:

• поймёте shared responsibility — что чинит AWS/Google/Yandex, а что чините вы;
• отличите snapshot от pg_dump;
• поймёте, зачем не открывать порт 5432 в интернет;
• свяжете облачные бэкапы с RPO/RTO из роли БД в организации.

Теория WAL и сбоев та же — см. Восстановление после сбоя. Меняется кто крутит диски и журналы под капотом.

Словарик облачной БД

Термин	Простыми словами
Managed / PaaS для БД	Вы заказываете «PostgreSQL 16, 4 CPU, 16 GB RAM» — провайдер поднимает кластер.
Endpoint	Адрес подключения: хост + порт + иногда только SSL.
Инстанс (instance)	Один работающий сервер БД (или кластер primary+standby).
Snapshot	Снимок диска на момент времени; основа PITR у провайдера.
Retention	Сколько дней хранятся автоматические бэкапы.
VPC / private network	База доступна из внутренней сети, а не из всего интернета.
Maintenance window	Окно, когда провайдер ставит патчи minor-версии.

---

Managed-сервис — что это

Managed relational database — СУБД как сервис: вы заказываете экземпляр (класс CPU/RAM, объём диска, регион), получаете endpoint (хост, порт), логин и политики бэкапа. Провайдер обслуживает кластер, ОС (в границах модели), обновления minor/patch по политике.

Отличия от смежных моделей:

Модель	Что вы получаете	Контроль
Managed DB (RDS, Cloud SQL)	Готовый PostgreSQL/MySQL	Средний: параметры из whitelist, бэкапы кнопкой
Своя VM + apt install postgresql	Тот же PostgreSQL	Полный DBA — 1.md
PaaS приложения (Heroku-style)	БД как приложение	Меньше настроек, быстрый старт
Serverless (Aurora Serverless, Neon)	Масштаб по нагрузке	Другая экономика и лимиты

---

Модель shared responsibility

Удобная схема (одинаковая по смыслу у AWS, Azure, GCP):

Зона	Провайдер (платформа)	Клиент (вы)
Дата-центр, питание, сеть до хоста	✓
Установка и патч СУБД (по SLA)	✓
Диски, RAID, часть мониторинга железа	✓
Схема, индексы, SQL		✓
Учётные записи, least privilege		✓
Данные, целостность, миграции		✓
Выбор размера инстанса, autoscaling		✓
Тест восстановления из бэкапа	частично ✓	✓ (обязательно проверять)
Шифрование на лету / at rest	опции ✓	настройка ✓
Сетевая изоляция (VPC, firewall)	инструменты ✓	правила ✓

Вывод: облачный DBA / platform engineer — другой набор задач: IaC, секреты, стоимость, наблюдаемость, DR между регионами.

---

Что обычно делает провайдер

• первичный запуск экземпляра и репликации (read replica по кнопке);
• автоматические снимки (snapshots) по расписанию;
• point-in-time recovery в окне хранения WAL (аналог PITR — см. 106);
• failover на standby в multi-AZ / regional конфигурации;
• обновление minor-версии в maintenance window;
• базовые метрики: CPU, IOPS, connections, replication lag.

---

Что остаётся за командой

Производительность и ёмкость

• выбор класса (vCPU, RAM, IOPS);
• медленные запросы — оптимизация, индексы;
• connection pooling (PgBouncer, RDS Proxy) — лимит соединений в managed часто ниже, чем кажется;
• рост данных → scale up / partition / архив.

Безопасность

• не открывать 5432 в интернет «для удобства»;
• private endpoint, VPN, bastion;
• ротация паролей, IAM-аутентификация (где есть);
• разделение ролей app / migration / readonly analyst.

Надёжность

• задать RPO (сколько данных можно потерять) и RTO (сколько простоя допустимо);
• проверять восстановление в отдельный инстанс раз в квартал;
• понимать, что удаление production инстанса в консоли — необратимо без бэкапа.

Соответствие и данные

• резидентность (регион EU/RU);
• персональные данные — Governance.

---

Типовые продукты (ориентиры)

Провайдер	Примеры managed PostgreSQL / SQL
AWS	Amazon RDS for PostgreSQL, Aurora PostgreSQL
Google Cloud	Cloud SQL for PostgreSQL, AlloyDB
Microsoft Azure	Azure Database for PostgreSQL, Azure SQL
Yandex Cloud	Managed Service for PostgreSQL
Другие	DigitalOcean, Aiven, Supabase (PG + платформа)

Имена меняются; смотрите документацию провайдера по backup retention, maintenance window, extensions (нужен ли вам pg_cron, PostGIS).

---

Отличия от «своего» сервера

Тема	On-prem / своя VM	Managed
Доступ к postgresql.conf	полный	часто whitelist параметров
Файловая система / pg_wal	видите	скрыто
Суперпользователь	postgres	роль с ограничениями (rds_superuser и т.п.)
Установка расширений	любые	по списку провайдера
Стоимость	CapEx железа	OpEx по часам + диск + исходящий трафик

Понимание WAL и recovery помогает читать SLA: «восстановление на точку во времени» — это про архив журнала, а не магию.

---

Первое подключение — что вы видите в консоли

Типичный путь (названия кнопок у провайдеров разные, логика одна):

1. Create instance — выбрать движок (PostgreSQL 16), регион (ближе к приложению), класс CPU/RAM, размер диска.
2. Credentials — мастер-пользователь и пароль (или IAM-аутентификация, где поддерживается).
3. Network — VPC, подсеть, «публичный доступ: нет» для prod.
4. Backup — включить автоматические snapshot, retention (например 7 или 35 дней).
5. Получить endpoint → прописать в приложении вместо localhost.

postgresql://app_user:****@mydb.abc123.eu-west-1.rds.amazonaws.com:5432/shop
         ^роль      ^секрет  ^хост провайдера                      ^порт ^БД

Разработчик подключается так же, как к «своему» серверу — через драйвер (psycopg, JDBC). Отличие — хост в интернете/VPC и политика SSL.

---

Бэкап в облаке — на что смотреть

Вопрос	Зачем спрашивать	Пример
Retention	Хватит ли окна для «удалили таблицу 3 недели назад»	7 дней — мало; 35 — чаще достаточно
Авто vs ручной snapshot	Перед крупной миграцией — точка отката «здесь и сейчас»	Snapshot перед ALTER на 200 ГБ таблице
Cross-region copy	Падение целого региона AWS/GCP	Replica + snapshot в другом регионе
pg_dump	Перенос версии, одна таблица, аудит	Дополняет snapshot, не заменяет
Object storage (S3)	Дешёвое долгое хранение	Дольше восстановление

Snapshot vs pg_dump простыми словами:

• Snapshot — фотография диска сервера БД целиком; быстро восстановить весь инстанс; нужен доступ к облачной консоли/API.
• pg_dump — логический экспорт SQL/архива; удобно перенести одну БД на ноутбук или в другую версию PG; восстановление может идти часами на больших объёмах.

В 212.md — резервное копирование в облако для SQL Server; идеи те же.

---

Роль «облачного DBA»

Частые обязанности:

• Terraform / Pulumi / CloudFormation для воспроизводимых окружений;
• секреты в Vault / Parameter Store;
• алерты: disk full, replication lag, connections near max;
• runbook: «как поднять read replica», «как откатить миграцию»;
• согласование с разработкой по конкурентному доступу и длинным транзакциям.

Разработчик в облаке всё равно должен знать SQL и транзакции — managed не прощает N+1 и блокировки на горячих строках.

---

Высокая доступность (HA) в облаке

Типовые паттерны (названия у провайдеров разные, смысл общий):

Паттерн	Что даёт	На что смотреть
Multi-AZ / зона доступности	Standby в другой зоне; failover при падении AZ	Время переключения, потеря ли последних секунд (RPO)
Read replica	Масштаб чтения, отчёты не бьют по primary	Lag реплики, что replica не для emergency write
Cross-region replica	DR при падении региона	Стоимость, задержка, конфликт при split-brain (редко)
Connection pooler (RDS Proxy, PgBouncer)	Стабильнее при множестве коротких коннектов от Lambda/K8s	Лимит max_connections на маленьких инстансах

Failover — не «магия»: приложение должно переподключаться (pool с retry), DNS/endpoint меняется у провайдера, возможен краткий разрыв сессий.

---

Стоимость — за что платите

Managed-счёт обычно складывается из:

• инстанс (vCPU, RAM) × часы;
• хранилище (ГБ/месяц, тип диска gp3/io2);
• IOPS сверх базового лимита;
• исходящий трафик и бэкапы в object storage;
• лицензии (Oracle/SQL Server в облаке дороже open-source PG).

«Подняли db.t3.micro» дешево, пока не выросли данные и не включили HA + 35 дней PITR. FinOps и DBA вместе смотрят стоимость на запрос (CPU wait, disk queue depth), а не только размер инстанса.

---

Runbook — три частых инцидента

1. Диск заполнен

Симптомы: could not extend file, алерт 95% disk. Действия: найти рост WAL (долгий checkpoint, архив не уходит), логи, временные файлы; расширить том; VACUUM/очистка bloat — не паника DELETE без анализа.

2. Слишком много подключений

Симптомы: too many connections. Действия: PgBouncer / RDS Proxy, уменьшить пул в приложении, найти утечку «забыли закрыть connection», не поднимать max_connections бесконечно.

3. Отставание реплики

Симптомы: replication lag растёт. Действия: тяжёлый DDL на primary, долгая транзакция, медленный диск на replica; не гонять отчёты на отстающую реплику с «свежими» цифрами.

Каждый пункт должен быть заранее в Confluence/runbook, а не импровизацией в 3 ночи.

---

Синий/зелёный релиз и миграции схемы

При крупных миграциях в облаке иногда поднимают новый инстанс с новой схемой, переключают приложение DNS/secret, старый гасят — аналог blue-green на уровне БД. Это снижает риск «долгого ALTER на prod», но требует продуманной синхронизации данных на переходный период (dual write, CDC).

---

Managed (RDS и аналоги) и своя VM с PostgreSQL

Критерий	Своя VM / on-prem	Managed (RDS, Cloud SQL, …)
Время до prod	Дольше: ОС, патчи, мониторинг	Быстрее: endpoint за минуты
Контроль параметров	Почти полный postgresql.conf	Whitelist + тикет в поддержку
Ответственность за ОС	Ваша	Провайдера
Ответственность за SQL/схему	Ваша	Ваша
DR между регионами	Сами строите	Кнопки + доп. плата
Стоимость при стабильной нагрузке 3+ года	Иногда ниже (CapEx)	OpEx, рост с диском и HA
Аудит «мы не трогали файлы PG»	Сами	Провайдер + ваши миграции

Выбор где провести границу shared responsibility: команда сильна в IaC и слаба в железе — managed; нужен PostGIS + экзотика + тюнинг ядра — чаще своя установка или гибрид.

---

Когда облако не панацея

• жёсткие требования только on-prem (отраслевой регулятор);
• предсказуемая огромная нагрузка 24/7 — иногда dedicated железо дешевле;
• нужны экзотические расширения или тонкая настройка ядра PG;
• latency к облаку неприемлема для цеха/банкомата on-edge.

---

Контрольные вопросы

1. Назовите три задачи, которые остаются у клиента даже в fully managed PostgreSQL.
2. Чем snapshot провайдера отличается от pg_dump?
3. Что такое RPO и как связано с окном хранения WAL/бэкапов?
4. Почему открытый в интернет порт БД — проблема и процесса, и безопасности?
5. Чем read replica отличается от standby для failover?
6. Назовите два компонента, из которых обычно складывается счёт за managed PostgreSQL.
7. В каких двух случаях своя VM с PostgreSQL может быть предпочтительнее RDS?

---

См. также

• Управление реляционными СУБД
• Справочник PostgreSQL
• Роль базы данных в организации
• Основы NoSQL — managed (сравнение подходов к эксплуатации)

---