Рейт лимит что такое
rate limit
Смотреть что такое «rate limit» в других словарях:
rate limit — rate restriction, instruction to buy or sell securities only within a set range of prices; restrictions on price ranges … English contemporary dictionary
rate-cap — rate caps, rate capping, rate capped 1) VERB: usu passive In Britain, when a local council was rate capped, the government prevented it from increasing local taxes called rates, in order to force the council to reduce its spending or make it more … English dictionary
rate-capping — rateˈ capping noun The setting by central government of an upper limit on the rate that can be levied by a local authority • • • Main Entry: ↑rate … Useful english dictionary
rate cap — ˈrate cap f2 [rate cap] noun (in the US) a limit placed on the amount of interest banks, etc. may charge … Useful english dictionary
Limit (mathematics) — This is an overview of the idea of a limit in mathematics. For specific uses of a limit, see limit of a sequence and limit of a function. In mathematics, the concept of a limit is used to describe the value that a function or sequence approaches… … Wikipedia
Rate of convergence — In numerical analysis, the speed at which a convergent sequence approaches its limit is called the rate of convergence. Although strictly speaking, a limit does not give information about any finite first part of the sequence, this concept is of… … Wikipedia
limit — lim|it1 [ lımıt ] noun count *** 1. ) the largest or smallest amount or the highest or lowest level of something that is allowed: speed/spending limits limit on: There are strict limits on presidential power. limit to: There has to be a fair… … Usage of the words and phrases in modern English
limit */*/*/ — I UK [ˈlɪmɪt] / US verb [transitive] Word forms limit : present tense I/you/we/they limit he/she/it limits present participle limiting past tense limited past participle limited 1) to prevent a number, amount, or effect from increasing past a… … English dictionary
limit — limitable, adj. limitableness, n. /lim it/, n. 1. the final, utmost, or furthest boundary or point as to extent, amount, continuance, procedure, etc.: the limit of his experience; the limit of vision. 2. a boundary or bound, as of a country, area … Universalium
Rate function — In mathematics mdash; specifically, in large deviations theory mdash; a rate function is a function used to quantify the probabilities of rare events. It is required to have several nice properties which assist in the formulation of the large… … Wikipedia
rate — 1. n. & v. n. 1 a stated numerical proportion between two sets of things (the second usu. expressed as unity), esp. as a measure of amount or degree (moving at a rate of 50 miles per hour) or as the basis of calculating an amount or value (rate… … Useful english dictionary
NGINX. Лимит частоты запросов.
Немного об ограничении частоты запросов к определённому адресу на сервере с Nginx и настройке исключений для такого ограничения.
Настраиваем лимиты.
Простое ограничение на частоту запросов выглядит так:
Здесь мы используя limit_req_zone обозначаем:
Обозначенную зону далее мы просто применяем на нужный location. В примере, была создана зона one, которая ограничивает частоту обращений к /login.php 30 запросами в минуту с одного IP.
Белый список IP.
Исключить применение лимитов для определённых IP адресов можно с помощью директив map и geo. Пример создания такого белого списка ниже:
Затем нам остаётся просто обозначить зону one, и применить её для нужного location. Если всё будет сделано верно, то IP, не входящие в белый список, будут попадать под заданные ограничения.
Несколько зон для location.
Кроме того, для IP из такого списка мы можем так же задать отдельные ограничения. При этом, для одного location просто будут использоваться две разных зоны:
В данном примере, для location актуальны две зоны. IP попавшие в зону def, имеют ограничение на 10 запросов в секунду, в то время как IP из зоны one имеют расширенный лимит в 30 запросов в секунду.
В примерах так же используется параметры burst и nodelay. Nginx позволяет указать, какое количество запросов клиент может выполнить сверх обозначенного зоной лимита. Запросы превышающие лимит, встают в очередь, размер этой очереди и задаётся параметром burst. Для того что бы сократить время обработки очереди, вместе с параметром burst можно использовать параметр nodelay.
2 thoughts on “ NGINX. Лимит частоты запросов. ”
Приветствую.
А если домен находится на Cloudflare, возможно такое сделать?
С Уважением.
Celery throttling — настраивам rate limit для очередей
В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit’a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.
So what’s the problem?
Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.
Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.
What’s in the box
Нельзя задать rate limit на группу задач.
Это неудобно, т.к зачастую доступ к какому-то лимитированому ресурсу размазан между разными тасками.
Этот лимит работает только внутри воркера, то есть он локальный и у каждого воркера свой.
Конечно, можно еще раз поделить лимит, теперь взяв в расчет еще и количество воркеров. Но все это начнет работать дико неэффективно, если таски будут прилетать неравномерно, например в какую-то минуту мы получим 60 вызовов get_github_api1() и 0 вызовов get_github_api2() — будут выполнены только 30 вызовов первого типа, хотя могли бы быть все 60. К тому же каждый раз, как появится новая таска, которой нужен доступ к этому ресурсу, придется снова везде пересчитывать все лимиты. Вобщем фича конечно полезная, но только для самых простых вариантов.
Bringing decision
Token Bucket
Решением проблемы для меня стал Token Bucket — алгоритм, использующийся для контроля полосы пропускания канала в компьютерных и телекомуникационных сетях. Опишу его в 2ух словах: пакет данных, чтобы пройти проверку канала на лимит, должен иметь при себе токен, который он взял из хранилища; в то же время в хранилище токены поступают с некоторой частотой. То есть пропускная способоность канала ограничивается скоростью выпуска токенов, которую нам и надо регулировать.
В нашем же случае вместо пакета данных мы имеем таску, а хранилищем токенов будут выступать очереди RabbitMQ.
Wrting some code
Чтож, приступим к написанию кода. Создадим файл main.py и зададим базовые настройки:
Не забудьте развернуть Rabbit, я предпочитаю делать это 1ой строчкой докера:
После этого в консоли раз в секунду начнут появляться сообщения:
Отлично, мы наладили выпуск токенов для нашего ‘ведра’. Осталось только научить наших воркеров из него брать. Попробуем оптимизировать код, который мы написали ранее для запросов в github. Добавим эти строчки к main.py :
А теперь проверим, как это все работает. В дополнение к уже запущенному beat добавим 8 воркеров:
И создадим отдельный маленький скрипт для запуска этих задач, назовем его producer.py :
Несмотря на то, что у нас целых 8 рабочих процессов, таски выполняются примерно раз в секунду, отправляясь в конец очереди, если на момент их выполнения не оказалось токена. Также, я думаю, вы уже заметили, что на самом деле мы накладываем rate limit не совсем на очередь, а скорее на какую-то логически связанную группу задач, которые на самом деле могут находится как в разных очередях, так и в одной. Таким образом наш контроль становится даже более детальным и гранулированным.
Putting it all together
Конечно, количество таких групп задач не ограничено (разве что возможностями брокера). Соберем весь код в кучку, расширим и причешим его:
Таким образом суммарные вызовы задач группы google не превысят 100/мин, а группы github — 60/мин. Заметьте, что для того, чтобы настроить такой throttling, понадобилось меньше 50 строк. Как по мне, достаточно просто.
Moving further
Ну, вот все и работает как надо, причем без каких-либо сторонних примочек, средствами только самого брокера. Но зачем останавливаться на достигнутом ;)? Грамотно используя данный алгоритм, можно пойти дальше и создать намного более сложные и гибкие стратегии. Например, некоторые таски могут брать не 1, а несколько токенов (возможно даже из разных очередей, если обращение идет к нескольким сервисам), таким образом у нас появится понятие ‘веса’ задачи, или же расширить размер нашего ‘ведра’ токенов, позволив им накапливаться, тем самым компенсируя периоды простоя. Вобщем, пространство для маневра просто огромное и ограничено только вашим воображением и инженерными навыками) Всем спасибо, всем удачи!
Как жить с ограничениями внешних API на количество запросов
Многие сервисы предоставляют возможность взаимодействовать с ними не только обычным пользователям через отточенные и оптимизированные графические интерфейсы, но и внешним разработчикам из своих программ через API. При этом сервисам важно контролировать нагрузку на свою инфраструктуру. В ситуации с обычными пользователями большинство проблем с нагрузкой не возникнет из-за контроля кода приложения, отправляющего запросы к сервису, со стороны разработчиков сервиса (пользователей, пытающихся что-то делать в приложении за рамками предложенных разработчиками интерфейсов и задокументированных возможностей, мы в данной статье не рассматриваем). В случае же со внешними разработчиками простор для создания нагрузки на сервис ограничен только фантазией этих самых внешних разработчиков. Чтобы немного ограничить этот простор, стала распространена практика введения ограничений на количество запросов в единицу времени к API сервиса.
Мы уже рассказывали о том, как можно реализовать эти ограничения, если вы сами разрабатываете API сервиса, сегодня хотим рассказать о том, как жить с «клиентской» стороны и удобно пользоваться ограниченным по количеству запросов API.
Вводные данные
Меня зовут Юрий Гаврилов, я работаю в команде Data Platfrom в ManyChat. У нас в компании есть маркетинговый отдел, который, среди всего прочего, любит общаться с нашими клиентами через сервис Intercom, позволяющий отправлять удобные In-App сообщения пользователю прямо в нашем веб-приложении. Чтобы эти коммуникации были осмысленными, Intercom должен получать некоторую информацию о наших клиентах (имя, дату регистрации, различные простые метрики их аккаунтов и т.д.). За предоставление этих данных в Intercom отвечает наш довольно-таки монолитный бекенд-компонент, хранящий информацию о наших пользователях. А ещё, совсем недавно, мы построили классный аналитический контур (о котором обязательно расскажем в следующих статьях), также хранящий кучу информации о наших пользователях, и довольно изолированный от упомянутого выше бекенд-компонента. В этом контуре аналитики обсчитывают более сложные пользовательские метрики, гоняют ML-алгоритмы и хранят витрины с результатами всех этих вычислений. Для ещё более крутых коммуникаций с клиентами, часть из этих результатов также хотелось бы иметь в Intercom.
И тут мы сталкиваемся с проблемой: есть разные, изолированные друг от друга компоненты, желающие делать вызовы внешнего API с довольно сильным ограничением в 1000 запросов в минуту. При этом, ограничение применяется в рамках всего аккаунта Intercom, а не рассчитывается индивидуально для каждого компонента.
Мысли о решении проблемы вслух
Понятно, что хаотичный вызов методов внешнего ограниченного API из разных компонентов когда хочется, может быстро привести к неприятным последствиям. Прогрузка «продвинутых» данных из аналитического контура рано или поздно перебьет и не даст загрузиться важным «базовым» данным из бекенд-компонента, каким бы настойчивым и терпеливым мы его не настроили.
Из-за этого сразу же приходят мысли, что нам нужна «единая точка общения» с этим API, которая будет непосредственно обращаться к API, контролировать исчерпание лимитов и управлять логикой по приоритизации взаимодействия с API. К этой точке, в свою очередь, должны обращаться все желающие взаимодействовать с API компоненты.
Реализация «единой точки общения»
Мы уже говорили, что в ManyChat любят Redis — он же нам помог для решения и этой задачи. Для создания такой «единой точки» нужно где-то собирать информацию о том, какие именно методы хотят вызвать во внешнем API наши компоненты. Если внешние компоненты захотят вызвать методов больше, чем позволено ограничениями API, на момент «передышки», пока не обновятся лимиты, эту информацию нужно где-то хранить. А ещё, нам бы очень хотелось ввести систему приоритетов, чтобы «базовые» данные, которые бекенд-компонент хочет отправить в Intercom, не ждали, пока прогрузится много «продвинутых» данных из аналитического контура.
Все эти проблемы позволяет решить Redis, а точнее структура данных List и реализованные на ней очереди.
На каждый приоритет нам нужно создать по своей очереди, в которую компоненты будут записывать свои намерения вызвать тот или иной метод в API, а один общий consumer будет в порядке приоритетности эти очереди вычитывать и непосредственно вызывать методы API. Если при вызове очереди он сталкивается с достижением rate-limit, он подождет, пока лимиты сбросятся, и продолжит работу.
В нашем случае очереди нужно две — для «базовых» данных из бекенд-компонента (давайте назовем её BackendQueue), и менее приоритетных «продвинутых» данных из аналитического контура (AnalyticsQueue). Прелесть такого подхода заключается также и в том, что совершенно не важно, на каких языках программирования написаны компоненты и consumer, все они смогут выполнять свою работу, нужно только определиться с форматом хранящихся в очереди данных.
Давайте для определенности и простоты примем в этой статье такой формат (JSON):
Тогда MVP нашего consumer’a может выглядеть так (PHP)
Здесь мы разбираем очереди в порядке приоритетов, при получении информации о методе пытаемся его выполнить, если сталкиваемся с лимитами — ждем и пытаемся снова ограниченное количество раз.
А наши компоненты на разных языках программирования могут отправлять запрос на вызов интересующего их метода:
Аналитический контур (Python):
Проблемы метода и их решения
Однопоточность → немасштабируемость
Когда мы попытались перейти на такую систему — всё заработало, данные доходили до Intercom, лимиты не исчерпывались. Но возникла другая проблема — каждое обращение к внешнему сервису занимает какое-то время, и когда все вызовы API «сместились» в один поток, мы совсем перестали доходить до rate-limit, перформанс customer’a был в несколько раз меньше rate-limit’ов, и стало понятно, что нужно всю эту радость как-то распараллеливать. Redis вполне безопасно (в смысле параллельности) позволяет разбирать свои очереди нескольким consumer’ам. В целом, нет никакой проблемы в том, чтобы запустить несколько consumer’ов, описанных выше, на одни и те же очереди и проблемы не будет. Каждый из них будет точно так же с соблюдением приоритетности разбирать очередь и, при превышении лимитов, ждать, пока внешний сервис сбросит лимит, и далее работать снова до исчерпания лимита.
Но мы решили немного ограничить вызовы с нашей стороны, потерять несколько десятков возможных вызовов в пределах лимитов, и не доводить consumer’ов до ситуации, когда внешний сервис сообщает им о достижении лимита вызовов. Для этого мы рассчитали для каждого consumer’а его собственный лимит на количество вызовов в единицу времени, при достижении которого он перестает разбирать очередь и делать вызовы к API до перехода к следующему временному интервалу.
Пример самоконтролирующего лимиты consumer’a (PHP)
Одностороннее взаимодействие с API
Иногда бывает нужно не только вызвать какой-то метод во внешнем API, но и получить и обработать его ответ. Мы же перевели наше взаимодействие компонентов с API в асинхронный формат. Проблема получения ответа от сервера и доведения его до исходного компонента — решаемая. Достаточно дополнить данные о методе, который мы хотим выполнить, данными о callback’e, который consumer’у необходимо выполнить при получении ответа от внешнего сервиса. Мы написали несколько стандартных callback’ов, которые складывают полученные ответы в определенные очереди, из которых компоненты могут их прочитать и обработать самостоятельно.
Внедрение такой структуры взаимодействия, безусловно, менее удобное, чем стандартные блокирующие вызовы методов и получение ответа сразу, но обойтись без такой жертвы нам не удалось.
Что делать, когда запросов становится настолько много, что очереди разгребаются часами/днями/неделями?
Здесь мы точно не волшебники, и запрограммировать свое взаимодействие с внешним API так, чтобы превышать его rate-limit, мы точно не можем. По задачам загрузки данных наших клиентов мы внедрили у себя систему по учету тех данных, что уже были отправлены во внешний сервис. Когда наступает очередная выгрузка данных о пользователях, отправляются только данные о тех пользователях, которые обновились, и, тем самым, уменьшается необходимое количество запросов.
В остальном, в данной ситуации не остаётся ничего иного, кроме как разговаривать со внешним сервисом на тему увеличения лимита запросов.
Заключение
В этой статье мы рассмотрели довольно простой подход к контролю количества запросов к внешнему сервису через API, а также их упорядочиванию, в условиях, когда обращаться к API желают различные несвязанные друг с другом компоненты, а пропускная способность API ограничена.
Надеюсь, что кому-нибудь такой подход окажется полезным и интересным. Буду рад ответить на вопросы в комментариях и узнать, какие подходы для взаимодействия с ограниченными по количеству запросов API используете вы.
Рейт лимиты с помощью Python и Redis
В этой статье мы рассмотрим некоторые алгоритмы рейт лимитов на основе Python и Redis, начиная с самой простой реализации и заканчивая продвинутым обобщённым алгоритмом контроля скорости передачи ячеек (Generic Cell Rate Algorithm, GCRA).
Для взаимодействия с Redis ( pip install redis ) мы будем пользоваться redis-py. Предлагаю клонировать мой репозиторий для экспериментирования с ограничениями запросов.
Ограничение по времени
Первый подход к ограничению количества запросов за период заключается в использовании алгоритма с ограничением по времени: для каждого ограничивающего ключа (rate-key, что-то уникальное, вроде ника или IP-адреса) отдельно хранятся счётчик (изначально задающий предельное значение) и срок действия (период), которые уменьшаются по мере получения запросов.
С помощью Python и Redis можно реализовать этот алгоритм следующим образом:
Можете посмотреть работу этого кода при эмуляции ограничения в 20 запросов в 30 секунд (чтобы было понятнее, я поместил функцию в модуль).
Ограничиваться не будут лишь первые 20 запросов, после них придётся ждать 30 секунд, чтобы снова можно было слать новые запросы.
Недостаток этого подхода в том, что он ограничивает не частоту, а количество сделанных пользователем запросов за определённый период. Если весь лимит будет сразу исчерпан, придётся ждать окончания периода.
Алгоритм текущего ведра (Leaky bucket)
Есть подход, при котором мы можем очень аккуратно ограничивать частоту: это алгоритм текущего ведра. Принцип работы такой же, как у самого настоящего протекающего ведра: мы наливаем воду (запросы) в ведро по самые края, пока какая-то часть воды постоянно вытекает через отверстие в днище (обычно реализуется с помощью фонового процесса). Если количество вливаемой в ведро воды больше, чем количество выливающейся, то ведро наполняется, и когда оно наполнится, новые запросы перестают приниматься.
Можно пропустить этот подход ради более элегантного решения, не требующего отдельного процесса для эмулирования утечки: обобщённого алгоритма контроля скорости передачи ячеек (Generic Cell Rate Algorithm).
Обобщённый алгоритм контроля скорости передачи ячеек
GCRA был создан в телекоммуникационной отрасли, где его называют режимом асинхронной передачи (Asynchronous Transfer Mode, ATM). Он использовался диспетчерах ATM-сетей для задержки или отбрасывания ячеек — маленьких пакетов данных фиксированного размера, — которые приходили с частотой выше заданного лимита.
GCRA отслеживает оставшийся лимит с помощью так называемого теоретического времени прибытия (Theoretical Arrival Time, TAT) каждого запроса:
и ограничивает следующий запрос, если время прибытия меньше текущего ТАТ. Это хорошо работает, если частота равна 1 запрос/период, когда запросы разделены по периодам. Но в реальности частоты обычно вычисляется как лимит/период. Например, если частота равна 10 запросов/60 сек, то пользователю можно будет делать 10 запросов в первые 6 секунд. А с частотой 1 запрос/6 сек ему придётся ждать по 6 секунд между запросами.
Чтобы иметь возможность отправлять в течение короткого периода группу запросов и поддерживать ограничение их количества за период с лимитом > 1, каждый запрос нужно разделить отношением период/лимит, и тогда следующее теоретическое время прибытия ( new_tat ) будет вычисляться иначе. Обозначим время прибытия запроса как t :
В этом случае нам не нужно обновлять ТАТ, потому что у ограниченных запросов нет теоретического времени прибытия.
Теперь соберём финальную версию кода!
Мы воспользовались Redis TIME, потому что GCRA зависит от времени, и нужно убедиться, что текущее время консистентно в течение нескольких развёртываний (расхождение часов между разными машинами может привести к ложно положительным срабатываниям).
Этот код демонстрирует работу GCRA при частоте 10 запросов/60 сек.
Алгоритм не ограничивает первые 10 запросов, но вам придётся ждать не меньше 6 сек, чтобы сделать следующий запрос. Попробуйте запустить скрипт спустя какое-то время и измените величину лимита и периода (например, limit = 1 и period=timedelta(seconds=6) ).
Чтобы сохранить чистоту реализации, я не стал добавлять блокировку между получением и отправкой вызовов. Но она нужна при многочисленных запросах с одинаковым ключом и в одно и то же время. С помощью Lua можно добавить блокировку в виде менеджера контекста.