- Оригинальный адрес:Performance Under Load
- Оригинальный автор:Netflix Technology Blog Netflix Technology Blog
- Перевод с:Программа перевода самородков
- Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
- Переводчик:WangLeto
- Корректор:sunui,xionglong58
Адаптивный предел параллелизма Netflix
Эран Ландау, Уильям Тёрстон, Тим Бозарт
В Netflix мы одержимы исследованием доступности услуг и за эти годы написали несколько сообщений в блогах о том, как этого добиться. Эти технологии включаютсхема автоматического выключателя, ограничения параллелизма, тестирование хаоса и многое другое. Теперь мы объявляем о последнем нововведении: ограничениях адаптивного параллелизма. Адаптивные ограничения параллелизма радикально улучшают производительность приложений при экстремальных нагрузках и позволяют избежать каскадных отказов служб. Мы убрали тяжелую работу по определению предела параллелизма системы, сохранив при этом низкую задержку. Одновременно с публикацией этой статьи мы открыли исходный код простой библиотеки классов Java, которая объединяет поддержку сервлета, исполнителя и инфраструктуры GRPC.
краткая предыстория
Параллелизм на самом деле представляет собой количество запросов, которые система может обработать в любое время, обычно определяемое аппаратными ресурсами, такими как ЦП. Обычно мы используем закон Литтла для расчета параллелизма системы: для системы в устойчивом состоянии параллелизм равен произведению среднего времени обслуживания и средней скорости обслуживания (L = 𝛌W). Любые запросы, превышающие этот параллелизм, не могут быть обслужены немедленно и должны быть поставлены в очередь или отклонены. Таким образом, даже если скорость поступления запросов и время обслуживания неравномерны, некоторые очереди могут полностью использовать всю систему, поэтому это необходимо.
Проблемы могут возникнуть, когда очередь не имеет принудительных ограничений, например запросы, поступающие быстрее, чем запросы, могут заканчиваться в течение длительного времени. По мере роста очереди увеличивается и задержка, пока все запросы не начнут истекать по таймауту, и в конечном итоге системе не хватит памяти и произойдет сбой. Если его не остановить, это может отрицательно сказаться на вызывающих его объектах, что приведет к каскадным сбоям системы.
Обеспечение принудительных пределов параллелизма - ничто новое; трудно найти пределы параллелизма в большой динамической распределенной системе, чьи характеристики параллелизма и задержки постоянно меняются. Основная цель нашего решения - динамически определить предел параллелизма. Эта сумма параллелизма может рассматриваться как максимальное количество запросов (запросы параллелизма в режиме реального времени), которые допускаются до падения производительности системы (например, задержка).
решение
Раньше в Netflix мы вручную настраивали ограничения на параллелизм в результате сложного тестирования и анализа производительности. Хотя в какой-то момент это точно, это измерение может быстро устареть при изменении топологии из-за частичных простоев системы, автоматического масштабирования системы или изменений характеристик задержки, вызванных отправкой кода в онлайн.
Мы знали, что можем работать лучше, чем статический предел параллелизма, поэтому мы изучили схему автоматического определения предела параллелизма, встроенного в систему, которая:
1. 不需要人工
2. 不需要集中协调
3. 不需要硬件信息或系统拓扑结构就能确定并发限制
4. 能适应系统的拓扑结构变动
5. 计算容易，执行简单
Чтобы решить эту проблему, мы обратились к испытанию реального алгоритма управления перегрузкой TCP, который может определить, сколько пакетов может быть передано одновременно (например, размер окна перегрузки), не вызывая тайм-аутов или добавления задержек. Эти алгоритмы постоянно отслеживают различные метрики для оценки предела параллелизма системы и непрерывно регулируют размер окна перегрузки.
Мы видим, что эта система представляет собой неизвестный фактический параллелизм с синей линией. Запросы, отправляемые клиентами, сначала ограничиваются более низкими уровнями параллелизма, и система часто проверяет более высокие уровни параллелизма, увеличивая окно параллелизма без увеличения задержки. Когда задержка начинает расти, датчик предполагает, что достигнут предел параллелизма, и возвращается к размеру окна перегрузки. Обнаружение ограничения параллелизма продолжается, что приводит к неровному изображению выше.
Наш алгоритм основан на алгоритме управления перегрузкой TCP на основе задержки, который рассматривает отношение между наименьшей задержкой (представляющей лучший случай без очереди), деленной на задержку, измеренную с выборкой по времени, по мере выхода очереди идентификации, и мерой эталона, которая начинает увеличивать латентность. Из этого соотношения можно узнать градиент или уровень изменения задержки:gradient=(RTTnoload/RTTactual)(Примечание переводчика:RTTОтносится к времени приема-передачи TCP-подключения пакета данных, RTTnoload относится к минимальному значению RTT без задержки, RTTactual относится к фактическим значениям RTT). Значение 1 указывает на то, что очередь невозможна, чтобы увеличить ограничения на параллелизм; значение меньше 1 указывает, что очередь также формируется, что должно уменьшить ограничения на параллелизм. Для каждого нового образца соотношение корректируется с использованием ограничений параллелизма и с помощью простой формулы для увеличения допустимого размера очереди:
newLimit = currentLimit × gradient + queueSize
После нескольких итераций алгоритм сходится к некоторому предельному уровню параллелизма, который поддерживает низкую задержку, позволяя при этом обрабатывать пакетные запросы некоторой очередью. Допустимый размер очереди настраивается, и это значение определяет, насколько быстро увеличивается предел параллелизма. Мы решили, что арифметический квадратный корень из текущего предела параллелизма является хорошим значением по умолчанию. Арифметический квадратный корень выбран главным образом потому, что он может в значительной степени отражать полезные характеристики текущего предела параллелизма при небольшом количестве запросов, обеспечивая быстрый рост во время итерации и гибкое сокращение при большом количестве запросов, тем самым обеспечивая стабильность системы.
Включить лимит адаптивного параллелизма
Если этот параметр включен, адаптивный предел параллелизма на стороне сервера будет отклонять чрезмерное количество RPS (запросов в секунду), чтобы поддерживать низкую задержку, тем самым защищая сам экземпляр и службы, от которых он зависит. Если слишком много одновременных запросов не будет отклонено, постоянное увеличение числа запросов в секунду или задержки может привести к еще большей задержке и, в конечном итоге, к сбою системы. Теперь службы могут снизить чрезмерную нагрузку и поддерживать низкую задержку, в то время как в игру вступают другие меры, такие как автоматическое масштабирование.
Важно отметить, что ограничения параллелизма применяются на уровне сервера (без координации), и ограничения трафика для каждого сервера могут быть применены довольно быстро. Таким образом, результирующий предел и количество одновременных запросов могут сильно различаться для разных серверов, особенно для нескольких серверов, арендованных у поставщиков облачных услуг. Когда в другом месте имеется достаточная пропускная способность, это может привести к тому, что сервер покинет сервисный кластер. Сказав это, с балансировкой нагрузки на стороне клиента клиенту нужно только повторить запрос один раз, и почти 100% достигают доступного экземпляра службы. Более того, поскольку служба может очень быстро сократить трафик за доли миллисекунды, это оказывает минимальное влияние на производительность службы, поэтому нет необходимости беспокоиться о DDOS и шторме повторных попыток, вызванном повторными запросами клиента.Клиент неоднократно повторяет запрос службы. потому что запрос был отклонен).
Суммировать
С появлением адаптивных ограничений параллелизма нам больше не нужно следить за производительностью системы, как ребенок, а затем вручную регулировать нагрузку на сервис. Что еще более важно, это одновременно повышает надежность и доступность всей нашей экосистемы, основанной на микросервисах.
Мы рады поделиться нашей реализацией идеи и общей интеграцией фреймворка в небольшой библиотеке с открытым исходным кодом: http://github.com/Netflix/concurrency-limits. Мы надеемся, что любой, кто хочет защитить свои службы от каскадных сбоев и снижения задержки с нагрузкой, сможет использовать наш код для повышения доступности. Мы с нетерпением ждем отзывов сообщества и будем рады принять запросы на вытягивание для новых алгоритмов или интеграций с платформами.
Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.
Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.