Когда вы растете на 100% каждый день, кризис случается почти каждый час, но Дэйв Шац и Исайя Тернер смогли не дать кораблю Gas утонуть. Вот взгляд изнутри на эту победу.
Речь идет о Gas — приложении для анонимного общения, предназначенном для тинейджеров и молодых людей, которые слишком застенчивы, чтобы разговаривать с другими, и вместо этого хотят спрятаться за экраном. Оно принадлежит создателю tbh, который был приобретен Facebook, а затем закрыт через несколько месяцев, и почти полностью копирует его.
Сегодня мы уменьшили загрузку 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.