Как запустить 1С в облаке на Yandex Managed Service for PostgreSQL и ускорить базу данных

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

Из чего состоит 1С и где в облаке живёт каждый слой

1С — многокомпонентная система, и в Yandex Cloud она раскладывается на три слоя.

Главная техническая ценность такого размещения — управляемая база: надёжное и быстрое хранение данных с восстановлением по требованию. Всё, что платформа «1С:Предприятие» умеет в части архитектуры, в облаке доступно точно так же — базовая инфраструктура 1С не меняется.

Как выглядит целевая схема размещения

Надёжность строится на зонах доступности. Сейчас у Yandex Cloud четыре зоны доступности, и приложение можно разнести по нескольким из них, а не держать на единственном сервере. Для отказоустойчивости достаточно двух или трёх зон.

На целевой схеме три горизонтальных слоя:

• защита и балансировка нагрузки перед веб-приложением;
• сами приложения 1С: веб-сервер, сервер приложений, сервер лицензий;
• управляемая база данных.

Внутренний контур или публикация через веб: как открыть доступ к 1С

Вариантов публикации несколько:

• Внутренний контур. 1С находится в закрытом периметре, доступ идёт через VPN и внутреннюю сеть. Пользователи работают так же, как если бы сервер стоял в инфраструктуре компании.
• Публикация через веб. Вариант сложнее и нужен, когда доступ к 1С требуется внешним контрагентам. Появляется дополнительный слой защиты периметра: во-первых, балансировщик нагрузки Yandex Application Load Balancer, во-вторых, Yandex Smart Web Security, который объединяет защиту от DDoS и WAF и блокирует вредоносный трафик и ботов. В остальном схема та же: кластер 1С и управляемая база данных.

Доступ пользователей тоже можно организовать по-разному: через браузер, через тонкий или толстый клиент.

Два пути к развёртыванию: партнёр или самостоятельно

Разместить свою конфигурацию — «Управление торговлей», «Бухгалтерию» или ERP — можно двумя способами:

• Обратиться к нам: клиентский архитектор, аккаунт-менеджер или служба поддержки посоветуют партнёра Yandex Cloud, который настроит инсталляцию полностью под вас. Это партнёр одновременно и 1С, и Yandex Cloud, он может взять на себя весь комплекс работ.
• Сделать всё самостоятельно по инструкциям из документации. Если в процессе возникнут вопросы, инженеры поддержки подскажут.

Разворачиваем 1С в облаке самостоятельно

Порядок действий при самостоятельном развёртывании выглядит так:

Сколько виртуальных машин нужно под 1С

Зависит от того, какую отказоустойчивость и масштабируемость вы хотите получить. Если система рассчитана на сотни пользователей, роли лучше развести по изолированным серверам. Если нагрузка — 30–50 пользователей, достаточно одного сервера средней мощности, на котором живут все три роли.

А зачем вообще переносить 1С в облако

Есть пять важных причин:

• Железо дорожает. Память подорожала в несколько раз, и покупка нового сервера — заметная статья расходов.
• Эксплуатация — это не только железо. Нужны инженеры, которые настраивают серверы, «1С:Предприятие» и базы данных. Держать такой штат может быть экономически нецелесообразно.
• Масштабирование по требованию. Когда нагрузка выросла, достаточно «подкрутить ползунки»: виртуальная машина или сервер баз данных станет мощнее без капитальных затрат. Когда нагрузка низкая, ресурсы можно сократить.
• Защищённая платформа. Контроль доступа и защита проработаны, решения сертифицированы.
• Кастомизация и интеграции. Если одной 1С недостаточно и нужны интеграции с другими приложениями или аналитикой, их можно развернуть рядом в облаке, например с помощью Yandex Data Transfer.

В сумме это снижает стоимость владения: если сравнить расходы на собственную инфраструктуру с виртуализированной в Yandex Cloud, для многих компаний облако окажется выгоднее.

PostgreSQL для 1С: отличия от стандартной сборки

Специализированная редакция PostgreSQL для 1С — одна из главных особенностей платформы Yandex Cloud. Яндекс — один из крупнейших мировых контрибьюторов в ядро PostgreSQL: у нас есть целое подразделение, которое разрабатывает патчи не для отдельных решений, а непосредственно для ядра. Эта экспертиза позволяет поддерживать редакцию для 1С, вкладываться в её развитие и делать новые патчи, которые повышают производительность 1С.

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

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

Бэкапы: восстановление на момент времени и хранение до трёх лет

«Из коробки» доступно восстановление на произвольный момент времени. Если администратор или пользователь случайно повредил данные или что-то удалил, базу можно вернуть к конкретному моменту.

Политика бэкапов гибкая: глубину хранения можно настроить до 60 дней. Если процессы комплаенса требуют большего, есть механизм LTR — бэкапы длительного хранения, которые лежат в Yandex Cloud до трёх лет, и из них тоже можно восстановиться.

Когда нужна диагностика производительности

Когда мы исследуем производительность базы данных, мы работаем в одной из трёх зон.

• Инцидент идёт прямо сейчас. Продакшен «горит»: распродажа, скидки, больше пользователей, что-то не работает. Нужно максимально быстро найти проблему и купировать её.
• Инцидент был какое-то время назад. Ночью что-то случилось и прошло само собой — или мы, не разбираясь, накинули ресурсов. Наутро хочется понять причину.
• Профилактический осмотр. Самое интересное направление: понимать, адекватна ли нагрузка, не потребляем ли мы больше ресурсов, чем нужно, не стал ли какой-то запрос есть больше CPU или выполняться дольше. Так инцидентов из первых двух категорий можно избегать: если деградация видна заранее, есть время починить запрос.

