Архитектура распределённой системы

Обеспечить интеграцию данных множества информационных систем (сотни тысяч), рассредоточенных географически (в т.ч. в облаках).
Основные техники интеграции данных:
Копирование данных: ETL (extract, transform, load), CDC (change data capture), потоковая обработка, репликация
Удалённый вызов: service mesh, сервисные шины
Распределённая обработка данных: data virtualization, data fabric, data mesh и другие типы федераций
Необходимо построить интеграционную платформу, предоставляющую участникам инструменты всех трёх групп для интеграции своих информационных систем.
ЗАДАЧА

Общее количество ИС УВ 200 000 (из них 20 000 поставляют данные и сервисы, 180 000 – потребляют)
Общий трафик (суммарный объём передаваемых данных) между ИС УВ 100 Gbps
Общее кол-во выполняемых операций обмена данными 1 000 000 tps (тут подразумевается, что тяжёлые взаимодействия выполняются потоком, и квант потока считается отдельной транзакцией). Таким образом оценка размера транзакции такова: 100 Gbps / 1 000 000 tps = 100 Kb ~ 10KB)
Задержки на приоритетных транзакциях передачи данных в пределах одной гео-локации 0.1 сек на передачу данных точка-точка. Доля приоритетных транзакций ~25%
Надёжность 99.995% (26 минут простоя в год)
ЦЕЛЕВЫЕ ПОКАЗАТЕЛИ НАЗНАЧЕНИЯ
Платформа должна состоять из типовых ПАК (vПАК), обеспечивающих 10 000 tps и 1Gbps.
Для особых случаев (например, федеральная ИЭП) можно предусмотреть и более мощные ПАКи.
ПАКи могут размещаться в нескольких ЦОД и реплицировать свои состояния для обеспечения катастрофоустойчивости.

Координатор Чтения
СМЭВ 3/2 adapter
предоставление данных через Виды Сведений / сервисы СМЭВ 3/2
СМЭВ 4 adapter
Предоставление данных по правилам НСУД / ПОДД
MPP adapter
Высокопроизводительные выгрузки данных в Kafka/HDFS
SQL adapter
Запросы к логической модели через JDBC/ODBC/ADO.NET
OpenAPI adapter
Публикация API доступа к данным
Координатор Записи
OpenAPI adapter
Запись в витрину через стандартный API
ETL adapter
Запись в витрину c использованием Pentaho/NiFi
CDC adapter
Перехват изменений из иных БД с использованием Debezium
MPP adapter
Высокопроизводительная запись данных в витрину с использованием Kafka/HDFS
HDFS
Хранение BLOB, журналов загрузки, запросов, бэкапов и т.д.
greenplum
Обработка запросов к сильно нормализованным структурам
clickhouse
Обработка аналитич. запросов
tarantool
Обработка запросов по ключу
Менеджер кластера, мониторинг (Prometheus, Grafana), журналирование (ELK)
Управление вычислительными ресурсами, управление топологией СУБД, управление точками подключения, балансировкой нагрузки, управление выделением вычислительного ресурса для сервисов в зависимости от внешней нагрузки. Управление бэкапами.
Единая шина/пространство для масштабируемого ввода-вывода (Kafka/HDFS)
Балансировка трафика загрузки данных
Сертифицированная виртуализация Росплатформа
Сертифицированная ОС АЛЬТ 8 СП
Ядровые компоненты
Интерфейсы взаимодействия с Витриной
Управление логической моделью данных витрины
Балансировка запросов от Потребителей данных
Безопасность информации и управление доступом
Инфраструктурные компоненты
SQL adapter
DDL логической модели через JDBC/ODBC/ADO.NET
хранилище метаданных
Запись данных на витрину
Чтение данных с витрины
Целевая функциональная архитектура витрины
Сервисы обеспечения катастрофо-устойчивости (ZooKeeper, и т.д.)

