Комментарии 16
Но как же определить является ли наша система отказоустойчивой и стабильной? И на сколько? Как в идеале замерить эти свойства, чтобы двигаться к цели согласно некой метрике, а не наощупь?
Единственный способ спроектировать систему, которая будет устойчива к сбоям — проводить стресс-тесты (resilience testing / chaos engineering), по результатам тестов делать выводы, менять архитектуру и подходы к написанию кода, снова запускать тест... и так до бесконечности :)
Количество пройденных тестов и будет метрикой отказоустойчивости отдельных компонентов и системы в целом. Только на основе метрики делаем вывод о повышении или понижении стабильности системы.
Разве отказоустойчивость (надежность) не считают количественно? Все эти "пять-шесть девяток" например. В статье "Проектирование отказоустойчивости IT-систем" нет ни одной цифры по надежности ... и тем более расчета.
Проектируете что-то "очень надежное", а надежность этого "очень надежного" не считаете?
пять-шесть девяток – метрика на основе уже случившегося. Стресс-тесты позволят посчитать метрику "а что если" – сколько будет девяток (как быстро система поднимется), если умрёт тот или иной хост к примеру
пять-шесть девяток – метрика на основе уже случившегося.
Есть подходы к проектированию систем с ровно заданным числом девяток (типа оптимизация, т.к. избыточная надежность стоит недешево), например, через алгоритм, какую конфигурацию кластера и с какими узлами (надежность узла) подобрать, чтобы получить, например, шесть девяток. Это Надежностное проектирование (через модели надежности), т.е. "задолго до "уже случившегося".
В Вашем случае, когда "Стресс-тесты позволят посчитать метрику " - чему равны значения коэффициента готовности "отказоустойчивой ИТ-системы"? Какие значения метрики (сколько будет девяток)?
Пример расчета с цифрами покажете?
Есть конкретный пример с прошлой недели – при сбое не переподнялись только системы, на которые поставили тулзу для аварийного автоматического переключения. По моделям и алгоритмам – у них выше показатели надёжности, по факту – оказалось что ниже, чем у систем, куда ещё не успели поставить тулзу.
Правильность установки тулзы и ее работоспособность при разных условиях кроме как учебными сбоями не проверить
Нет, это расчетный показатель. Как и базовые RTO/RPO, которые я с немалым удивлением не нашел :)
Вы собираете требования к системе, реализуете решение, чтобы они выполнялись, а потом тестами, вплоть до реального отключения проверяете
И именно так, проектируете под требования!!
Про асинхрон. Смотрите. Разницу определяет суть взаимодействия. Условно, если пользователь дал запрос и ждет ответа - это синхронное взаимодействие.
Вы можете напихать внутри 100500 очередей, но суть не изменится - если клиент за условные 10 секунд не дождался ответа -> fail. И иногда, это определено задачей. Вот просто по определению. Плюс сам по себе асинхрон не панацея. Система чудесно может лечь в обоих вариантах легко и непринужденно :)
тут уже на лицо архитектурные ошибки — если мы синхронное взаимодействие пользователя с системой реализуем на бэкенде через асинхронщину
Нет никакой ошибки. Так можно делать без проблем со своими плюсами/минусами. Асинхрон конвертирует нагрузку в очередь. Это дает следующие плюсы
Сохранность сообщений, если инициируется транзакционный запрос. Банально проще и комфортнее
Система не ляжет технически от повышенной нагрузки, так как забирает ровно столько, сколько может проглотить. Но с другой стороны может быть все зря, так как получатель уже ушел :)
Проще и естественнее оркестровать через сообщения. Это не единственный способ конечно, но с сообщениями это более природно, что ли
Может быть пример, что под капотом компоненты перетирают "за жизнь" через MQ, а наружу торчит http-фасад.
Короче, это очень в общем. Иногда проще взять http, просто потому, что на короткой дистанции более важно то, с чем умеет работать команда здесь и сейчас :)
тут вопрос во взаимодействии с пользователем, т.е. в UI/UX. Если мы понимаем, что за увлоный таймаут в 1 секунду мы не сможем пользователю сказать, что всё ок, транзакция выполнена или не ок, завершилась с ошибкой — то пользователю явно прозрачно об этом сообщаем. К примеру, секунду крутим лоадер, если за секунду не успели — говорим, что ещё обрабатывается, результат пришлём на почту, вкладку можно закрыть (или, "пожалуйста не закрывайте вкладку, обновим статус операции через 10 секунд"). Короче не кидаем пользователя в неопределенности с бесконечным лоадером. Но это уже несколько отдельная от отказоустойчивости тема :)
Позволю себе не согласиться с некоторыми примерами из статьи.
Пример номер раз:
у нас есть несколько экземпляров бэкенда, на каждом живут свои сессии. При утери одного бэкенд-экземпляра у нас остаются клиенты с куками (токенами), которые на оставшихся будут не валидны. Что делает автор? Вфигачивает туда Redis, да еще и в нескольких экземплярах. Что предлагаю я? "Разлогинить" пользователя, и попросить залогиниться заново.
Конечно, конечное конкретное решение зависит от задачи и ограничений, поставленных бизнесом, но падения как такового в моём случае нет - просто у пользака внезапно протухла сессия. Бывает. Зато мы экономим денег (в некоторых случаях - много денег, потому что кластер Redis'ов не бесплатная игрушка).
Пример номер два:
"умри быстро". Работаю в компании, в которой именно так поступили разработчики. "умри быстро". А знаете, что происходит, когда у вас контейнеры массово дохнут и потом вновь массово поднимаются? Они штурмуют базу. И чем хуже приложению, тем сильнее штурм базы. Более того, некоторые успевают не только закидать "коннектами" БД, но еще и закинуть туда непосредственно чего-либо внутрь. Например, тяжелых запросов. Идеальный шторм.
Количество соединений растёт, пока база не упадёт или не упрётся в лимит коннектов, после которого у вас все новые контейнеры просто паникуют нон-стопом.
Количество запросов растёт. Количество тредов на базе растёт, лаг ответа растёт, запросы не отвечают вовремя (в лимиты, прописанные разрабами на своей стороне), и контейнеры (даже живые) начинают схлапываться, потому что думают, что они умирают (раз не получили ответа от БД), оркестратор спаунит новые, которые уже ничего не получают от базы, кроме коннекта, и всё. Спираль смерти.
У вас будет от 30 секунд до 3 минут, чтобы из неё выйти, или у вас, с высокой вероятностью, хлопнется база - а это уже серьёзный залёт, даже если вам есть куда переключиться после такого шторма.
"умри быстро" надо применять с умом, нельзя этот совет применять бездумно. Это точно не серебряная пуля.
Спасибо за статью! Материал годный, но хотелось бы больше примеров из практики, особенно интересны метастабильные состояния.
Этот паттерн обычно используют взамен классической стратегии простых повторов (Retry) запроса в случае неуспеха, ставшей антипаттерном.
Мне кажется тут авторы подборки антипаттернов либо не знакомы со всеми паттернами либо лукавят. А как же retry with exponential backoff?
В 99.9% случаем он работает прекрасно. В моей практике был только один случай когда circuit breaker мог бы быть лучше exponential backoff (но это не точно). И проблема даже не в самом exponential backoff, а в его классической реализации - полностью аннулировать накопившийся backoff на первый успешный ответ (что в результате может убивать систему периодически, волнами). Если бы backoff откатывался плавно, то проблем бы не было.
Circuit breaker хорош там где ответы не "подвисают", а где клиент не понимает ответа и отсылает новый запрос немедленно.
Проектирование отказоустойчивости IT-систем