Подкармливаем «химией» 1С, или Как обеспечить масштабирование вашей 1С-системы

Привет! Меня зовут Александр Леонов, я работаю в Magnit Tech. В этой статье я расскажу существующих способах масштабирования вашей 1С-системы.

Начну со слов великого автора:

1С – самая лучшая в мире платформа © Антон Дорошкевич

Если вы в этом сомневаетесь, я сейчас докажу, почему это действительно обоснованно:

• Во-первых, практически все пользователи умеют работать с 1С. Нет бухгалтера, который никогда не видел 1С-систему. В любой компании пользователи понимают, что такое 1С, знакомы с элементами интерфейса, и проблем с освоением новых решений на 1С у них не возникает.

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

• Для изучения 1С есть огромная база знаний и сообщество – сайт и конференция Инфостарта этому подтверждение. Есть сформированный рынок специалистов и курсы с возможностью подтвердить качество своих знаний через сертификацию. В таких условиях, как правило, нет проблемы найти специалиста, способного реализовать ваши бизнес-кейсы.

• Лицензии 1С стоят не так уж дорого – даже сверхмалый бизнес может купить себе 1С:Розницу и развернуть ее локально или в облаке. Более того, для разработчиков есть бесплатные лицензии на платформу – устанавливайте, изучайте, развивайтесь. Все это делает продукты 1С доступными.

• Но главное в 1С-системе – это ее высокая производительность. Платформа 1С действительно может работать очень быстро – с единственной ремаркой – «в прямых руках». Если вы все делаете правильно – выбираете правильную архитектуру, пишете красивый, классный, чистый, производительный код – все в 1С работает замечательно.
   

Фирма «1С» уже давно системно работает в направлении производительности: проводятся нагрузочные тесты, публикуются результаты и планируются задачи по улучшению платформы.

1С-платформа уверенно демонстрирует работу на 12 и даже на 30 тысячах одновременно работающих пользователей, сохраняя при этом хорошие показатели APDEX. И это действительно впечатляет.

Конечно, есть отдельные нюансы – например, непонятно, как при таких нагрузках будет производиться закрытие месяца.

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

Что же есть в арсенале для роста?
 

Давайте разберемся, какие механики и подходы есть в 1С для достижения высокой производительности.

Базовый уровень оптимизации, с которым сталкиваются практически все – это варианты развертывания.

• Для небольших систем есть файловая база – в нее мы можем без проблем подключить 5-10 пользователей.

• Далее к файловой базе можно добавить веб-сервер, и это уже позволит запустить в вашу систему 1С чуть больше пользователей и дать им возможность подключаться к работе из любой части земного шара.

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

• И, наконец, лучший инструмент для повышения производительности в 1С – это сервер приложения 1С. В нем сконцентрирована вся сила и мощь платформы, без него достижение максимальных показателей производительности было бы невозможно.
   

Многие скажут, что сервер 1С – это что-то на богатом, и он нужен только для отказоустойчивости. Но сервер 1С – это еще и про производительность.

• Производительность достигается за счет практически неограниченного масштабирования – платформа позволяет подключить в ваш кластер 256 рабочих серверов. Если ресурсов не хватает, вы можете распараллелить нагрузку и добавить еще один сервер, а потом еще один. За счет горизонтального масштабирования система может обрабатывать огромную нагрузку.

• Кроме того, платформа позволяет гибко разделять различные операции по рабочим серверам за счет требований назначения функциональности (ТНФ). Вы можете выносить отдельные вычисления или функции на специализированное «железо»: например, использовать серверы с GPU для работы конкретной библиотеки, которой нужны быстрые вычисления. Либо добавить сервер с быстрыми дисками, и отдельные операции, которым требуется быстрое сохранение данных на диск, выносить туда.

• Вы можете настраивать потребление ресурсов – если у вас на сервере работает не только 1С, но и другие приложения, вы можете распределять нагрузку между ними.

• У платформы 1С очень умная балансировка нагрузки между рабочими серверами. Мы об этом часто забываем, но по меркам других платформ это серьезное преимущество. 1С практически в реальном времени оценивает мощность серверов и скорость обработки запросов, определяет доступные ресурсы и в зависимости от этого балансирует нагрузку. Здесь, конечно, возможны отдельные нюансы, но в целом механизм работает очень эффективно.

