Все о создании надежных, функциональных и масштабируемых систем.

Хола,

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

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

Возьмем пример medium.com. Как правило, на этом сайте есть рецензии, блоги и публикации. А если он пропадет на несколько часов? Мир не собирается отказываться, но в случае с программным обеспечением для поддержки самолетов (программное обеспечение, которое помогает самолетам работать во время полета) произойдет сбой на несколько минут, на карту будут поставлены сотни жизней. Так что это крайне неприемлемо. Если YouTube когда-либо отключится на несколько часов, это вызовет хаос, потому что сотни и миллионы людей используют YouTube каждый день, и это повлияет на большую часть населения. Давайте подойдем к главному вопросу: что означает доступность системы? Обычно мы измеряем доступность в процентах от времени безотказной работы системы в данном году. В настоящее время, когда мы имеем дело с доступностью, мы имеем дело с очень высоким процентом. В отрасли большинство систем нацелены на очень высокую доступность, поэтому в конечном итоге мы измеряем доступность не точно в процентах, а скорее в «девятках».

Если система онлайн 99% года, можно сказать, что доступность системы равна двум девяткам, если она онлайн 99,9% года, то мы можем сказать, что доступность системы равна трем девяткам. Здесь у нас есть диаграмма из Википедии, содержащая различную информацию о времени простоя и показателях доступности в днях и часах.

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

В настоящее время пять девяток считаются золотым стандартом доступности, и мы должны ориентироваться на него при разработке системы. У многих поставщиков услуг есть нечто, называемое SLA (соглашение об уровне обслуживания), и это соглашение между поставщиком услуг и клиентами или конечными пользователями системы. Так много поставщиков услуг прямо написали соглашения об уровне обслуживания и говорят клиентам: «Эй, мы гарантируем такую ​​доступность услуг, как указано в соглашениях об уровне обслуживания». SLO — это синоним SLA, он связан с SLA, но это не одно и то же. SLO означает целевой уровень обслуживания. Вы можете думать о них как о компонентах SLA. Если я предоставляю вам услугу, я предоставляю процент времени безотказной работы системы, этот процент времени безотказной работы является SLO. Все поставщики облачных услуг, такие как GCP, AWS и Azure, имеют четкое соглашение об уровне обслуживания, и это упоминается на странице продукта на их веб-сайте.

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

Как повысить доступность системы?

В системе не должно быть единой точки отказа. Это означает, что в вашей системе не должно быть единой точки отказа, из-за которой вся система выходит из строя. Это может быть достигнуто за счет «избыточности», что означает, что определенные части систем могут быть продублированы, реплицированы или размножены, чтобы уменьшить единую точку отказа. Итак, давайте предположим простое приложение с архитектурой клиент-сервер, когда клиент отправляет запрос на сервер, а сервер взаимодействует с сервером базы данных. Сервер можно назвать единой точкой отказа. Поэтому мы хотим сделать серверы избыточными, что означает, что мы должны дублировать серверы и добавить балансировщик нагрузки для равномерного распределения трафика по разным серверам. Но теперь балансировщик нагрузки является единственной точкой отказа. Таким образом, балансировщики нагрузки используются в значительной степени, чтобы избежать единой точки отказа (обсуждается в описании балансировщика нагрузки). Нам приходится дублировать балансировщики нагрузки, чтобы преодолеть большие проблемы с трафиком. У нас есть два типа резервирования, активное и пассивное.

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

Вы можете найти меня на LinkedIn — https://www.linkedin.com/in/connectayush

Спасибо :)