← назад к разделу

Диск под базой заполнился в три часа ночи, а резервная копия последний раз снималась вручную месяц назад. Тот, кто держал PostgreSQL на своей машине, эту ночь помнит. Главная ценность облака для разработчика — не виртуальные машины, а именно это: рутина вокруг данных переложена на провайдера.

Но «управляемый» не значит «беззаботный». Провайдер снимает копии и меняет сломанный узел, а схему, индексы и защиту от повторной обработки сообщения делаете вы, как и раньше. В этой статье — четыре вида управляемых данных, общие для всех провайдеров, и честная граница между «делает облако» и «делаете вы».

Главное

  • Управляемый сервис — та же технология (PostgreSQL, Redis, Kafka), у которой обслуживанием занимается провайдер: копии, реплики, обновления, замена узла.
  • Не снимается с вас: схема и индексы, лимит соединений и пул, дизайн ключей кэша, идемпотентность потребителей очереди.
  • Очередь доставляет сообщение «хотя бы один раз»: дубли нормальны, и обработчик обязан их переживать.
  • Объектное хранилище — не диск: плоское пространство объектов, доступ по HTTP, любая правка — перезапись объекта целиком.
  • Копии снимает провайдер, а что они восстанавливаются — проверяете вы, до аварии.
  • Своё вместо управляемого берут только с причиной: особая настройка, версия, которой нет у провайдера, или расчёт, где своё дешевле с учётом людей.

Что значит «управляемая база»

Управляемая база — это PostgreSQL (MySQL, другой движок), к которому вы привыкли, только вокруг него автоматика провайдера: резервные копии с восстановлением на момент в прошлом, реплика в другой зоне с автоматическим переключением, обновления версий в заданное окно, метрики из коробки. Вы получаете адрес, пользователя и пароль и подключаетесь обычным драйвером.

Что не снимается. Схема, миграции, индексы и медленные запросы — ваши целиком. Лимит соединений определяет класс машины под базой: чем меньше машина, тем меньше соединений, и десяток копий приложения со своими пулами выедают его незаметно, поэтому размер пула считают от лимита, а не по умолчанию. И восстановление: копии есть, но восстанавливаются ли они и сколько это занимает, надо проверить заранее, иначе в худший день выяснится, что копии битые.

Кэш и очереди

Управляемый кэш — Redis или совместимый с ним движок с кластером, репликами и переключением при сбое на стороне провайдера. Применяют его как обычный Redis: ответы с временем жизни, распределённые блокировки, ограничение частоты запросов. Дисциплина именования ключей, выбор времени жизни и защита от лавины промахов остаются в коде. Главное правило: кэш — не база, данные, потеря которых недопустима, в нём не хранят.

Очереди у провайдеров бывают двух видов, и это разные инструменты. Простая очередь задач: положил задачу, забрал задачу, удалил; ни сервера, ни кластера, оплата за запросы. Брокер событий вроде Kafka: лента, которую независимо читают несколько потребителей, а события хранятся заданный срок. Раздать работу — очередь; несколько подсистем должны переварить одно событие или важна история — брокер.

Общее у обоих одно: доставка «хотя бы один раз». Сообщение придёт повторно, если подтверждение не дошло или потребитель упал между обработкой и подтверждением. Это не сбой, а следствие надёжности, и обработчик обязан быть идемпотентным: повтор не создаёт второй заказ и не шлёт второе письмо.

Объектное хранилище

Файлы на диске машины кончились, а при пересоздании машины пропали — от этого уходят в объектное хранилище, где данные живут отдельно от машин. Модель одна у всех провайдеров: контейнер верхнего уровня, в нём объекты, у каждого — ключ вида images/2026/logo.png. Папок нет, слэши — просто часть имени, пространство плоское.

Доступ только по HTTP, не как к диску: читать можно по частям, а менять по частям нельзя — любая правка означает перезапись объекта целиком. У объектов есть классы хранения: горячие данные дороже за хранение и дёшевы в чтении, архивные — копейки за хранение и доплата за извлечение, часто с минимальным сроком хранения. Временную ссылку на приватный объект дают подписанным адресом с ограниченным сроком жизни, а большие файлы грузят частями, чтобы обрыв связи не начинал всё заново.

Управляемое или своё

Своя база на машине дешевле железом и дороже людьми: кто-то должен снимать копии, обновлять, следить за диском и просыпаться ночью. Для команды из трёх разработчиков без администратора это почти всегда проигрыш. Своё берут с причиной: нужна настройка или расширение, которых у провайдера нет; версия, которую он не поддерживает; или объём, при котором расчёт с учётом людей выходит в пользу своего. Без такой причины начинают с управляемого и не возвращаются.

Глубже: как провайдер держит копии и реплики

Резервная копия у управляемой базы — это ежедневный снимок диска плюс непрерывный журнал транзакций, поэтому восстановиться можно на любой момент внутри окна хранения, а не только на ночь. Окно ограничено: обычно от недели до месяца, глубже него восстанавливать не из чего, и данные, которые должны переживать месяцы, копируют отдельно.

Реплика для отказоустойчивости живёт в другой зоне и получает изменения синхронно: транзакция подтверждается после записи на обе стороны, за это платят задержкой в миллисекунды. При отказе основного узла провайдер переводит адрес на реплику за десятки секунд, и приложение видит это как разрыв соединений — пул должен уметь переподключиться, а не упасть. Реплика для чтения — другая вещь: она отстаёт и разгружает основной узел, но не защищает от его отказа.

Глубже: что провайдер не увидит за вас

Метрики базы приходят сами: загрузка процессора, число соединений, отставание реплики. Но провайдер не знает, какой запрос у вас медленный и почему. Топ запросов по суммарному времени, раздувание таблиц, забытый индекс — это ваша работа с теми же инструментами, что и на своём сервере. Управляемая база снимает эксплуатацию, а не проектирование: разбор планов и индексов остаётся частью ремесла.

Что почитать дальше