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

Я разделяю перенасыщение трафика на два типа в зависимости от их причин: положительное перенасыщение и отрицательное перенасыщение.

Положительное перенасыщение

Положительное перенасыщение - это перенасыщение, которое происходит, когда входящий трафик увеличивается до превышения пропускной способности. Чтобы лучше продемонстрировать эффект положительного перенасыщения, мы создали макет сервиса и запустили на нем моделирование нагрузки с помощью Gatling. Наш макет-сервис может обрабатывать 20 одновременных запросов параллельно с максимальной пропускной способностью примерно 200 запросов в секунду. Моделирование постепенно увеличивает входящий трафик. См. Время ответа, сообщаемое Gatling ниже.

Рис. 1. Положительное перенасыщение трафика - время отклика.

Как видно на диаграмме, когда насыщение трафика происходит при 200 запросах в секунду, задержки резко увеличиваются с примерно 100 мс до более 6–7 секунд. В нашем тесте мы ограничиваем количество одновременных попыток подключения до 900, из-за этого ограничения и высоких задержек входящий трафик падает до 200 запросов в секунду (см. Диаграмму ниже), но задержки продолжают расти.

Рис. 2. Положительное перенасыщение трафика - откликов в секунду.

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

Отрицательное перенасыщение

Отрицательное перенасыщение - это перенасыщение, которое возникает, когда пропускная способность оказывается ниже входящего трафика. Опять же, давайте воспользуемся симуляцией, чтобы продемонстрировать этот сценарий. В этой модели имитационная служба начинается с пропускной способности 220 запросов в секунду, обслуживая трафик 180 запросов в секунду. Затем его пропускная способность снижается на 30% до 150 запросов в секунду примерно в 15:32, что означает, что пропускной способности становится меньше 30 запросов в секунду.

Рис 3. Отрицательное перенасыщение трафика - время отклика.

За считанные секунды задержка выросла до более чем 10 секунд. Затем из-за этой высокой задержки входящий трафик падает до 110 запросов в секунду. Но задержки продолжали расти. Примерно в 15:39 емкость восстановилась. Но из-за конкуренции и очереди, уже вызванного предыдущим переполнением трафика, задержки остаются ужасными. Как и в моделировании положительного перенасыщения, одновременное соединение было ограничено до 900, вместе с высокой задержкой входящий трафик упал примерно до 110 запросов в секунду (см. Ниже).

Рис. 4. Положительное перенасыщение трафика - откликов в секунду.

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

Меры по оказанию противодавления при перенасыщении дорожного движения

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

Один из подходов к созданию противодавления с динамической емкостью - это противодавление, основанное на вытягивании. Основная идея состоит в том, чтобы каждый рабочий в цепочке обработки тянул работу из источника. Недавний пример такого подхода - Akka Stream. Основная стоимость реализации этого подхода заключается в том, что все этапы обработки должны реализовывать механизм извлечения в зависимости от их возможностей, это может быть проблематичным для службы, которая полагается на другие службы, например база данных, интерфейс которой основан на push.

Решение Каналоа

Kanaloa - это библиотека, которую мы разработали в iHeartRadio с использованием scala и Akka. Каналоа применил другой подход к созданию противодавления с изменяющейся производительностью. Это обратный прокси-сервер перед службой, который рассматривает службу как черный ящик. Он адаптивно регулирует количество одновременных запросов, обрабатываемых службой, и, таким образом, ограничивает количество запросов, ожидающих во внутренних очередях службы. Этот дроссель является адаптивным в том смысле, что во время перенасыщения параллельные запросы, обрабатываемые службой, постоянно оптимизируются в соответствии с производительностью (измеряемой пропускной способностью и задержкой), которую Каналоа наблюдает по нему. Установив этот дроссель, Kanaloa буферизует избыточный трафик в своей собственной очереди, с которой он применяет механизм управления трафиком, называемый Улучшенный пропорциональный интегральный контроллер (PIE). Вот диаграмма:

Трафик идет через Каналоа в сторону сервиса. Адаптивный дроссель в Kanaloa гарантирует, что одновременные запросы, обрабатываемые сервисом, ограничены. Когда количество одновременных запросов к сервису достигнет предела, в очереди kanaloa будут ждать лишние запросы. Регулятор PIE отклоняет запросы с возможностью, основанной на времени ожидания в очереди kanaloa.

Адаптивный дроссель параллелизма

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

Адаптивный дроссель kanaloa управляет параллельным запросом, который обрабатывает служба, имея набор рабочих процессов, которые выполняют работу над поведением службы. Эти работники ждут результата, возвращаемого службой, прежде чем принять дополнительную работу от диспетчера. Таким образом, количество одновременных запросов, обрабатываемых службой, не может превышать количество рабочих, то есть размер пула рабочих. Затем адаптивный дроссель kanaloa отслеживает пропускную способность и задержку для каждого размера пула и оптимизирует размер рабочего пула (т. Е. Параллелизм) в сторону того, который обеспечивает наилучшую производительность (измеряемую по пропускной способности и задержке). Это достигается путем периодического выполнения следующих двух операций изменения размера (по одной):

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

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

Регулятор PIE

Теперь, когда количество одновременных запросов, обрабатываемых службой, ограничено, избыточные запросы попадают в очередь, созданную внутри kanaloa. Каналоа контролирует эту очередь и применяет алгоритм регулирования трафика под названием PIE (Proportional Integral Controller Enhanced), предложенный в этой статье Ронг Пэна и его сотрудников.

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

Регулятор PIE также позволяет использовать пакетный режим - в течение короткого периода он пропускает весь трафик. Это помогает избежать ненужного отклонения запросов, когда это всего лишь кратковременный всплеск трафика.