• Еще один важный механизм – кэширование данных. При обращении пользователей к СУБД данные могут сохраняться в кэше, что позволяет существенно сократить количество обращений к базе данных. Механизм кеширования в платформе работает «из коробки», но им тоже важно уметь правильно пользоваться.

• И это далеко не все – в платформе реализовано огромное количество возможностей, которые позволяют достигать действительно высокой производительности.

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

Но есть важный момент. Если на сервере приложений возникли проблемы с производительностью, сначала стоит сделать следующее:

• Выполнить оптимизацию наиболее критичных мест и оценить потенциальный объем дополнительной оптимизации.

• Взвесить все «за» и «против» – если стоимость оптимизации дороже, чем покупка железа, покупаем железо и добавляем.

• Не забывайте про отказоустойчивость – серверы в кластере должны быть распределены по разным физическим машинам и так далее.
   

Следующий неотъемлемый элемент современной системы 1С – это веб-сервер.

При масштабировании 1С с помощью веб-сервера вы тоже наверняка не испытаете особых проблем, потому что здесь все построено на стандартных и общеизвестных технологиях Apache и IIS, для которых методы балансировки нагрузки уже давно придуманы.

Если нужно больше производительности, просто поднимаете еще один веб-сервер и настраиваете для него балансировку.

Можно поиграться с вариантами развертывания, например:

• Разделять разные веб-серверы с разными эндпоинтами по видам трафика – настроить, чтобы на первый сервер шли только клиентские соединения, а на второй – вызовы HTTP сервисов.

• Использовать прокси-сервер с единым endpoint, который будет перенаправлять запросы в зависимости от их типа или параметров.

Кроме этого, существуют специализированные балансировщики нагрузки на веб-сервере – например, Nginx, HAProxy, по их использованию для масштабирования 1С уже накоплено большое количество инструкций. Для них можно настроить несколько вариантов балансировки нагрузки:

• Round Robin – самый простой вариант, когда запросы распределяются между серверами поочередно.

• Weighted Round Robin (Round Robin с весами) – распределение с учетом мощности серверов, где вы сами настраиваете, что этот сервер мощный, на него нужно отдавать 70% нагрузки. А вот эти два – слабые, на них по 15%. И они будут распределяться вот в таком соотношении.

Итого, все проблемы с веб-сервером мы можем победить. Да и на сервере приложений нерешаемых проблем тоже практически нет.

Что есть для СУБД

Но есть в масштабировании 1С узкое горлышко – это СУБД. Добавить еще один сервер приложений легко, а вот еще одну СУБД мы к базе 1С так просто не добавим. В строке подключения она всегда указывается одна, и 1С об этом знает. В этом смысле СУБД можно назвать своеобразной «ахиллесовой пятой» в архитектуре 1С-системы.

Именно на уровне СУБД мы сталкивались с наибольшим количеством сложностей, и о них я сейчас расскажу.
 

Первый инструмент, который платформа 1С может предложить для масштабирования СУБД – это хранилище двоичных данных, технология, решающая проблему чрезмерного роста базы данных и высокой нагрузки на запись и чтение.

Если вы храните у себя в базе двоичные данные или большие тексты, то хранилище двоичных данных решает проблему излишнего роста базы. Включаете эту настройку и задаете порог размера данных – все, что превышает этот порог, будет автоматически сохраняться не в базе данных, а во внешнем хранилище. Но здесь есть нюансы:

• Хранилище двоичных данных работает только при наличии лицензии КОРП.

• Для его работы требуется режим совместимости больше чем 8.3.21.

У механизма хранилища двоичных данных есть несколько особенностей:

• Данные файлов хранятся на стороне сервера приложений 1С – во внутреннем формате или в объектном S3-хранилище. В отличие от обычного хранения в базе данных или в каталогах, для хранилища двоичных данных доступны кластеризация и отказоустойчивость на высшем уровне – вы можете очень быстро записывать данные и не бояться, что они пропадут.

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

• Запись и чтение из хранилища двоичных данных происходят автоматически – 1С сама определяет, что размер данных выше порога, значит, их нужно записать в хранилище, а в СУБД поместить ссылку на эту запись. А при чтении данных 1С видит ссылку и сама идет в хранилище, подгружает данные оттуда и возвращает их в результате запроса. При этом все работает так, как будто все данные хранятся в СУБД. То есть для поддержки этого механизма вам не потребуется ни одной дополнительной строчки кода – все будет делать сама платформа.

