Клюковкин Г.К., Михайлов Б.А. Проектирование отказоустойчивых систем с учетом экстремальных пиков нагрузки // Вестник Науки и Творчества. 2021. № 3(63). С. 44-51.
Статья: Клюковкин, Михайлов 2021-03.pdf
Полный выпуск: Вестник Науки и Творчества. Выпуск № 3 (2021).pdf
ПРОЕКТИРОВАНИЕ ОТКАЗОУСТОЙЧИВЫХ СИСТЕМ
С УЧЕТОМ ЭКСТРЕМАЛЬНЫХ ПИКОВ НАГРУЗКИ
Клюковкин Георгий Константинович,
ведущий инженер-программист, RingCentral,
г. Санкт-Петербург
E-mail: kliukovkin@gmail.com
Михайлов Богдан Александрович,
ведущий инженер-программист,
Компания VK, г. Москва
E-mail: bogdan.mihailov@internet.ru
Аннотация. В статье рассматриваются современные архитектурные подходы к проектированию отказоустойчивых систем с учётом экстремальных пиков нагрузки. Проведён теоретический и прикладной анализ архитектур Active-Passive и Active-Active, проанализирована теорема CAP и применимость различных паттернов отказоустойчивости в микросервисной архитектуре. Представлена типология отказов, рассмотрены метрики надёжности, систематизированы подходы. Выявлены ограничения современных решений – от высокой стоимости до архитектурных компромиссов. В заключение обозначены перспективы дальнейших исследований: предиктивная аналитика, автоматизация восстановления, мультиоблачные и edge-архитектуры, а также обеспечение отказоустойчивости в условиях высоких требований к безопасности и соответствию нормативным требованиям.
Ключевые слова: отказоустойчивость, пиковые нагрузки, Active-Passive, Active-Active, микросервисная архитектура, CAP-теорема, self-healing, масштабирование, предиктивная аналитика, отказоустойчивая система, отказоустойчивые паттерны, облачная инфраструктура.
Актуальность исследования
Актуальность исследования обусловлена стремительным ростом требований к отказоустойчивости цифровых систем в условиях возрастания интенсивности и непредсказуемости пиковых нагрузок. В современном технологическом ландшафте, где цифровые платформы обслуживают миллионы пользователей в режиме реального времени, даже кратковременный сбой в работе критически важной инфраструктуры может повлечь за собой значительные финансовые убытки, утрату доверия клиентов и снижение конкурентоспособности компании.
Типичными примерами таких пиковых ситуаций являются массовые онлайн-распродажи, запуск новых цифровых продуктов, повышение активности пользователей вследствие информационных поводов или внешние атаки (включая DDoS). Традиционные методы обеспечения надёжности, как показывает практика, не всегда эффективно справляются с экстремальными отклонениями от средней нагрузки, поскольку часто ориентированы на статическую конфигурацию и не учитывают динамические характеристики инфраструктуры. Это приводит к деградации производительности, недоступности сервисов и каскадным сбоям в системе. В то же время современные подходы, основанные на концепциях адаптивной архитектуры, микросервисности, горизонтального масштабирования, автоматической балансировки и систем самоисцеления (self-healing), позволяют проектировать архитектурные решения, устойчивые к аномальным всплескам нагрузки. Однако такие архитектуры требуют формализованного научного подхода, включающего моделирование пиковых ситуаций, выбор эффективных паттернов отказоустойчивости и обоснование механизмов контроля деградации.
В условиях перехода к цифровому государству, развитию облачных технологий и появлению новых классов высоконагруженных систем особую актуальность приобретает задача интеграции этих принципов в рамках проектирования устойчивой ИТ-инфраструктуры, особенно в отраслях с повышенными требованиями к непрерывности и доступности, таких как финтех, здравоохранение, транспорт, государственные услуги.
Цель исследования
Целью данного исследования является обоснование и систематизация архитектурных и методологических подходов к проектированию отказоустойчивых систем, устойчивых к экстремальным пиковым нагрузкам, с учётом современных технологических реалий, требований к непрерывности обслуживания и специфики распределённых вычислений.
Материалы и методы исследования
В качестве материалов использованы: открытые публикации в научных журналах, техническая документация облачных провайдеров, статьи на ведущих инженерных порталах, аналитические отчёты. Методология исследования опирается на системный и сравнительный анализ, концептуальное моделирование, теоретическое обоснование отказоустойчивых архитектур, исследование паттернов надёжности и применение формализованных метрик отказов и доступности.
Результаты исследования
Масштабирование системы, как правило, имеет целью увеличение производительности системы на задачах, критичных к времени их решения. Однако сопутствующий горизонтальному масштабированию экстенсивный рост количества используемых компонентов ведет к уменьшению времени наработки на отказ: порядка 20% вычислительной мощности высокопроизводительных систем теряется по причине возникших неисправностей и восстановления после них [2, с. 59].
Отказоустойчивость распределенной системы определяется возможностью функционирования системы, несмотря на отказы ограниченного числа ее компонентов [1, с. 208].
В отличие от устойчивых систем, они сохраняют работу без снижения производительности.
Высокая доступность – обеспечение заранее определённого уровня «времени безотказной работы», часто выражаемого в процентах: от «трёх девяток» (99,9%) до «пяти девяток» (99,999%).
Основные метрики надёжности и отказоустойчивости системы представлены в таблице 1.
Таблица 1
Основные метрики надёжности и отказоустойчивости системы
Метрика |
Расшифровка |
Определение |
Назначение / Пояснение |
MTBF |
Среднее время между отказами (Mean Time Between Failures) |
Среднее ожидаемое время между двумя последовательными отказами системы |
Оценивает общую надёжность и устойчивость системы |
MTTF |
Среднее время до отказа (Mean Time To Failure) |
Среднее время до полного отказа системы, не подлежащей ремонту |
Применяется для неремонтируемых компонентов (например, одноразовые модули) |
MTTR |
Среднее время восстановления (Mean Time To Repair / Recovery) |
Среднее время, необходимое для восстановления работоспособности после отказа |
Используется для расчёта доступности и оценки времени простоя |
RTO |
Целевое время восстановления (Recovery Time Objective) |
Максимально допустимое время, в течение которого система должна быть восстановлена после сбоя |
Ключевая метрика при разработке планов аварийного восстановления (Disaster Recovery) |
RPO |
Целевая точка восстановления (Recovery Point Objective) |
Максимально допустимое количество данных, которые могут быть утеряны в результате инцидента |
Используется при проектировании резервного копирования и репликации |
Availability (A) |
Доступность |
Доля времени, в течение которого система полностью функционирует |
Выражается в процентах и рассчитывается по формуле: A = MTBF / (MTBF + MTTR) |
Разработка высоконагруженных систем является сложным и ресурсоемким процессом. Такие системы требуют особого внимания и профессионализма со стороны разработчика, поскольку высоконагруженная система рассчитана на огромное количество пользователей и высокую отказоустойчивость [3, с. 10].
Типология отказов в распределённых и высоконагруженных вычислительных системах представляет собой важнейший аспект в проектировании отказоустойчивых архитектур. В научной литературе и практических руководствах по системной инженерии различают три базовых класса отказов в зависимости от их природы и характера возникновения: временные, интермиттирующие и постоянные.
1) Временные отказы являются кратковременными сбоями, возникающими в результате внешних или случайных воздействий, таких как всплески нагрузки, электромагнитные помехи или кратковременные ошибки программного обеспечения. Они, как правило, не указывают на физическую деградацию системы и могут быть устранены с помощью стандартных перезапусков или временной изоляции компонента.
2) Интермиттирующие отказы, в свою очередь, носят спорадический характер: они возникают нерегулярно и являются индикаторами надвигающегося фатального сбоя. Такие сбои особенно сложны для диагностики, поскольку часто не повторяются в контролируемых условиях, но свидетельствуют о начальных признаках деградации аппаратного или программного компонента.
3) Постоянные отказы – это наиболее тяжёлый класс сбоев, при которых компонент системы полностью выходит из строя и требует физической замены или полной реконфигурации.
Соответственно, методы обеспечения отказоустойчивости группируются по принципу их направленности на преодоление тех или иных типов отказов:
1. Реактивные методы – включают репликацию, создание контрольных точек (чекпоинтинг) и процедуры восстановления после отказов. Эти подходы направлены на минимизацию последствий уже произошедших сбоев.
2. Проактивные методы – основаны на постоянном мониторинге состояния системы и прогнозировании возможных отказов с использованием методов машинного обучения (ML). Основной акцент делается на предупреждение сбоев до их наступления за счёт превентивных мероприятий.
3. Резилиентные методы – предполагают автоматическое восстановление работоспособности системы, использование алгоритмов выбора ведущего узла, а также автономное переключение между резервными компонентами без участия оператора.
Архитектуры высокой доступности чаще всего делятся на два фундаментальных типа: active‑passive и active‑active (рисунок 1).
Рис. 1 Сравнительная схема архитектур Active-Passive и Active-Active в отказоустойчивом кластере Azure Stack HCI с использованием Storage Replica
В active‑passive конфигурации только один узел или кластер активно обрабатывает трафик, остальные находятся в резерве и переходят в активное состояние только при сбое основного узла. Такая модель проста в реализации, но во время сбоя производительность может резко снижаться, если резерв недостаточно масштабен.
Active‑active архитектура предполагает, что все узлы одновременно активны и делят нагрузку. При отказе одного из них остальные продолжают обработку без значительного ухудшения своими ресурсами. Такой подход сложнее в поддержке, требует компетентного балансирования и синхронизации данных, но обеспечивает почти непрерывную доступность
Вторая важная область – CAP‑теорема в распределённых системах (рисунок 2). Теорема CAP (известная также как теорема Брюера) – эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств [5]:
– согласованность данных (consistency) – во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
– доступность (availability) – любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают;
– устойчивость к разделению (partition tolerance) – расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Рис. 2 Иллюстрация CAP-теоремы
Следующий важный тренд – микросервисная архитектура и паттерны отказоустойчивости. Одной из ключевых задач при разработке микросервисов является обеспечение их отказоустойчивости. В системе, состоящей из множества сервисов, сбои одного компонента могут вызвать цепочку ошибок, затронувшую другие части системы [4].
В таблице 2 систематизированы ключевые паттерны отказоустойчивости, применяемые в микросервисной архитектуре.
Таблица 2
Паттерны отказоустойчивости в микросервисной архитектуре
Паттерн |
Назначение |
Принцип работы |
Примеры реализаций / технологий |
Ограничитель цепи |
Предотвращает перегрузку зависимого сервиса в случае его отказа |
При обнаружении сбоев прерывает поток запросов до восстановления доступности сервиса |
Hystrix (Netflix), Resilience4j, Istio, Envoy |
Повтор запроса |
Обеспечивает устойчивость при временных сбоях |
Автоматическое повторение запроса через заданные интервалы |
Spring Retry, Resilience4j, политика Retry в gRPC |
Тайм-аут |
Предотвращает «зависание» микросервиса при ожидании ответа |
Прекращает выполнение запроса, если ответ не получен в установленное время |
OpenFeign, OkHttp, Envoy, настройки Kubernetes |
Разделение на отсеки |
Изоляция компонентов системы, чтобы сбой одного не повлиял на другие |
Ограничивает ресурсы (потоки, соединения) для каждой части системы отдельно |
Kubernetes namespaces, Istio, Resilience4j |
Запасной сценарий |
Обеспечивает альтернативное поведение при сбое основного сервиса |
При недоступности основного сервиса используется предопределённый ответ или резервный источник |
Hystrix fallback, ручные обработки в логике приложения |
Контроль давления |
Управление входящими запросами при перегрузке |
Ограничивает или приостанавливает поток запросов при достижении пороговых значений нагрузки |
Akka Streams, RxJava, Istio, Envoy |
Самовосстановление |
Автоматическое восстановление после отказов |
Система автоматически перезапускает или восстанавливает компоненты без вмешательства человека |
Пробы Liveness и Readiness в Kubernetes, Operator Pattern |
Ограничение скорости |
Защита от перегрузки и DoS-атак |
Ограничивает частоту запросов от клиента в заданный интервал времени |
NGINX rate limit, Envoy, Istio, Kong API Gateway |
Обнаружение сервисов |
Поддерживает актуальный список рабочих микросервисов |
Автоматически определяет доступные экземпляры сервиса и перенаправляет к ним запросы |
Consul, Eureka, CoreDNS в Kubernetes |
Балансировка нагрузки |
Равномерное распределение запросов между экземплярами сервиса |
Перенаправление трафика на менее загруженные узлы |
HAProxy, NGINX, Kubernetes Services, Istio, Envoy |
Плавная деградация |
Сохранение основной функциональности при частичном отказе компонентов |
Временное отключение второстепенных функций, чтобы сохранить работу критических сервисов |
Ручная логика, Istio fault injection |
Несмотря на широкий спектр архитектур и паттернов отказоустойчивости, используемых в современных распределённых и микросервисных системах, они имеют ряд серьёзных ограничений. Эти проблемы связаны как с техническими особенностями реализации, так и с экономическими, организационными и правовыми аспектами эксплуатации. В таблице 3 представлены ключевые ограничения.
Таблица 3
Проблемы и ограничения существующих архитектурных решений
Проблема / Ограничение |
Суть |
Стоимость реализации |
Высокие затраты на инфраструктуру, дублирование ресурсов, лицензии и техническое обслуживание |
Сложность конфигурации и сопровождения |
Требуются высококвалифицированные DevOps-инженеры и системные архитекторы |
Рост технического долга |
Многоуровневая архитектура приводит к накоплению ошибок, «заплат» и непредсказуемому поведению |
Компромиссы по CAP-теореме |
Невозможно одновременно обеспечить согласованность, доступность и устойчивость к разделению |
Невозможность полной предикции пиков |
Даже ML-модели не способны всегда точно предсказать всплески нагрузки или поведение пользователей |
Ограничения масштабирования монолитных частей |
Некоторые бизнес-функции всё ещё завязаны на монолит и плохо масштабируются |
Зависимость от внешних поставщиков облака/СУБД |
Возможны сбои на стороне провайдеров, проблемы с локализацией, юридические ограничения |
Регламентные и юридические риски |
Особенно в отраслях с высокой степенью регулирования (финансы, здравоохранение, оборона) |
Тестирование отказов в проде – риск |
Даже при наличии sandbox- или staging-окружений невозможно смоделировать все реальные сценарии сбоев |
Проблемы совместимости при масштабировании |
Микросервисы с разными версиями API или библиотек могут конфликтовать при увеличении нагрузки |
Перспективы и направления дальнейших исследований в области проектирования отказоустойчивых систем с учётом экстремальных пиков нагрузки связаны с развитием интеллектуальных и самоадаптирующихся архитектур. Одним из ключевых векторов является интеграция машинного обучения и методов предиктивной аналитики для раннего выявления потенциальных точек отказа и автоматической коррекции параметров системы до возникновения инцидентов.
Особое внимание уделяется разработке гибридных архитектур, сочетающих возможности мультиоблачных и edge-решений, что позволяет распределять нагрузку не только между дата-центрами, но и ближе к конечному пользователю. Продолжается активное изучение автоматизированных систем самовосстановления, построенных на основе операторов Kubernetes и политики «chaos engineering», имитирующей реальные сбои в безопасной среде. Перспективным направлением также остаётся формализация архитектурных шаблонов отказоустойчивости для различных отраслей с учётом специфики SLA, нормативных требований и поведения пользователей, что позволит повысить воспроизводимость решений. Ведутся разработки в области автоматического обеспечения согласованности в условиях высокой латентности и разделения сетей.
Важным становится вопрос энергоэффективности и устойчивости систем к киберугрозам, особенно в распределённых средах, где необходимо одновременно учитывать надёжность, безопасность и производительность.
Выводы
Таким образом, традиционные подходы к отказоустойчивости недостаточно эффективны в условиях экстремальных пиков нагрузки из-за их статической природы и неспособности масштабироваться в режиме реального времени. Микросервисная архитектура, сочетание Active-Active кластеризации и внедрение отказоустойчивых паттернов (Circuit Breaker, Bulkhead, Retry и др.) обеспечивают адаптивность, гибкость и устойчивость системы. Вместе с тем, такие подходы сопровождаются рядом вызовов: высокие издержки, сложность управления, архитектурные компромиссы по CAP и сложности в прогнозировании реальных сценариев сбоев.
Перспективными направлениями являются развитие интеллектуальных механизмов самовосстановления, интеграция предиктивных ML-моделей и унификация архитектурных шаблонов отказоустойчивости под отраслевые требования. Всё это позволяет повысить надёжность и устойчивость критически важных систем при любых сценариях нагрузки, снижая операционные и репутационные риски.
Литература:
1. Бабичев Р.П., Клабуков А.Д., Родионов К.В. Модель оптимального энергоэффективного состояния распределенной отказоустойчивой системы с учетом почасовых колебаний нагрузки // Вестник Белгородского государственного технологического университета им. В.Г. Шухова. – 2017. – № 2. – С. 208-212.
2. Мелентьев В.А. О топологической отказоустойчивости масштабируемых вычислительных систем // Управление большими системами: сборник трудов. – 2017. – № 70. – С. 58-86.
3. Мирзапулатов Р.У., Сейдаметова З.С. Особенности разработки высоконагруженных систем // Информационно-компьютерные технологии в экономике, образовании и социальной сфере. – 2018. – № 2(20). – С. 6-13.
4. Паттерны отказоустойчивости для микросервисов | Учебник Elixir [Электронный ресурс]. – Режим доступа: https://nweb42.com/books/elixir/patterny-otkazoustoychivosti-dlya-mikroservisov/.
5. Теорема CAP – Рувики: Интернет-энциклопедия [Электронный ресурс]. – Режим доступа: https://ru.ruwiki.ru/wiki/Теорема_CAP.