Каналоа в действии

Чтобы протестировать kanaloa, мы создали фиктивный сервис и поместили его за сервером Akka Http, чтобы мы могли проверить, как kanaloa помогает этому фиктивному сервису. с Гатлингом. Этот фиктивный сервис может обрабатывать X одновременных запросов параллельно. Если служба получает запросы, превышающие X одновременных, это отрицательно влияет на скорость обработки как имитация конкуренции. Чрезмерные запросы будут ждать в очереди внутри службы, что вызовет некоторые задержки.

Каналоа борется с положительным перенасыщением дорожного движения

Сначала мы запускаем ту же симуляцию, которая показана на рис. 1, но на этот раз мы помещаем kanaloa перед службой и позволяем ей работать дольше. Теперь результаты гатлинга выглядят так:

Рис 5. Положительное перенасыщение трафика с каналоа - время отклика

Рис 6. Положительное перенасыщение трафика каналоа - откликов в секунду

Когда входящий трафик превышает пропускную способность на уровне 200 запросов в секунду, мы сначала видим всплеск задержки примерно до 4 секунд; затем он возвращается примерно к 1–1,5 секунде. Пик вызван включенным в каналоа пакетным режимом. В пакетном режиме kanaloa не будет отклонять трафик, отсюда и высокие задержки. Режим серийной съемки ограничен коротким периодом времени. Как только он выходит из пакетного режима, kanaloa начинает отклонять избыточный трафик, чтобы контролировать задержку. После этого латентность постепенно улучшается по мере того, как каналоа оптимизирует дроссельную заслонку. Очень легче увидеть разницу, которую дает kanaloa, сравнивая рис. 1, 2 и рис. 5, 6.

Теперь давайте посмотрим, как Каналоа этого добился. Kanaloa обеспечивает мониторинг в реальном времени, что дает нам хорошее представление о том, как это работает.

Рис. 7. Положительное перенасыщение трафика с помощью Kanaloa - входящий трафик.

Kanaloa обеспечивает низкую задержку, разрешая только часть входящего трафика, которая находится в пределах возможностей службы, и отклоняет избыточную часть. Как показано на диаграммах выше, после того, как входящий трафик превышает пропускную способность, которая составляет 200 запросов в секунду, kanaloa начинает отклонять часть трафика. При входящем трафике со скоростью 250 запросов в секунду, kanaloa отклоняет 50 запросов в секунду, что оставляет 200 запросов в секунду для прохождения через службу, что и соответствует его мощности.

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

Рис. 8. Положительное перенасыщение трафика с Kanaloa - дроссель параллелизма

Показатель использовано на верхней диаграмме - это количество одновременных запросов, обрабатываемых службой. Когда входящий трафик нарастает, это число также медленно увеличивается, но когда перенасыщение трафика происходит примерно в 16:14, оно быстро достигает максимального ограничения, которое Каналоа настроено на разрешение, которое составляет 60. Это означает, что из всех одновременных запросов Каналоа поступило на тот момент 60 уходят в сервис. Время, которое они провели в обслуживании, указано в нижнем графике, озаглавленном «Время обработки». Как показано на диаграмме, когда происходит перенасыщение трафика, время обработки быстро увеличивается только вместе с количеством одновременных запросов в обслуживании. Благодаря ограничению, которое kanaloa накладывает на одновременные запросы, время обработки также ограничивается 300 мс.

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

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

Рис. 9. Положительное перенасыщение трафика с Kanaloa - очередь kanaloa

Когда перенасыщение трафика происходит примерно в 16:14, kanaloa сначала переходит в пакетный режим - все лишние запросы попадают в очередь; с примерно 700 запросами в очереди (как видно на диаграмме «Длина очереди») время ожидания, определяемое как время, в течение которого запросы остаются в этой очереди, прежде чем они могут быть отправлены в службу, также достигает 3–4 секунд. Это основная часть начального всплеска задержки, который мы видели на рисунке 5.

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

Рис. 10. Положительное перенасыщение трафика с помощью Kanaloa - PIE

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

Каналоа борется с негативным перенасыщением трафика

Теперь давайте запустим такое же моделирование, как показано на рис. 3 и 4, на этот раз с Kanaloa в качестве обратного прокси-сервера перед службой.

Рис 11. Отрицательное перенасыщение трафика с помощью Kanaloa - время отклика.

Рис. 11. Отрицательное перенасыщение трафика с помощью Kanaloa - ответов в секунду.

Как показано на диаграммах выше, с Kanaloa, когда пропускная способность услуги снижается ниже уровня входящего трафика, задержки сначала увеличиваются до 5 секунд в периоде пакетного режима, а затем быстро восстанавливаются до примерно 1 секунды. После восстановления емкости задержки также быстро восстанавливаются до уровня, предшествующего деградации.

Как и в случае с положительным сценарием перенасыщения трафика, Kanaloa добивается этого, отклоняя трафик, превышающий пропускную способность. Смотрите удар:

Рис. 12. Отрицательное перенасыщение трафика с помощью Kanaloa - входящий vs пропускная способность.

На приведенных выше диаграммах пропускная способность (изображенная на верхней диаграмме) - это емкость службы. По мере того, как скорость снижается до 150 запросов в секунду, Kanaloa начинает отклонять запросы примерно со скоростью 30 запросов в секунду из 180 входящих запросов в секунду. Это сохраняет задержки на низком уровне по сравнению с задержки в 10+ секунд, которые мы видели на рис. 3. Как и в сценарии положительного перенасыщения, Kanaloa отклоняет этот трафик за счет комбинации адаптивного дросселя параллелизма и PIE.

Вывод

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

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

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