• Можно использовать несколько хранилищ – реализовать своего рода «охлаждение» данных. Новые данные писать в быстрое и производительное хранилище, а старые – переносить на более дешевые диски.
   

Если у вас нет КОРП-лицензии, для механизма хранилища двоичных данных есть альтернатива – библиотека для БСП, позволяющая хранить файлы на S3 (minio, Amazon S3, Mail.Ru Cloud и т.п.).

Библиотека подключается к существующей функциональности БСП через расширение и позволяет подсистеме «Работа с файлами» использовать сохранение данных в S3.

Решение абсолютно открытое, можете скачать на GitHub и попробовать.
 

Но даже если мы вынесем все большие данные из СУБД во внешние хранилища, проблемы все равно могут оставаться, потому что нагрузку на диск создают не только файлы, но и обычные записи в регистры. И с этим тоже нужно уметь справляться.

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

• Например, вы можете настроить, что одни таблицы будут храниться в одном файле, другие – в другом, а индексы вынести отдельно. Можете разнести эти файлы по разным дискам – для одних данных использовать быстрые диски, для других – не очень. Это будет классно и быстро работать.

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

• Главный плюс встроенного механизма секционирования – эти настройки не слетают при обновлении. В случае реструктуризации таблиц все настройки сохранятся, и вам не придется ничего дополнительно проверять – все будет работать как есть.
   

Но если проблема производительности возникает из-за огромной таблицы, встроенное секционирование уже не спасает. Например, у нас встречались таблицы размером в десятки терабайт – при их интенсивном чтении или записи возникала огромная нагрузка на диск и СУБД.

В таких ситуациях тоже применяют секционирование – но уже нелегально и на свой страх риск, на стороне самой СУБД.

• Например, делят таблицу и ее индексы по определенному критерию – чаще всего, по периоду. Данные за один год – в одной секции, за другой – в следующей, и так далее. Тогда при запросах с отбором по периоду СУБД не просматривает всю таблицу целиком, а работает только с нужной секцией. Это заметно ускоряет получение результата и снижает нагрузку на систему.

• Дополнительный профит – появляется возможность быстро обрезать старые данные. Если раньше обрезка огромной таблицы могла занимать недели или даже месяц, то, используя секционирование, можно удалить целый раздел с данными по прошлым периодам буквально за пару секунд.

• Однако у секционирования на стороне СУБД есть особенность – при реструктуризации таблицы все настройки разделов сбрасываются. Но если вы знаете, что размер вашей таблицы 10 терабайт, то наверняка к любым изменениям ее структуры вы относитесь осторожно и взвешенно. Мы, например, за этим внимательно следим и стараемся не допускать.

Разбивать данные можно не только по периодам, но и по организациям, по контрагентам, и вообще логическим наборам данных, которые подходят под вашу модель. Это вполне корректно реализуется на стороне СУБД и дает ощутимый прирост производительности.

В качестве примера можно изучить статью о методике секционирования в SQL – возможно, она будет для вас полезна.
 

Казалось бы, если мы сняли нагрузку с дисков, значит, главная проблема производительности СУБД на высоконагруженных системах уже решена.

Но на самом деле, помимо диска на работу СУБД могут влиять ограничения в ресурсах процессора, оперативной памяти и даже задержки при передаче данных по сети.

Кроме этого, у СУБД есть технические «узкие горлышки» из-за специализированных очередей, которые вы тоже не сможете разделить и все равно упретесь в нагрузку. Об этом коллеги рассказывали на прошлой конференции Инфостарта – очень интересный технический доклад, рекомендую его посмотреть, особенно если вы уже сейчас подошли к пределу возможностей вашей СУБД.
 

А поскольку фирма «1С» понимает, что для повышения производительности СУБД недостаточно решить только проблему нагрузки на диск, в платформе развивается механизм копий.

Основная идея механизма копий заключается в том, что мы, насколько это возможно, разделяем нагрузку на чтение (OLAP) и нагрузку на запись (OLTP) – для этого мы подключаем к серверу 1С копию базы и используем ее для операций чтения.

Копия базы на чтение, создаваемая в рамках этого механизма, может быть либо полная, либо частичная. И актуализируется она либо средствами 1С, либо средствами самой СУБД.

