Ограничение скорости с использованием шлюза приложений Azure
Я меняю развертывание нашего веб-приложения со службы приложений Azure на виртуальные машины за шлюзом приложений, потому что служба приложений не смогла справиться с пиковой нагрузкой, которая была у нас несколько дней назад.
То, что я сейчас хотел бы сделать, чтобы защитить приложение от возможного очень короткого пикового использования, - это реализовать ограничение скорости (например, макс. 60 запросов в минуту на клиент / IP).
Ожидается, что у приложения будет очень короткий пик использования (приложение для продажи билетов и начало продажи очень популярного мероприятия).
В прошлый раз, когда случился пик, и сервер стал медленнее, люди начали нажимать «Обновить» так быстро, как могли, и полностью отключили всю систему без возможности восстановления (при нескольких тысячах запросов в секунду наша система не могла запуститься опять же, поскольку он на самом деле не рассчитан на такую высокую нагрузку, поскольку в 99,9% случаев у нас есть <100 запросов в секунду) - поэтому мы хотели бы иметь возможность избежать таких пользователей, "DDoS-атакующих" систему " случайно или из-за страха не получить свой билет »...
Возможно ли это с помощью шлюза приложений?
Есть ли другая идея, как можно реализовать такое (по запросу) ограничение скорости?
Я обнаружил следующее: https://docs.microsoft.com/en-us/azure/api-management/ api-management-sample-гибкое регулирование но, похоже, это не относится к шлюзам приложений, или, по крайней мере, я не понял, как ...
В шлюзе приложений Azure нет собственного механизма для применения ограничения скорости.
Вероятно, самым простым было бы взглянуть на службу входной двери Azure:
https: // docs .microsoft.com / en-us / azure / frontdoor / front-door-overview
В частности, правила WAF, ограничивающие скорость клиента:
https://docs.microsoft.com/en-us/azure/frontdoor / waf-overview # waf-rules
Обратите внимание, что это ограничит лимиты скорости на основе определенного IP-адреса клиента, если у вас есть целый диапазон клиентов, это не обязательно поможет вам.
Обратите внимание, что Backend Pool для FrontDoor может быть любое имя хоста, поэтому это может быть набор виртуальных машин, или у вас может быть простой балансировщик нагрузки Azure, который можно использовать в качестве конечной точки. Хотя я бы не стал предлагать использовать шлюз приложений Azure в этой настройке, поскольку он дублирует функции Front Door и требует затрат, которых нет у базового балансировщика нагрузки Azure.
Я бы также порекомендовал взглянуть на виртуальную машину Наборы масштабирования (VMSS) и использовать это как механизм для автоматического масштабирования в зависимости от потребности. Таким образом, вы можете ограничить индивидуальные IP-адреса клиентов (из-за заклинивания кнопки обновления), а также масштабировать свое приложение в соответствии с допустимым объемом клиентов - и затем снова уменьшить его, чтобы сэкономить средства. См.:
https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview
Наконец, ссылка, на которую вы ссылаетесь, является частью управления API Azure, которое является платформой. специально для создания и демонстрации сложных платформ API. Хотя с помощью этой службы вы можете реализовать ряд вариантов манипулирования трафиком, в данном случае это, вероятно, не то, что вы ищете, поскольку она предназначена как более комплексная платформа управления корпоративным API с целым рядом возможностей, которые вы не сможете потребность.
ОБНОВЛЕНО: хотя мне было легко добавить некоторые URL-адреса, на самом деле не очень хорошо задокументировано, как применить политику к входной двери Azure, чтобы сделать то, чего вы хотите достичь.
Итак, вот некоторые шаги в PowerShell, которые дают ему шанс - обратите внимание, что это может быть не совсем то, что вам нужно, но с него вы должны начать (используя новый модуль Az.Frontdoor):
Сначала мы создаем условие соответствия, здесь я сопоставляю любой IP-адрес (хотя вы можете создать определенные условия для диапазона IP-адресов, если хотите):
$mc = New-AzFrontDoorMatchConditionObject -MatchVariable RemoteAddr -OperatorProperty Any
Затем мы создаем настраиваемое правило ограничения скорости, оно будет соответствовать любому условию соответствия, и если оно увидит более 10 запросов за 1-минутный период которые соответствуют этому условию, он заблокирует их на 1 минуту (I тонкий k - это очень новая услуга, и документация не очень ясна, это то, что я обнаружил в результате некоторых экспериментов):
$cr = New-AzFrontDoorCustomRuleObject -Name MyRule1 -RuleType RateLimitRule -MatchCondition $mc -Action Block -RateLimitThreshold 10 -RateLimitDurationInMinutes 1 -Priority 10
Затем мы создаем политику WAF только с нашим единственным настраиваемым правилом:
$policy = New-AzFrontDoorFireWallPolicy -ResourceGroupName AD -Name MyPolicy -Customrule $cr -EnabledState Enabled -Mode Prevention
Затем мы присоединяем его к нашему экземпляру Front Door (замените TestRG и TestFD своими именами группы ресурсов и экземпляра Front Door соответственно):
$fd = Get-AzFrontDoor -ResourceGroupName TestRG -Name TestFD
$fd[0].FrontendEndpoints[0].WebApplicationFirewallPolicyLink = $policy.Id
Set-AzFrontDoor -InputObject $fd[0]
Надеюсь, это поможет вам начать работу, как я уже сказал, кажется немного неясным, как ограничение скорости фактически применяется. Если я найду нашу дополнительную информацию - или они есть у других, я буду рад обновить ответ снова.
Ссылка, которую я использовал для создания этого, была документация Az.Frontdoor:
https://docs.microsoft.com /en-us/powershell/module/az.frontdoor/?view=azps-1.6.0