Как я спасал Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок

Значимый прорыв формирует отрасль ИИ: AlexanderTereta 54 минуты назад Как я спасал Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок Средний 9 мин 2. 2K Magento * Веб-разработка * Серверная оптимизация * Высоконагруженные системы * Разработка под e-commerce * Кейс Из песочницы Технологический стек:Magento 2. 4MariaDBRedisVarnishOpenSearchРазмер проекта:~1,000,000 товаров~3,000 категорий~10,000,000 CMS страницПроблема:504 ошибки под нагрузкой поисковых роботовВысокая нагрузка на MariaDBНестабильный FPC hit ratioГод:2022Let's go!

Сразу оговорюсь: события происходили в 2022 году. На тот момент я не планировал вести блог, поэтому полноценные метрики из Grafana уже не сохранились. Но часть заметок осталась в старых тикетах, поэтому основные цифры и решения получилось восстановить.

Технические детали

Магазины с каталогом порядка 1 000 000 товаров, особенно на Magento 2, уже сами по себе задача не простая. А если добавить к этому ~ 3 000 категорий и более 10 000 000 CMS-страниц, можно представить, что происходит во время пиковых нагрузок и активного налета краулеров. На старте инфраструктура выглядела как по статьям: Magento 2, Redis, Varnish и OpenSearch.

Все компонентные слои были настроены в соответствии с рекомендациями по оптимизации Adobe Commerce / Magento. Но во время активного обхода сайта клиентами с user-agent'ами вроде Googlebot/2. 0 (bingbot), а также многочисленными менее известными пауками, ситуация переросла в пожар.

К этому всему, пиковые нагрузки пользовательского трафика, особенно в акционные дни. Результат этого всего: 504 ошибки, высокая нагрузка на базу данных и MariaDB, которая только и пыталась выжить под этим напором. Для оценки объёма Full Page Cache я посчитал примерный теоретический максимум.

Отраслевые последствия

На проекте медианный размер HTML-страниц составляла около 100 KB. Считаем:~1,000,000 товаров~3,000 категорий~10,000,000 CMS-страницВсего: ~11,003,000 приблизительно страниц11,003,000 × 100 KB = 1,049 GB ≈ 1 TBКонечно, это теоретический максимум. На практике весь этот объём никогда одновременно не окажется в кеше: часть страниц устаревает имея TTL, часть вытесняется, часть просто не запрашивается.

Тем не менее именно от таких цифр я отталкивался при перепроектировании системы кэширования и выборе стратегии работы с FPC. RedisMemory crashВозникает вопрос: сколько денег будет стоить хранение такого объема данных в Redis и вообще в RAM? Даже если отбросить теоретический максимум в 1 TB данных для Full Page Cache (а мы его значительно режим и будем мониторить), остается очевидная проблема: Redis нужен не только для FPC.

В нём также должны храниться сессии пользователей, системный кеш Magento, конфигурация, layout, block_html и другие данные. Поэтому идея масштабировать инфраструктуру за счёт постоянного увеличения объема RAM выглядела не экономно, особенно с технической точки зрения. Метрики Redis в Grafana лишь подтверждали это.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.