К вопросу о повышении надежности программного обеспечения за счет применения методов избыточности

Бесплатный доступ

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

Еще

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

Короткий адрес: https://sciup.org/14129609

IDR: 14129609   |   DOI: 10.47813/2782-5280-2024-3-2-0201-0211

Текст статьи К вопросу о повышении надежности программного обеспечения за счет применения методов избыточности

В настоящее время, когда основным продуктом ведущих корпораций может являться всего лишь один программный продукт, проектирование архитектуры является важным этапом в построении таких продуктов, так как все детали разработки должны быть продуманы до мелочей. При проектировании программных систем в архитектуру зачастую закладываются основные направления, на которые в дальнейшем делается основной упор. Среди таких направлений выделяют, например, безопасность, удобство дальнейшего расширения и сопровождения программного продукта, производительность системы, её безопасность и защищенность, а также её надежность [1]. При этом, следует отметить, что некоторые направления могут являться «антагонистами». Это значит, что нацеленность на одно направление может негативно сказаться на другом. Так, например, для повышения производительности приложения придется отказаться от разбиения приложения на отдельные модули для исключения затратного межмодульного обмена.

Большинство производителей программного обеспечения (ПО) уделяют особое внимание надежности своего продукта, а именно его отказоустойчивости. В зависимости от области применения стоимость сбоя программы может иметь существенное значение для пользователей. Примером может служить космическая отрасль или даже линия производства какого-либо товара, где остановка производства на несколько часов может обернуться большими убытками. Данный показатель непосредственно влияет на степень доверия к продукту – потребитель должен быть уверен в том, что ПО будет удовлетворять его потребности и при этом случаи отказов приложения будут минимальны. Вместе с тем, программное обеспечение, которое с периодической постоянностью имеет отказы, вряд ли будет пользоваться большой популярностью на рынке.

МАТЕРИАЛЫ И МЕТОДЫ

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

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

Избыточность (redundancy) в целом является принципом, который основан на увеличении количества тех или иных объектов (модулей/компонентов) в разрабатываемой системе. В построении отказоустойчивых приложений избыточность может включать в себя несколько концепций. Одной из них является введение в архитектуру нескольких одинаковых с точки зрения выполняемых действий, но разных в реализации модулей. Под модулем в данном случае понимается компонент системы, который может быть как простой функцией, так и целым набором функций, служащих определенной цели. Другой же концепцией является выделение из монолитной системы какой-то части и распределение её на нескольких независимых пространствах, что позволяет исключить влияние определенной среды на тот или иной модуль.

Избыточность может быть нескольких типов [2]:

  • -    пространственная избыточность – число модулей, присутствующих в системе, в количестве двух и более;

  • -    временная избыточность – наличие запаса времени, предназначенного для восстановления системы в случае ее отказа;

  • -    информационная избыточность – фактически, представляет собой систему бекапов (резервных копий), предназначенных для восстановления данных при наличии ошибки в работе системы.

Цель избыточности – обеспечить высокую доступность и надежность системы, даже при наличии ошибок или отказов отдельных компонентов. Это достигается за счет дублирования критических компонентов, резервирования ресурсов и оптимизации системы для минимального влияния ошибок на работу системы.

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

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

Схематично избыточность может быть представлена следующим образом (рисунок 1).

Рисунок 1. Схема избыточности в построении программного обеспечения.

Figure 1. Diagram of redundancy in software construction.

Активное резервирование – это метод обеспечения высокой доступности и надежности систем, при котором резервные модули постоянно работают параллельно с основными, обеспечивая мгновенный переход на резерв в случае отказа основного модуля [3].

Наряду с активным резервированием также выделяют пассивное резервирование. Отличие состоит в том, что при пассивном резервировании компоненты, назначенные как резервные, задействуются только при отказе основных компонентов. В отличие от пассивного, активное резервирование подразумевает постоянную работу основных компонентов и мониторинг системы на предмет наличия отказов в работе.

Среди основных преимуществ активного резервирования выделяются следующие факторы:

  • -    общее повышение надежности всей системы, увеличение её доступности;

  • -    снижение времени, когда система простаивает при наличии отказов в работе основных модулей;

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

  • -    увеличенную безопасность эксплуатации за счет защиты от перенапряжений и других опасных ситуаций.

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

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

Дублирование в построении отказоустойчивых приложений – это метод, который заключается в создании копий важных компонентов системы, таких как серверы, системы хранения данных и сетевые подключения. Это позволяет обеспечить минимальное время простоя в случае сбоя одного из компонентов, так как дублирующий компонент может взять на себя его функции [4].

Дублирование может быть реализовано на различных уровнях, включая:

  • -    дублирование дисковых массивов (RAID), которое обеспечивает избыточность данных и позволяет восстановить данные в случае сбоя одного из дисков;

  • -    дублирование серверов и систем хранения данных, которое позволяет обеспечить высокую доступность системы и минимальное время восстановления в случае сбоя;

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

