Как #SRE защитить приложение от лишней нагрузки? 🤔
📜Вы наверно видели инциденты, когда все перестало работать из-за внутренней DoS атаки из-за баги в сервисе. Это когда твой сервис 🅰️ предоставляет API и другой сервис
🅱️ к тебе пришел за данными. И вот однажды сервис 🅱️ всеми силами начинает заваливать API сервиса 🅰️ запросами. Тот, бедный, пыжиться, но не может своими мощностями такое прожевать. В итоге сервис 🅱️ не получает данные, а сервис 🅰️ отказывает другим и падает. Кто виноват? 🅰️ потому что был слаб? Или 🅱️ потому что сильно налегал?
🔍Небольшой постмортем. Триггером был излишний трафик сервиса 🅱️. Но ведь и 🅰️ никак не говорил "Хватит, я на пределе". А еще оказалось, что на обращения сервиса 🅱️ вообще не рассчитывали, не ждали его как клиента в 🅰️. Это в итоге создало сбой.
Как от этого защитить приложение?
1. Аутентификация запросов по API ключу.
Зачем? Затем чтобы не было возможности нагружать сервис пока он не готов. В Amazon применяют это так: команда сервиса 🅱️ просит ключ API к сервису 🅰️, команда 🅰️ запрашивает у команды 🅱️ ожидаемую нагрузку в RPS и смотрит хватит ли мощности, если не хватит, то ключ не дают, а планируют работы по доделке сераиса 🅰️ для получения нужной производительности. Когда 🅰️ готов - для 🅱️ выдают ключ API.
2. Ограничение частоты запросов Rate-limiter.
Тут можно сразу всем кто без API ключа долбит дать очень маленький лимит, чтобы видеть таких "новых" клиентов, но не давать им перегружать сервис.
Как думаете это излишние меры? Есть ли иные способы?
#практики #нагрузка #разработчику #микросервисы
Post #42
95