Отказоустойчивость Fault tolerance

• Отказоустойчивость Fault tolerance
  • Зачем
    • Факторы риска
  • Паттерны
    • Методы инфраструктуры, физической архитектуры
    • Методы разработки (программные)
  • Метрики

Зачем

Отказоустойчивость — это способность системы продолжать полноценно работать при выходе из строя отдельных компонентов — серверов или каналов связи, сбоев на уровне отдельных модулей системы и т.д.

• CAP теорема - концепции распределённости — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций:
  • согласованность (consistency)
  • доступность (availability)
  • устойчивость к разделению (англ. partition tolerance)
  • Вы хотите консистентность или доступность в случае инцидента?

Факторы риска

• Инфраструктурные
  • Сбой электропитания
  • Сбои Сервера, ОС
  • Выход из строя канала интернет
• Программные
  • Ошибки софта
  • Некорректная обработка ошибок
• Безопасность
  • Умышленное или случайное изменение данных в базе данных
  • Ddos атаки

Паттерны

Методы инфраструктуры, физической архитектуры

• исключение единой точки отказа — это либо решения с «горячей заменой»
• резервирование, дублирование, кластеры, либо горизонтальное масштабирование.
• Прокси
• файервол
• капча
• Балансировка
• api management
• Установка лимитов запросов rate limits, тайм-аут
• Dev ops ci/cd:
  • docker
  • kubernetes
  • jenkins
  • авто распределенный конфиг etcd
  • кеш redis
• системы мониторинга
  • аптайм доступность сервиса, выраженная в процентах
• ИБП, генератор электричества, охлаждение серверов
• DB:
  • репликации
  • кластер
  • Горизонтальное шардирование данных
• Распределенные файловые системы
• Бэкапы

Методы разработки (программные)

Design for failure

• Идемпотентность, Retry Policy, Fail Fast, Rate Limit, Circuit Breakers
• распределенная архитектура
  • Микросервисы: слабая связность, изоляция сбоев
  • stateless
• модульный монолит
• Health check
• CQRS
• Асинхронная обработка
  • Брокер очереди Message Bus
    • RMQ
  • воркеры
  • буферы входного потока данных
• Git, rollback
• миграции бд
• graceful shutdown
• Deadlines — здесь на стороне клиента определяется время ожидания, а дальше общее время ожидания учитывается по всей цепочке вызовов
  • Более простой подход с отдельными timeouts при вызовах между сервисами в цепочке работает сильно хуже (например, таймауты могут быть не синхронизированы или из-за retries мы можем получить смещенную картину)

Метрики

TODO