Создание фейловер-стратегии для высоконагруженного приложения

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

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

✏️ Фейловер-стратегия (Failover Strategy) — это механизм обеспечения высокой доступности приложения, в рамках которого «основная» система в случае сбоя может быть заменена «резервной».

В этом уроке вы узнаете:

Какие бывают требования к доступности системы?
Как рассчитывается время обслуживания системы?
Зачем нужна фейловер-стратегия?

Требования к доступности системы

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

Для определения доступности нужно знать согласованное время обслуживания, предъявленное в требованиях к системе, и реальное время простоя.

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

Так мы можем измерить доступность в процентах:

🔹 Доступность = (Согласованное время обслуживания – Время простоя) / Согласованное время обслуживания * 100

Например, если у приложения согласовано время обслуживания 8500 часов в год, а суммарное время простоя составило 50 часов, то мы получим реальную доступность 99,412%:

🔹 (8500 – 50) / 8500 * 100 = 99,412%

Сергей

Почему нужно отталкиваться от «согласованного» времени работы, а не от общего количества часов в сутках?

К каждому приложению предъявляют уникальные требования. От приложения курьерской службы, которая работает по всему миру и без выходных, будут ожидать доступности 24/7 и 365 дней в году. А к приложению для ввода показателей счётчиков ЖКУ могут предъявить более мягкие требования.

Сергей

А почему бы не делать все приложения сразу так, чтобы обеспечивать их доступность 100% времени?

Любая разработка имеет ограничение ресурсов, которое обусловлено экономическими показателями. Чем выше доступность приложения, тем дороже оно обойдётся как на этапе разработки, так и на этапе сопровождения. Поэтому при предъявлении требований к приложению нужно учитывать, что это должно быть обосновано экономическими показателями.

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

Зная требуемую доступность, мы можем определить максимальное время простоя за год:

99,671% = 28,8 часа простоя в год;
99,741% = 22 часа простоя в год;
99,982% = 1,6 часа простоя в год;
99,995% = 26,3 минуты простоя в год.

Время обслуживания системы

Подробнее разберём, из чего состоит время обслуживания системы. Глобально его можно разделить на два основных параметра, отражающих промежутки времени:

MTBF, mean time between failure
Продолжительность времени работы приложения без сбоев. По-другому это можно назвать временем между сбоями или временем между началом нормальной работы и следующим сбоем.
MTTR, mean time to recovery
Это время, которое потребовалось для восстановления после сбоя. Или период времени, когда рабочая нагрузка остаётся недоступна, а неисправная подсистема ремонтируется или возвращается в эксплуатацию. Этот показатель складывается ещё из двух других:
- MTTD, mean time to detect
  Промежуток времени, который потребовался на обнаружение неисправности и начало работ по восстановлению;
- Repair time
  Промежуток времени, который потребовался на само восстановление приложения до рабочего состояния.

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

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

Определение требований к системе

Представим, к системе предъявлено требование доступности 99,5%. Эти требования предъявляют сами владельцы бизнеса, основываясь на расчётах издержек в случае недоступности.

Показатель системы за последний год равен 99,741% = 22 часа суммарного простоя в год. И хотя формально приложение соответствует требованиям, оно всё ещё может негативно влиять на бизнес, так как приложение могло упасть всего 1 раз за год, но «лежать» все 22 часа.

Долгое время простоя может привести ко множеству последствий:

неудовлетворённости клиентов,
потере доходов,
репутационным издержкам.

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

Поэтому при формировании требований к системе важно фиксировать не только целевой процентиль доступности, но и показатель RTO (Recovery Time Objective) — время, необходимое для восстановления работоспособности системы.

RTO накладывает ограничения на доступное MTTR, которое разбиралось выше. Этот показатель критически важен при определении фейловер-стратегии. Позже вы ещё разберёте этот момент, а сейчас нужно перейти к классам критичности.

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

Обычно определяют четыре класса критичности:

Mission critical;
Business critical;
Business operational;
Office productivity.

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

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

Как определить класс критичности приложения?

Важно соблюдать два правила:

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

Сергей

Что определяет уровень критичности?

Приоритет восстановления при массовых сбоях. Восстановление всех систем после аварии необходимо, но, если затронуто несколько систем, в первую очередь восстанавливаются наиболее важные.
Типичные значения SLA (соглашение об уровне обслуживания). Если простой системы ведёт к потерям, следует повысить её критичность, а не винить администраторов.
Стандартные инфраструктурные решения. Каждое решение обладает своими характеристиками надёжности, скоростью восстановления при сбоях и определённой стоимостью. В мировой практике существует определённое распределение систем по уровням критичности. Если на вашем предприятии более 15% систем отнесены к классу Mission critical, это повод пересмотреть критерии классификации.

Пример.

Что произойдёт, если приложение будет недоступно в течение 10 минут, 1 часа, 1 суток?

сколько денег будет потеряно/не заработано;
будут ли негативные публикации в СМИ;
потребуется ли выплата неустоек клиентам.

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

Время перейти к фейловер-стратегиям системы.

Фейловер-стратегии системы

