Хабрахабр

[Перевод] Как Netflix эвакуируется из региона AWS за семь минут

Netflix уменьшил время аварийного переключения с 45 до 7 минут без каких-либо затрат

Изображение: Florida Memory. Доработано Opensource.com. CC BY-SA 4.0

Всё ваше взаимодействие с Netflix происходит через AWS, кроме самого потокового видео. Зимой 2012 года Netflix пережил длительный сбой, уйдя в отключку на семь часов из-за проблем с сервисом AWS Elastic Load Balancer в регионе US-East (Netflix работает на AWS — у нас нет собственных дата-центров. Во время сбоя ни один пакет из региона US-East не доходил до наших серверов. Как только вы нажмете Play, начинает загружаться видеопоток из нашей собственной сети CDN).

Аварийное переключение (failover) — это система обеспечения отказоустойчивости, когда в случае сбоя основной системы автоматически активируется резервное оборудование.
Чтобы такого больше не повторилось, мы решили создать систему аварийного переключения, устойчивую к сбоям базовых поставщиков услуг.

Мы расширились на три региона AWS: два в США (US-East и US-West) и один в Евросоюзе (EU). Зарезервировали достаточно ресурсов для переключения, если один регион выйдет из строя.

Типичная отработка отказа выглядит следующим образом:

  1. Понять, что один из регионов испытывает проблемы.
  2. Масштабировать два спасательных региона.
  3. Проксировать трафик спасателям из проблемного региона.
  4. Изменить DNS из проблемного региона на спасателей.

Изучим каждый шаг.

1. Определить наличие проблемы

Нужны метрики, а лучше одна метрика, которая говорит о здоровье системы. В Netflix используется бизнес-метрика «запуски потоков в секунду» (stream starts per second, сокращённо SPS). Это число клиентов, успешно запустивших потоковую трансляцию.

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

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

Если в нескольких регионах, то не повезло, потому что мы в силах эвакуировать только один регион за раз. Если падение SPS произошло только в одном регионе, то это отличный кандидат для аварийного переключения. Если возникла проблема с развёртыванием, можно немедленно эвакуироваться и исправить проблему позже. Именно поэтому мы разворачиваем микросервисы в регионах по очереди. Точно так мы хотим избежать сбоя, если проблема сохранится после перенаправления трафика (как это происходит в случае DDoS-атаки).

2. Масштабировать спасателей

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

Шаблон трафика Netflix меняется в течение дня. Что означает масштабирование в данном контексте? Пик трафика в регионе US-East наступает на три часа раньше, чем в регионе US-West, который на восемь часов отстаёт от региона EU. Есть пиковые часы, как правило, в районе 6−9 вечера, но в разных частях мира это время наступает в разный момент.

Это необходимо для уменьшения задержки и наилучшего качества работы сервиса. При аварийном отключении US-East мы направляем трафик с Восточного побережья в регион EU, а трафик из Южной Америки — в US-West.

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

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

3. Прокси для трафика

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

Прокси-сервер Zuul может выполнять и проксирование между регионами. Эти прокси предназначены для аутентификации запросов, сброса нагрузки, повтора неудачных запросов и т. д. Мы используем эту функцию, чтобы перенаправить трафик от пострадавшего региона, а затем постепенно увеличить количество перенаправленного трафика, пока оно не достигнет 100%.

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

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

4. Смена DNS

Последний шаг в аварийной эвакуации — обновление DNS-записей, указывающих на пострадавший регион, и перенаправление их в рабочие регионы. Это полностью переведёт туда трафик. Клиентов, не обновивших DNS-кэш, по-прежнему будет перенаправлять Zuul в пострадавшем регионе.

Раньше процесс занимал много времени — около 45 минут (если повезёт). Таково общее описание процесса, как происходит эвакуация Netflix из региона.

Мы заметили, что бóльшая часть времени (примерно 35 минут) уходит на ожидание масштабирования спасательных регионов. Хотя AWS может предоставлять новые инстансы в течение нескольких минут, но в процессе масштабирования львиную долю времени отнимают запуск сервисов, разогрев, а также обработка других необходимых задач, прежде чем будет зарегистрирован UP в discovery.

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

Если мы уже платим за эти мощности, почему бы не использовать их? Мы резервируем мощности во всех трёх регионах на случай отказа одного. Так стартовал Project Nimble (проект «Шустрик»).

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

Некоторые команды разработчиков Netflix иногда используют часть «кормушки» для своих пакетных заданий, поэтому мы просто не можем взять её целиком в горячий резерв. Неиспользованная зарезервированная ёмкость называется «кормушкой» (trough). Остальные инстансы доступны для пакетных заданий. Но можно поддерживать теневой кластер для каждого микросервиса, чтобы в каждое время суток впритык хватало инстансов для эвакуации трафика, если такая необходимость возникнет.

Процесс занимает около четырёх минут, в отличие от прежних 35-ти. Во время эвакуации вместо традиционного масштабирования AWS мы внедряем инстансы из теневого кластера в рабочий кластер.

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

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

Инстансы останутся в тени, пока не начнётся эвакуация. Мы также убрали регистрацию UP для инстансов из теневых кластеров, изменив наш клиент обнаружения.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть