Resilience как архитектурная характеристика (из книги Continuous Architecture in Practice)
Я уже упоминал несколько раз книгу "Continuous Architecture in Practice" как достойный изучения труд по архитектуре (посты: 1 и 2). А сегодня я решил поделиться кратким саммари того, как авторы подходят к устойчивости и надежности систем. Для начала авторы определяются с терминологией
- A fault is an accidental condition that, if encountered, may cause the system or a system component to fail to perform as required.
- A failure is when a system or system component deviates from its required behavior. So, a fault is something that has gone wrong and that may cause a failure to occur.
- Availability is a measurable quality attribute of a system, defined as the ratio of the time when the system is available to the overall time when it could have been available.
- Reliability builds on availability and adds the constraint of correct operation, not just availability. A widely used definition of the reliability of software is “the probability of failure-free software operation for a specified period of time in a specified environment.”
Дальше авторы рассказывают про старый подход к обеспечению надежности, который обычно назывался high-availability и был основан на создании кластеров приложений, кластеров баз данных, использования cross-site репликации данных. Суть подхода была в том, чтобы в случае проблем с одной из нод в кластере, рабочая нагрузка могла переехать на другую ноду. А если падал кластер целиком, то можно было перенести нагрузку в другой кластер, который всегда стоял наготове (hot standby), в котором уже были все (или большинство) данных, благодаря репликации данных. И все было бы хорошо с этим подходом, удобным для разработчиков приложений, но
- эти механизмы повышения доступности запутанны и сложны в использовании
- зачастую они достаточно дорогие (даже в плане работающего вхолостую hot standby)
- failover процессы могут занимать много времени и требовать много работы
- во время восстановления система может быть полностью недоступна В общем, эти high-availability подходы были расчитаны на монолитные on-premise системы и плохо подходят для распределенных микросервисных систем, которые могут быть развернуты как on-premise, так и в облаках.
Дальше авторы переходят к resilience как другому подходу для обеспечения reliability. В этом подходе каждая часть системы сама отвечает за свой вклад в обеспечение общесистемной availability за счет адаптации своего поведения к происходящим faults, например, распознавая сбои и используя, повторные запросы, автоматический перезапуск процессов, ограничивая распространение ошибки, правильно работая с latency запросов. В итоге, инженерам стоит знать и использовать такие механизмы обеспечения надежности, а не надеяться на технологии обеспечения high-availability из прошлого. Если использовать их правильно, то итоговая система будет более устойчива к ошибкам и сбоям и сможет более гибко приспособиться к проблемам во время эксплуатации систем.
Интересно еще рассмотреть эти подходы в контексте стандартных показателей
- Mean time between failures (MTBF) - среднее время наработки на отказ
- Mean time to recover (MTTR) - среднее время восстановления
В подходе с high-availability предполагалось, что время между сбоями у нас большое и когда сбой все-таки случается, то мы просто задействуем механизмы high-availability. И когда-то это было неплохим подходом. Но в текущих условиях у нас сбои частей систем могут происходить достаточно часто и тут на сцену выходит MTTR и умение этих частей системы ограничивать blast radius проблемы и не влиять на общую reliability всей системы.
#SRE #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #SystemDesign #SystemThinking