Kubernetes Patterns (Рубрика #Architecture)

В последнее время я читаю много информации про Kubernetes для прохождения повторной сертификации.
Среди читаемого есть как мануалы с официального сайта, так и интересные книги с платформы O'Reilly и даже playbook'и от katacoda.com.
Но сегодня я решил всвпомнить про книгу "Kubernetes Patterns", которая не так полезна в сертификации, как в понимании того, какие абстракции дает K8s разработчикам в построеннии их сервисов.
По структуре книга напоминает классическую книгу “Design Patterns” банды четырех, которая содержала creational, structural и behavioral паттерны. Но у нас здесь 5 категорий паттернов:
- Foundation patterns - базовые блоки k8s, на основе которых строится все остальное
- Behavioral patterns - поведенческие паттерны, которые позволяют добиться желаемого поведения, например, запуска периодических job или приложения синглтона
- Structural patterns - структурные паттерны, которые показывают как можно расширить функционал основного контейнера добавив другие контейнеры в pod
- Configuration patterns - конфигурационные паттерны, которые позволяют эффективнее управлять конфигурацией ваших приложений
- Advanced patterns - продвинутые паттерны, которые раскрывают темы того, как работает сам k8s и как его можно расширять

Подробнее можно почитать в статье в моем блоге

#Software #Infrastructure #Kubernetes #Patterns #Architecture #DistributedSystems

Вчера я получил отбивку о том, что успешно сдал экзамен CKA (Certified K8s Administrator Exam) и сразу после этого решил написать обзор по отличному курсу подготовки к этому экзамену от Sander van Vugt. Курс доступен на платформе O'Reilly, в нем 11 часов видео и при большом желании его можно успеть посмотреть за 1 день. Краткий обзор курса в статье - https://bit.ly/CKAPrepCourse

А теперь кратко зачем я заморочился с изучением деталей K8s и сдачей экзамена, в котором надо решить 17 практических задач за 2 часа
Я считаю, что K8s достаточно интересно спроектирован
- декларативное описание целевого состояния вместо императивного
- концепция control loop’ов для поддержания состояния
- подход с тотальным decoupling частей k8s (labels и концепция селекторов)
- отличный способ для имплементации 12 factor app
- крутой пример проектирования с продумыванием точек расширения
...

Рекомендую изучение K8s для улучшения понимания как проектировать системы
#Kubernetes #Infrastructure #Architecture #Software #ExternalReview

Kubernetes: The Documentary (Рубрика #Infrastructure)

Посмотрел сегодня документальный фильм про Kubernetes, который рассказывает как этот оркестратор появился и как стал стандартом де-факто для оркестрации контейнеров.
Фильм получился очень интересным и показал, что
- для захвата доли на cloud рынке Google пришлось придумать что-то новое
- это что-то новое решили делать по моделе Open Source и в итоге создать отдельную структуру Cloud Native Computing Foundation и задонатить в нее
- совместная работа разных заинтересованных лиц RedHat, Google, ... помогла проекту влючить разный опыт участников и совместно двигать проект вперед
- успешный пилот с Pokemon Go, инфраструктура которого была развернута поверх K8s, показал, что оркестратор имеет большие перспективы
- ну и еще ряд интересных моментов, например, размер изначальной команды в несколько человек или очень камерный первый Kubecon:)

В общем, смотреть было интересно. Фильм состоит в сумме из двух частей (1 и 2), которые в сумме составляют порядка часа

#Kubernetes #Film #Documentary #Software #DistributedSystems #Architecture #Engineering

Retrospective on "In-Datacenter Performance Analysis of a Tensor Processing Unit" (Рубрика #AI)

Интересная заметка на две страницы про то, как и почему появился TPU в Google, продолжая тему прошлого поста про железо для ML/AI. TPU оказался отличным решением и поддерживал продуктовизацию deep learning инициатив внутри Google уже 10 лет подряд, начиная с начала 2015 года, когда он появился в проде. Завтра будет заметка побольше про всю историю эволюции TPU, а для завтравки рекомендую прочитать этот мини whitepaper, где есть такое объяснение старту проекта

A key signal soon afterward was that matrix multiplication exceeded 1% of CPU fleet cycles in Google Wide Profiling. Another signal was the analysis by Jeff Dean (a Google Fellow, now the Chief Scientist) that processing a few minutes of speech or video by 100M users would require doubling or tripling the size of the CPU fleet. Other options were clearly required.

#AI #Infrastructure #Engineering #Architecture

[1/2] История появления Google TPU и их эволюции (Рубрика #Engineering)

Буквально вчера я рассказывал про доклад "CodeFest Russia: Куда катится железо для нейронок?", а сегодня я решил рассказать про то, как у Google появились свои процессоры для перемножения матриц. Собственно все начиналось еще в начале 2000х годов, когда Google активно внедряла ML модели к себе в продукты (поиск, переводчик, фото). Они делали это настолько успешно, что с появлением сложных нейронных сетей (а мы помним феерию с CNN сетями и ImageNet в 2012) захотели внедрить и их к себе в продукты, но вычислительная мощность как обучения, так и инференса расла экспоненциально. В 2013 году Google осознали, что если ничего не менять, то придется удваивать количество датацентров на существующем оборудовании (существующих тогда CPU и GPU). В итоге, ребята подумали и придумали проект создания TPU с такими целями
- Создать Application-Specific Integrated Circuit (ASIC), который обеспечит 10-кратное преимущество в соотношении стоимость/производительность при выполнении инференса по сравнению с GPU
- Построить решение быстро (ASAP или в сжатые сроки)
-Достичь высокой производительности на масштабе с новыми рабочими нагрузками "из коробки", оставаясь при этом экономически эффективным

Досталось рулить проектом Норману Джупи (Norman "Norm" Jouppi), выдающийся компьютерный архитектор и Google Fellow. Норман до этого успел отличиться в проектировании MIPS процессоров. А непосредственно до Google он он работал в HP Labs, где руководил лабораторией передовых архитектур. Интересно, что по словам Джонатана Росса, одного из первых инженеров TPU (впоследствии основателя компании Groq), три отдельные группы в Google разрабатывали ИИ-ускорители, но именно дизайн TPU был в итоге выбран для реализации.

Если говорить про результаты, то они получились хорошими, особенно, если учесть то, что уже доступна седьмая версия TPU. А вот как они выглядили в динамике (я ориентировался на статью "TPU transformation: A look back at 10 years of our AI-specialized chips" от Google Cloud)

1. TPU v1 (2015) - Инференс
Он разработан с рекордной скоростью - всего за 15 месяцев с момента начала проекта до развёртывания в дата-центрах Google в начале 2015 года. Такая скорость была достигнута благодаря использованию "устаревшего" 28-нанометрового техпроцесса и относительно низкой тактовой частоты 700 МГц, что позволило относительно просто уложиться в сроки. Энергопотребление было 40 Вт, а производительность 92 TOPS для 8-битных целых чисел. Этот процессор был предназначен только для инференса. Чип показал производительность в 15-30 раз выше, чем современные ему CPU и GPU, с 30-80-кратным преимуществом по энергоэффективности.
2. TPU v2 (2017) - Инференс + Обучение
Уже в конце 2014 года, когда TPU v1 находился в производстве, Google осознала, что возможность обучения становится ограничивающим фактором для создания моделей. TPU v2, представленный в 2017 году, стал революционным шагом — это была уже не просто микросхема, а полноценная суперкомпьютерная система. Ключевые нововведения TPU v2:
- Поддержка как обучения, так и инференса
- TPU Pod - сеть из 256 чипов TPU v2 с высокопропускной межсоединительной сетью
- Производительность: 180 TFLOPS
- Память: 64 ГБ HBM
3. TPU v3 (2018) - Жидкостное охлаждение
TPU v3 ввёл жидкостное охлаждение для эффективного управления теплом, что позволило работать на более высоких уровнях производительности. Производительность выросла до 420 TFLOPS, была улучшена межсоединительная сеть и пропускная способность памяти.

Продолжение истории в следующем посте.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

[2/2] История появления Google TPU и их эволюции (Рубрика #Engineering)

Продолжу рассказ про TPU от Google с 2021 года, а точнее с TPU v4.
4. TPU v4 (2021) - Optical Circuit Switching
TPU v4 представил оптическое переключение цепей для ускорения связи между чипами, что критически важно для работы со всё более сложными ИИ-моделями. Производительность составила 275 TFLOPS на чип, с улучшенными оптическими межсоединениями.
5. TPU v5 и v5e (2023) - Оптимизация затрат
TPU v5e и v5p сфокусированы на экономически эффективном обучении на масштабе, с улучшенной энергоэффективностью, динамическим масштабированием и поддержкой разреженности.
6. TPU v6 Trillium (2024) - Оптимизация производительности
Trillium, шестое поколение TPU, предлагает впечатляющий скачок в 4.7 раза по вычислительной производительности на чип по сравнению с TPU v5e. А также обладает следующими характеристиками
- Удвоенная ёмкость и пропускная способность High Bandwidth Memory (HBM)
- Удвоенная пропускная способность межчиповых соединений
- На 67% более энергоэффективен, чем TPU v5e
- Масштабируется до 256 TPU в одном поде с низкой задержкой
7. TPU v7 Ironwood (2025) - опять инференс
Ironwood, представленный в апреле 2025 года, стал заново TPU, специально разработанным для инференса (как TPU v1). Революционные характеристики Ironwood:
- Масштабирование до 9,216 чипов с жидкостным охлаждением
- 42.5 экзафлопс вычислительной мощности (в 24 раза больше самого мощного суперкомпьютера El Capitan)
- 4,614 TFLOPS на чип с 192 ГБ HBM памяти (в 6 раз больше, чем у Trillium)
- 2-кратная энергоэффективность по сравнению с Trillium

Если суммировать то видно, что процессоры Google прошли большой путь. Правда, остается вопроса, а как они чувствуют себя в сравнении с NVidia? И ниже есть ответ на этот вопрос
- NVIDIA H100: 3,958 TFLOPS (FP8), 80 ГБ HBM3, пропускная способность памяти 3.35 ТБ/с
- NVIDIA H200: 3,958 TFLOPS (FP8), 141 ГБ HBM3e, пропускная способность памяти 4.8 ТБ/с
- TPU v6 Trillium: ~2 PFLOPS FP16 для тензорных операций
- TPU v7 Ironwood: 4,614 TFLOPS на чип, 192 ГБ HBM, 7.37 ТБ/с пропускной способности

Как видим по FLOPS все норм. А если смотреть на эффективность по независимым исследованиям, то TPU v5e показывает в 50-70% более низкую стоимость на миллиард токенов для обучения крупных моделей по сравнению с кластерами NVIDIA H100. TPU v5e также потребляет значительно меньше энергии, чем H100 для аналогичной рабочей нагрузки (H100 может потреблять в ~5 раз больше энергии, чем чип TPU v5e под нагрузкой). В реальных задачах показатели примерно такие
- Для обучения GPT-масштабных моделей: TPU более экономически эффективны в 4-10 раз по сравнению с GPU
- Для инференса: TPU v5e обеспечивает в 3 раза больше пропускной способности на доллар
- TPU v4 показал производительность 1.2-1.7 раза быстрее и использует 1.3-1.9 раза меньше энергии, чем NVIDIA A100

В итоге, у TPU есть как преимущества, так и недостатки
(+) Специализация для тензорных операций и глубокого обучения
(+) Высокая энергоэффективность и экономическая эффективность
(+) Интеграция с Google Cloud и оптимизация для TensorFlow/JAX
(+) Масштабируемость в экосистеме Google Cloud
(-) Доступность только через Google Cloud
(-) Меньшая гибкость по сравнению с GPU для различных типов вычислений
(-) Ограниченная экосистема разработки по сравнению с CUDA
(-) Меньший объём памяти на чип по сравнению с новейшими GPU (до недавнего времени)

Если подводить итоги, то кажется, что у Google все хорошо со своей линейкой процессоров для Gen AI / ML задач и они дальше продолжат отстраивать эту инфру, которая дает им значимое конкурентное преимущество в эпоху лета Gen AI приложений. А вот для остальных эти процессоры означают vendor lock при прямом использовании или ориентир, куда стоит стремиться, если смотреть в будущее.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

[2/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Аспекты инженерной культуры (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так
- Принцип "Move fast"
- Открытость технологий
- Research in production
- Единая инфраструктура и стандартизация

А теперь давайте поговорим про каждый пункт подробнее.

Принцип "Move fast"
С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов.

Открытость технологий
Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.)

Research in production
В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (так как все понимают, что в продакшен окружении они просто не работают)

Единая инфраструктура и стандартизация
В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты.

Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно.

В конце этой части приводится первый инсайт

Insight 1 : Despite many challenges, it is feasible for a large organization to maintain a culture of moving fast, using a common infrastructure, and sharing a monorepo without strictly enforcing code ownership.

В следующем посте мы поговорим про подходы к обработке пользовательских запросов.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании 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

[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.

Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.

Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи

Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.

Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.

Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт

Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.

В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.

All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом

Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.

Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так

Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.

In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)

Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.

В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.

Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.

В общем случае подход Meta можно сформулировать таким инсайтом

Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.

В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора

Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.

В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)

Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.

AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.

Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.

Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.

Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.

Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.

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

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps