[Анализ и проектирование систем, Микросервисы] Повышение устойчивости микросервисов к отказам
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Как уже известно, около 70 % отказов в приложениях происходят из-за изменений: развёртывания нового кода, применённых миграции в базе данных, изменения конфигурационных файлов и т.д. Остальные 30 % сбоев происходят в ходе работы приложения без прямого вмешательства разработчиков и системных администраторов: из-за проблем с сетью или дисками, возросшей нагрузки от пользователей, аварии в дата-центре. На первую группу мы можем повлиять с помощью управления изменениями и стратегии проведения этих изменений, а как повысить устойчивость к проблемам из второй группы, мы поговорим в этой статье.HealthchecksЭкземпляры сервисов непрерывно запускаются, перезапускаются и останавливаются из-за отказов, развёртывания или автомасштабирования, что приводит к временной или постоянной недоступности экземпляров. Чтобы избежать проблем с обработкой запросов, балансировщик нагрузки должен исключать из маршрутизации нерабочие экземпляры сервисов.
Экземпляр сервиса может сам отправлять информацию о своём состоянии с определённой периодичностью, либо предоставлять API для проверки внешним сервисом. Современные средства обнаружения непрерывно собирают данные о состоянии экземпляров и динамически перенастраивают балансировщики для направления трафика на здоровые сервисы.Self-healingМеханизм самовосстановления может восстановить работу приложения без сторонней помощи. В большинстве случаев это реализуют с помощью сторонней службы, которая наблюдает за экземплярами, собирает данные о состоянии и перезапускает в случае, если какой-то экземпляр слишком долго находится в сломанном состоянии. Например, supervisord или systemd.В большинстве случаев такая реализация будет очень полезной, но может привести к непрерывному перезапуску приложения, когда из-за перегрузки или таймаута базы данных приложение не может ответить наблюдающей службе, что оно работает. В таком случае потребуется реализовать дополнительную логику обработки подобных пограничных ситуаций, чтобы служба наблюдения узнавала о состоянии приложения и не перезапускала его.
Failover cachingАварийное кеширование позволит сервисам продолжать работу в случае временной недоступности. Такой кеш имеет два времени жизни: более короткое для обычного кеширования и более долгое — для аварийного. В нормальном режиме работы, когда основной кеш истёк, запрос будет обработан сервисом. В случае недоступности сервиса данные берутся из аварийного кеша. А если аварийный кеш истёк, то фиксируется отказ.Однако этот механизм можно использовать только в том случае, когда возвращать устаревшие данные лучше, чем не возвращать ничего.
RetryВ тех случаях, когда невозможно использовать кеширование, либо когда данные необходимо изменить, подходящим вариантом может быть повтор запроса. За время ожидания перед повторным запросом сервис может перезапуститься, или балансировщик может переключить маршруты на работающие экземпляры. При реализации логики повторного запроса следует учесть некоторые моменты:
- Большое количество повторных вызовов может усугубить аварийную ситуацию или блокировать восстановление работы сервиса.
- В системах микросервисов повторные вызовы могут каскадом порождать новые запросы.
- Если вызывающая сторона не знает, была ли выполнена операция прежде, чем запрос завершился с ошибкой, то повторный запрос может привести к множественному выполнению операции.
Чтобы минимизировать или избежать негативных последствий повторного вызова, следует жёстко ограничить количество попыток повтора и увеличивать время ожидания перед следующей попыткой, например, по алгоритму экспоненциальной выдержки. Также вызываемый сервис должен уметь обрабатывать запросы идемпотентно.
Мы используем повторные вызовы в случае сетевых ошибок: таймаут TCP-соединения и разрешения имени в DNS. При этом используем не только для HTTP-запросов, но и для критичных запросов к базе данных.
Rate limitingОграничение частоты запросов помогает предотвратить перегрузки сервиса и его отказ, пока сервис не будет масштабирован под нагрузку. Если клиенты сервиса могут без проблем для себя уменьшить частоту запросов, то можно использовать этот приём. Если же это невозможно, например, в случае событий реального времени, то придётся искать другой способ.Есть две стратегии реализации ограничения:
- по количеству запросов в минуту;
- по количеству одновременно выполняющихся запросов.
Ограничение по числу запросов в единицу времени.Ограничение по числу запросов в единицу времени.Первый вариант защищает сервис от флуда, вызванного ошибкой в скрипте, внешними ботами или настойчивыми пользователями. Второй вариант позволяет держать под контролем нагрузку на ресурсоёмкие методы API и не позволять потреблять все ресурсы сервиса одним пользователем.
Ограничение можно настроить не только по IP-адресу. У себя мы используем лимитер с настраиваемым ключом для защиты от дублирования заявок с сайтов. Он проверяет не только адрес, но и значения некоторых полей форм, а также имеет гибкую настройку количества запросов по минутам, часам и дням.
Load sheddingЛимитеры частоты запросов принимают решение в зависимости от того, какой конкретно клиент выполняет запрос. Это хорошо подходит для обычного режима работы, но в случае инцидента может быть необходимо сбросить часть неприоритетных запросов, чтобы критически важные продолжили выполняться. Такой механизм должен работать на основе информации о состоянии всей системы, а не участия отдельных клиентов. Возможны два варианта:
- выделенный запас мощности;
- анализ потребления.
В первом варианте мы выделяем долю общей пропускной способности сервиса под критический трафик. Например, сервис способен обрабатывать 50 тысяч запросов в секунду, устанавливаем резерв в 20 % (10 тыс.). В таком случае остальной трафик не должен превышать 80 % (40 тыс.). Шеддер отклонит все некритичные запросы сверх этого потока. Жёсткий лимит позволит гарантировать, что весь критический трафик всегда будет обработан.
Во втором варианте мы анализируем загруженность сервиса, и в случае замедления его работы начинаем плавно подрезать наименее критичные запросы. Если ситуация пришла в норму, то начинаем плавно возвращать трафик. Если не помогло, то продолжаем урезать трафик с приоритетом выше, вплоть до того, что остаются только критически важные запросы. Такой подход позволяет ограничить влияние уже происходящего инцидента и контролировать ущерб. 
BulkheadsЭтот паттерн получил название от корабельных переборок. Они делят внутреннее пространство корабля на отсеки, позволяя изолировать пробоину в корпусе. При этом затапливается только один или несколько отсеков, остальные остаются сухими и поддерживают корабль на плаву. В контексте программного обеспечения паттерн предполагает разделение ресурсов сервиса на несколько независимых блоков, например, создание двух пулов подключений к базе данных: один для критических задач, второй для остальных. Таким образом один полностью занятый пул не приведёт к полному отказу в обслуживании клиентов и сервис сохранит ограниченную работоспособность.
Circuit breakerЧтобы ограничить время выполнения операции или запроса, мы можем использовать таймауты. Они позволяют предотвратить зависание операций, однако подобрать подходящие значения времени в сложных, динамических, распределенных системах почти невозможно. Поэтому вместо того, чтобы полагаться на таймауты, следует использовать паттерн предохранитель.Предохранитель защищает ресурсы сервиса (соединения, дескрипторы), не позволяя их использовать в случае отказа вызываемого сервиса. Вместе с тем, вызываемый сервис быстрее восстановится после отказа, так как на него не поступают запросы от других сервисов.Предохранитель открывается, когда зафиксирует некоторое количество ошибок за короткий промежуток времени. Все последующие запросы через него будут возвращать ошибку сразу, без отправки во внешний сервис. Предохранитель сохраняет такое состояние в течение заданного промежутка времени, после чего закрывается и снова пропускает все запросы во внешний сервис.
Возможен вариант с полуоткрытым режимом. В этом случае спустя некоторое время после открытия предохранитель пропустит один запрос для проверки сервиса. Если запрос отработал, то предохранитель закрывается, если же завершился с ошибкой — возвращается в открытое состояние.
С настройкой параметров предохранителя следует быть аккуратным, иначе он может оказаться слишком чувствительным и будет срабатывать даже при кратковременных проблемах с сетью. В итоге открытый предохранитель может отклонить с ошибкой больше запросов, чем было бы без него.
===========
Источник:
habr.com
===========
Похожие новости:
- [Микросервисы] Как мы переписывали сервер-сайд СберБанк Онлайн на микросервисы
- [PHP, Анализ и проектирование систем, SQL] Идеальный каталог, базовая библиотека
- [Анализ и проектирование систем] Погрузиться в поиск музыкальной информации [MIR] — книги, которые помогут сделать это
- [Анализ и проектирование систем, IT-инфраструктура, Управление проектами, Веб-аналитика, Бизнес-модели] 6 функций, которые нужны интернет-аптеке
- [Анализ и проектирование систем, Работа с 3D-графикой, CAD/CAM, Софт] Российские BIM-технологии: проектирование наружных инженерных сетей в Model Studio CS
- [Анализ и проектирование систем, Графические оболочки, CAD/CAM] Анализ внешнего потока в SOLIDWORKS Flow Simulation
- [Анализ и проектирование систем, Управление разработкой, Управление проектами, Карьера в IT-индустрии] Bus-фактор в работе аналитика. Как экстренно погрузиться в проект и не перегореть от объема задач
- [Системное администрирование, Серверное администрирование, DevOps, Микросервисы] АМА-сессия Слёрма по service mesh. Часть 2
- [Анализ и проектирование систем] Как описать архитектуру продукта по нотации C4 (перевод)
- [Программирование, Анализ и проектирование систем, Совершенный код, Проектирование и рефакторинг, ООП] Метрика Cognitive complexity или простой способ измерить сложность кода
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_mikroservisy (Микросервисы), #_arhitektura_prilozhenij (архитектура приложений), #_mikroservisy (микросервисы), #_backend, #_sitimobil (ситимобил), #_blog_kompanii_sitimobil (
Блог компании Ситимобил
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:49
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Как уже известно, около 70 % отказов в приложениях происходят из-за изменений: развёртывания нового кода, применённых миграции в базе данных, изменения конфигурационных файлов и т.д. Остальные 30 % сбоев происходят в ходе работы приложения без прямого вмешательства разработчиков и системных администраторов: из-за проблем с сетью или дисками, возросшей нагрузки от пользователей, аварии в дата-центре. На первую группу мы можем повлиять с помощью управления изменениями и стратегии проведения этих изменений, а как повысить устойчивость к проблемам из второй группы, мы поговорим в этой статье.HealthchecksЭкземпляры сервисов непрерывно запускаются, перезапускаются и останавливаются из-за отказов, развёртывания или автомасштабирования, что приводит к временной или постоянной недоступности экземпляров. Чтобы избежать проблем с обработкой запросов, балансировщик нагрузки должен исключать из маршрутизации нерабочие экземпляры сервисов.  Экземпляр сервиса может сам отправлять информацию о своём состоянии с определённой периодичностью, либо предоставлять API для проверки внешним сервисом. Современные средства обнаружения непрерывно собирают данные о состоянии экземпляров и динамически перенастраивают балансировщики для направления трафика на здоровые сервисы.Self-healingМеханизм самовосстановления может восстановить работу приложения без сторонней помощи. В большинстве случаев это реализуют с помощью сторонней службы, которая наблюдает за экземплярами, собирает данные о состоянии и перезапускает в случае, если какой-то экземпляр слишком долго находится в сломанном состоянии. Например, supervisord или systemd.В большинстве случаев такая реализация будет очень полезной, но может привести к непрерывному перезапуску приложения, когда из-за перегрузки или таймаута базы данных приложение не может ответить наблюдающей службе, что оно работает. В таком случае потребуется реализовать дополнительную логику обработки подобных пограничных ситуаций, чтобы служба наблюдения узнавала о состоянии приложения и не перезапускала его.  Failover cachingАварийное кеширование позволит сервисам продолжать работу в случае временной недоступности. Такой кеш имеет два времени жизни: более короткое для обычного кеширования и более долгое — для аварийного. В нормальном режиме работы, когда основной кеш истёк, запрос будет обработан сервисом. В случае недоступности сервиса данные берутся из аварийного кеша. А если аварийный кеш истёк, то фиксируется отказ.Однако этот механизм можно использовать только в том случае, когда возвращать устаревшие данные лучше, чем не возвращать ничего.  RetryВ тех случаях, когда невозможно использовать кеширование, либо когда данные необходимо изменить, подходящим вариантом может быть повтор запроса. За время ожидания перед повторным запросом сервис может перезапуститься, или балансировщик может переключить маршруты на работающие экземпляры. При реализации логики повторного запроса следует учесть некоторые моменты:
 Чтобы минимизировать или избежать негативных последствий повторного вызова, следует жёстко ограничить количество попыток повтора и увеличивать время ожидания перед следующей попыткой, например, по алгоритму экспоненциальной выдержки. Также вызываемый сервис должен уметь обрабатывать запросы идемпотентно. Мы используем повторные вызовы в случае сетевых ошибок: таймаут TCP-соединения и разрешения имени в DNS. При этом используем не только для HTTP-запросов, но и для критичных запросов к базе данных.
 Ограничение по числу запросов в единицу времени.Ограничение по числу запросов в единицу времени.Первый вариант защищает сервис от флуда, вызванного ошибкой в скрипте, внешними ботами или настойчивыми пользователями. Второй вариант позволяет держать под контролем нагрузку на ресурсоёмкие методы API и не позволять потреблять все ресурсы сервиса одним пользователем. Ограничение можно настроить не только по IP-адресу. У себя мы используем лимитер с настраиваемым ключом для защиты от дублирования заявок с сайтов. Он проверяет не только адрес, но и значения некоторых полей форм, а также имеет гибкую настройку количества запросов по минутам, часам и дням.
 Во втором варианте мы анализируем загруженность сервиса, и в случае замедления его работы начинаем плавно подрезать наименее критичные запросы. Если ситуация пришла в норму, то начинаем плавно возвращать трафик. Если не помогло, то продолжаем урезать трафик с приоритетом выше, вплоть до того, что остаются только критически важные запросы. Такой подход позволяет ограничить влияние уже происходящего инцидента и контролировать ущерб.  BulkheadsЭтот паттерн получил название от корабельных переборок. Они делят внутреннее пространство корабля на отсеки, позволяя изолировать пробоину в корпусе. При этом затапливается только один или несколько отсеков, остальные остаются сухими и поддерживают корабль на плаву. В контексте программного обеспечения паттерн предполагает разделение ресурсов сервиса на несколько независимых блоков, например, создание двух пулов подключений к базе данных: один для критических задач, второй для остальных. Таким образом один полностью занятый пул не приведёт к полному отказу в обслуживании клиентов и сервис сохранит ограниченную работоспособность.  Circuit breakerЧтобы ограничить время выполнения операции или запроса, мы можем использовать таймауты. Они позволяют предотвратить зависание операций, однако подобрать подходящие значения времени в сложных, динамических, распределенных системах почти невозможно. Поэтому вместо того, чтобы полагаться на таймауты, следует использовать паттерн предохранитель.Предохранитель защищает ресурсы сервиса (соединения, дескрипторы), не позволяя их использовать в случае отказа вызываемого сервиса. Вместе с тем, вызываемый сервис быстрее восстановится после отказа, так как на него не поступают запросы от других сервисов.Предохранитель открывается, когда зафиксирует некоторое количество ошибок за короткий промежуток времени. Все последующие запросы через него будут возвращать ошибку сразу, без отправки во внешний сервис. Предохранитель сохраняет такое состояние в течение заданного промежутка времени, после чего закрывается и снова пропускает все запросы во внешний сервис.  Возможен вариант с полуоткрытым режимом. В этом случае спустя некоторое время после открытия предохранитель пропустит один запрос для проверки сервиса. Если запрос отработал, то предохранитель закрывается, если же завершился с ошибкой — возвращается в открытое состояние. 
С настройкой параметров предохранителя следует быть аккуратным, иначе он может оказаться слишком чувствительным и будет срабатывать даже при кратковременных проблемах с сетью. В итоге открытый предохранитель может отклонить с ошибкой больше запросов, чем было бы без него.
=========== Источник: habr.com =========== Похожие новости:
Блог компании Ситимобил ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:49
Часовой пояс: UTC + 5