Нам удалось выяснить причину произошедшего и восстановить работу сайта. Оказалось, что одна из нижестоящих рекламных систем, самая старая и хуже всех поддерживаемая, начала выдавать ответы очень медленно. Подобное поведение является одним из наихудших режимов сбоя, с которым можно столкнуться. Отсутствие системы определяется довольно быстро. А когда она просто замедляется, то прежде, чем среагировать на сбой, приходится некоторое время занимать выжидательную позицию. Но какой бы ни была причина неполадок, мы создали систему, уязвимую для каскадного сбоя. Практически не контролируемый нами нижестоящий сервис способен был обрушить всю систему.
Пока одна команда изучала проблемы, возникшие с нижестоящей системой, все остальные приступили к выявлению причин возникновения нештатной ситуации в нашем приложении. Были обнаружены сразу несколько проблем. Для обслуживания нижестоящих подключений мы использовали пул HTTP-соединений. Потоки этого пула имели показатели времени ожидания, настроенные на время ожидания HTTP-вызова, направляемого в адрес нижестоящей системы, что было вполне приемлемо. Проблема заключалась в том, что всем исполнителям при замедлении нижестоящей системы приходилось ожидать истечения лимита времени. Пока они ждали, в пул приходили новые запросы, требовавшие исполнительных потоков. Из-за отсутствия доступных исполнителей эти запросы зависали. Оказалось, что у библиотеки пула соединений, которую мы использовали, была настройка лимита времени ожидания исполнителей, но по умолчанию она была отключена! Это вызвало огромное скопление заблокированных потоков. У нашего приложения в любой момент времени обычно было 40 параллельных соединений. В течение пяти минут возникшая ситуация привела к резкому возрастанию количества соединений до 800, что и обрушило систему.
Хуже того, нижестоящий сервис, с которым шел диалог, обеспечивал менее 5 % функциональных возможностей, используемых нашей клиентской базой, а доля доходов от него была еще меньше. Разобравшись в ситуации, мы пришли к стойкому убеждению, что с системами, просто замедляющими свою работу, справиться намного сложнее, чем с системами, которые быстро выходят из строя. Замедление в распределенных системах имеет убийственный эффект.
Даже при наличии правильно выставленных в пуле лимитов времени у нас для всех исходящих запросов был общий единственный пул HTTP-соединений. Это означало, что один медленный сервис мог в одиночку исчерпать количество доступных исполнителей, даже если все остальные продолжали работать в штатном режиме. В конце концов стало понятно, что рассматриваемый нижестоящий сервис дал сбой, но мы продолжали отправлять трафик в его направлении. В данной ситуации это означало, что мы усугубили и без того плохое состояние дел, поскольку у нижестоящего сервиса все равно не было шансов на восстановление нормального режима работы. Во избежание повторения подобных случаев мы сделали три доработки: выставили правильные значения времени ожидания, реализовали переборки, чтобы отделить друг от друга различные пулы соединений, и создали предохранитель, исключающий отправку вызовов к нездоровой системе.
В своей книге «Антихрупкость» (Random House) Нассим Талеб (Nassim Taleb) рассказывал о таких вещах, как получение, как бы странно это ни звучало, пользы от сбоев и нештатной работы. Ариэль Цейтлин (Ariel Tseitlin) применительно к тому, как работает Netflix, воспользовался этой концепцией для выработки понятия «антихрупкая организация».
Масштабы работы Netflix хорошо известны, как и тот факт, что Netflix целиком полагается на AWS-инфраструктуру. Эти два фактора означают, что данное понятие должно включать в себя также возможность возникновения сбоя. Компания Netflix выходит за рамки этого подхода, фактически провоцируя сбой, чтобы убедиться в том, что система к нему устойчива.
Некоторые организации были бы рады устроить испытательные дни, в которые сбой имитируется выключаемыми системами и наблюдением за реакцией различных команд. Когда я работал в Google, это весьма часто практиковалось для различных систем, и я, конечно же, думал, что многие организации могут извлечь пользу из регулярного выполнения подобных упражнений. Google выходит за рамки простых тестов для имитации сбоя сервера и как часть своих ежегодных упражнений DiRT (Disaster Recovery Test — тестирование на восстановление работоспособности после аварии) имитирует широкомасштабные бедствия наподобие землетрясений. Компания Netflix также практикует более агрессивный подход, создавая программы, вызывающие сбой, и ежедневно запуская их в производственном режиме.
Наиболее известная программа называется Chaos Monkey, она занимается тем, что в течение определенного времени выключает случайно выбранные машины. Сведения о том, что такое может произойти и реально происходит в производственном режиме, означают, что разработчики, создавшие системы, должны быть к этому по-настоящему готовы. Chaos Monkey является лишь одной из составляющих используемого в Netflix комплекса роботов имитации сбоев под названием Simian Army. Программа Chaos Gorilla используется для вывода из строя центра доступности (эквивалента дата-центра в AWS), а программа Latency Monkey имитирует медленную работу сетевого соединения между машинами. Компания Netflix сделала эти инструментальные средства доступными под лицензией открытого кода. Для многих завершающим тестом надежности системы может стать выпуск на волю собственной обезьяньей армии (то есть Simian Army) в своей производственной инфраструктуре.
Включение и провоцирование сбоев посредством программных средств и создание систем, способных справиться с ними, — это всего лишь часть того, что делает Netflix. В этой компании понимают важность извлечения уроков из происходящих сбоев и привития культуры терпимости к допускаемым ошибкам. Затем к извлечению уроков привлекают разработчиков, поскольку каждый разработчик также отвечает за сопровождение своих сервисов, работающих в производственном режиме.
Искусственно вызывая сбои и создавая условия для их появления, компания Netflix обеспечивает более успешное масштабирование своих систем и лучше реагирует на нужды своих клиентов.
Принимать экстремальные меры по примеру Google или Netflix нужно не всем, при этом важно понять, что для работы с распределенными системами нужен иной взгляд на вещи. Сбои неизбежны. То, что ваша система в данный момент разбросана по нескольким машинам (которые могут и будут сбоить) и по сети (которая обязательно проявит свою ненадежность), может как минимум повысить степень уязвимости системы. Следовательно, независимо от того, собираетесь ли вы предоставлять сервис в таких же масштабах, как Google или Netflix, готовность к сбоям, характерным для более распределенных архитектур, играет весьма важную роль. Итак, что же нам нужно сделать, чтобы справиться со сбоями в системах?
Настройки времени ожидания очень легко упустить из виду, но для правильной работы с нижестоящими системами они играют весьма важную роль. Долго ли мне нужно ждать, пока я не смогу считать нижестоящую систему фактически отказавшей?
Если слишком долго ждать решения о том, что вызов не удался, можно замедлить работу всей системы. Если сделать время ожидания слишком маленьким, можно будет посчитать потенциально работоспособный вызов неудавшимся. Если полностью отказаться от времени ожидания, то обрушившаяся нижестоящая система может «подвесить» всю систему.
Настройки времени ожидания нужно иметь для всех вызовов, адресуемых за пределы процесса, и для всех таких вызовов нужно выбирать время ожидания по умолчанию. Зарегистрируйте истечение времени ожидания, найдите причину и соответствующим образом скорректируйте значение времени ожидания.
У вас дома предохранители существуют для защиты электрических устройств от скачков напряжения. Если произойдет такой скачок, предохранитель сработает, защищая дорогостоящие домашние устройства. Предохранитель можно выключить вручную, чтобы отключить электричество в какой-нибудь части дома, что позволит безопасно работать с электропроводкой. В книге Майкла Нигарда (Michael Nygard) Release It! (Pragmatic Programmers) показано, как та же идея может творить чудеса, когда используется в качестве защитного механизма для наших программных средств.
Рассмотрим историю, которой я только что поделился. Нижестоящее устаревшее рекламное приложение реагировало очень медленно, пока в конце концов не вернуло ошибку. Даже при правильной настройке времени ожидания до получения ошибки мы томились бы в долгом ожидании. А затем повторили бы попытку при следующем поступлении запроса и снова ждали. Плохо, конечно, что нижестоящий сервис сбоит, но ведь он при этом заставляет и нас замедлить работу.
Предохранитель же срабатывает после конкретного количества безответных запросов к нижестоящему сервису. И пока он находится в этом состоянии, все последующие запросы быстро получают отказ. По истечении определенного времени клиент отправляет несколько запросов, чтобы определить, не восстановился ли нижестоящий сервис, и при получении достаточного количества нормально обслуженных запросов восстанавливает сработавший предохранитель. Обзор подобного процесса показан на рис. 11.2.
Рис. 11.2. Обзор предохранителей
Конкретная реализация предохранителя зависит от значимости получившего отказ запроса, но когда мне приходилось создавать его для HTTP-соединений, за сбой принимались либо истечение времени ожидания, либо возвращаемый код из серии 5хх HTTP. Таким образом, когда нижестоящий ресурс отказывал, или истекало время ожидания, или возвращались коды ошибок, после достижения определенного порога мы автоматически прекращали отправление трафика и быстро констатировали сбой. И в случае нормализации обстановки могли осуществлять повторный запуск в автоматическом режиме.