Стратегии формирования / регулирования трафика API для изоляции арендаторов

Question

Я начну свой вопрос с предоставления некоторого контекста о том, что мы делаем и о проблемах, с которыми мы сталкиваемся.

• В настоящее время мы создаем SaaS (размещенный на Amazon AWS), который состоит из нескольких микросервисов, которые находятся за шлюзом API (мы используем Kong).
• Шлюз обрабатывает аутентификацию (через потребителей с ключами API) и предоставляет API-интерфейсы упомянутых мною микросервисов, все из которых не имеют состояния (нет сессий, файлов cookie и т. П.).
• Каждый сервис развертывается с использованием сервисов ECS (один или несколько док-контейнеров на сервис, работающий на одном или нескольких компьютерах EC2) и балансировка нагрузки выполняется с помощью Amazon Application Balancer (ALB).
• Все арендаторы (клиенты) используют одну и ту же среду, то есть одни и те же машины и ресурсы. Учитывая нашу бизнес-модель, мы ожидаем, что у нас будет несколько, но «крупных» арендаторов (сначала).
• Большинство запросов к этим службам преобразуются в интенсивное использование ресурсов (главным образом, в ЦП) на время запроса. Время, необходимое для обслуживания одного запроса, находится в диапазоне 2-10 секунд (а не мс, как в традиционных «веб-подобных» приложениях). Это означает, что мы обрабатываем относительно небольшое количество запросов в минуту, и обработка каждого из них занимает некоторое время (фоновая или пакетная обработка невозможна).

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

Мы думаем о стратегиях по ограничению / ограничению или в целом подготовке системы к «изоляции» арендаторов, чтобы один арендатор не мог ухудшить производительность для других, делая больше запросов, чем мы могли бы обработать:

• Ограничение скорости : Определите максимальное количество запросов / м, которое может сделать арендатор. Если поступит больше запросов, отбросьте их. У Конга даже есть плагин для этого. К сожалению, мы используем модель ценообразования «оплата за запрос», и бизнес не позволяет нам использовать эту стратегию, потому что мы хотим обслуживать как можно больше запросов, чтобы получать за них деньги. Если лишние запросы занимают больше времени для арендатора, это нормально.
• Изоляция арендатора : создание изолированной среды для каждого арендатора. От этого тоже отказались, так как он усложняет обслуживание и ведет к снижению использования ресурсов и повышению затрат.
• Автоматическое масштабирование : добавьте больше машин для поглощения очередей. По нашему опыту, Amazon ECS не очень быстро это делает, и к тому времени, когда эти новые машины будут готовы, возможно, уже слишком поздно.
• Запрос "регулирования" : Использование таких алгоритмов, как Leaky Bucket или Token Bucket на уровне шлюза API, чтобы гарантировать, что запросы будут обрабатывать сервисы со скоростью, которая, как мы знаем, мы можем обработать.

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

Если прибывает пакет, избыточные запросы помещаются в очередь (до предела), а затем высвобождаются с фиксированной скоростью (с использованием негерметичного сегмента или аналогичного алгоритма). Это гарантирует, что арендатор не сможет повлиять на производительность других арендаторов, поскольку запросы будут обрабатывать службы с заранее определенной скоростью. В идеале разрешенная частота запросов должна быть «динамической», чтобы арендатор мог использовать некоторые «запросы в минуту» других арендаторов, которые их не используют (в пределах безопасности). Я полагаю, что это называется алгоритмом «динамическая скорость утечки». Цель состоит в том, чтобы максимально использовать ресурсы.

Мои вопросы:

• Является ли предложенная стратегия жизнеспособной? Известны ли вам какие-либо другие жизнеспособные стратегии для этого варианта использования?
• Существует ли коммерческая служба или служба SaaS с открытым исходным кодом, которая может предоставить такие возможности формирования трафика? Насколько я знаю, Kong или Tyk не поддерживают ничего подобного, так что ... Есть ли какие-либо другой шлюз API, который делает?
• В случае, если Kong не поддерживает это, насколько сложно реализовать что-то вроде того, что я описал как плагин? Мы должны принять во внимание, что для этого потребуется некоторое общее состояние (используя Redis например), поскольку мы используем несколько экземпляров Kong (для балансировки нагрузки и высокой доступности).

Большое спасибо, Микель.

Answer 1

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

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

Не могу сказать о Конге, но Tyk в этом случае предоставляет два основных числа, которыми вы можете управлять: квота - максимальное количество запросов, которые клиент может сделать за данный период времени, и ограничения скорости - защита безопасности. Вы можете установить ограничение скорости 1) для «политики», например, для группы потребителей (например, если у вас несколько уровней обслуживания, с разными допустимыми ограничениями использования / скорости), 2) для отдельного ключа 3) Глобально для API (работает вместе с ключевыми предельными ставками). Так, например, вы можете установить некоторые умеренные ограничения скорости клиента и ограничить общий лимит с помощью глобальной настройки API.

Если вы хотите полностью динамическую схему и пересчитать пределы на основе нагрузки кластера, это должно быть возможно. Вам нужно будет где-то написать и запустить этот планировщик, время от времени он будет выполнять перерасчет на основе текущего общего использования (которое рассчитывает Tyk для вас, а вы получаете его из Redis) и будет общаться с Tyk API, перебирая через все ключи (или политики) и динамически обновлять их ограничения скорости.

Надеюсь, это имеет смысл:)