Доступность High Availability

Для обеспечения Надежности ИС.

• Таблица сколько времени простоя разрешено для достижения заданного уровня доступности.
• Доступность Uptime ИС зависит от частоты и продолжительности простоев. Она измеряется через:
  • Частоту простоя, или обратную от нее: MTTF (mean time to failure, среднее время безотказной работы)
  • Продолжительность простоя, MTTR (mean time to repair, среднее время восстановления). Продолжительность простоя определяется временем пользователя: от начала неисправности до возобновления нормальной работы сервиса.
    • Observability напрямую связана с MTTR. Чем выше Observability сервиса, тем проще определить ошибку, исправить и автоматизировать, и тем ниже MTTR.
  • Доступность определяется как MTTF/(MTTF+MTTR)
• Доступность можно определять по-разному:
  • Сервер AWS считается недоступным только в случае, если за пять минут не дает никаких ответов на запросы, кроме 500 или 503. Эти коды ответов обозначают две ошибки: Internal Server Error и Service Unavailable. Все остальные ответы сервера не учитываются при расчёте надёжности.
    • в Amazon успешен только один запрос в 5 минут, по их мнению, это 100%-я доступность
    • иначе: у вас могут быть до 21 минуты полной деградации, и неограниченное число частичных деградаций.
    • Амазон не нарушит свои условия о 99,95% доступности. Или в крайнем случае - 8640 успешных запросов (по 1му раз в 5 минут) и неограниченное число неуспешных.

Метрики

• доступность сервиса (время простоя) (A) за конкретный период зависит от планового значения этого показателя (B) и суммарного времени простоев (C) A = (B - C)/ B * 100 %
• важно определить максимально возможное время простоя и его цену
• RTO (Recovery Time Objective, целевое время восстановления) – промежуток времени, в течение которого система может оставаться недоступной в случае аварии, т.е. время, необходимое для восстановления полного функционирования сервиса после наступления аварийного события.
• Процент времени, в течение которого ваш API работает и способен обрабатывать запросы (ping health check)
  • Nginx
    • Available Upstream
      • This indicates the number of upstream servers available to serve the requests in case NGINX is working as a reverse proxy.
      • Impact and remediation: This tells you whether your upstream servers are working or not. If these go down, your request serving capacity will likely decrease due to the loss of an upstream server.
      • Thresholds: Any decrease in the number of upstreams indicates that your upstream server is down.
    • Active Upstream Connections
      • Active upstream connections are the total active connections with the upstream servers in case of a reverse proxy.
      • Impact and remediation: A change here indicates that there is a high number of connections with an upstream server. This could mean that your connections are not getting served properly. You may also see an increase in response time due to the added latency. An increase in RPS also means that throughput has increased and your NGINX servers need to be scaled.
      • Thresholds: This will depend on your machines and the number of upstream servers. Look out for any sudden spikes.
    • Upstream Errors
      • This alerts you to errors coming from upstream servers if NGINX is working as a reverse proxy.
      • Impact and remediation: An increase in this value indicates that there are errors from upstream servers that may need to be dealt with.
      • Thresholds: This will depend on your application, as with server errors.
  • Traefik
    • Configure health check to remove unhealthy servers from the load balancing rotation. Traefik will consider your servers healthy as long as they return status codes between 2XX and 3XX to the health check requests (carried out every interval).
  • K8s
    • Kubernetes has an health check mechanism to remove unhealthy pods from Kubernetes services (cf readiness probe). As unhealthy pods have no Kubernetes endpoints.
  • Zabbix
  • PRTG
  • KUMA
    • интеграция с Traefik
• Circuit Breaker Trips: If you’re using the circuit breaker pattern to handle failures, you might track how often the circuit breaker is tripped. This can give you a sense of how often your API or its dependencies are failing.

Паттерны

• Ограничение ресурсов ИС throttling
• TODO
• отказоустойчивость и масштабирование MariaDB и RabbitMQ в основе лежит разделение баз и брокеров по сервисам.
• Избегайте состояния (stateless) в вашем приложении
• Балансировка
• Big data