Отказ распределённой системы может начаться с ошибки, которая кажется незначительной, но быстро перерасти в цепочку сбоев, когда множество компонентов зависит друг от друга. В выступлении Sam Newman, независимый консультант по разработке программного обеспечения, связывает понятие каскадного отказа (Progressive Collapse) в гражданском строительстве с проблемами устойчивости цифровых систем и приходит к выводу, что предотвратить все ошибки невозможно, однако можно снизить вероятность их распространения и масштаб последствий.
От здания Ronan Point до облачных сервисов
Newman возвращается к инциденту частичного обрушения башни Ronan Point в районе Canning Town в Лондоне в 1968 году. Ограниченный взрыв газа в квартире Mrs. Ivy Hodge выбил внешнюю стену, которая поддерживала часть здания. Четыре этажа над местом взрыва обрушились, после чего часть угла башни упала в результате последовательного воздействия. Погибли четыре человека, а время происшествия — незадолго до шести часов утра — помогло ограничить число жертв.
Смысл этой истории для программного обеспечения заключается не в физическом сходстве здания и цифрового сервиса, а в характере отказа: небольшой первоначальный сбой выводит из строя компонент, от которого зависят другие компоненты, и круг ущерба расширяется. Такую цепочку трудно понять в распределённых системах, поскольку связи между сервисами, базами данных, балансировщиками нагрузки и системами DNS не всегда видны как ряд костяшек домино.
Цифровые примеры каскадного отказа
Во время сбоя в зоне us-east-1 AWS в октябре один из вспомогательных компонентов DynamoDB столкнулся с проблемой при обновлении маршрутов DNS внутри инфраструктуры AWS. Ошибка в процессе обновления планов привела к удалению маршрутов в Route 53, после чего начали отказывать сервисы, зависевшие от этих маршрутов, включая сетевые балансировщики нагрузки, вычислительные сервисы, очереди и EKS. Поскольку эти базовые сервисы использовались другими сервисами, проблема распространилась на продукты и компании, взаимодействующие с пользователями, включая Alexa, Ring, Slack, Snapchat, Zoom и Shopify; некоторые из них пострадали частично, а другие — полностью.
Согласно объяснению Newman, основанному на отчёте AWS, система включала планировщик, создававший планы изменений DNS, и несколько исполнителей, применявших их. Один из планов выполнялся дольше обычного, затем был создан другой план, который другой исполнитель применил быстро. Когда выполнение старого плана позднее завершилось, он удалил маршруты, созданные новым планом. В результате возникло состояние гонки (Race Condition), приведшее к удалению записей DNS.
Вторым примером был сайт продажи подержанных автомобилей, мотоциклов и прицепов, работавший на приложении под кодовым названием Sauron на десяти серверах. Обычно приложение обрабатывало от 30 до 60 одновременных запросов, но столкнулось с более чем 800 запросами. Один из зависимых сайтов принимал соединения, а затем зависал без ответа, тогда как приложение ожидало 30 секунд перед завершением запроса. Пул соединений был исчерпан, затем начали накапливаться программные потоки, и процессоры тратили время на управление ими, в результате чего система полностью остановилась. Пользователи усилили нагрузку, многократно нажимая кнопку обновления.
Три направления для снижения вероятности обрушения
Newman считает, что сосредоточение на одной «первопричине» ведёт к чрезмерному упрощению. Предотвращение искры может быть полезным, но оно не устраняет все условия, позволяющие огню распространиться. Поэтому инженерия устойчивости предполагает принятие вероятности отказов и подготовку к ограничению их последствий посредством трёх взаимосвязанных категорий:
- Снижение рисков: устранение источников опасности или ограничение их способности истощать ресурсы. В случае AWS это включало временную остановку автоматического управления DNS до устранения проблемы и добавление более качественных тестов компонента. В приложении Sauron можно было бы использовать сброс нагрузки (Load Shedding), принимая ограниченное число запросов и отклоняя те, что превышают возможности системы, вместо того чтобы позволять им накапливаться до отказа.
- Укрепление компонентов: повышение способности сервиса выдерживать отказ части системы посредством избыточности, мониторинга, тестирования и улучшения реализации. Это может означать запуск нескольких экземпляров сервиса за балансировщиком нагрузки, однако решение зависит от важности компонента и его стоимости: приложение Sauron находилось на этапе вывода из эксплуатации и обеспечивало лишь часть доходов, поэтому запуск дополнительных резервных экземпляров в тот момент был коммерчески непривлекательным вариантом.
- Уменьшение связанности: предотвращение распространения отказа одного компонента на остальную систему. Это включает использование изолирующих перегородок (Bulkheads), ограничений времени ожидания, альтернативных маршрутов и локальных архитектур, когда это возможно. Чем меньше одна часть системы зависит от другой, тем легче локализовать отказ, а не распространять его.
Что это практически меняет для технических команд?
Устойчивость не означает автоматический запуск системы в двух регионах или двух облаках. Newman объясняет, что варианты простираются от резервного копирования и восстановления до архитектуры Pilot Light, которая реплицирует данные без полного запуска инфраструктуры, затем до тёплого восстановления и, наконец, до одновременной работы двух активных площадок. Эти варианты постепенно сокращают время простоя и потери данных, но повышают стоимость и сложность.
Он также предостерегает от того, чтобы считать двунаправленную синхронизацию между площадками простой задачей, особенно при добавлении её к существующему приложению, которое для этого не проектировалось. То же относится к использованию нескольких облаков: оно может уменьшить зависимость от одного провайдера, но требует разных навыков и операционных процессов для каждой платформы, а простого развертывания одного и того же кода в AWS и Azure недостаточно для обеспечения независимости, поскольку одна и та же программная ошибка может вывести из строя обе среды.
Заключение
Главный урок заключается в том, что устойчивость — это не поиск среды, которая никогда не отказывает, а проектирование системы таким образом, чтобы её часть продолжала работать при отказе другой части. Поэтому следует оценивать риски, пределы ёмкости, узкие места и цепочки зависимостей, а затем находить баланс между избыточностью, изоляцией и стоимостью. Такие решения, как работа в нескольких регионах или облаках, остаются инженерными и коммерческими вариантами, зависящими от важности сервиса, а не универсальным рецептом для любой системы.