Управление кэшированием на сайте ВСК

В этой статье мы расскажем про управление кэшированием сайта. Казалось бы, это вещь сугубо техническая и бизнес от нее далеко. Но это не так и вот почему:

1.            Сайт ВСК активно развивается и контент постоянно меняется. Но текущие версии Nginx, используемые ВСК, и в общем архитектура решения не позволяет затирать кэш и видеть обновления на сайте мгновенно. Как отключить кэширование? Для этого нужна отдельная функциональность «сбрось кэш везде по одной кнопке».

2.           Команда ВСК сама частично развивает фронтенд, и онбординг нового специалиста в эту тему всегда отнимал много сил и времени.

3.           В рамках реализации тех. стратегии мы обновили версию Angular с 12 до 17. А она уже «не дружит» с текущим движком SSR. А значит, пришло время провести небольшой рефакторинг архитектуры в целом и работы с фронтендом в частности.

Сначала расскажем о текущей схеме обработки запросов на сайте, чем она сложна и как она работает.

При входе на страницу клиенту сначала отдаётся html, затем на страницу добавляются поведение и assets с помощью JavaScript, при этом вложения и картинки берутся из CMS.

Работа проходит под нагрузкой 100 запросов в секунду в обычное время и до 500–800 во время атак (которые случаются регулярно).

В текущей архитектуре сайта три ключевых компонента:

·             SSR движок – рендерит страницы на сервере на основе данных из CMS и отдает клиенту сформированную html для целей SEO (не все поисковые роботы умеют работать с JavaScript)

·             Фронтенд – который состоит из оболочки Shell и приложения микрофронтенда MFE. Кстати, микрофронтенды - это отличный инструмент для того, чтобы сложный сайт разделить на разные модули и его развивать. 

·             CMS Directus – система управления контентом, содержит контент, который хранит в базах Minio изображения и файлы и в Postgress данные. Подробнее о нашей работе с headless CMS мы писали в одной из статей. 

Масштабирование SSR движка и CMS требует большого количества ресурсов. Вместо этого для оптимизации нагрузки используется несколько уровней кэширования.

Кэши, считая от клиента (браузера):

1.            Nginx - кэширует js и assets, время жизни 30 минут

2.           Redis для html, которые генерирует SSR движок, время жизни 30 минут

3.           Redis для шаринга между подами Directus

Реализованная ранее конфигурация позволяет переживать пики нагрузки, но появляется 3 проблемы:

1.            После обновления контента или фиче флагов нужно сбрасывать кэш на всех экземплярах Nginx, при этом нет возможности им управлять - для сброса рестартят все поды, сбросить общий кэш CMS в Redis и не забыть про кэш для html.

2.           Нет инструмента, чтобы сбросить кэш по отдельной коллекции в Directus. Нужно сбрасывать весь и везде, при этом запускается прогрев кэша – скрипт, который обходит все страницы, нагружая SSR движок и Directus.

3.           Делать это надо в четкой последовательности, иначе можно получить частично неработающий сайт. А сбрасывать кэш приходится довольно часто – контент обновляется постоянно.

Решение:

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

1.            Вместо отдачи поисковым роботам html они будут перенаправляться на отдельный сервис botview, который отдает им сформированную облегченную страничку без картинок и js.

Вместе с SSR уйдет один уровень кэширования.

Новая схема выглядит так:

 2.           Перенесли кэширование на уровень ниже, чтобы все поды с Nginx получали уже закэшированные данные.

Остановились на двух схожих инструментах:

·             Souin

·             Apache Server mod_socache

Для них мы собрали рабочие версии, которые сейчас тестируем.

Если не вдаваться в подробности, то оба сервиса кэшируют все ответы на GET запросы и складывают их в Redis. При этом мы можем сбрасывать весь кэш при необходимости в CMS

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

·             Снизить порог входа в проект для разработчиков

·             Сократить время на сопровождение при релизах

·             Обновлять отдаваемый сайтом контент условно мгновенно