Відеосайт із високим трафіком скоротив кількість запитів до бази даних для стрічки трендових сторінок із 4 000 на хвилину до менше ніж 50 і знизив час відповіді на рівні 95-го перцентиля з 380 мс до 40 мс, перейшовши від кешування цілих сторінок до фрагментарного кешування за допомогою Varnish та Edge Side Includes (ESI).

Чому сайту знадобилася інша стратегія кешування

Головна сторінка, на якій відображаються найпопулярніші кліпи дня, виглядає майже однаково для кожного відвідувача в регіоні: близько 95 відсотків HTML-коду є ідентичним для мільйона користувачів, тоді як решта 5 відсотків містить персональні дані, такі як ім'я авторизованого користувача або поле пошуку. Команда інженерів зіткнулася з двома небажаними варіантами:

  • Кешувати всю сторінку та ризикувати показом застарілих персональних даних авторизованим користувачам.
  • Повністю обходити кеш і дозволяти кожному запиту перевантажувати базу даних.

Обидва підходи псували користувацький досвід. Команда звернулася до ESI — технології, яка дозволяє реверс-проксі збирати сторінку з незалежно кешованих фрагментів на межі мережі (edge).

Як було налаштовано фрагментарне кешування

Varnish, HTTP-прискорювач із відкритим вихідним кодом, сприймав сторінку як скелет із трьома частинами, що підлягають заміні:

  • Сітка відео — дорога для обчислень, масштабована на весь регіон, черга трендових відео. Кешується на 60 секунд, оскільки часто змінюється, але є однаковою для кожного анонімного відвідувача.
  • Перемикач мов — статичний елемент інтерфейсу, який змінюється рідко. Кешується на 24 години.
  • Хедер — єдиний справді персоналізований фрагмент (ім'я користувача, аватар, сповіщення). Ніколи не кешується; Varnish щоразу перенаправляє запит на сервер застосунку.

Коли надходить запит, Varnish видає кешований скелет, дістає два кешовані фрагменти зі свого локального сховища та вставляє «живий» хедер із бекенду.

Цифри, що мають значення

Після переходу:

  • Навантаження на базу даних для трендинг-сторінки впало з 4 000 запитів на хвилину до менше ніж 50.
  • Затримка на рівні 95-го перцентиля знизилася з 380 мс до 40 мс.

Три практичні уроки впровадження

1. Періоди поблажливості (grace periods) згладжують промахи кешу Коли термін дії TTL фрагмента закінчується, Varnish зазвичай робить паузу, щоб отримати свіжий контент, що створює стрибок затримки, який може перерости в ефект «громового гуркоту» (thundering herd) одночасних викликів до бекенду. Завдяки налаштуванню періоду поблажливості (grace period), Varnish продовжує видавати застарілий фрагмент, поки непомітно оновлює кеш у фоновому режимі. Користувачі не помічають паузи, а бекенд отримує стабільну, керовану частоту запитів.

2. Видаляйте cookies для анонімних фрагментів Cookies, що додаються до кожного запиту, змушують Varnish вважати кожен запит унікальним, що нівелює переваги кешування. Команда видаляла cookies для сітки відео та перемикача мов, що дозволило агресивно кешувати ці фрагменти. Тільки фрагмент хедера містить cookies, зберігаючи персоналізацію без втрати ефективності кешування.

3. Суррогатні ключі дозволяють миттєве очищення Іноді відео потрібно видалити негайно — наприклад, з міркувань авторського права. Чекати закінчення 60-секундного TTL неприпустимо. Позначивши кожен кешований фрагмент суррогатним ключем, який відображає ID відповідних відео, команда може надіслати одну команду очищення (purge), яка миттєво анулює всі копії конкретного відео на кожному edge-вузлі. Це дозволяє уникнути повного очищення кешу та забезпечує відповідність правилам.

Підсумок: Фрагментарне кешування з використанням Varnish та ESI перетворює монолітну сторінку, прив'язану до бази даних, на набір легких, багаторазових частин, різко знижуючи навантаження на бекенд і затримку, зберігаючи при цьому персоналізацію для кожного користувача.