Почему диагностировать PostgreSQL руками сложно

В PostgreSQL, в отличие от некоторых других промышленных СУБД, статистики много, но она разбросана по разным местам, и нужно знать, где смотреть: pg_stat_activity, pg_locks и другие представления. Историчности они не хранят — чтобы понять, что было некоторое время назад, приходится периодически снимать слепки или довольствоваться агрегированными цифрами.

Дальше — расширения, о которых нужно узнать, поставить и как-то ими управлять: pg_stat_statements со статистикой по запросам, auto_explain, который записывает планы долгих запросов.

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

Диагностика производительности в Yandex Managed Service for PostgreSQL

Диагностика производительности закрывает большую часть этих задач.

• Верхнеуровневый обзор по pg_stat_activity в разрезах по хостам, базам данных и пользователям: кто наиболее активен, какие виды блокировок встречаются, какие запросы чаще всего на них зависают.
• Слепок pg_stat_activity на любой момент времени с точностью до интервала сбора — например, какие запросы выполнялись позавчера в 03:12 и на чём они висели.
• Агрегированная статистика по запросам: какие выполняются долго, сколько ресурсов едят, попадают ли в кеш, используют ли JIT.

Режимов два — стандартный и расширенный, оба бесплатные:

Переключение между режимами происходит без рестарта PostgreSQL, если диагностика уже включена, — экспериментировать безопасно.

Кейс № 1: продакшен «горит», CPU на 100%

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

Демонстрационный кластер — PostgreSQL 18, два ядра и 8 ГБ оперативной памяти. Нагрузку мы дали через pgbench: лёгкие запросы шли в районе 50 транзакций в секунду, а тяжёлые выполнялись очень медленно — 0,2 транзакции в секунду.

План можно смотреть в виде графа, в классическом текстовом виде PostgreSQL или как JSON для внешнего аналитического инструмента. Классический текст оказался удобнее всего.

Что было в плане

PostgreSQL оценивал выполнение примерно в 110 тыс. условных единиц стоимости. Спускаясь по узлам к самому дорогому, мы нашли nested loop, на который приходилось 95% стоимости запроса.

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

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

Какой индекс исправил ситуацию

Проверка индексов показала: индекс по скору есть, но он плохой, и планировщик его не выбирает. Нужен свой индекс на таблице events, в котором точно должна быть категория. Мы собрали его так:

• поля category_id и score — по ним идёт выборка, хотя скор не очень селективен;
• условие processed = false — вместо того чтобы класть низкоселективное поле в индекс, сделали частичный индекс только по необработанным событиям, потому что обработанные обычно нужны только аналитике;
• INCLUDE (user_id) — соединение с users идёт по user_id, и чтобы не ходить за ним в таблицу, добавили поле в индекс.

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

Что изменилось

За пять минут у запроса появился второй план. На графике видно момент, когда старый план сменился новым — как раз когда создался индекс. Новый план выполнился уже гораздо больше раз и потребил гораздо меньше ресурсов: максимальное время упало с 14 787 мс до 510 мс. Те же index scan, но по нужному индексу и без цикла.

CPU при этом остался загружен на 100%: нагрузка действительно высокая, и в такой ситуации базу нужно масштабировать. Но с теми же ресурсами мы стали делать больше работы: лёгкие запросы дошли до 63–70 транзакций в секунду, а тяжёлые ускорились с 0,2 до 7,5 транзакции в секунду — примерно в 15 раз или больше.

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

Кейс № 2: ночной инцидент, который прошёл сам

Второй сценарий — разбор постфактум. Звонили около восьми вечера, на графиках в это время видны аномалии. Переходим к нужному окну: CPU в порядке, с диском и сетью проблем нет. Но среди аномалий видно, что один запрос выполнялся нетипично долго для нашей нагрузки — около 7–9 минут. Запоминаем время: 20:20.

Дальше — вкладка History в диагностике производительности, это слепки pg_stat_activity. Открываем 1 апреля, 20:20. Видим три запроса, два из них висят на блокировках: один пытался обновить заказ с конкретным идентификатором, второй делал SELECT ... FOR UPDATE, чтобы потом обновить. Держала их транзакция, которую кто-то из разработчиков забыл закрыть — что-то делал с заказами руками. На практике причина часто другая: длительный аналитический запрос или ночная очистка базы, которая неожиданно что-то блокирует.

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

Сколько стоит включённая диагностика

Сбор статистики по запросам работает через хуки, которые выполняются до и после каждого пользовательского запроса, — это не бесплатно. С каждой версией PostgreSQL накладные расходы pg_stat_statements снижались, и на новых версиях — 16, 17, 18 — они минимальны, на 15-й чуть дороже.

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

Обычно о диагностике вспоминают, когда инцидент уже идёт, а она не включена, — и постфактум это не помогает. Поэтому включать её стоит заранее. Расширенный режим полезен, когда мало видеть дорогие запросы и хочется понимать, почему они дорогие: не всегда получится выполнить EXPLAIN ANALYZE в продакшене в нужный момент. Запрос с INSERT или UPDATE днём может работать нормально, а ночью — плохо, потому что после удаления данных изменился план. Если план ночью не записан, днём этого уже не отследить.

Как включить диагностику и какой интервал выбрать

Диагностика доступна на любых версиях. При создании или редактировании кластера есть блок «Диагностика производительности», обычно по умолчанию он выключен. В нём выбирают стандартный или расширенный режим и интервалы сбора. Мы советуем минимальные интервалы — 5 или 60 секунд: статистика получается гранулярнее, а на нагрузку это не влияет, интервал лишь определяет, как часто выполняются служебные запросы к базе.