Объясните механизм, благодаря которому активная проверка состояния экземпляров повышает отказоустойчивость сервиса.
Активная проверка состояния отправляет экземпляру специальные контрольные запросы до того, как пользовательский трафик столкнётся с отказом. Если экземпляр не проходит проверку, маршрутизатор или балансировщик временно исключает его из пула, поэтому новые запросы направляются к работоспособным экземплярам.
Это повышает отказоустойчивость только при корректном выборе проверяемого состояния. Слишком поверхностная проверка пропустит функциональный отказ, а слишком глубокая может создать лишнюю нагрузку или ошибочно вывести экземпляр из работы.
В распределённых системах отказ отдельного узла неизбежен: процесс может завершиться, зависнуть, потерять сетевую связность или исчерпать ресурс. Без автоматического обнаружения такой узел продолжает получать запросы, а отказ проявляется для каждого клиента, которому он достался.
Активные проверки появились как практический механизм отделения исправных экземпляров от неисправных без ожидания пользовательских ошибок. Они особенно важны за балансировщиками, в кластерах и при автоматическом масштабировании, где состав рабочих экземпляров постоянно меняется.
Сам факт, что процесс запущен и принимает сетевые соединения, ещё не означает, что он способен успешно обслуживать запросы. Он может потерять связь с базой данных, исчерпать пул соединений, зависнуть на блокировке или работать настолько медленно, что фактически непригоден для трафика.
Если система не обнаруживает это заранее, пользователи получают ошибки и задержки, а здоровые экземпляры могут перегружаться из-за повторных попыток и перераспределения трафика. Если же проверка слишком агрессивна, кратковременный сетевой сбой вызовет лишнее исключение экземпляра и уменьшит доступную ёмкость.
Проверяющий компонент периодически отправляет экземпляру контрольный запрос. По результату и, обычно, по тайм-ауту он классифицирует экземпляр как исправный или неисправный; после заданного числа последовательных неудач экземпляр исключается из маршрутизации.
После восстановления экземпляр не всегда возвращают в трафик немедленно. Часто используют отдельный этап допуска: несколько успешных проверок, постепенное увеличение доли трафика или подтверждение готовности приложения. Это снижает риск отправить большой поток на ещё нестабильный экземпляр.
Важно различать проверку работоспособности процесса и проверку готовности обслуживать трафик. Первая отвечает на вопрос, жив ли процесс, а вторая — может ли он сейчас корректно выполнить рабочий запрос. Для маршрутизации обычно важнее вторая проверка.
Проверка не должна без необходимости вызывать дорогие операции или зависеть от большого числа компонентов. Если включить в неё все зависимости, кратковременный отказ одной зависимости может одновременно вывести из пула множество экземпляров. Компромисс состоит в том, чтобы проверять критический путь обслуживания, но ограничивать глубину зависимостей и задавать разумные тайм-ауты.
Активные проверки не устраняют сам отказ и не гарантируют корректность бизнес-ответа. Они также создают дополнительный трафик, могут давать ложные срабатывания и требуют согласования интервалов проверки, тайм-аутов и порогов неудач с целевым временем обнаружения отказа.
У сервиса три экземпляра. Один из них потерял соединения с базой данных, но процесс продолжает принимать TCP-соединения. Балансировщик считает его доступным, поэтому примерно треть запросов получает ошибки.
Рассматривались три варианта. Полагаться только на пользовательские ошибки было просто, но задерживало реакцию и ухудшало клиентский опыт. Проверять только открытый сетевой порт было дёшево, но такая проверка не обнаруживала отказ базы данных. Проверять полноценный бизнес-запрос было информативно, но создавало лишнюю нагрузку и могло само усиливать проблему.
Выбрали отдельную проверку готовности, которая использовала ограниченную проверку критической зависимости, имела короткий тайм-аут и требовала нескольких последовательных неудач для исключения экземпляра. После восстановления экземпляр возвращался в пул только после серии успешных проверок.
В результате неисправный экземпляр перестал получать новый трафик до массового появления пользовательских ошибок. При этом кратковременный сбой связи не вызывал мгновенного исключения узла, а контрольная нагрузка оставалась предсказуемой.
Если каждый экземпляр регулярно выполняет тяжёлую проверку базы данных, при росте числа экземпляров увеличивается фоновая нагрузка на ту же зависимость. При проблемах базы проверки начинают тайм-аутиться, экземпляры исключаются из пула, а оставшиеся получают больше пользовательского трафика и создают ещё больше запросов к базе.
Поэтому проверку делают дешёвой, ограничивают частоту и число одновременных запусков. Иногда разделяют сигнал живости процесса и сигнал готовности, а состояние зависимости получают через контролируемый механизм, не создающий значительную дополнительную нагрузку.
Единичная ошибка может быть вызвана потерей пакета, кратким превышением задержки или временной конкуренцией за ресурс. Немедленное исключение снижает ёмкость пула и может вызвать колебания маршрутизации: экземпляры будут постоянно выходить из строя и возвращаться.
Последовательные пороги неудач и успешных проверок работают как фильтр кратковременного шума. Их выбирают по компромиссу между скоростью обнаружения настоящего отказа и риском ложного исключения; слишком большие пороги, напротив, задерживают реакцию.
Проверка обычно охватывает только небольшой заранее выбранный путь. Она может успешно завершаться, пока отдельная бизнес-операция сталкивается с повреждёнными данными, редким тайм-аутом, перегрузкой конкретного ресурса или ошибкой в определённом типе запроса.
Поэтому активные проверки дополняют, а не заменяют метрики ошибок, задержек, трассировку и пользовательские SLI. Проверка нужна для быстрого управления маршрутизацией, а наблюдаемость по реальному трафику — для выявления отказов, которые контрольный запрос не моделирует.