Причем для хранения копии вы можете использовать не только стандартную СУБД, но и СУБД in memory – фирма «1С» назвала такую СУБД Дата акселератор. Если использовать Дата акселератор, копия базы будет находиться в памяти на сервере приложения 1С, и все данные в ответ на запросы механизм будет читать из памяти.

Но здесь есть нюанс: все таблицы, которые используются в запросе, должны быть в копии. Если какой-то таблицы не хватает, запрос пойдет в основную СУБД. Поэтому тут нужно прям четко понимать, какие именно данные нужны в запросе, используя для автоматического определения таких таблиц специальную обработку от фирмы «1С».

Ну и не забывайте про отказоустойчивость. Как только вы начали использовать реплику на чтение, она перестает быть просто репликой – это уже полноценный рабочий сервер. А значит, ей тоже нужно быть отказоустойчивой – с резервированием и масштабированием, что подразумевает добавление под нее серверов.

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

У механизма копий может быть альтернатива – механизм снапшотов на уровне ОС или СХД.

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

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

Это не полноценное масштабирование, но в пиковые моменты – вполне рабочий вариант.
 

И последний способ снизить нагрузку на СУБД – это шардирование.

Самый правильный и поддерживаемый путь – реализовать шардирование на уровне прикладной логики 1С, просто взаимодействуя с другой СУБД через код 1С.

• Например, можно подключать к базе внешние источники данных и выносить туда некоторые данные – записывать, читать оттуда. Это особенно полезно, если у нас mission-critical система с геораспределенной инфраструктурой, потому что у таких систем обязательно должно быть несколько серверов в геораспределенных ЦОДах, а это на самом деле очень дорого. Но поскольку не все данные настолько критичны – есть технические данные (замеры производительности, очереди, вспомогательные журналы) – всю эту некритичную информацию можно выносить во внешние источники данных: писать туда и читать оттуда. В результате у нас нет конкуренции за ресурсы основной СУБД. А требования к отказоустойчивости этих некритичных данных можно сделать гораздо ниже, что позволит нам еще и сэкономить.

• Есть варианты взаимодействия с внешними СУБД с помощью ADODB или COM – но это не кроссплатформенно, поэтому не рекомендую.

• Или можно взаимодействовать с другими СУБД через REST API – например, интегрироваться с Clickhouse и таким образом снять нагрузку с вашей основной СУБД.

Есть и другие способы шардирования, которые реализуются на уровне СУБД, но они у нас расцениваются как что-то на грани темной магии и нелегальности.

• Если у вас MS SQL – там на уровне СУБД точно нет ничего такого, с помощью чего можно бы разнести нагрузку и реализовать полноценное шардирование базы 1С.

• А для PostgreSQL несколько вариантов есть.

  • Например, приложение Citus, позволяющее распределять нагрузку между разными базами на PostgreSQL – единственное, что на версиях PostgreSQL от 1С версии 13 и выше оно уже перестает работать, работает только на версии 12 и ниже. С помощью Citus вы можете подключить таблицу, расположенную в другой СУБД, но при этом все равно рано или поздно упретесь в узкие горлышки вашей основной СУБД, с которой производится работа.

  • То же самое касается плагина Postgres_fdw – он тоже классно работает, но у него уже нет зависимости от версии PostgreSQL, его можно попробовать на любой версии PostgreSQL от 1С, включая 17-ю. Мы делали эксперимент и подключали через него справочник к двум одинаковым базам данных 1С. Вы записываете в одной базе, а данные появляются в другой – выглядит как космос и магия. Но с этим нужно быть очень осторожным, потому что там и нумерацию нужно учитывать, и все остальное. И все равно при высокой нагрузке вы столкнетесь с узкими горлышками на стороне вашей основной СУБД PostgreSQL, в которой установлен этот плагин.

  • И есть различные специализированные модификации PostgreSQL, поддерживающие шардирование – GreenPlum, Shardman и другие. Но с ними 1С, к сожалению, 100% не заработает – пока можно даже не пытаться. Поэтому ждем решения от вендора – чтобы, наконец, снять это узкое горлышко с помощью официальной поддержки в платформе 1С СУБД с возможностью шардирования.

Бонус

В заключение хочу вам сказать:

Выбирайте правильную архитектуру, пишите хороший код, и ваша 1С будет работать без предела.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.