Сценарий регулирования Apigee

Наша организация находится в процессе перехода на Apigee.

Мы хотим добиться следующего сценария. Не могли бы вы посоветовать мне, как это сделать? Может быть, использовать одновременно SpikeArrest, Quota и ConcurrentRatelimit?

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

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

http://apigee.com/docs/api-services/content/shield-apis-using-spikearrest
http://apigee.com/docs/api-services/content/rate-limit-api-traffic-using-quota#identifying-apps
http://apigee.com/docs/api-services/content/throttle-backend-connections-using-concurrentratelimit

Примером пробела является мой предыдущий вопрос о SpikeArrest, который возник в результате настройки SpikeArrest и не получил ожидаемого поведения из-за того, что в документации не указано, что SpikeArrests не распространяются: Синхронизация Apigee SpikeArrest между процессорами сообщений (MP)

Эти ребята также были пойманы по тому же сценарию: Apigee — поведение SpikeArrest

Сценарий и желаемый результат:

В нашей организации есть 6 процессоров сообщений (MP), и я предполагаю, что они работают строго циклическим образом.

У нас есть следующий серверный API — Api-1.

У Api-1 есть потребители из нашей организации наряду с потребителями Apigee. Мы хотим, чтобы наш Api-1 не забивался и не падал. Допустим, он прошел нагрузочное тестирование, чтобы обрабатывать максимум 50 запросов в секунду. Мы подсчитали, что с помощью Apigee мы хотим ограничить максимум 30 запросами в секунду, так как другие 20 запросов в секунду предназначены для пользователей из наших организаций (в основном других наших собственных продуктов), которые не проходите через апигей.

Из числа приложений DeveloperApp, использующих Api-1 через Apigee, мы определили 4 приложения/клиента, которые имеют самые высокие пики потребления. Из 30 пс, выделенных для Apigee, мы хотели бы иметь возможность выделять 5 пс для каждого из этих 4 высоких потреблений. DevApps/клиенты, а остальная скорость 10ps распределяется между другими DevApps/клиентами.

Основная проблема, с которой я постоянно сталкиваюсь в TargetEndpoint, описана здесь, поскольку политика SpikeArrest не распределяется между процессорами сообщений: Синхронизация Apigee SpikeArrest между процессорами сообщений (MP)

Как мы можем обойти это и достичь желаемого сценария?

Вот примеры того, что я пытался сделать и добиться желаемого поведения:

Целевая конечная точка прокси-сервера:

Ограничение скорости одновременного использования:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConcurrentRatelimit async="true" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
    <DisplayName>Concurrent Rate Limit 1</DisplayName>
    <AllowConnections count="1" ttl="5"/>
    <Distributed>true</Distributed>
    <TargetIdentifier name="default"></TargetIdentifier>
</ConcurrentRatelimit>

СпайкАрест:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="true" continueOnError="false" enabled="true" name="Spike-Arrest-2">
    <DisplayName>Spike Arrest 2</DisplayName>
    <FaultRules/>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

Кроме того, что произойдет, если организация добавит или удалит депутатов без моего ведома, это полностью остановит регулирование?

Очень признателен!

Спасибо!


api backend throttling apigee
person atkuzmanov    schedule 30.04.2014    source источник
comment
Пробовали ли вы разделить его на количество известных обработчиков сообщений? То есть, если у вас есть   -  person Michael Bissell    schedule 30.04.2014
comment
Это мое текущее решение. На данный момент я установил остановку пика на 5 пс (30 пс / 6 мп = 5 пс). Я ищу лучшее решение, так как по какой-то причине числа должны быть очень низкими, насколько я знаю, вы не можете установить что-то вроде 0,5 пс в качестве скорости для SpikeArrest.   -  person atkuzmanov    schedule 01.05.2014

Ответы (1)


arrow_upward
1
arrow_downward

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

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

person Michael Bissell    schedule 02.05.2014
comment
У меня также реализована политика квот. Может ли ConcurrentRateLimit помочь в описанном выше сценарии? Как это работает? Что именно он делает? В документации говорится: Политика ConcurrentRatelimit позволяет вам ограничивать входящие подключения к вашим серверным службам от прокси-серверов API, работающих на Apigee Edge. В распределенных средах трафик приложений может управляться множеством реплицированных прокси-серверов API. apigee.com/docs/api-services/content/ - person atkuzmanov; 02.05.2014
comment
Кроме того, политики квот, по-видимому, распределяются между процессорами сообщений, и, похоже, это не вызывает дополнительной болтовни между MP, поэтому я не понимаю, почему политики SpikeArrest не синхронизируются таким же образом? Если по какой-либо причине количество MP изменится без моего ведома, это испортит дросселирование и отключит API, который я пытаюсь защитить именно от этого сценария. Защита от DOS-атак и дросселирование являются главными заботами моей команды, и если это не сработает, Apigee станет для нас бесполезным. - person atkuzmanov; 02.05.2014