Балансировка нагрузки (load balancing) – это процесс распределения входящего трафика между несколькими серверами для обеспечения высокой доступности, масштабируемости и надежности системы. Такой подход позволяет повысить эффективность обработки запросов за счет горизонтального масштабирования системы, то есть разделения её на несколько отдельных компонентов, каждый из которых имеет свой «запас прочности» на количество одновременно обрабатываемых запросов. При этом, такое масштабирование имеет запас на будущее, так как при таком подходе количество компонентов может быть увеличено под необходимую нагрузку.

Балансировка нагрузки предлагает несколько преимуществ, таких как:

  • -    повышение производительности и скорости реагирования приложений;

  • -    лучшая географическая доступность и уменьшение задержки;

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

  • -    защита от сбоев сервера и автоматическое перенаправление трафика на доступные ресурсы.

Балансировка нагрузки применима как к аппаратному обеспечению (кластеры серверов, сетевые устройства, прокси-сервера), так и к программному обеспечению (экземпляры компонентов системы) [5].

Разделение на микросервисы. Так называемая микросервисная архитектура подразумевает подразделение единой системы (монолит) на отдельные подсистемы – микросервисы. Микросервисы, в свою очередь, являются компонентами целой системы и предназначены для какой-либо области, например, для вычислительных работ или для преобразований одного типа файлов в другой.

Микросервисы не ограничены в выборе технологий, на основе которых они проектируются и разрабатываются. При этом, эти технологии не обязательно должны быть аналогичны основным компонентам системы и могут отличаться, если того требуют происходящие в системе процессы [6].

Среди преимуществ микросервисной архитектуры выделяют следующее:

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

  • -    оптимизация процесса управления изменениями. В микросервисной архитектуре зачастую обновляется не вся система целиком, а только отдельные микросервисы, что упрощает их изменение;

  • -    повышение надежности системы. В микросервисной архитектуре отказ одного или нескольких микросервисов не всегда является критическим фактором. Остальные микросервисы зачастую продолжают свою работу.

Однако, микросервисная архитектура также имеет свои недостатки:

  • -    усложнение процесса развертывания. В случае, если изначально не заложены механизмы для развертывания системы как единого целого, то развертывание каждого микросервиса может представлять собой более сложный процесс;

  • -    усложнение процесса отладки системы. Учитывая, что микросервисы могут разрабатываться как разными людьми, так и с применением разных технологий, процесс отладки может быть усложнен;

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

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

Горячее резервирование отличается от холодного резервирования, где резервный сервер или система не работают до тех пор, пока основной сервер или система не выйдут из строя. В горячем резервировании резервный сервер или система постоянно работают и готовы к немедленному переключению в случае сбоя основного.

В целом, горячее резервирование похоже на активное резервирование. Отличие между этими двумя методами состоит в том, что при горячем резервировании оба модуля (или более) работают одновременно, но лишь один из них принимает запросы, тогда как другие модули находятся в активном состоянии с целью продолжить работу системы при сбое в основном модуле. Активное резервирование, в свою очередь, предполагает одновременную работу основных и резервных модулей, они также одновременно обрабатывают запросы.

Резервное копирование (backup) – это процесс создания копии данных на отдельном носителе, предназначенной для восстановления информации в случае потери, повреждения или замены устройства. Это важнейшая функция защиты данных, которая снижает риск полной или частичной потери данных в случае непредвиденных событий.

Выделяют следующие виды резервного копирования:

  • -    полное – при каждом резервном копировании производится копия всех данных;

  • -    инкрементное – при каждом резервном копировании производится копия только тех данных, которые изменилось с последнего резервного копирования;

  • -    дифференциальное – копирование только тех данных, которые были изменены с момент предыдущего полного резервного копирования [7].

Если горячее резервирование и активное резервирование можно назвать «активными» способами повышения надежности системы, то резервное копирование является «пассивным» способом.

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

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

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

Детектирование ошибок – это процесс обнаружения и идентификации ошибок или сбоев в системе. Это может быть достигнуто с помощью систем мониторинга, которые отслеживают работу системы и автоматически оповещают об обнаружении ошибок. Детектирование ошибок позволяет быстро реагировать на проблемы и минимизировать время простоя системы.

ЗАКЛЮЧЕНИЕ

Для повышения надежности используются такие методы, как: избыточность (пространственная, временная и информационная), активное и пассивное резервирование, мониторинг состояния системы и журнала работы, дублирование аппаратного и программного обеспечения, балансировка нагрузки на компоненты системы, разделение системы на отдельные подсистемы (микросервисы), горячее резервирование, резервное копирование (полное или частичное), а также организационные методы – прогнозирование и детектирование ошибок.

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

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

Статья