В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.
Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами
CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.
Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи
Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.
Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи
Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.
Это является ключевым принципом устойчивости и эффективности при гипермасштабе.
Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов
В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps