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

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

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

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

Провайдер держит копии, патчит и меняет сломанный узел. Схема, индексы, размер кэша и защита от повторной обработки сообщения остаются вашими, как и при своей установке.

Обязательно

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

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

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

Кэш и очереди

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

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

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

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

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

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

Управляемое или своёспросят на собеседовании

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

Дополнительно: при первом чтении можно пропустить

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

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

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

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

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

Глубже: клиент провайдера и повторы: что он делает сам на 429 и 503расширенное

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

Что делает сама. У каждого API провайдера есть ограничение частоты, и превышение отвечает не ошибкой, а просьбой подождать: 429 или его аналог (ThrottlingException, RESOURCE_EXHAUSTED), а временные сбои дают 503. Библиотеки всех трёх крупных провайдеров повторяют такие ответы сами, с растущей паузой и случайным разбросом, обычно три попытки; у AWS есть и адаптивный режим, который сам снижает темп при серии отказов. Повторяются только вызовы, которые библиотека считает безопасными для повтора; запись без ключа идемпотентности повторится как есть, и дубль это ваша забота, о чём раздел про очереди.

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

Вторая ошибка: не заметить, что повторы уже идут. Задержка вызова выросла с 20 мс до двух секунд без единой ошибки в логе: это библиотека молча повторяла. Включают журнал попыток на уровне библиотеки и метрику числа повторов, по ней виден приближающийся предел частоты раньше, чем он ударит. Идентификатор запроса из ответа провайдера пишут в журнал: с ним поддержка провайдера найдёт вызов, без него нет.

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

Коротко

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

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