Напомним, что фейловер-стратегия — это совокупности механизмов и подходов, которые обеспечивают переключение на резервную (redundant) систему, когда основная (primary) система выходит из строя. Резервная система должна быть надёжной и неподверженной сбоям.

Причины выхода из строя

Система может выйти из строя по разным причинам. К этому может привести:

Аппаратный сбой
Из строя может выйти сервер, накопитель или другое оборудование. Такие неисправности могут быть выявлены системами мониторинга, которые затем могут запустить процессы аварийного переключения для перехода на резервное оборудование.
Программный сбой
Ошибки и другие проблемы с ПО, которые приводят к недоступности приложения. Эти неисправности можно обнаружить с помощью инструментов мониторинга или healthchek-ами, которые могут запустить аварийное переключение на резервные экземпляры ПО.
Сбой в работе сети
Если сбои в работе сети приводят к невозможности взаимодействия компонентов между собой, то могут быть предусмотрены резервные сетевые маршруты и каналы связи.
Ручное вмешательство
Проблемы и сбои также вызываются человеческим фактором: ошибками в конфигурациях ПО или оборудования, несвоевременными работами или действиями в системе. Банально служба эксплуатации может случайно выключить сервер, на котором запущен основной экземпляр приложения.

Почему фейловер-стратегия важна

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

Три самых больших преимущества использования проработки правильной фейловер-стратегии:

Обеспечивает непрерывность обслуживания — в случае отказа одного из узлов системы вы можете продолжать обслуживать клиентов и поддерживать работу бизнеса.
Минимизирует время простоя — позволяет бизнесу работать практически в обычном режиме за счёт резервного узла системы, пока основной узел ремонтируется. Это позволяет избежать затрат на простои: потерь производительности, данных, дохода и репутации.
Снижает риски — вероятность одновременного выхода из строя основной и резервной системы очень мала. Поэтому риск полной недоступности приложения сильно ниже.

Реализация фейловер-стратегии

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

Привлечение ручной работы напрямую влияет на скорость реакции и общее время восстановления. Для систем, от которых требуется высокая доступность в районе 99,95% в год, «завязывать» фейловер на пользователей не получится.

Фейловер-стратегии могут применяться абсолютно к любым компонентам системы:

само приложение;
база данных;
кеш;
балансировщик;
брокер сообщений.

При этом глобально фейловер-стратегии бывают 2 типов: Active-Active и Active-Standby.

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

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

В следующем уроке разберём каждый из типов подробнее.

Задание 1

Определите реальный показатель доступности системы за последний год (365 дней) на основе следующих вводных:

для системы согласованы технические окна раз в 2 месяца в течение 12 часов, в остальное время приложение должно работать;
за год система «падала» 5 раз;
первый раз восстановительные работы заняли 1 час, в остальные 4 раза — по 30 минут;
в среднем каждый раз команде понадобилось 12 минут на обнаружение сбоя.

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

Ваш ответ правильный

99,954

Для начала нужно определить согласованное время работы приложения. Приложение должно быть доступно всё время, за исключением технических окон, которые проводятся раз в 2 месяца на протяжении 12 часов. Поэтому берём 8760 часов (количество часов в 365 днях) и вычитаем 72 (количество доступных технических окон в году, помноженное на их продолжительность):

$\text{Согласованное время работы} = 8760 - 72 = 8688$

Далее нужно определить суммарное время простоя. Общее время, которое ушло на восстановительные работы, равно 3 часам (1 час + 4 аварии по 30 минут). Но также стоит учесть время, ушедшее на обнаружение аварии. Суммарно это ещё 1 час (12 минут умножить на 5 аварий). Итого 4 часа.

В итоге получается:

$A = (8688 - 4) / 8688 * 100 = 99,9539$

Задание 2

Выберите утверждения, которые правильно описывают фейловер-стратегию.

Фейловер-стратегия способствует повышению производительности системы за счёт распределения нагрузки между несколькими серверами

Хотя распределение нагрузки важно для улучшения производительности, цель фейловер-стратегии — это обеспечение отказоустойчивости. Она помогает минимизировать время простоя в случае сбоя системы, но не связана с повышением производительности или балансировкой нагрузки.

Фейловер-стратегия в первую очередь нацелена на снижение времени простоя, но не гарантирует доступность при полном сбое системы

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

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

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

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

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

Дополнительные материалы

Итоги

Фейловер-стратегия (Failover Strategy) — это механизм обеспечения высокой доступности приложения, в рамках которого «основная» система в случае сбоя может быть заменена «резервной».
Доступность — один из основных способов измерения отказоустойчивости. Она определяется как процент времени, в течение которого приложение доступно для использования.
Время обслуживания системы делится на два основных параметра, отражающих промежутки времени: MTBF, mean time between failure, и MTTR, mean time to recovery.
При формировании требований к системе важно фиксировать не только целевой процентиль доступности, но и показатель RTO (Recovery Time Objective) — время, необходимое для восстановления работоспособности системы.
Система может выйти из строя по разным причинам: из-за аппаратного сбоя, программного сбоя, сбоя в работе сети или ручного вмешательства.
Фейловер-стратегия важна, потому что она обеспечивает непрерывность обслуживания, минимизирует время простоя и снижает риски.