Оставайтесь в сети при сбое региона: высокодоступный Redis для приложений на Python

Active-Active Redis и клиентский географический отказоустойчивый переход

Active-Active Redis распределяет данные по нескольким регионам, позволяя каждому региональному экземпляру базы данных обслуживать как операции чтения, так и записи. Какая магия позволяет это делать? Redis использует типы данных с бескомфликтной репликацией (CRDT) для разрешения параллельных обновлений и обеспечения того, чтобы экземпляры в конечном итоге сходились к согласованному состоянию.

Стандартный клиент redis-py подключается к одной настроенной конечной точке. Чтобы иметь возможность быстро переключаться между экземплярами в случае сбоя, приложение может создать отдельные клиенты для нескольких региональных экземпляров базы данных, но тогда оно должно реализовать (и поддерживать!) мониторинг работоспособности, выбор конечной точки, отработку отказа и возврат к исходному состоянию. Бессчетное количество приложений по всему миру, реализующих ту же логику — некоторые с большим успехом, чем другие, — с инженерной точки зрения не имеет особого смысла, поэтому мы решили предложить единую «каноническую» реализацию, которая предоставляет клиентский API, управляющий этими обязанностями, тем самым обеспечивая клиентский географический отказоустойчивый переход.

Этот API предоставляется через MultiDBClient — обертку над обычными экземплярами единого клиента и клиента кластера. MultiDBClient маршрутизирует трафик к одной выбранной конечной точке (активной базе данных), одновременно отслеживая работоспособность всех настроенных конечных точек. Если активная база данных считается неработоспособной, клиент выбирает другую работоспособную конечную точку в соответствии с настроенными весами и перенаправляет на нее трафик. Когда включен автоматический возврат к исходному состоянию, клиент периодически оценивает недоступные конечные точки и может вернуться к работоспособной конечной точке с наибольшим весом. MultiDBClient не транслирует команды и не реплицирует данные между конечными точками. Репликация данных остается обязанностью уровня базы данных Active-Active, позволяя CRDT проявить себя во всей красе.

Внутри MultiDBClient

Каждый DatabaseConfig определяет одну конечную точку и ее вес. Создайте по одному объекту для каждого регионального экземпляра базы данных. MultiDbConfig собирает эти конфигурации конечных точек и определяет поведение, применяемое ко всей настройке MultiDBClient, включая проверки работоспособности, повторные попытки, отработку отказа и возврат к исходному состоянию. Как мы увидим позже, здесь имеется множество параметров для различных сценариев и настроек.

MultiDBClient делегирует обмен данными с конечными точками и управление подключениями лежащему в основе клиенту Redis или RedisCluster. Вы можете выбрать один или другой вариант глобально с помощью MultiDbConfig.client_class: используйте Redis для стандартных конечных точек и RedisCluster для конечных точек, поддерживающих OSS Cluster API. Передавайте параметры клиента для конкретной конечной точки через DatabaseConfig.client_kwargs.

От обнаружения сбоя до восстановления

MultiDBClient использует шаблон «автоматический выключатель» (circuit breaker) для управления трафиком к каждой конечной точке. Когда активная конечная точка считается неработоспособной, ее цепь размыкается, и клиент переключается на работоспособную конечную точку с наибольшим весом. Эта концепция заимствована из электрических цепей, где элементы защиты предохраняют электрическую цепь от повреждений, вызванных нагрузкой, превышающей возможности оборудования.

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

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

Сбои команд, подлежащих повторной попытке, обрабатываются глобальной политикой повторных попыток. Перед каждой повторной попыткой MultiDBClient проверяет текущую активную конечную точку, позволяя повторить попытку выполнения команды для вновь выбранной базы данных.

Автоматический возврат к исходному состоянию периодически проверяет, восстановилась ли конечная точка с более высоким весом. Как только конечная точка становится работоспособной, MultiDBClient может снова переключить на нее трафик. Веса можно настроить так, чтобы отдавать приоритет конечной точке, находящейся ближе всего к приложению.

Эта система позволит вам всегда предпочитать конечные точки, находящиеся ближе к приложению, будучи при этом готовыми к сбоям.

