Availability

Телеграмм не подключается❗Висит загрузка. Волнительно. Неприятно. Снижается удовлетворенность пользователей от использования сервиса.

Реклама не показывается. Трафик падает. Акционеры в панике скидывают акции 📉. Совет директоров вызывает главного архитектора.
СВ: "Что происходит, дорогой?"
А: "Доброе утро. Зачем меня разбудили так рано?"
СВ: "Посмотри новости."
А: "А, так это плановые ночные работы на нашем единственном сервере с небольшим downtime."
СВ: "😳"
СВ: "Это не допустимо!"
А: "Почему?"
СВ: "Мы теряем деньги. Нам нужна доступность 24/7 !"
А: "Такого требования при проектирование системы не было 🤷"
Архитектор медленно наливает горячий шоколад, разворачивается и идёт в своей пижаме в сторону лифта.

В современном мире всё должно быть доступно:
1) Сотрудник в течение рабочего дня для решения вопросов;
2) Чайник для заваривания крепкого бодрящего чая когда захотелось его попить;
3) Сервис доставки еды для вкусного обеда;
Я хочу зайти в телеграмм нажатием по значку в телефоне или кликом мышки на ПК и через 0.5 секунды увидеть состояние диалогов и чатов.

С точки зрения разработки архитектуры Availability / Доступность значит многое:
1) Система продолжает функционировать даже при падение критического компонента;
2) Система обрабатывает ошибки компонентов без нарушения обработки запросов;
3) У критически важных компонентов должны быть реплики-дублирующие компоненты;
4) Существует мониторинг, который помогает быстро обнаруживать проблемы;
5) Есть возможность быстрого отката функционала;
6) Отсутствует единая точка отказа;
7) Система справляется с быстрорастущим трафиком;
8) Система переживает сбои сети, софт, железа;

2 популярных паттерна для реализации этого требования:
1) Replica - дублирующий компонент c разными вариантами записи, чтения типа master/slave
К примеру, реплицируем БД. Запрос от клиента приходит в master. Master скидывает в slave. Если режим записи синхронный, то ответим клиенту только после записи в slave.
2) Failover - дублирующий компонент готов к обработке текущего трафика.
a) Стратегия active-active. Оба обрабатывают текущий трафик.
b) Стратегия active-passive(standby). Failover мониторит состояние active инстанца. При его падение берёт трафик на себя.

Пример реализации этого паттерна в nginx.

В этом посте про "Доступность" сервиса мы разобрали:
1) Мотивацию использования этого нефункционального требования;
2) Его основные характеристики;
3) 2 паттерна для реализации требования в системе.

Удачи в построение отказоустойчивых систем!

#Requirements #Availability #Replica #Failover