Тонкости архитектуры in-memory: сколько стоит Redis-кластер и чем тут поможет Dragonfly

В Рекламной платформе мы эксплуатируем более 90 Redis-кластеров (>25 из них в проде), и они постоянно растут: крупнейший уже перешагнул 2 ТБ в хранимых данных (что занимает 8 ТБ RAM суммарно на сотне хостов) - это миллиарды ключей. Наши кластеры самые требовательные к памяти во всем Wildberries. В процессе обслуживания таких кластеров мы поняли, что модель масштабирования Redis через шарды упирается в две системные проблемы. Во-первых, ресурсы греют воздух: под данные приходится закладывать в среднем в 4 раза больше памяти, чем они занимают, а CPU при этом простаивает — на наших объемах это перестает влезать в разумный бюджет. Во-вторых, сложность администрирования только возрастает: раскатка изменений на десятки хостов идёт часами, а решардинг может растягиваться на неделю. Мы разобрали архитектурные решения, которые использует Dragonfly как in-memory хранилище, и на нагрузочных тестах сравнили его с Redis по времени обработки запросов и использованию памяти. Результаты убедили рискнуть и проверить Dragonfly на реальных сервисах в проде - делимся тем, что получилось. Слушатели узнают: - почему кластер на 100+ нод и 8 ТБ RAM - проблема в инфраструктуре, и как его превратить в две железки (не жертвуя вместимостью и latency); - какие метрики реально показательны при тестировании in-memory хранилищ и как рассчитать ресурсы будущего кластера; - чем Dragonfly отличается от Redis архитектурно и сколько это экономит ресурсов на практике; - в каких сценариях переход на Dragonfly оправдан, а когда лучше остаться на Redis.