«Управляемый» (managed) сервис — это когда вы пользуетесь технологией, а её обслуживанием занимается провайдер. Своя база на сервере — это вы сами ставите PostgreSQL, настраиваете резервные копии, по ночам чините, когда диск заполнился. Управляемая база — та же PostgreSQL, но копии, замену сломанного узла и обновления делает Yandex Cloud. Вы платите за это деньгами, но не временем и не бессонными ночами.
Главная ценность облака для backend-разработчика — не виртуальные машины, а именно управляемые данные: базы, кэши, очереди и брокеры, у которых рутина переложена на провайдера. Эта статья — карта соответствий «то, что вы знаете по своему серверу → как это называется в Yandex Cloud», и честный список того, что managed-сервис за вас не делает.
Managed Service for PostgreSQL
Managed Service for PostgreSQL — это тот же PostgreSQL, к которому вы привыкли, только вокруг него автоматика: резервные копии с восстановлением на момент в прошлом, реплики, обновления версий в заданное окно. Аналог RDS в AWS.
Главное для новичка: managed-база снимает с вас эксплуатацию железа, но не проектирование данных. Она спасёт от сгоревшего диска, но не от запроса SELECT без индекса, который перебирает миллион строк. Схема таблиц, индексы, блокировки, безопасные изменения структуры без остановки, тюнинг медленных запросов — всё это по-прежнему ваша работа.
Для высокой доступности можно поднять хосты в разных зонах доступности: при отказе основного облако само переключит нагрузку на реплику. А грабли, на которые наступают почти все, — лимит соединений: у базы есть максимум одновременных подключений, и десяток приложений со своими пулами выедают его незаметно. Лечится дисциплиной размеров пулов и пулером соединений (например, встроенным менеджером подключений).
Помимо PostgreSQL, в том же семействе есть управляемые MySQL, ClickHouse, Greenplum, OpenSearch и MongoDB — модель у всех одинаковая.
Managed Service for Redis (кэш)
Кэш — быстрое временное хранилище, куда кладут уже посчитанный результат, чтобы не считать заново. Managed Service for Redis (на движке Valkey — открытый форк Redis) даёт управляемый кэш: кластер, реплики и переключение при сбое настраивает облако. Аналог ElastiCache в AWS.
Применяют его как обычный Redis:
- кэширование ответов с временем жизни (TTL — через сколько секунд запись исчезнет);
- распределённая блокировка — чтобы две копии приложения не сделали одну операцию дважды;
- ограничение частоты запросов (rate limiting).
Главное правило новичку: кэш — это не база данных. Данные, потеря которых недопустима (заказы, платежи), в нём не хранят: кэш может сбросить содержимое в любой момент.
Message Queue (очередь)
Message Queue — управляемая очередь сообщений, совместимая с протоколом Amazon SQS. Очередь развязывает отправителя и получателя: приложение кладёт задачу в очередь и идёт дальше, а обработчик разгребает её в своём темпе. Так сглаживают всплески нагрузки и не теряют задачи, если обработчик временно недоступен.
Совместимость с SQS удобна практически: подходят те же библиотеки и подходы, что для AWS. Очередь часто служит триггером для Cloud Functions — сообщение пришло, функция обработала.
Managed Service for Apache Kafka
Когда нужна не простая очередь, а поток событий, который читают несколько независимых потребителей и перечитывают историю, берут Managed Service for Apache Kafka — тот же Kafka, но с эксплуатацией на стороне облака. Аналог MSK в AWS. Разницу между очередью и брокером-логом, а также устройство самого Kafka разбирает раздел Kafka.
Управляемый против своего: как выбирать
| Управляемый | Свой на сервере | |
|---|---|---|
| Эксплуатация | Копии, переключение, обновления — облако | Всё ваше, включая три часа ночи |
| Цена | Надбавка к стоимости железа | Дешевле железом, дороже людьми |
| Контроль | Версии и параметры из списка облака | Любые расширения и тонкая настройка |
Разумное правило по умолчанию: компоненты с состоянием (базы, кэши, очереди) берём управляемыми, пока нет конкретной причины делать иначе — например, нужно расширение PostgreSQL, которого нет в управляемом варианте. Прежде чем самому обслуживать базу при доступном managed-сервисе, честно ответьте, на что команда потратит время, которое сервис ей освобождает.
Где это применяется
Управляемые данные — это костяк почти любого сервиса: база под основные данные, кэш перед ней, очередь для фоновых задач, брокер для событий. Всё это живёт во внутренней сети без публичных адресов и доступно приложению через привязанный сервисный аккаунт.
Типичные ошибки новичков:
- хранят важные данные в кэше — теряют их при сбросе;
- выедают лимит соединений к базе без пулера;
- берут свой сервер там, где хватило бы managed, и тонут в эксплуатации;
- выдают базе публичный IP ради удобства — открывают её сканерам.
Что учить дальше: когда обычной базы мало и нужен горизонтальный масштаб — YDB; файлы и большие объекты — объектное хранилище; как обращаться к этим сервисам из кода — Yandex Cloud из Spring Boot. Та же карта соответствий есть в AWS — сравните с управляемыми данными в AWS.