ЦОД-1
Обеспечение доступности Витрины на уровне 99,99%
ZooKeeper
Экземпляр Витрины
ЦОД-2
ZooKeeper
Экземпляр Витрины
ЦОД-3
ZooKeeper
Экземпляр Витрины
Сеть доступа потребителей (Внутренняя сеть, СМЭВ, Интернет, VipNET, …)
Для обеспечения надёжности потребуется размещение оборудование в 3-х ЦОД, при этом 3-й ЦОД может быть облегчённым и содержать только кластер ZooKeeper, а первые два ЦОД содержат Active-Active реплики витрины.
Ещё большую надёжность можно обеспечить устанавливая 3 гео-распределённые реплики
ЦОД-1
99.982%
ЦОД-3
99.749%
ЦОД-2
99.982%
ZK-1
99.95%
ZK-3
99.95%
ZK-2
99.95%
2/3
Витрина-1
99.5%
Витрина-2
99.5%
Структурная схема надёжности гео-распределённой витрины
(ГОСТ Р 51901.14-2007)
99.991%
Нормативная доступность элементов:
Сеть 2-3
99.5%
Сеть 1-2
99.95%
Сеть 1-3
99.5%
1/3

Витрина
Координатор Чтения
СМЭВ 3 adapter
предоставление данных через Виды Сведений СМЭВ 3
SQL <= XML
Хранилища
витрины
SQL результат => XML
Сервисы ЭП
СМЭВ 3
Получение запроса из СМЭВ
Предоставление выписки в СМЭВ
Формирование ЭП выписки и ЭП ответа в СМЭВ
Выполнение SQL-запросов в витрине
Выполнение SQL-запросов в хранилищах
Передача результата SQL-запроса из хранилища
Передача результата SQL-запроса из витрины
Формирование выписки с витрины с использованием СМЭВ 3 адаптера
SQL <= XML
Необходимо разработать шаблон SQL-запросов, который с использованием XPath выражений извлечёт параметры запроса и подставит их в SQL-запрос. При использовании банка выписок запрос максимально простой:
SQL результат => XML
Необходимо разработать шаблон XML ответа, который с использованием полученных из витрины данных, сформирует ответ в формате ВС
SELECT Выписка, Подпись FROM Банк_Выписок
WHERE Кадастровый_Номер = '77:08:0009005:1596'

Формирование выписки с витрины с использованием НСУД
РОСРЕЕСТР (Поставщик)
Витрина Росреестра
ИС 1
ИС 2
ИС 3
Хранилища
витрины
Агент ПОДД
Ядро ПОДД СМЭВ
Потребитель (МФЦ)
Агент ПОДД
ИС МФЦ
-- получение выписки с использованием банка выписок (для передачи ФЛ, например)
SELECT Выписка, Подпись FROM Росреестр.Банк_Выписок
WHERE Кадастровый_Номер = '77:08:0009005:1596'
-- получение отдельных атрибутов недвижимости для использования в бизнес-процессах
SELECT сделка.Продавец, сделка.Покупатель, сделка.Дата_Регистрации_Сделки
FROM Росреестр.Записи_О_Сделках сделка
WHERE сделка.Покупатель.Паспорт.Номер = '1234098765'
-- Выполнение распределённых запросов к государственным данным
SELECT сделка.*, адрес.*
FROM Росреестр.Записи_О_Сделках сделка
JOIN ФИАС.Адресные_Объекты адрес ON адрес.ID_Адреса = сделка.Адрес_ФИАС
WHERE сделка.Покупатель.Паспорт.Номер = '1234098765'
AND адрес.Статус = 15
Размещение и актуализация данных на витрине
Формирование SQL-запросов (JDBC – уже есть, OpenAPI будет в 2021 г.):
Оплата выписки инициируется в МФЦ/ЕПГУ. Детали взаимодействия с Росреестром по этому вопросу зависят от того, доверяет ли Росреестр МФЦ и ЕПГУ и если нет – в какой степени.
В запросах справа предполагается, что доверяет.
Так же нужно понять, какие логи требуются на стороне Росреестра о предоставлении выписок.
ПОДД СМЭВ – распределённая БД

МВД
АННУЛИРОВАННЫЕ ПАСПОРТА
ГИБДД
ВОДИТЕЛЬСКИЕ УДОСТОВЕРЕНИЯ
ЗАГС
СВИДЕТЕЛЬСТВА
О РОЖДЕНИИ
МКС
ПРОФИЛИ
ЕСИА
126 млн строк
227 млн строк
88 млн строк
75 млн строк
ПОДД СМЭВ
ПОТРЕБИТЕЛЬ
Отправка запроса к ПОДД
Отправка запросов к витринам
Схема стенда

