Podlodka Techlead Crew про архитектурные антипаттерны (Рубрика #Architecture)

Когда рассказывают про архитектуру, то теоретики часто фокусируются на том, а как строить качественную архитектуру. Но на практике инженеры часто сталкиваются с неидеально спроектированными системами, которые доставляют много проблем. Поэтому часто бывает полезно знать симптомы того, что ваша архитектура требует доработок. Ну а вообще лучше изначально разобраться с типовыми ошибками проектирования, которые бывают и у опытных инженеров. Именно этой теме посвящен новый сезон онлайн-конференции Podlodka Techlead Crew.

В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).

Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.

P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.

#Architecture #DistributedSystems #Software #Engineering #Processes #AI

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI)

Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже

- Введение и тема выпуска
- Почему оценка ИИ‑приложений сложна; рост важности валидации
- Валидация в пайплайнах и сложности доменов
- Ограничения бенчмарков и переход к продуктовой валидации
- Риски неконтролируемой генерации
- Теория информации: энтропия как база метрик
- Кросс‑энтропия и KL‑дивергенция для оценки моделей
- Перплексия и влияние контекста на уверенность модели
- Функциональная корректность vs нефункциональные требования
- От лексической к семантической близости; эмбеддинги
- Паттерны валидации и AI as a judge
- Попарные сравнения и ранжирование моделей; транзитивность и голосования
- Каркас системы: критерии → выбор моделей → сборка пайплайнов
- Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн
- Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Программирование смыслов (Рубрика #AI)

Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать.

Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам
1) Как всё началось
В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает.
2) Поворотный момент
В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи.
3) Что именно сделали (и где)
- Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов.
- Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение.
- Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы.
4) Машинное обучение как конвейер
Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей
- Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления.
5) Какие проблемы были и как их лечили
- Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры.
- Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают.
- В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код.
6) Принципы ранжирования и ответов
Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха.
Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] Hands-On Large Language Models (Рубрика #AI)

В свой отпуск я захватил с собой этот визуальный путеводитель по большим языковым моделям или просто LLM:) Так как я воспринимаю информацию визуально на порядок лучше, чем на слух, а также сам строю схемы для визуализации сложных тем, то эта книга мне показалась просто блестящей - она не просто объясняет сложные темы, она показывает их через визуализации и код.

Книгу написали два эксперта в ML/AI:
- Джей Аламмар - engineering fellow в Cohere, автор культовых визуальных гайдов по ML и NLP. Его диаграммы разбирают в документации NumPy, pandas и на курсах deeplearning.ai. У него есть свой топовый блог
- Маартен Гротендорст - дата-сайентист, автор open-source библиотек (BERTopic, KeyBERT), специалист в теме тематического моделирования и эмбеддингов. У него есть свой топовый блог

Они придерживаются философии обучения когда сначала развивается интуиция (через качественное понимание концепций), а уже затем подкрепляют его формальным описанием и примерами. Для этого используется формат визуального повествования: книга содержит почти 300 оригинальных иллюстраций и диаграмм, созданных специально для этого издания. Посредством наглядных схем, графиков и рисунков сложные механизмы LLM (например, механизм self-attention в трансформерах, работа токенизаторов, многомерные пространства эмбеддингов и т.д.) разъясняются постепенно и доступно. Помимо визуализации, авторы делают акцент на практической стороне применения языковых моделей (об этом говорит hands-on в названии книги). Они приводят много примеров кода, сценариев и практических кейсов (код доступен на GitHub).

Книга отлично подойдет для всех
- Начинающих и продвинутых специалистов в ML/NLP
- Разработчиков и аналитиков, внедряющих LLM в проекты
- Всех, кто хочет уверенно ориентироваться в современных моделях вроде ChatGPT, Mistral или Claude

В продолжении немного про содержимое всех трех частей книги.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[2/2] Hands-On Large Language Models (Рубрика #AI)

Продолжая рассказ про эту книгу, скажу о том, что она состоит из трех частей и 12 глав (я пока прочитал четыре с половиной главы, поэтому про них расскажу подробнее). Но если кратко, то книга начинается с основ LLM, дальше авторы переходят к их использованию для решения задач, а заканчивают методами обучения моделей.

Часть I: Понимание языковых моделей
Первая часть закладывает фундамент, объясняя, что такое языковые модели и как они устроены.
Глава 1. Здесь приведен обзор развития обработки языка - от "bags of words и классических представлений текста до появления методов вроде word embeddings и архитектуры трансформеров. Читатель узнает, что собой представляют большие языковые модели, и чем они отличаются от предыдущих подходов. В главе также обсуждается, почему LLM стали настолько полезными.
Глава 2. Авторы погружаются в тему токенизации и эмбеддингов - ключевых понятий для представления текста в численной форме. Авторы подробно описывают, как работает токенизатор LLM (преобразуя текст в токены), сравнивают разные виды токенов (слова, подслова, символы, байты) и демонстрируют свойства обученных токенизаторов. Далее рассматривается, как модель превращает токены в векторные представления (эмбеддинги) и как эти эмбеддинги могут использоваться для представления слов, предложений и документов. Приводятся примеры, как с помощью эмбеддингов измерять семантическую близость текстов. В этой же главе объясняются традиционные алгоритмы построения эмбеддингов (например, word2vec) и более современные подходы, вплоть до того, как LLM сами формируют эмбеддинги во время работы. Завершает главу практический пример: обучение модели эмбеддингов для рекомендательной системы (например, рекомендация песен по схожести эмбеддингов).
Глава 3. Авторы показывают внутренности трансформера, объясняя что происходит под капотом. Они рассказывают про forward-pass модели: как обрабатываются входные токены, как вычисляется матрица внимания (attention) и как на её основе модель выбирает следующий токен. Важная часть главы - интуитивное объяснение механизма Self-Attention (внимания), благодаря которому модель учитывает контекст слов при генерации. Также обсуждаются оптимизации: как модели обрабатывают несколько токенов параллельно, какой максимальный размер контекста поддерживается, и как кеширование ключей и значений ускоряет генерацию текста.

Часть II: Использование предварительно обученных моделей
Вторая часть посвящена практическим способам применения готовых языковых моделей и эмбеддингов в разных задачах обработки текста. Здесь авторы переходят от устройства моделей к их использованию "из коробки" для решения прикладных задач.
Глава 4. Классификация текста
Глава 5. Кластеризация и тематическое моделирование (BERTopic)
Глава 6. Инженерия промтов (Chain of Thought, ReAct, Tree of Thought)
Глава 7. Продвинутые техники генерации текстов и инструменты (LangChain и агенты, Memory, Tools)
Глава 8. Семантический поиск и Retrieval-Augmented Generation (RAG)
Глава 9. Мультимодальные модели (текст + картинки, CLIP, BLIP-2)

Часть III: "Обучение и тонкая настройка моделей"
Последняя часть книги посвящена тому, как создавать свои модели и адаптировать существующие LLM под конкретные задачи. Здесь материал становится более продвинутым
Глава 10. Создание моделей эмбеддингов для текста
Глава 11. Fine-tuning representation models для классификаций
Глава 12. Fine-tuning генеративных моделей

В заключительной части (Afterword) авторы подводят итоги проделанному пути и заглядывают в будущее развития больших языковых моделей. Они отмечают, какой колоссальный и широкомасштабный эффект LLM уже оказали на мир и что понимание принципов их работы открывает перед специалистами новые возможности.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[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