Вы наверняка время от времени встречали в новостях сообщения о том, что какой-то крупный интернет-магазин или востребованный сервис вышел из строя и был недоступен в течение нескольких часов или даже суток. Такие ситуации приводят к финансовым потерям (недополученной прибыли или даже штрафам) и становятся ударом по репутации провайдера.Если вы работаете с юридическими лицами, обязательства по обеспечению доступности обычно фиксируются в виде SLA — Service Level Agreements, соглашении об уровне сервиса. Например, вы гарантируете, что сервис будет доступен 99,95% времени. Если вы работаете с обычными пользователями, формальные SLA могут не заключаться, но вы и сами заинтересованы в том, чтобы ваше приложение работало без сбоев.Не существует универсального решения, которое устраняло бы все проблемы, связанные с отказоустойчивостью. Но если сочетать различные подходы со стороны разрабатываемого приложения и настройки инфраструктуры, то можно подобрать удачные решения для каждого конкретного случая и минимизировать риски отказа работы системы.Мы уже затрагивали отдельные вопросы отказоустойчивости в предыдущих уроках: балансировка нагрузки, зоны доступности, автоматическое масштабирование и автоматическое восстановление — все это помогает поддерживать непрерывную работу системы.
Как можно обеспечивать отказоустойчивость
Есть несколько классических подходов к обеспечению отказоустойчивости.
- Масштабирование. Система должна быть готова быстро предоставить дополнительные ресурсы при повышении нагрузки и уметь освобождать лишние ресурсы при снижении нагрузки. Этот принцип заложен в облачной архитектуре.
- Избыточность и резервирование. Наличие независимых дублирующих компонентов повышает надежность системы: например, если один диск выйдет из строя, данные можно быстро перенести на запасной диск.
Отказоустойчивые системы часто строят, создавая несколько копий приложения или его компонентов: баз данных, очередей сообщений и т.д. Реализация может строиться двумя способами: так, чтобы взаимодействие происходило сразу с двумя компонентами одновременно, или так, чтобы постоянно работал только один компонент, а второй находился в ожидании.
- Мониторинг. Для быстрого реагирования нужно отслеживать состояние всех компонентов системы и анализировать историю событий. В небольших системах это можно делать вручную. В крупных или критически важных системах необходим автоматический мониторинг с уведомлениями при приближении к критическим значениям параметров. Такой мониторинг называют проактивным — он позволяет не исправлять проблемы, а не допускать их появления. Мониторингу мы посвятим отдельную тему.
- Реакция на сбои. Например, система может сама перенести данные со сбойнувшего диска на резервный или развернуть дополнительные виртуальные машины при повышении нагрузки. Подобные действия тоже входят в проактивный мониторинг и их тоже можно автоматизировать.
Понимайте вашу систему
Чтобы выбрать оптимальное решение, хорошо изучите устройство вашей системы. Мы говорим именно «системы», а не «приложения» или «сервиса», потому что слабым звеном может оказаться не код, а часть инфраструктуры. Например, это могут быть сбои в работе сети или проблемы на стороне провайдера.Вам нужно понимать слабые места системы — точки отказа. Точкой отказа называется компонент в системе, при выведении из строя которого вся система перестает работать корректно. Часто выход из строя точки отказа приводит к неработоспособности других компонентов, которая в свою очередь ведёт к отказу следующих. Такие ситуации называют каскадными сбоями, или эффектом домино, и приводят к самым масштабным авариям.
Отказоустойчивость в облаке
При проектировании отказоустойчивых приложений важно понимать, что представляют собой отдельные сущности облачной инфраструктуры в реальном мире.Например, понятие зона доступности — достаточно условное и определяется провайдером инфраструктуры. Какой-то провайдер может назвать три соседние стойки в дата-центре тремя разными зонами доступности.В Yandex.Cloud зоны доступности — это дата-центры в разных регионах России. За счет такого географического разделения обеспечивается более высокая надежность. Но это и накладывает определенные ограничения — при отказе некоторые сущности физически не смогут мигрировать в другую зону доступности (например, кеши записи при отказе диска). Значит, вам нужно настраивать репликацию на более высоком уровне, например, на уровне приложения.
Рассчитывайте целесообразность
Высокая доступность приложения или сервиса требует инвестиций. Когда вы планируете меры по повышению отказоустойчивости, старайтесь соотносить затраты и отдачу от них.Например, если ваше приложение просто формирует какой-то ежемесячный отчет, вряд ли стоит добиваться для него времени работы 99,999%. И уж точно не стоит уделять большое внимание отказоустойчивости сред разработки и тестирования.Вот пример оценки вложений в отказоустойчивость для небольшого интернет-магазина: стоит ли бороться за повышение времени доступности с 99% до 99,9%? Судя по этим расчетам, инвестиции окупаются только если выручка магазина составляет не менее 40 тыс. руб. в день.
Мы рекомендуем вам инвестировать в отказоустойчивость, но подходить к этому расчетливо и вдумчиво, с «калькулятором» в руках и четкой картинкой в голове.В следующих четырех уроках мы рассмотрим четыре самых распространенных сценария сбоев и посмотрим, как обеспечивается в этих случаях отказоустойчивость системы.
Свежие комментарии