В современном мире высоких технологий и стремительного роста онлайн-сервисов, масштабирование систем кэширования становится одной из ключевых задач разработчиков и инженеров по данным. Компания 7shifts, специализирующаяся на упрощении управления командами в ресторанной индустрии, столкнулась с необходимостью масштабировать свой кэш на базе Redis в условиях быстрого роста клиентской базы и нагрузки на системы. Эта история технических решений и сложностей, с которыми они столкнулись в 2023 году, несет в себе множество ценных уроков для специалистов, работающих с распределенными системами и кэшированием. Первыми шагами в развитии 7shifts был отказ от кэширования на уровне приложений. Все данные, включая сессии пользователей, напрямую сохранялись и извлекались из основной базы данных.
Такой подход позволял поддерживать архитектуру максимально простой, а масштабирование происходило за счет увеличения ресурсов БД. Однако в условиях роста компании это перестало быть эффективным – нагрузка на базу стала слишком высокой, и стал вопрос о внедрении кэширования для снижения давления на базу данных. Выбор пал на Redis, поскольку этот инструмент давно зарекомендовал себя как надежный и производительный сервис для кэширования данных. Сначала был реализован классический подход: модели, которые требовали дорогостоящих запросов, начали кэшироваться. Это существенно улучшило производительность приложений и снизило нагрузку на БД, подтвердив правильность направления.
Визуализация архитектуры показывала простую схему с одним экземпляром Redis, к которому обращалось монофоничное PHP-приложение. Однако скоро появились новые проблемы, связанные с тем, как именно это приложение взаимодействовало с Redis. Каждый запрос открывал и закрывал собственное соединение с Redis, что на небольших объемах нагрузки не влияло существенно. По мере роста нагрузки число таких соединений стремительно увеличивалось, вызывая рост задержек и ухудшение производительности. Решением стала интеграция прокси-сервера для управления пулами соединений.
7shifts выбрал Twemproxy, который позволил минимизировать накладные расходы на установку соединений с Redis, существенно снизив латентность и стабильнее выдерживая пиковые нагрузки. Летом 2023 года рост числа клиентов 7shifts ускорился, что вызвало возросшую нагрузку на базу данных, в частности по показателю загрузки CPU, приближающемуся к 90%. Масштабирование БД путем перехода на более крупный тариф не рассматривалось как первоочередное решение, так как существовала вероятность быстрого достижения предельных ресурсов. Поэтому разработчики решили увеличить объем данных, находящихся в кэше, что по идее должно было разгрузить базу. Но неожиданно отказавшись от осторожности, они заметили рост задержек, несмотря на снижение нагрузки по CPU, заставив их откатить изменения.
Изучая проблему глубже, команда обратилась к показателям Redis. Процесс мониторинга здесь фокусировался на двух основных метриках: потреблении памяти и загрузке CPU. В то время как памяти оставалось достаточно, CPU Redis превысил отметку в 100%, показывая, что нагрузка превышает возможности одного потокового процессора. Это было критично, так как Redis исполняется в одном потоке и не может использовать несколько ядер для повышения производительности. Для решения проблемы было исследовано несколько путей.
Среди них – переход к Redis Cluster с шардированием данных. Эта опция обещала распределение нагрузки по нескольким экземплярам Redis с автоматическим шардированием. Однако при использовании облачного MemoryStore от Google Cloud Platform, который в момент начала работ еще не поддерживал Redis Cluster, этот вариант стал недоступен. Вторым вариантом стали read-реплики Redis, доступные в GCP, но их внедрение требовало усложнения логики приложения, чего хотели избежать разработчики для сохранения простоты и удобства конфигурации. Шардирование с переносом логики в приложение рассматривалось, но также рассматривалось как слишком сложное и трудоемкое.
Тогда команда обратила внимание на идею клиент-ориентированного шардирования через прокси, основываясь на опыте Envoy – современного прокси с поддержкой продвинутых конфигураций. Использование Envoy в качестве прокси дало несколько преимуществ. Во-первых, оно позволило отделить логику шардирования от приложения, сохранив для разработчиков привычную и простую конфигурацию. Во-вторых, инфраструктурная команда получила полный контроль над масштабированием, меняя настройки прокси, а не обновляя код приложений. Замена Twemproxy на Envoy была относительно простой и заметной.
Внедрение Envoy привело к мгновенному снижению загрузки CPU Redis и уменьшению задержек приложений, что стало приятным бонусом и для команды разработчиков, и для пользователей. Секрет такого роста производительности частично мог крыться в поддержке Redis протокола более новой версии, но детальное исследование причин не было приоритетом – улучшение было очевидно. Дальнейшим шагом стал запуск шардирования по схеме client-side с помощью Envoy. В 7shifts было развернуто три небольших инстанса Redis вместо одного большого. Они были объединены в отдельный кластер и конфигурировались через прокси Envoy, используя функцию зеркалирования запросов, позволяющую одновременно записывать данные во все инстансы.
При этом учитывался TTL кэша, что позволило безопасно мигрировать данные в течение суток. Однако при переходе на новую архитектуру возникла новая сложность – неравномерная загрузка CPU на разные шардовые инстансы. Выяснилось, что это объясняется наличием "горячих" ключей, к которым обращаются чаще всего, и которые концентрируются на одном из инстансов, используя больше ресурсов. Для решения этой проблемы было введено понятие "ключей с высоким трафиком" (high frequency keys). Такие ключи помечались специальным префиксом в приложении.
Envoy при записи таких ключей направлял данные во все шардированные инстансы, а при чтении использовалась политика round robin для равномерного распределения нагрузки. Это позволило существенно сгладить пики загрузки CPU и оптимизировать работу кластера Redis. Опыт 7shifts демонстрирует, что масштабирование Redis – сложный, но выполнимый процесс, требующий глубокого анализа метрик, постоянного мониторинга и готовности экспериментировать с архитектурными решениями. Важным является сохранение баланса между простотой в использовании для разработчиков и эффективной нагрузкой на инфраструктуру. В конечном счете, подход команды 7shifts можно считать успешным примером внедрения продвинутого кэширования в условиях быстрорастущего веб-приложения.
Использование Envoy как прокси для шардирования Redis позволило не только снизить нагрузку на базу данных и улучшить производительность, но и сохранить архитектурную простоту и минимизировать изменения в коде приложения. Этот кейс также подчеркивает важность адекватного мониторинга, который позволил выявить проблему с "горячими" ключами своевременно и предложить уникальное решение. Такой положительный опыт масштабирования Redis может стать полезным руководством для других компаний, сталкивающихся с вызовами при росте пользовательской базы и нагрузки на кэш-системы. Несомненно, будущее Redis и его экосистемы связано с более широкой поддержкой кластеризации и многопоточности, что позволит системам кэширования выдерживать растущие требования бизнеса и технические вызовы с меньшими затратами ресурсов. Однако пока компаниям приходится искать творческие решения, применяя прокси, клиентские шардирования и особые оптимизации ключей.
Опыт 7shifts в масштабировании Redis ценен тем, что он показывает настоящий путь от простого к сложному, от проблем к решению без лишних усложнений в приложении. Это практический пример того, как грамотный подход к инфраструктурным изменениям и своевременный мониторинг позволяют избежать узких мест и обеспечивают масштабируемость, высокую производительность и удовлетворенность конечных пользователей.
