Обеспечение надёжности уровня данных путём масштабирования на примере информационной системы оператора роуминга

АННОТАЦИЯ

На примере ИС оператора роуминга рассмотрена техника масштабирования на основе горизонтального шардинга и leader/follower репликации. Проанализировано распределение нагрузки между шардами. Для общего случая приведена математическая модель распределения основных и реплицированных шардов между физически и логически обособленными серверами.

ABSTRACT

The technique of scaling based on horizontal sharding and leader/follower replication is considered by the example of a roaming operator's IS. The load distribution between shards is analyzed. For the general case, a mathematical model for the distribution of primary and replicated shards between physically and logically separated servers is presented.

Ключевые слова: NoSQL, MongoDB, шардинг, репликация.

Keywords: NoSQL; MongoDB; sharding; replication.

Введение

Согласно Постановлению Кабинета министров [1], в Республике Узбекистан при взаиморасчётах между хозяйствующими субъектами используются электронные счета-фактуры. Уполномоченным оператором роуминга по централизованному хранению, учёту, обработке и передаче электронных документов определён Научно‑информационный центр новых технологий при ГНК РУз. ИС оператора роуминга, начало разработке которой было положено ещё в 2018 году, в настоящее время успешно функционирует, обеспечивая бесперебойную работу операторов ЭДО.

Очевидно, что для обеспечения бесперебойной работы с большим количеством данных первоочередными задачами являются:

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

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

Масштабирование базы данных оператора роуминга на основе горизонтального шардинга и репликации

В ИС оператора роуминга для организации уровня хранения данных используется NoSQL решение: СУБД MongoDB, параллельно развёрнутая на восьми серверах. Для масштабирования данных используется техника горизонтального шардинга. Это принцип проектирования базы данных, при котором логически независимые строки таблицы базы данных хранятся раздельно, заранее сгруппированные в секции, которые, в свою очередь, размещаются на разных, физически и логически независимых серверах базы данных, при этом один физический узел кластера может содержать несколько серверов баз данных [2].

Механизм шардинга даёт ряд преимуществ при реализации больших документно-ориентированных баз данных, так как большое количество пользователей, обращающихся к централизованному серверу, создают затраты процессорного времени, использованной памяти и, как следствие, снижают пропускную способность [3, c.228]. В рассматриваемой ИС всего выделено 48 шардов, по 6 на каждом сервере. Условием распределения документов между шардами является операция получения остатка от деления некоторого ключа документа на количество шардов. В рассматриваемой системе таким ключом является числовое представление идентификационного номера налогоплательщика (ИНН).

Рассмотрим каким образом распределяется нагрузка при таком подходе. Для этого сделаем три выборки случайных ИНН по 100, 1000 и 100000 в каждой из них соответственно. Каждый ИНН представим как девятизначное число, рассчитаем для него остаток от деления на 48, и подсчитаем количество получившихся остатков для всех 48 случаев. Построим три графика зависимости (рис. 1 – 3)

Рисунок 1. Распределение по шардам при случайной выборке из 100 документов

Рисунок 2. Распределение по шардам при случайной выборке из 1000 документов

Рисунок 3. Распределение по шардам при случайной выборке из 100 тыс. документов

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

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

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

Репликация — это синхронное или асинхронное копирование данных между несколькими серверами [2]. Репликация страхует от сбоев, обеспечивая высокую доступность и аварийное восстановление [4, с.219]. В рассматриваемой информационной системе для каждой из 48 баз данных создаётся по одной реплике, используя встроенные механизмы репликации СУБД MongoDB. Таким образом, полная концептуальная схема приведена на рис. 4.

Рисунок 4. Схема организации уровня данных ИС

Чтобы определить закономерность распределения индексов шардов по серверам, построим математическую модель. Пусть S – множество серверов, физически разделённых друг от друга. В рассматриваемом случае это множество состоит из 8 элементов:

Введём N – множество индексов шардов. В рассматриваемой ИС выделено 48 шардов, проиндексируем их, начиная с нуля, то есть:

Очевидно, что при проектировании количество шардов следует подбирать таким образом, чтобы оно было больше либо равно количеству серверов и кратно ему:

Обозначим k – количество шардов на каждом сервере. Тогда:

Пусть  и  – множества развёрнутых на i-ом сервере основных и реплицированных шардов соответственно. Настроим для каждого шарда по одной реплике. Тогда на i-ом сервере будет развёрнуто k основных шардов и k реплицированных:

Теперь предложим правила, по которым индексы шардов будут распределяться между серверами:

Здесь:

 – индекс сервера;

 – индекс шарда.

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

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

Заключение.

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

Список литературы:

1.     Постановление Кабинета Министров Республики Узбекистан № 522 от 25.06.2019 «О мерах по улучшению использования электронных счетов-фактур в системе взаиморасчётов»;

2.     Шардирование баз данных — Национальная библиотека им. Н. Э. Баумана, [Электронный ресурс]. Режим доступа: https://ru.bmstu.wiki/ (дата обращения: 31.07.2020 г.);

3.     Dan Sullivan, NoSQL for Mere Mortals, Addison-Wesley Professional, 2015 – 552 pages;

4.     Кайл Бэнкер, MongoDB в действии, Москва, 2012 – 394 с.