Масштабирование

Managed Postgres предоставляет возможности гибкого масштабирования в соответствии с требованиями вашей рабочей нагрузки. Доступно более 50 типов инстансов с NVMe-накопителями, поэтому вы можете независимо масштабировать CPU, память и хранилище, чтобы оптимизировать производительность и стоимость под свой сценарий использования.

Типы инстансов и гибкость

Managed Postgres предлагает широкий выбор типов инстансов, каждый из которых оптимизирован под разные рабочие нагрузки:

Более 50 типов инстансов доступны в конфигурациях, оптимизированных по вычислительным ресурсам, памяти и хранилищу
NVMe-хранилище на всех типах инстансов обеспечивает стабильно высокую производительность дискового ввода-вывода
Независимое масштабирование ресурсов: выбирайте оптимальный баланс CPU, памяти и хранилища в зависимости от вашей рабочей нагрузки

Выбор подходящего типа инстанса

Для разных рабочих нагрузок подходят разные конфигурации ресурсов:

Тип рабочей нагрузки	CPU	Память	Хранилище	Рекомендуемый инстанс
С упором на вычисления	Высокий	Средний	Среднее	Оптимизированный для вычислений (большое число vCPU)
С упором на память (большой рабочий набор)	Средний	Высокий	Среднее	Оптимизированный для памяти (высокое соотношение памяти к CPU)
С упором на хранилище (большие датасеты, интенсивный I/O)	Средний	Средний	Высокое	Оптимизированный для хранилища (большая ёмкость NVMe)

Как работает масштабирование

При смене типа инстанса Managed Postgres выполняет вертикальное масштабирование: подготавливает новую инфраструктуру и переносит вашу базу данных с минимальным простоем.

Процесс масштабирования

В процессе масштабирования из резервных копий поднимается новый резервный инстанс и выполняется контролируемый failover:

Подготовка резервного инстанса: Создаётся новый резервный инстанс с целевым типом инстанса (CPU, память и конфигурация хранилища)
Восстановление из резервных копий в S3: Резервный инстанс инициализируется восстановлением из самой свежей резервной копии, хранящейся в S3
Параллельное воспроизведение WAL: Резервный инстанс применяет все изменения Write-Ahead Log (WAL), произошедшие с момента создания резервной копии, с помощью механизмов параллельного восстановления на базе WAL-G
- WAL-G обеспечивает быстрые параллельные операции восстановления
- Создатель WAL-G входит в команду Ubicloud, с которой мы сотрудничаем, что обеспечивает глубокую экспертизу и оптимизацию
Догоняющая репликация: Резервный инстанс догоняет основной, потоково получая и применяя текущие изменения WAL
Failover: Когда резервный инстанс полностью синхронизирован, контролируемый failover переводит его в роль нового основного
- Это единственный шаг, который вызывает простой (~30 секунд)
- Все активные соединения прерываются во время failover
- После завершения failover клиентам необходимо переподключиться
Вывод старого инстанса из эксплуатации: Исходный инстанс выводится из эксплуатации после завершения failover

Продолжительность масштабирования

Общее время, требуемое для масштабирования, в первую очередь зависит от размера вашей базы данных и объема данных WAL, которые нужно воспроизвести из резервных копий:

Восстановление резервной копии: время, необходимое для восстановления последней полной резервной копии из S3 на новый инстанс
Воспроизведение WAL: время, необходимое для воспроизведения инкрементальных изменений WAL с момента последней полной резервной копии
Параллельное восстановление: механизмы параллельного восстановления WAL-G значительно ускоряют процесс

Время восстановления может составлять от нескольких минут до нескольких часов, но время обслуживания/простоя при этом очень мало (всего ~30 секунд).

Минимальный простойВо время переключения на резервный инстанс ваше приложение будет недоступно примерно 30 секунд, независимо от того, сколько времени займет весь процесс масштабирования. Все восстановление и догоняющая синхронизация выполняются в фоновом режиме на резервном инстансе.

Параллельное восстановление с WAL-G

Managed Postgres использует WAL-G для ускорения восстановления из резервных копий во время операций масштабирования. Важно отметить, что создатель WAL-G входит в команду Ubicloud, с которой мы сотрудничаем, что добавляет процессу восстановления глубокую экспертизу. WAL-G обеспечивает:

Параллельную загрузку и распаковку: Несколько сегментов резервной копии одновременно загружаются из S3 и распаковываются
Эффективное воспроизведение WAL: Инкрементальные изменения WAL по возможности применяются параллельно
Оптимизированную потоковую передачу: Прямая потоковая передача из хранилища S3 без промежуточного копирования
Быстрое восстановление: Хотя общее время зависит от объема данных, параллельный подход заметно ускоряет этот процесс

Эти оптимизации значительно сокращают время, необходимое для ввода в работу нового резервного инстанса. Что особенно важно, восстановление полностью выполняется в фоновом режиме — ваше приложение столкнется с простоем только во время короткого, примерно 30-секундного окна failover.

Запуск операции масштабирования

Чтобы масштабировать инстанс Managed Postgres:

Перейдите на вкладку Настройки вашего инстанса
В разделе Масштабирование прокрутите страницу до пункта Размер сервиса
Выберите целевой тип инстанса
Просмотрите изменения и нажмите «Применить изменения»

Стратегии масштабирования

Вертикальное масштабирование

Вертикальное масштабирование (смена типа инстанса) — основной способ изменения объёма ресурсов в Managed Postgres. Этот подход обеспечивает:

Точную настройку: Выбирайте из более чем 50 типов инстансов, чтобы точно подобрать CPU, память и хранилище
Оптимизацию под рабочую нагрузку: Выбирайте конфигурации, оптимизированные под конкретную рабочую нагрузку (с упором на вычисления, память или хранилище)
Экономичность: Платите только за те ресурсы, которые вам нужны, без избыточного выделения

Реплики для чтения для горизонтального масштабирования

Для рабочих нагрузок с преобладанием чтения рассмотрите возможность использования реплик для чтения для горизонтального масштабирования производительности чтения:

Перенесите запросы на чтение на выделенные реплики для чтения
Каждая реплика для чтения — это полностью независимый инстанс Postgres с собственными вычислительными ресурсами и памятью
Реплики для чтения получают изменения WAL из Объектного хранилища, что обеспечивает эффективную репликацию

Этот подход идеально подходит для приложений с высоким соотношением операций чтения к записи, таких как отчетные панели мониторинга, аналитические запросы или конечные точки API с преобладанием чтения.