В этой статье от разработчиков компании DST Global, описаны различные подходы к защите систем от скрытых узких мест масштабирования, которые могут проникнуть в систему при реализации кэширования.
Кэширование часто реализуется как общее решение, когда мы думаем об улучшении характеристик задержки и доступности вызовов службы зависимостей. Задержка уменьшается, поскольку мы избегаем необходимости совершать обратный путь по сети к службе зависимостей, а доступность улучшается, поскольку нам не нужно беспокоиться о временных простоях службы зависимостей, поскольку кеш обслуживает необходимый ответ, который мы ищем. Важно отметить, что кэширование не помогает, если наши запросы к службе зависимостей каждый раз приводят к отдельному ответу или если клиент делает совершенно разные типы запросов с небольшим перекрытием между ответами. Существуют также дополнительные ограничения на использование кэширования, если наша служба не переносит устаревшие данные.
Мы не будем углубляться в типы, методы и применимость кэширования, поскольку они широко описаны в Интернете. Вместо этого мы сосредоточимся на менее обсуждаемом риске, связанном с кэшированием, который игнорируется по мере развития систем, и это подвергает систему риску масштабного сбоя.
Когда использовать кэширование
Во многих случаях кэширование развертывается для маскировки известных узких мест масштабирования с помощью службы зависимостей или кэширование берет на себя роль, чтобы с течением времени скрыть потенциальный недостаток масштабирования службы зависимостей. Например, когда наша служба начинает реже обращаться к службе зависимостей, они начинают верить, что это норма для стабильного трафика. Если наш коэффициент попадания в кеш составляет 90 %, то есть 9 из 10 вызовов службы зависимостей обслуживаются кешем, то служба зависимостей видит только 10 % фактического трафика. Если кэширование на стороне клиента перестанет работать из-за сбоя или ошибки, трафик службы зависимостей увеличится в 9 раз! Почти во всех случаях такой всплеск трафика приведет к перегрузке службы зависимостей, что приведет к сбою. Если служба зависимостей является хранилищем данных, это приведет к отключению нескольких других служб, зависящих от этого хранилища данных.
Чтобы предотвратить такие сбои, как клиент, так и служба должны рассмотреть следующие рекомендации по защите своих систем.
Рекомендации от разработчиков DST Global
Для клиентов важно перестать относиться к кэшу как к оптимизации, которую «полезно иметь», а вместо этого относиться к нему как к важнейшему компоненту, который требует такого же обращения и проверки, как и обычный сервис. Сюда входит мониторинг и оповещение о пороговом значении коэффициента попадания в кэш, а также об общем трафике, отправляемом в службу зависимостей.
Любое обновление или изменение бизнес-логики кэширования также должно пройти такую же строгую проверку в средах разработки и на этапах подготовки к производству. Развертывания на серверах, участвующих в кэшировании, должны гарантировать, что сохраненное состояние будет передано на новые серверы, которые появятся после развертывания, или падение частоты попаданий в кэш во время развертывания будет приемлемым для службы зависимостей. Если во время развертывания отключается большое количество серверов, обслуживающих кэш, это может привести к пропорциональному снижению коэффициента попадания в кэш, оказывая давление на службу зависимостей.
Клиентам также необходимо внедрить ограждения для контроля общего трафика, измеряемого как количество транзакций на услугу (TPS), к службе зависимостей. Алгоритмы, такие как корзины токенов, могут помочь ограничить доступ TPS к парку, когда парк кэширования выходит из строя. Это необходимо периодически проверять, отключая экземпляры кэширования и наблюдая, как клиенты отправляют трафик в службу зависимостей. Клиентам также следует подумать о реализации стратегии отрицательного кэширования с меньшим временем жизни (TTL). Отрицательное кэширование означает, что клиент будет хранить ответ об ошибке от службы зависимостей, чтобы гарантировать, что служба зависимостей не будет засыпана повторными запросами во время длительного простоя.
Аналогичным образом, на стороне службы необходимо реализовать механизмы распределения нагрузки, чтобы защитить службу от перегрузки. В данном случае перегрузка означает, что служба не может ответить в течение тайм-аута на стороне клиента. Обратите внимание, что по мере увеличения нагрузки на службу это обычно проявляется в увеличении задержки, поскольку ресурсы сервера чрезмерно используются, что приводит к замедлению ответа. Мы хотим ответить до истечения тайм-аута на стороне клиента для запроса и начать отклонять запросы, если общая задержка начинает превышать тайм-аут на стороне клиента.
Существуют различные методы предотвращения перегрузки; Один из самых простых методов — ограничить количество подключений от балансировщика нагрузки приложений ( ALB ) к вашему узлу службы. Однако это может означать неизбирательное отбрасывание запросов, а если это нежелательно, то на уровне обслуживания приложений можно реализовать методы определения приоритетов, чтобы отбрасывать менее важные запросы. Целью сброса нагрузки является обеспечение защиты службы полезного объема, т. е. запросов, обслуживаемых в течение тайм-аута на стороне клиента, по мере роста общей нагрузки на службу. Службе также необходимо периодически запускать нагрузочные тесты для проверки максимального значения TPS, обрабатываемого узлом службы, что позволяет точно настроить ограничение количества подключений ALB. Мы представили несколько методов защиты эффективности услуги, которые должны широко применяться, но есть и другие подходы, которые читатели могут изучить в зависимости от своих потребностей в услугах.
Заключение
Кэширование обеспечивает немедленные преимущества в плане доступности и задержки при низких затратах. Однако игнорирование областей, которые мы обсуждали выше, может выявить скрытые узкие места масштабирования при выходе из строя кэша, что потенциально может привести к сбоям в системе. Регулярное обеспечение правильного функционирования системы, даже если кэш не работает, имеет решающее значение для предотвращения катастрофических сбоев, которые могут повлиять на надежность вашей системы.