Для большего контроля вы можете отключить автоматический возврат к исходному состоянию, установив auto_fallback_interval в значение -1, и явно выбирать работоспособную конечную точку в динамическом режиме с помощью set_active_database().

Настройка высокодоступного клиента Python

Политики проверки работоспособности

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

• HEALTHY_ALL — строгая: конечная точка считается работоспособной только тогда, когда успешны все зонды. Используйте этот вариант, когда продолжение отправки трафика на нестабильную конечную точку более рискованно, чем редкий ненужный переход на резервный ресурс. Его недостаток — низкая устойчивость к кратковременным сетевым ошибкам и большее время оценки.
• HEALTHY_ANY — мягкая: конечная точка остается работоспособной, если успешен хотя бы один зонд, а зондирование прекращается после первого успешного результата. Используйте этот вариант, когда ожидаются кратковременные сбои соединения или переключение на резерв обходится дорого. Это минимизирует ложноположительные переключения, но может удерживать трафик на деградированной конечной точке и требует выполнения всех настроенных зондов для подтверждения полного сбоя.
• HEALTHY_MAJORITY — сбалансированная: более половины зондов должны завершиться успешно. Она допускает периодические сбои и при этом реагирует на постоянные проблемы. Это лучшая отправная точка для большинства производственных развертываний.

Кратко: выбирайте HEALTHY_ALL для приоритета качества конечной точки, HEALTHY_ANY для приоритета стабильности и предотвращения лишних переключений, либо HEALTHY_MAJORITY, когда вам нужен баланс между тем и другим.

Например, следующая конфигурация запускает пять зондов и считает конечную точку работоспособной, если успешны по крайней мере три из них:

Как настройки влияют на производительность

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

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

Окно обнаружения сбоев: короткое окно позволяет быстро реагировать и быстрее забывать старые сбои, что подходит для высокого трафика. Приложениям с низким трафиком требуется более длинное окно; в противном случае они могут никогда не собрать достаточное количество выборок для достижения min_num_failures.

Попытки отработки отказа: failover_attempts × failover_delay определяет примерное окно восстановления, когда каждая конечная точка временно недоступна. API, чувствительный к задержкам, должен делать это окно коротким и возвращать управление приложению. Фоновый воркер может подождать дольше, пока конечная точка восстановится.

Сценарий с высокой пропускной способностью

Этот пресет отдаем приоритет пропускной способности и быстрому обнаружению сбоев:

• Короткие тайм-ауты предотвращают слишком долгое занятие соединений запросами.
• Одна попытка повтора ограничивает усиление трафика во время сбоя.
• Джиттер предотвращает одновременный повтор попыток всеми экземплярами приложения.
• Короткое окно обнаружения сбоев быстро реагирует на концентрированные сбои.
• Более длительный интервал проверки работоспособности ограничивает фоновый трафик.

Наблюдаемость и интеграция с приложениями

MultiDBClient предоставляет уведомления во время выполнения всякий раз, когда аварийное переключение или возврат меняют активную базу данных. Приложения могут использовать пользовательские прослушиватели событий для записи перехода, обновления метрик, запуска оповещений или синхронизации внешнего состояния. Эти прослушиватели регистрируются через EventDispatcher, передаваемый в MultiDbConfig.

Когда включена наблюдаемость redis-py, MultiDBClient записывает счетчик redis.client.geofailover.failovers. Он включает следующие атрибуты:

• db.client.geofailover.fail_from
• db.client.geofailover.fail_to
• db.client.geofailover.reason, например автоматический или ручной

Демонстрация регионального аварийного переключения

Чтобы увидеть, как MultiDBClient обрабатывает региональное аварийное переключение и возврат от начала до конца, изучите пример географического аварийного переключения redis-py.

Заключение

Active-Active Redis заботится о синхронизации ваших данных между регионами, в то время как MultiDBClient помогает вашему Python-приложению оставаться на связи. Он объединяет мониторинг работоспособности, взвешенный выбор конечных точек, аварийное переключение и возврат, повторные попытки и наблюдаемость за привычным API клиента Redis.

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

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