Роман Ремизов
Системный аналитик ГК Юзтех
Привет, мир!
Меня зовут Роман Ремизов. Я системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я делюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.
Данная статья, как и первые две статьи этого цикла (первая статья доступна по следующей ссылке; вторая статья доступна по следующей ссылке), написана с допустимым уровнем конкретики и соблюдением NDA. И уже традиционно отмечу: стоит помнить, что все банки разные и на других проектах могут преобладать иные архитектурные решения.
В этой статье мы познакомимся или освежим в памяти знания о концепции «share nothing». Попробуем уйти от всем надоевшей Kafka и поговорить о других компонентах архитектуры.
О концепции «share nothing»
Концепция «share nothing» (без разделения ресурсов, или словами Володарского — «делить нечего») в распределенных системах баз данных радикально меняет подход к архитектуре, предлагая принципиально иной уровень масштабируемости и отказоустойчивости по сравнению с традиционными архитектурами с общим доступом к ресурсам.
В основе этой концепции лежит идея полной независимости узлов: каждый сервер в кластере работает автономно, не имея прямого доступа к памяти, процессорному времени или дисковому пространству других серверов. Это позволяет избежать узких мест, которые часто возникают в системах с общими ресурсами, и добиться высокой производительности при обработке больших объемов данных.
Ключевые особенности
Архитектура «share nothing» нашла широкое применение в различных типах баз данных, включая как реляционные (SQL), так и нереляционные (NoSQL), а также в распределенных хранилищах данных, таких как Hadoop Distributed File System (HDFS). Её ключевые особенности проявляются в нескольких аспектах:
Масштабируемость
Возможность горизонтального масштабирования — добавления новых узлов в кластер — является одним из главных преимуществ. В отличие от вертикального масштабирования, требующего замены оборудования на более мощное, горизонтальное масштабирование позволяет увеличивать производительность системы практически линейно с ростом числа узлов. Это достигается за счет того, что каждый новый узел привносит свои вычислительные мощности и хранилище, не влияя на работу существующих. Более того, современные облачные платформы идеально подходят для реализации архитектуры «share nothing», позволяя динамически добавлять и удалять виртуальные машины по мере необходимости.
Отказоустойчивость
Высокая отказоустойчивость обеспечивается благодаря независимости узлов. Если один узел выходит из строя (из‑за аппаратного сбоя, программной ошибки или других причин), остальные продолжают функционировать без перебоев. Данные, как правило, реплицируются на нескольких узлах, что обеспечивает дополнительную защиту от потери информации. Например, в системах с репликацией данных на трех узлах, даже выход из строя двух узлов не приводит к потере доступности данных. Механизмы самовосстановления, встроенные в многие распределенные базы данных, автоматически перераспределяют нагрузку и восстанавливают работоспособность системы. В контексте микро‑сервисной архитектуры, «share nothing» обеспечивает изоляцию сбоев — падение одного микро‑сервиса не влияет на работу остальных, повышая общую стабильность системы.Балансировка нагрузки
Распределенная природа архитектуры «share nothing» позволяет эффективно балансировать нагрузку между узлами. Специальные механизмы, такие как load balancers, распределяют входящие запросы между доступными серверами, предотвращая перегрузку отдельных узлов и обеспечивая равномерное использование ресурсов. Это особенно важно для высоконагруженных систем, где необходимо обрабатывать тысячи или даже миллионы запросов в секунду. Кроме того, балансировка нагрузки может быть реализована не только на уровне запросов, но и на уровне функциональности, распределяя различные задачи между специализированными узлами. Это позволяет оптимизировать работу системы и повысить общую производительность.
Упрощение управления
Управление распределенной системой на основе архитектуры «share nothing» может быть упрощено благодаря независимости узлов. Администраторы могут управлять каждым узлом автономно, что снижает сложность операций обслуживания и мониторинга. Автоматизированные инструменты управления кластером, предоставляемые многими платформами баз данных, значительно облегчают эту задачу. Например, автоматическое масштабирование, управление репликацией и мониторинг состояния узлов могут выполняться автоматически, уменьшая потребность в ручном вмешательстве.
Преимущества и недостатки
Преимущества:
Высокая доступность. Система продолжает работать даже при выходе из строя нескольких узлов.
Простота масштабирования. Легкое добавление новых узлов для увеличения производительности.
Улучшенная производительность. Изолированные ресурсы предотвращают конкуренцию за ресурсы и повышают эффективность.
Гибкость. Возможность использования различных типов оборудования и программного обеспечения на разных узлах.
Экономичность. Возможность использовать менее мощное оборудование на каждом узле, что снижает общие затраты.
Недостатки:
Сложности с обеспечением консистентности данных. Необходимо реализовать сложные механизмы согласования данных между узлами, чтобы гарантировать целостность информации. Это включает в себя использование различных протоколов, таких как Paxos или Raft, для достижения консенсуса.
Потребность в механизмах управления распределенными транзакциями. Обеспечение атомарности операций в распределенной среде требует реализации сложных механизмов управления транзакциями, что может снизить производительность. Двухфазная фиксация (2PC) — один из таких механизмов, но он имеет свои ограничения по производительности.
Увеличенная сложность архитектуры. Несмотря на упрощение управления отдельными узлами, общая архитектура системы становится более сложной, требуя квалифицированных специалистов для проектирования, развертывания и обслуживания.
Затраты на сетевую инфраструктуру. Высокая производительность сети является критическим фактором для эффективной работы системы «share nothing», так как все коммуникации между узлами происходят через сеть. Поэтому, инвестиции в высокоскоростную и надежную сетевую инфраструктуру являются необходимыми.
Опыт использования. Спойлер: это работает хорошо.
К примеру, при появлении требований, согласно которым система должна нумеровать определённые виды документов в различных срезах, первоначально появляется вопрос по расширению архитектуры уже имеющейся системы. Мы обращаем внимание на то, что:
Нумерация документов на больших объёмах данных — процесс достаточно нетривиальный. Особенно, если под руками есть только Tarantool, который, в отличие от Redis, не даёт преимущества при последующей записи данных в персистентное хранилище по результатам обработки пула сообщений с документами. Про файловую реализацию в этом контексте также рассуждать нет смысла.
Основная схема БД уже нагружена трактом основных таблиц. Что такое основные таблицы? Это таблицы с большим количеством операций. Или, выражаясь языком бизнеса, значимые данные. Обычно, там ещё и индексы. Они уже есть и уже притормаживают.
Не всегда есть железо, но часто есть облачная структура. Так называемое, наследие MVP. Чтобы не масштабироваться в вертикаль, нам подойдёт уже имеющийся cloud. Приятно, как будто деньги в старой куртке нашёл.
В числе уже имеющихся компонентов представлены микро-сервисы, добавление нумерации документов в бизнес-логику которых приведёт либо к «распуханию» (существенному усложнению) логики, либо к развитию «макарон» (когда в рамках существенно усложнённой логики добавляются ветки дерева вариативности).
Другими словами, нельзя просто взять и добавить пару таблиц в основную схему БД, чтобы затем в коде уже имеющегося микро-сервиса реализовать нумерацию, если на входе 5к mps, а целевой исходящий поток 200кк mps. Такое решение приведёт к тому, что важная, но отнюдь не ключевая, функциональность будет причиной высокой утилизации ресурсов оборудования.
Оптимальным решением, в моем опыте, было добавление в перечень компонентов системы нового микро-сервиса, ответственного за логику нумерации. Данный микро-сервис должен был каждым инстансом владеть пулом нумеров, доставшимся ему из хранилища.
Мы могли бы нумеровать каждый вид документов отдельной группой инстансов, и тогда бы среди всех инстансов нового микро-сервиса был бы выделен один «лидер» или «маршрутизатор», а остальные инстансы выступали бы в роли «работников». Однако, от этой идеи пришлось отказаться, так как среди видов нумеруемых документов на практике было всего три варианта, один из которых имел более 92 процентов популярности использования. В реализации с группами инстансов лишь одна группа имела бы полную утилизацию ресурсов, а две другие группы большую часть времени простаивали бы.
Нам повезло, и в требованиях ничего не было сказано о БСО (бланки строгой отчётности), поэтому мы могли свободно использовать небольшие пулы по десять номеров на один инстанс, не переживая за последовательность нумерации. Также, на стороне нового микро-сервиса не выполнялась фиксация выданных номеров, что облегчало задачу и позволило добиться высокого быстродействия. Требования по идемпотентности нумерации появились позже и были реализованы в рамках обходных решений, одним из которых, например, можно считать передачу пулов уже выданных номеров отдельным потоком в область оперативного хранилища специализированной платформы. Вообще, по моему скромному мнению, uuid для нумерации документов выгоднее, но не всегда такое решение понятно заказчику. Однако, проблемы понимания – это отдельная тема для обсуждения, которая, обычно, решается обсуждением.
Для нового микро-сервиса в БД была добавлена отдельная схема. В рамках новой схемы были реализованы таблицы для организации срезов номеров. Например, номер документа может быть сформирован исходя из того, какому филиалу этот документ принадлежит. При этом в БД хранится только последний выданный микро-сервису номер в рамках конкретного среза, что также позитивно сказывается на быстродействии, так как в основной таблице схемы БД фактически находится порядка 200-250 записей.
В рамках пилотирования нового микро-сервиса его схема БД была размещена на том же оборудовании, что и основная схема, а затем была перенесена в облако.
В итоге получился простой по логике, хорошо масштабируемый микро-сервис, внутри которого есть процессы-кандидаты на расширение и модификацию. Ничего лишнего, как это и было запланировано нами и заказчиком.
Предварительное заключение 3
Архитектура «share nothing» — это мощный подход к построению масштабируемых и отказоустойчивых распределенных систем баз данных.
Несмотря на определенные сложности в реализации, преимущества, которые она предоставляет в плане производительности, доступности и масштабируемости, делают её привлекательным решением для обработки больших объемов данных и обеспечения высокой надежности в современных приложениях.
Выбор конкретной реализации зависит от требований к производительности, доступности, консистентности данных и бюджета.
Спасибо за внимание и отличного настроения!
