В январе мы пообещали себе, что к концу полугодия медианный TTFB чтения документа не будет превышать 100 мс ни в одной точке нашего присутствия. На момент обещания медиана по миру была 380 мс, а 95-й перцентиль — 1.2 секунды. К маю мы выехали в 95 мс и 240 мс соответственно. Расскажу, как.
Что было
До перестройки у нас был один origin в Москве и один в Франкфурте, плюс CDN-партнёр для статики (бандлы, картинки, шрифты). Динамика — то есть собственно документы — всегда шла на origin. Это работало, пока 90% пользователей сидели в РФ и ЕС.
В прошлом году подключились клиенты с распределёнными командами: руководство в Дубае, разработчики в Тбилиси, продакты в Лиссабоне, дизайнеры в Ереване. Они ныли. Справедливо.
Что хотели
- держать содержимое документов рядом с пользователем;
- не нарушать гарантии «данные в выбранной юрисдикции» — то есть кешировать только то, что разрешено;
- уметь инвалидировать кеш мгновенно при изменении прав доступа;
- деградировать аккуратно: при выпадении edge-узла пользователь не должен видеть ошибку.
Архитектура
Мы делим запросы на три класса по характеру данных:
| Класс | Что это | Где обрабатывается |
|---|---|---|
| Статика | JS, CSS, шрифты, иконки | CDN-edge, кеш 1 год с хешированными URL |
| Холодные данные | опубликованные документы, медиа | edge-узел с подписью URL, TTL до инвалидации |
| Горячие данные | совместное редактирование, права | origin в регионе пользователя, edge только для туннеля |
«Туннель через edge» — это важная часть. Даже когда содержимое нельзя кешировать (потому что мы не знаем, имеет ли запросивший доступ), сам сетевой путь через близкий edge-узел сильно лучше, чем прямое подключение к Москве из Дубая. Edge поднимает TLS-сессию с клиентом и держит keep-alive до origin — это экономит RTT.
Чем взяли
После долгих сравнений мы остановились на смешанной модели: основные edge — Yandex Cloud (внутри РФ и СНГ) и собственные узлы на Hetzner / VK Cloud в EU. Для специфических регионов (Юго-Восточная Азия, Латам) подключили партнёров. Это не очень дёшево, но даёт гранулярный контроль над тем, что и где кешируется.
Главный урок: «у нас глобальный CDN» — это не про количество точек, а про то, насколько вы готовы отвечать на тонкие вопросы вроде «куда уехала эта конкретная пользовательская сессия в момент инвалидации».
Что было больно
Инвалидация под нагрузкой
Когда автор закрывает доступ к документу, мы должны выбить кеш во всех точках за разумное время. У одного из партнёров инвалидация в самом плохом регионе занимала до 90 секунд. Решили двумя вещами: переходом на короткий TTL для приватного контента и дополнительной проверкой авторизации на самом edge через подписанные токены.
Маршрутизация в смешанных подсетях
Anycast и геомаршрутизация работают хорошо в среднем, но иногда пользователь из Тбилиси попадает на узел во Франкфурте — потому что у его провайдера так настроены пиринги. Мы добавили health-чек со стороны клиента (фоновый ping в редактор) и переключение на лучший edge, если текущий не оптимален.
Метрики
Изначальный мониторинг показывал нам средние значения по миру. Это бесполезно. Перешли на распределение по регионам и провайдерам пользователей. Стало видно, что у клиентов «Билайн Мобайл» в Москве TTFB в два раза хуже, чем у тех же пользователей по проводу — пришлось чинить отдельно.
Что дальше
Сейчас замеряем эффект от подключения H3/QUIC на edge. На мобильных сетях с высокими потерями это даёт заметный выигрыш — особенно для совместного редактирования, где имеют значение не только средние, но и хвост распределения. Если измерения подтвердятся, выкатим в продакшен к концу июня.