Бессерверное Управление. Как Избежать «Повторных Попыток» В Распределенных Сервисах?

«Шторм повторных попыток» возникает, когда клиенты настроены на повторную попытку заданное количество раз, прежде чем отказаться от нее. Политика повторных попыток необходима, поскольку при нормальной работе службы произойдет потеря пакетов.

Возьмем этот пример:

Если, например, службы в целом были масштабированы для поддержки 80 000 запросов в секунду и работали примерно на 80 % мощности, всплеск трафика, из-за которого служба получала 101 000 запросов в секунду, привел бы к сбою 1 000 из этих запросов.

Когда вступают в силу политики повторных попыток, вы получаете дополнительно более 1000 запросов, в зависимости от того, где был обнаружен сбой, что приведет к увеличению скорости службы в целом до 102 000 запросов в секунду - после этого ваша служба переходит в смертельную спираль, удваивая это число. неудачных запросов каждую секунду.

За исключением массового избыточного предоставления услуг сверх прогнозируемого пика транзакции, что было бы неэффективно. Какие стратегии вы можете использовать, чтобы избежать «повторных штормов»?

#бессерверные #облако #распределенные системы

Это зависит от того, чего вы пытаетесь избежать.

Если вы пытаетесь избежать каких-либо прерываний обслуживания чего-то, что является действительно критически важным сервисом (я думаю в терминах «люди умрут, если мой вызов API не будет обработан должным образом»), вам нужно просто заложить в бюджет огромную неэффективность, которая происходят из-за чрезмерного выделения выделенных ресурсов. И да, они должны быть выделены, ничто из этого не допускает всплесков трафика, поэтому всплеск нескольких услуг может привести к сбою.

В далеко Более вероятный сценарий, когда у вас отключится служба, будет неудобным, вы можете решить проблему как со стороны клиента, так и со стороны сервера. Хотя стоит отметить, что на самом деле решить проблему слишком большого трафика логически невозможно, поскольку без обработки трафика (который потребляет ресурсы) вы не можете знать, повторная ли это попытка, повторная ли это повторная попытка запроса, который был успешным, но был неправильно обработан. со стороны клиента, если это DDOS и т. д. Но вы может смягчить воздействие.

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

Для вашего серверная часть инфраструктуру. Самое простое решение — дросселировать. Жесткие ограничения на запросы, особенно если вы можете попытаться распределить их логически на основе вашего конкретного варианта использования (т. е. если у вас есть централизованная служба, принимайте некоторые трудные решения, хотите ли вы начать блокировать географически удаленные запросы, которые могут привести к зависанию потоков? Или вы хотите равномерно распределить неизбежные, но незначительные сбои и т. д.) По сути, это сводится к тому, что намеренно вернуть 503 со шлюза намного дешевле, чем позволить запросу пройти и отправить 504? в любом случае. По сути, вы заставляете клиентов вести себя в соответствии с тем, что вы в данный момент можете предоставить, и даете правильные ответы, чтобы клиенты могли реагировать соответствующим образом.

Одним из способов предотвращения таких повторных попыток является использование механизмов отсрочки.

Из Реализация отсрочки при повторной попытке раздел Google App Engine Масштабное проектирование гид:

Ваш код может повторить попытку в случае неудачи, независимо от того, вызываете ли вы такую ​​службу, как Облачное хранилище данных или внешний сервис с использованием URL-адреса или сокета.