Разработка отказоустойчивого веб-сервиса: резервирование и восстановление

Для каждого сервиса, а лучше для каждой его части, записываются два показателя.

• Допустимая потеря данных (RPO): за какой период последние изменения можно потерять при аварии. Для ленты новостей это может быть час, для оплаченных заказов — ноль.
• Допустимое время восстановления (RTO): сколько сервис может быть недоступен до возвращения. Для внутреннего справочника это рабочий день, для сервиса приёма платежей — минуты.

Эти показатели определяют схему. Нулевая потеря данных требует синхронной записи на вторую копию, что замедляет операции и усложняет эксплуатацию. Время восстановления в минуты требует автоматического переключения и людей, которые знают, как оно работает. Каждый шаг вниз по обоим показателям стоит заметно дороже предыдущего, поэтому на обследовании мы просим назвать не «как можно меньше», а цену простоя: сколько заказов и платежей не пройдёт за час.

Условный пример: в сервисе записи клиентов заявку терять нельзя, личный кабинет можно показывать с задержкой, а отчёты руководителю подождут до утра. Три части получают три схемы, и итог дешевле защиты всего на уровне самой дорогой.

Цель по доступности в процентах («три девятки») — следствие этих решений, а не их замена. Как читать такую цель и что считать простоем, описано в статье о доступности «три девятки».

Репликация: что именно копируется и когда

Реплика получает изменения с главной базы. При асинхронной репликации главная база подтверждает запись, не дожидаясь реплики, и при аварии последние изменения могут пропасть. При синхронной подтверждение приходит после записи на реплику: потери нет, но запись медленнее, а при недоступной реплике может остановиться совсем. Выбор делается отдельно для каждой базы и записывается как решение.

Переключение: кто решает, что главный упал

Опасный случай — когда оба узла считают себя главными и принимают записи: данные расходятся, и сводить их приходится вручную. Поэтому автоматическое переключение строится на внешнем арбитре (узлы голосуют), а не на правиле «не отвечает, значит, упал». Для PostgreSQL есть зрелые инструменты вроде Patroni; нужны ли они вам или хватит ручного переключения, решает размер системы и умение команды её сопровождать.

Репликация не заменяет копии

Если из базы удалили таблицу или запустили неверное обновление, это мгновенно попадёт на реплику. Защищают от этого копии с журналом изменений, из которых можно вернуться на нужный момент времени. Поэтому горячая реплика и резервная копия — два разных механизма, и нужны оба.

Восстановление проверяется, иначе его нет

Копию разворачивают на чистом сервере по инструкции, запускают на ней приложение, сверяют число и суммы заказов с боевой системой и записывают время. Если оно больше допустимого, ускоряем восстановление или пересматриваем цель. Сам файл копии ничего не доказывает.

• Изменения структуры данных идут в два шага. Сначала добавляем новое так, чтобы старая версия приложения продолжала работать, потом переключаем код, и только после этого удаляем старое. Тогда откат кода возможен в любой момент.
• Выкладка по частям. Новая версия сначала получает один узел или малую долю запросов; если ошибок становится больше, выкладка останавливается.
• Откат отработан заранее. Предыдущая версия хранится собранной, порядок возврата проверен. Откат, который делают в первый раз во время аварии, обычно не получается.

Остановку выкладки по ошибкам дают метрики, поэтому отказоустойчивость и мониторинг веб-сервисов строятся вместе.

Отказоустойчивость отвечает на вопрос «что будет, если что-то сломается». Высокая нагрузка отвечает на другой: «что будет, если придёт много пользователей». Решения частично общие, например несколько копий приложения, но цели разные: от нагрузки спасают кэш, очереди и отключение функций на пике, и они разобраны на странице высоконагруженного B2C-сервиса.

Сигналы о сбое, панели и правила оповещений описаны на странице о мониторинге веб-сервисов; а принять уже работающую систему на постоянное обслуживание — услуга сопровождения. Про разбиение на сервисы — микросервисная архитектура: распределённая система ломается чаще, и отказоустойчивости там нужно больше, а не меньше.

Порядок шагов по возрастанию цены собран в статье «Как сделать веб-сервис отказоустойчивым по шагам».