#sre #ratelimits #кулстори представьте, сидите вы как всегда никого не трогаете, и тут инцидент - все горит, пришла слишком большая нагрузка на систему. каким-то образом удается потушить и сразу переносимся на стадию разбора инцидента. идет брейшторм по тому как выстраивать защиту от таких бед и тут какой чрезвычайно опытный и достопочтенный инженер говорит: "да давайте просто рейтлимиты бахнем и сё!?". ну а мы с вами давайте разбираться, есть ли у нас причины не бахнуть рейтлимитов то? а они есть: 1. если рейтлимитить запросы в лоб - например 1000 рпс, то вы рискуете разрушить пользовательскую сессию в абсолютно неудачном месте. представим что 1001 запрос всегда будет авторизацией, все работает а она нет, во чудеса. 2. хорошо, а может как-то per IP сделаем? плохая идея - большие кампусные сети, где тысячи сотрудников за одним айпи вас удивят и ботов в ботнете делают так много, чтоб рейтлимит их не видел. 3. тогда по умному прокинем сессию юзера во все сервисы, и не будем пускать новых пользователей если системы перегружены? ну вот это уже не дурно, но это уже целый admission control и все равно есть еще ряд проблем. 4. текущие рейты надо где-то хранить, а еще проверять на каждый запрос иначе вы при каждом горизонтальном масштабировании ваших реплик апигейтвея или балансировщика будете повышать суммарные лимиты. 5. ну и если вы их храните и проверяете на каждый запрос, будьте готовы что ваши стейтлес сервисы станут очень зависимы от базы данных/кэша в которых рейты будут жить и этот поход добавит латенси вашим пользователям и станет потенциальным узким местом. 6. финальная проблема - за рейт лимитами надо следить, адаптировать и менять с течением времени и внезапно приходящая легитимная нагрузка, которая упоролась в забытый рейтлимит это крайне распространенный кейс. как готовить рейтлимиты? (спойлер: не просто) 1. адаптивный троттлинг (лимиты на основе p99 latency/CPU usage) - забываем статические лимиты, не забываем вкручивать еще burst лимиты и скользящее окно 2. контекстные рейтлимиты по юзер сценарию (авторизованные и неавторизованные, на странице платежки или только проходят онбординг) 3. все обмазываем метриками и алертами 4. а лучше использовать такие практики как: tarpit/backpressure с повышением латенси вместо дропов, circuit breaker, deadline propagation, fail fast на гейтвеях, graceful degradation и retry budget. про них будет в следующих сериях! давайте ответим достопочтенному инженеру, что мы серьезно подумаем над его предложением и с ходу не будем пока ничего бахать :) а на досуге почитать: https://developers.google.com/speed/protocols/trickle_tech_report.pdf https://aws.amazon.com/ru/blogs/architecture/rate-limiting-strategies-for-serverless-applications/