Продолжаю рассказывать про инфраструктуру и сегодня у нас HealthChecks.
Данный паттерн необходим для повышения надежности сервисов. А чтобы он работал на нас, а не против, нужно его правильно настроить :)
HealthChecks дословно переводится как "проверка жизни", это специальный набор API, которые выставляются сервисом чтобы извне периодически проверять его на готовность, работоспособность и т.п.
Эти API простые, обычно реализуются в виде HTTP endpoints:
/ready
/healthy
/startup
Каждый эндпойнт реализует свою логику, по которой он что-то проверяет и возвращает 200 (healthy) или 503 (unhealthy).
Но могут быть и TCP/gRPC и другие способы проверки.
Если вы деплоите сервис в k8s, то в деплойменте Вы можете настроить как проверять ваше приложение.
Например,
/ready будет readiness probe (чтобы знать можно ли направлять трафик в сервис)
/healthy будет liveness probe (чтобы знать пора ли перезапустить)
/startup будет startup probe (чтобы знать, запустился ли сервис)
Так вот, если Вы ранее не были знакомы с паттерном HealthChecks, то почитав статьи из интернета вроде этой, может сложиться впечатление, что нужно настроить проверку всего и вся: базы данных, других сервисов и будет все отлично.
На самом деле, важно разделять сценарии проверок и четко понимать зачем и когда проверять ту или иную зависимость.
Напомню, что /healthy проверяет работоспособность сервиса. Если в какой-то момент он начнет возвращать 503 (или вообще не отвечать), то k8s решит что сервис нужно перезапустить.
Поэтому если на /healthy ваш сервис проверяет еще доступность других сервисов или базы данных, то при их недоступности, ваш сервис тоже станет считаться недоступным и будет перезапускаться.
А если проверка других сервисов осуществляется аналогично через их /healthy, то может произойти зацикливание.
Отсюда вывод такой:
/ready /healthy должны всегда проверять работоспособность только самого сервиса, иначе это может повлечь за собой каскадный отказ ваших сервисов.
Помимо этого у Вас может быть сложная инфраструктура и сетевые доступы к другим сервисам или базам данных могут выдаваться через согласования ИБ.
В таком случае иметь специальный API или любой другой инструмент, который сможет сказать что все доступы имеются - будет максимально полезно.
Для этого мы можем завести новый эндпойнт, например
/check-deps-availability, который всё проверит и вернет информацию о доступности всех зависимостей сервиса.
Такой API можно вызывать самим при необходимости или автоматизированно для мониторинга, собирая по пути метрики доступности внешних сервисов, скорости их ответа и т.п.
Но следует помнить, что это дополнительный трафик, который может быть нежелательным, поэтому не стоит проверять слишком часто.
Помимо этого, проверку зависимостей сервиса может быть полезно делать еще до старта самого приложения.
Например, при выкладке новой версии, у сервиса появилась новая зависимость - база данных.
Допустим Вы забыли запросить сетевые доступы или где-то опечатались в строке подключения, оказался не тот пароль, хост, порт и т.п.
В таком случае, если не делать startup probe, то все поды быстренько обновятся до новой версии и когда трафик будет переключен на них, начнутся ошибки и соответственно будет инцидент.
В свою очередь наличие startup probe просто не позволит раскатить новую версию если бд недоступна и старая версия подов продолжит обрабатывать запросы, пока всё не будет починено и задеплоено заново.
Если в startup добавить проверку доступности внешних систем, то при недоступности хоть одного из них мы не сможем выкатить новую версию, с этим нужно быть аккуратным :)
Данный паттерн необходим для повышения надежности сервисов. А чтобы он работал на нас, а не против, нужно его правильно настроить :)
HealthChecks дословно переводится как "проверка жизни", это специальный набор API, которые выставляются сервисом чтобы извне периодически проверять его на готовность, работоспособность и т.п.
Эти API простые, обычно реализуются в виде HTTP endpoints:
/ready
/healthy
/startup
Каждый эндпойнт реализует свою логику, по которой он что-то проверяет и возвращает 200 (healthy) или 503 (unhealthy).
Но могут быть и TCP/gRPC и другие способы проверки.
Если вы деплоите сервис в k8s, то в деплойменте Вы можете настроить как проверять ваше приложение.
Например,
/ready будет readiness probe (чтобы знать можно ли направлять трафик в сервис)
/healthy будет liveness probe (чтобы знать пора ли перезапустить)
/startup будет startup probe (чтобы знать, запустился ли сервис)
Так вот, если Вы ранее не были знакомы с паттерном HealthChecks, то почитав статьи из интернета вроде этой, может сложиться впечатление, что нужно настроить проверку всего и вся: базы данных, других сервисов и будет все отлично.
На самом деле, важно разделять сценарии проверок и четко понимать зачем и когда проверять ту или иную зависимость.
Напомню, что /healthy проверяет работоспособность сервиса. Если в какой-то момент он начнет возвращать 503 (или вообще не отвечать), то k8s решит что сервис нужно перезапустить.
Поэтому если на /healthy ваш сервис проверяет еще доступность других сервисов или базы данных, то при их недоступности, ваш сервис тоже станет считаться недоступным и будет перезапускаться.
А если проверка других сервисов осуществляется аналогично через их /healthy, то может произойти зацикливание.
Отсюда вывод такой:
/ready /healthy должны всегда проверять работоспособность только самого сервиса, иначе это может повлечь за собой каскадный отказ ваших сервисов.
Помимо этого у Вас может быть сложная инфраструктура и сетевые доступы к другим сервисам или базам данных могут выдаваться через согласования ИБ.
В таком случае иметь специальный API или любой другой инструмент, который сможет сказать что все доступы имеются - будет максимально полезно.
Для этого мы можем завести новый эндпойнт, например
/check-deps-availability, который всё проверит и вернет информацию о доступности всех зависимостей сервиса.
Такой API можно вызывать самим при необходимости или автоматизированно для мониторинга, собирая по пути метрики доступности внешних сервисов, скорости их ответа и т.п.
Но следует помнить, что это дополнительный трафик, который может быть нежелательным, поэтому не стоит проверять слишком часто.
Помимо этого, проверку зависимостей сервиса может быть полезно делать еще до старта самого приложения.
Например, при выкладке новой версии, у сервиса появилась новая зависимость - база данных.
Допустим Вы забыли запросить сетевые доступы или где-то опечатались в строке подключения, оказался не тот пароль, хост, порт и т.п.
В таком случае, если не делать startup probe, то все поды быстренько обновятся до новой версии и когда трафик будет переключен на них, начнутся ошибки и соответственно будет инцидент.
В свою очередь наличие startup probe просто не позволит раскатить новую версию если бд недоступна и старая версия подов продолжит обрабатывать запросы, пока всё не будет починено и задеплоено заново.
Если в startup добавить проверку доступности внешних систем, то при недоступности хоть одного из них мы не сможем выкатить новую версию, с этим нужно быть аккуратным :)