Архитектура корпоративных приложений высокой производительности на примере SimpleOne

Как показывает мировая практика и наш личный опыт, если высоконагруженное корпоративное приложение начинает медленно обрабатывать запросы пользователя, то с большей степенью вероятности проблема кроется в работе с базой данных (БД). Реляционные БД стали стандартом для хранения данных, и организация их работы с серверным и клиентским приложением — одна из самых важных задач разработчиков. Чтобы сделать платформу SimpleOne действительно быстрой, мы применили несколько современных технологий масштабирования и балансировки: разделили данные по типам, распределив их по четырём видам серверов, применили горизонтальное масштабирование и настроили кеширование с помощью базы данных NoSQL. Кроме того, мы поставили себе задачу минимизировать число обращений к БД и сделать их максимально быстрыми.

Кластеризация и горизонтальное масштабирование

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

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

Распределение данных и запросов между узлами кластера помогает во многих вычислительных задачах. Большинство корпоративных информационных систем способны выполнять вычисления одновременно на нескольких серверах, распределяя нагрузку, чтобы повысить скорость обработки данных. Однако при работе приложений с базами данных такой вариант не является самым оптимальным. Мы используем «умное» горизонтальное масштабирование, которое использует определённые ноды для решения конкретных задач.

Балансировка в SimpleOne

Для того чтобы справляться с любой нагрузкой, платформа автоматизации бизнес-процессов SimpleOne использует «умное» горизонтальное масштабирование. Запросы от пользователей приходят на клиентский сервер, который отвечает за отображение интерфейса, обработку скриптов и получение входящих данных. С ростом нагрузки к одному клиентскому серверу подключаются другие, они становятся нодами кластера. Умный балансировщик равномерно распределяет запросы между нодами, чтобы они обрабатывались параллельно (см. рисунок выше).

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

Специализация серверов

Первый уровень масштабирования — распределение системы по видам выполняемых задач. Мы используем четыре типа серверов:

• серверы клиентского приложения;
• серверы системного приложения;
• серверы баз данных;
• серверы файлового хранилища.

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

Иерархия баз данных

На уровне реляционных баз данных мы используем архитектуру Master/Slave, в которой применяется репликация. Сервер БД Master получает только запросы на запись и реплицирует их на несколько серверов Slave. А все запросы на чтение обрабатывают серверы Slave. Таким образом, несмотря на то, что Master должен продублировать всю информацию на несколько Slave, он оказывается не сильно загружен, так как не отвечает за чтение. В свою очередь, большинство запросов к БД от системного приложения производятся именно на чтение, и, поставив 10 серверов Slave, мы почти в 10 раз увеличиваем производительность системы.

Следующим этапом масштабирования является партицирование.

Партицирование

Данные в таблице на сервере БД делятся на группы по заранее определённому признаку. Например, записи с чётными ID относим к одной группе, а с нечётными — к другой. Первая группа формирует свою новую таблицу, а вторая — свою. Это позволяет производить параллельные запросы к БД и повышать скорость обработки данных. Признаков разделения может быть множество, так же как и групп данных, на которые будет разделяться обработка запросов.

Например, принцип партицирования используется для распределения по разным серверам таблиц ядра системы и пользовательских таблиц. В отдельной базе данных на выделенном сервере размещены часто используемые sys_db_table, sys_db_column, user и другие системные таблицы, а те пользовательские таблицы вынесены на другие, менее производительные серверы.

Также партицирование хорошо работает с большими базами данных. Например, база данных логов изменений очень быстро наращивает свой объём и разделение её на несколько отдельных таблиц значительно повышает скорость обработки запросов.

Шардирование

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

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

Отдельное хранение файлов

Последним уровнем распределения данных, который мы используем в SimpleOne, является вынесение файлов за пределы базы данных. PostgreSQL позволяет хранить файлы непосредственно в БД, но, когда такие файлы имеют ощутимый размер, их чтение и запись снижают производительность всей БД. Поэтому в БД мы оставляем только ссылки на файлы, а сами данные выгружаем на отдельный файловый сервер S3. Так сокращается и число обращений к БД, и нагрузка на операции ввода-вывода.

Подробнее об этом можно прочитать в статье «Эффективное хранение данных в SimpleOne».

Базы данных и кеширование

На протяжении нескольких лет мы используем реляционную систему управления базами данных PostgreSQL и имеем экспертные знания в её настройке и администрировании. Это одна из старейших реляционных баз данных, работа с которой несколько сложнее, чем с MySQL или SQLite, но в результате грамотной настройки она даёт отличную стабильность и скорость работы. Ключевыми преимуществами использования PostgreSQL в SimpleOne стали полная SQL-совместимость, возможность программного расширения для хранения собственных процедур и обеспечение высокого уровня целостности данных.

Однако, сделав свой выбор в пользу PostgreSQL для хранения основного массива данных, мы дополнили ее кеширующим слоем в виде БД Redis, которая использует оперативную память сервера для хранения наиболее горячих данных. Такая связка показала отличную производительность, и о ней мы расскажем дальше.

Особенности кеширования

Для горячих данных мы используем технологию с большой скоростью доступа — NoSQL Data Base. Она позволяет создавать кеш с наиболее используемыми данными в оперативной памяти сервера, которая имеет наивысшую скорость чтения. После первичного запроса к БД данные переносятся в кеш и в дальнейшем читаются уже из него. Причём некоторая информация из таких таблиц, как SSISDB table, SSISDB column, SSISDB columntype, всегда востребована и её сразу можно перемещать и хранить в кеше. Так мы не только ускоряем доступ к этим данным, но и разгружаем серверы БД, поскольку кеш может храниться в оперативной памяти серверов системных приложений.

В то время как традиционные СУБД соответствуют требованиям ACID к транзакционной системе, используемая для кеша база данных NoSQL вполне может работать с набором свойств BASE. Требования ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Долговечность) обеспечивают наиболее надёжную и предсказуемую работу БД. В то время как BASE (Basically Available — Базовая доступность, Soft State — Гибкое состояние, Eventual Consistency — Согласованность в конечном счёте) менее требовательны к транзакциям и согласованности данных.

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

Заключение

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