Витрина
ИС Потребителя
Коннектор Tarantool
Tarantool
Коннектор Clickhouse
Clickhouse
Выполнение запросов к витрине
Координатор чтения
API чтения
Запрос по ключу
Запрос статистики
select * from demo_gibdd.driver_lic
where driver_lic_number = '100000622';
select child_first_name, count(*) "Count"
from demo_zags.birth
group by child_first_name
order by "Count" desc;
select year(d_issue_date) "Year", count(*) "Count"
from demo_gibdd.driver_lic
group by year(d_issue_date)
order by "Count" desc;
Запрос по ключу – в тарантул
Запросы статистики – в кликхауз
ПОДД СМЭВ
Запрос атрибутов водительского удостоверения по номеру
Запрос частоты имён в свидетельствах о рождении
Запрос количества выданных водительских удостоверений по годам
Комментарии
Выполнение через ПОДД/СМЭВ добавляет около секунды
Оптимизация выбора СУБД для исполнения запроса на основе использования статистики в координаторе чтения
Релиз №3 (дек.20) – Упрощенная версия
Март №4 (март.21) – Продвинутая версия (надо научить тарантул и кликхауз отдавать подробные планы запросов)

СМЭВ
Сбор информации об объекте из нескольких витрин
Витрина
ВОДИТЕЛЬСКИЕ УДОСТОВЕРЕНИЯ
ПОДД
Витрина
СВИДЕТЕЛЬСТВА О РОЖДЕНИИ
❶
❷
Запрос водительского удостоверения по его номеру
❸
Передача всех атрибутов водительского удостоверения в ПОДД
❺
Передача всех атрибутов свидетельств о рождении в ПОДД
Макет ИС Потребителя
❹
Запрос детей по номеру паспорта, указанного в водительском удостоверении
❻
Передача объединённого набора сведений Потребителю
Запрос сведений о водительском удостоверении и детях по номеру водительского удостоверения
1-2 – формирование запроса в витрину водительских удостоверений
3-4 – формирование запроса в витрину свидетельств о рождении
5-6 – формирование объединённого набора сведений
select dl.*, b.*
from demo_gibdd.driver_lic dl
join demo_zags.birth b on b.mother_passport = dl.passport
where dl.driver_lic_number = '254030801' ;
Комментарии
Сейчас ~ 3 сек, пропускная способность примерно 1000 запросов/сек
CМЭВ 4 – 0,2 сек (каналы до витрин – не хуже 1Gbps / 10ms)

Хранилище реплик
СМЭВ
Репликация реестра аннулированных паспортов и пересечение с документами ЕСИА внутри витрины ЕСИА ~ 5 сек
Витрина
АННУЛИРОВАННЫЕ ПАСПОРТА
Макет ЕСИА
ПОДД
SOAP-команда на регистрацию подписки
Витрина
ПРОФИЛИ ЕСИА
❶
❷
Регистрация подписки в витрине Поставщика
❸
Передача данных
в ПОДД СМЭВ
❹
Передача данных Потребителю
Выполнение пересечения локально в витрине ЕСИА
❺
select d.passport_number from replicas.passport p
join esia.doc_shard d
on p.passport_number = d.passport_number;
Комментарии
Сейчас запрос отправляется непосредственно в Clickhouse
В релизе №2 (авг.20) будут реализованы стандартные интерфейсы доступа к данным, позволяющие использование визуальных инструментов

Зачем нужна витрина данных

Витрина
Kafka
Макет ИС поставщика
Коннектор Tarantool
Tarantool
72 ядра
Коннектор Clickhouse
Clickhouse
54 ядра
Файлы
- ДОКУМЕНТЫ ЕСИА
- АННУЛИРОВАННЫЕ ПАСПОРТА
- СВИДЕТЕЛЬСТВА О РОЖДЕНИИ
- ВОДИТЕЛЬСКИЕ УДОСТОВЕРЕНИЯ
Схема загрузки данных в витрину
Координатор записи
REST-команда на загрузку файлов в витрину
API Записи
данные
Команда на запись данных
Комментарии:
75 млн номеров паспортов
Сейчас ~ 1 минуты
В релизе №3 (дек.20) – 25 секунд (поточная запись, до скорости тарантула)
В релизе №4 (март.21) – 15 секунд (ускорение ядра тарантула)