Как в Gas уменьшили нагрузку Redis на CPU на 80%

Когда вы растете на 100% каждый день, кризис случается почти каждый час, но Дэйв Шац и Исайя Тернер смогли не дать кораблю Gas утонуть. Вот взгляд изнутри на эту победу.

Сегодня мы уменьшили загрузку CPU Redis Engine на 80% и выжили, чтобы получить еще один день на развитие.

Мы были ограничены в ресурсах ЦП и исчерпали пределы масштабирования для нашего кластера ElastiCache. У нас было 2 часа на то, чтобы снизить нагрузку до следующего всплеска трафика, иначе бы мы прогорели.

Что мы сделали?

Во-первых, мы подключились к нашему кластеру через redis-cli и запустили MONITOR, чтобы определить ключевые префиксы, используемые с наибольшей частотой.

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

Предположение: значения Redis HASH хранятся внутри с использованием структуры данных ziplist. В нашей конфигурации виновником потребления CPU при таком масштабе может быть де/сериализации.

Мы переместили эти ключи в новый кластер и увидели выигрыш ЦП на 2%.

Это не то.

Новое предположение: у нас есть агрессивное кэширование для большинства наших запросов к БД. Все эти команды GET/SET/DEL/EXPIRE.

Перемещение этого в наш новый кластер должно помочь, верно?

Это принесло нам дополнительный выигрыш ЦП на 1.5%.

Все равно не то.

Нам нужно было больше информации. Где была проблемная зона? Конкретный шард?

Мы выполнили запрос CloudWatch, чтобы составить график разбивки Engine CPU Utilization по нодам в кластере. Одна нода выделялась загрузкой 50%, а другие — около 12%.

Теперь мы на что-то наткнулись.

Новое предположение: может быть, есть часто используемый большой ключ или операция (скрипт Lua / EVAL), которые тормозят эту ноду?

Мы подключились напрямую к этому узлу и провели анализ самых больших ключей.

БИНГО.

Мы определили один ключ, SET с ~ 90 000 членами и ростом! Хуже того, мы получали всех участников (SMEMBERS) для этого SET в большинстве наших запросов!

Даже больше, этот SET продолжал увеличиваться в размерах из-за общих действий в приложении — а нам даже не нужны были и не использовались его значения!

Провели быстрый тест: жестко закодировали возвращаемое значение для этого конкретного ключа, что привело к мгновенному снижению загрузки ЦП на 80%. Мы исправили основную причину и предоставили себе достаточно места для масштабирования!

Надеемся, что наш процесс отладки поможет другим устранить такие же проблемы в большом потреблении ресурсов процессора в Redis.