Пролог
Этот пост продолжает тему проблем возникающих при применении архитектурных паттернов начатую в статье Моделирование данных в слоеной архитектуре.
В Enterprise архитектуре следует серьезно относиться к требованиям информационной безопасности. В данной статье хотелось бы поднять проблемы возникающие вследствие реализации нефункциональных требований по фиксации событий, классифицированных как заслуживающие того, чтобы быть зафиксированными в специальном журнале.
НФТ, которые в терминах микросервисной архитектуре называется Observability and Monitoring реализуются сервисами Журналирование, Аудит и Мониторинг. Журналирование и Мониторинг не являются темой этой статьи, темой является Аудит.
ГОСТ Р ИСО/МЭК ТО 18044-2007 дает следующее определение события информационной безопасности, которые должны попадать в журнал Аудита: «Идентифицированное появление определенного состояния системы, сервиса или сети, указывающего на возможное нарушение политики ИБ или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности».
На практике это сводится к тому, что надо классифицировать события несущие риск и записать их в журнал. Анализ на регулярной основе этого журнала и поиск по нему в случае инцидента и является тем самым улучшением эффективности.
Наша команда занимается миграцией Legacy монолитного вендорского приложения на целевую микросервисную архитектуру.
Как было
Как выглядит процесс аудирования в монолитном приложении:
У разработки всегда есть полная база данных с полным набором сущностей и исчерпывающим атрибутивным набором у этих сущностей.
Реализация журналов Аудита заключается в написании SQL запросов к БД и защите таких представлений через встроенную ролевую модель.
Все довольны: бизнес, разработчики, безопасность и сопровождение.
Как стало
В микросервисной архитектуре активно используются паттерны:
слоеная архитектура, об этом упоминается в моей статье на Хабре;
Одна БД на сервис — database‑per‑service;
архитектура микросервисов microservices;
декомпозиция по поддоменам decompose‑by‑subdomain.
Как они влияют на Журнал Аудита:
на каждом слое реализуется свое приложение и своя модель данных;
дробление модели данных на поддомены согласно SOLID;
дробление операции на шаги саги saga.
Требования к регистрации событий событий Аудита
Событие должно быть читаемым на русском языке, без использования языковых конструкций языков программирования и наименований объектов атрибутов и сущностей физической модели данных;
Событие должно содержать не ключи, а значения ключей сущностей, не идентификатор клиента, но его ФИО;
Событие, если оно регистрирует изменение должно содержать два значения на каждый атрибут: было и стало;
События должны фиксироваться в каждой автоматизированной системе.
Следствия
С учетом деления системы на слои сервисов, каждая команда разрабатывая сервиса на своем слое должна записывать событие в журнал Аудита.В результате при чтении в журнал Аудита запишут события: Приложение PL слоя, Приложение слоя Бизнес‑Логики, Приложение слоя Доступа к данным.
С учетом декомпозиции приложения на поддомены, и принципу DDD для поддержки требования полноты атрибутивного события,микросервису не хватает атрибутного состава сущностей для выполнения требования по регистрации значений ключей.
С учетом паттерна саги каждый из микросервисов — участников саги запишет свою часть распределенной транзакции в Журнал Аудита.
Исполнения требований в лоб
В Журнале Аудита одна бизнес операция будет представлена записями как минимум 3-х приложений с каждого слоя.
Реализация модели данных события будет зависеть от команды ответственной за слой и может расходится по неймингу атрибутов, а в каких‑то случаях и по значению.
Если событие является распределенной транзакцией каждый участник саги добавит запись в журнал Аудита.
Потребуются дополнительные ресурсы для соблюдения SLA участвующих сервисов c учетом выполнения требования полноты.
Эпилог
Цель данного поста не публикация готового решения, а скорее рассуждения на тему проблем которые приносят архитектурные паттерны в устоявшиеся порядки и регламенты.
В то время как приложения пытаются декомпозировать, разбить на домены и поддомены, сделать слабосвязанными и автономными Принцип Наблюдаемости ведет потоки событий, порождаемых в декомпозированных сервисах обратно к композиции.
Требования, предъявляемые к системе Аудита возвращают микросервисную архитектуру обратно к монолитной.
Комментарии (10)
alex1t
00.00.0000 00:00+2В подходе Database per service надо всё-таки подходить разумно к разделению. В микросервисе в первую очередь есть сущности с которыми он предназначен работать и за которые отвечает. Обычно одна-две плюс возможно несколько вспомогательных таблиц. А для "внешних" сущностей есть смысл иметь упрощённые таблицы реплики с минимально необходимым набором данных (обычно их действительно немного). Этого может вполне хватить, чтобы писать человекочитаемые события аудита с указанными в статье требованиями.
Если это не вариант, то всегда можно сделать микросервис для ведения событий аудита :)
psergal Автор
00.00.0000 00:00Все так, об этом и пост, что надо догружать модель данными только ради аудита
VladimirFarshatov
00.00.0000 00:00+1Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.
Микросервисы? Не, ну можно конечно, если тур-агенство способно закупить супер железо, и выкачивать каждый раз 3/4 БД обращаясь к нескольким сервисам .. транзакционность? Да тоже можно на программном уровне, только стоит ли овчинка выделки для тур-агенства, в котором как правило "3 пленных немца", включая директора.
Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.
Кмк, очень спорно и далеко не всегда полезно. Но, как средство выколачивания из бизнеса денег на покупку самого толстого железа - очень надежно.
mvladlen
00.00.0000 00:00Может просто задачи были маленькие? Какие там бизнес процессы в турагентстве? Составить план поездки и выписать билеты? Рассчитаться с партнёрами, разместить рекламу?
А представьте как вы сделаете на монолите и одной базе банковские транзакции, которых миллионы в день и там же процесс кредитных заявок, которых тоже тысячи, в которых надо кучу запросов на проверки клиентов делать.
Это просто вопрос опыта, что вы не встречали такую задачу.
VladimirFarshatov
00.00.0000 00:00А каким способом перенос сложности бизнес приложения с внутреннего монолита, на микросервисную архитектуру повышает производительность, при внесении как миниум дополнительной сетевой задержки?
Если бизнес-монолит реентерабелен и шардируем, в чем преимущество микросервисов? Поясните пожалуйста.
psergal Автор
00.00.0000 00:00Повышается масштабируемость, там где надо, а не везде. Естественно просто распил понизит быстродействие.
VladimirFarshatov
00.00.0000 00:00Вы не внимательны. Написал же не просто так: "монолит - реентерабелен И шардируем". Давайте уточню. Скажем монолит на горутинах, шардируется в нужных горутинах. Где выгода?
psergal Автор
00.00.0000 00:00Владимир, холивар на тему преимуществ и недостатков монолита и микросервисов никоим образом не относиться к теме. Дискутировать на эту тему я не планировал.
VladimirFarshatov
00.00.0000 00:00Извините, но из Вашего возражения про маленькие банковские транзакции на миллионы этого не следует. Я просто хотел чтобы Вы всего лишь уточнили, что Вы имели ввиду в деталях. Никаких холиваров, просто любопытно, чего такого я не знаю про микросервисы и монолиты..
Ares_ekb
По ссылке Pattern: Database per service описаны преимущества такого подхода:
"Уменьшается связность между сервисами, можно независимо менять схему данных." - но это действительно хорошо, когда схемы данных для сервисов разрабатываются полностью независимо? В них могли бы использоваться общие справочники, общая схема именования таблиц, столбцов. Профит от того, что за всю схему данных отвечает один человек или группа людей мне понятен: потом эти данные проще анализировать, проще строить по ним отчеты, не нужно писать сложные ETL процедуры для приведения данных к единому виду, нет дублирования данных, схема данных достаточно устойчивая и не приходится всё переделывать при её изменении. Краткосрочный профит от распиливания схемы данных, ну, с натяжкой понятен: можно быстрее фигачить новые фичи в продакшен не парясь о схеме данных. Но в долгосрочной перспективе что потом с этими данными делать?
"Каждый сервис может использовать свою СУБД". Очень важный пункт (sarcasm), хипстеры в каждой команде смогут использовать свои любые MongoDB, Neo4j или даже каждый месяц переходить на новую СУБД. Если серьезно я думаю, что в 2023 году такой зоопарк скорее минус, чем плюс.
Недостатки:
"Сложнее реализовывать транзакции между микросервисами"
"Сложнее join-ить данные из разных СУБД"
"Сложнее админить разные СУБД" - если что-то упадёт и потом понадобится восстанавливать из бэкапов, то это выглядит просто страшным сном админов
Ну, ещё они забыли упомянуть:
Сложнее обеспечивать целостность данных (внешние ключи)
Сложнее реализовывать какие-то общесистемные вещи типа аудита, как вы описываете в статье
Очень странный паттерн, который имеет очевидные недостатки, но при этом не очень очевидные преимущества. Интересно есть какой-то промежуточный вариант, который решает задачу распиливания приложения, но при этом не добавляет столько проблем?.. Если только общая база данных и для каждого сервиса своя схема.