Kubecon Chicago - November 6-9

На днях в Чикаго проходил Kubecon, который закончился только вчера. Я конечно же не мог посетить конференцию лично, но планировал посмотреть трансляции и даже купил виртуальный билетик. Я даже букал себе время в календаре под это дело, но ничего не помогло
- время старта выступления было в 18 по Мск
- на начало ноября у меня выпали хлопоты по переезду
- и в среду я заболел
В итоге, я так ни одно выступление в прямом эфире не посмотрел, но если получиться, то гляну записи в выходные. Хотя по фидбеку от друга, который был там лично, уровень докладов слабее, чем на условном Highload++. В итоге, если я найду интересные выступления, то я о них напишу в этот канал:)

#Conference #SRE #Devops #DistributedSystem

[2/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Вызовы на сети в эру AI (Рубрика #Infrastructure)

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

1. WAN как новая LAN
Обучение современных foundation models требует объединения тысяч TPU/GPU. И то, что раньше размещалось в пределах одного датацентра, теперь распределено географически (континент как датацентр - примерно тот же посыл у запрещенной в России Meta). Сеть должна масштабироваться на порядок больше прежнего, чтобы связать удалённые кластеры так, словно они в одном локальном сегменте. При этом трафик от распределённого обучения идёт всплесками, которые нужно эффективно обнаруживать и маршрутизировать без потери производительности.

2. Нулевая терпимость к сбоям
Процессы обучения моделей ИИ и крупномасштабный inference очень чувствительны к перебоям. Остановка обучения из-за сетевого сбоя - неприемлема из-за простев дорого железа. От сети теперь ожидают практически 100% доступности, без ощутимых перерывов, а значит сеть должна быть спроектирована так, чтобы любые отказоустойчивые механизмы срабатывали мгновенно и вообще не влияли на долгий процесс обучения.

3. Повышенные требования безопасности и контроля
Данные, на которых обучаются модели, и сами модели - ценный и чувствительный ресурс. Их нужно защищать как от утечек, так и от несанкционированных изменений. Кроме того, по мере распространения ИИ растут требования к соблюдению региональных регуляторных норм и к контролю данных "на лету" (в транзите). Сеть должна обеспечивать изоляцию, шифрование, соответствие политикам разных стран и компаний, чтобы ИИ-сервисы оставались надёжными и законопослушными.

4. Операционное совершенство при возросшей сложности
Масштаб, растущий на порядок, не может управляться по-старому. Google применяет лучшие практики SRE и уже использует машинное обучение для управления сетью, но теперь ставится цель минимизировать человеческий фактор. Сеть должна работать с минимумом ручного вмешательства, потому что линейное наращивание инфраструктуры иначе приведёт к неуправляемому росту сложности и затрат. Новые подходы требуются для автоматизации, быстрого выявления и устранения проблем, оптимизации емкости.

Отсюда появляются новые дизайн принципы сетей, которые мы обсудим в следующий раз.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[3/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Новые принципы дизайна сетей (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит рассказать про то как новые подходы к архитектуре сетей решает вызовы, озвученные в прошлом посте

1. Экспоненциальная масштабируемость
Сеть должна гибко выдерживать лавинообразный рост трафика и данных, особенно в регионах, где сосредоточены ИИ-вычисления. Принцип "WAN - это новая LAN" реализуется через отказ от монолитна в пользу горизонтального масштабирования (архитектура multi-shard network). Шарды независимы - у каждого свой набор контроллеров и каналов. Это позволяет параллельно наращивать пропускную способность - с 2020 по 2025 год пропускная способность глобального WAN Google увеличилась в 7 раз. Кроме того, такая сегментация упрощает управление: каждая «шардинговая» подсеть более контролируема по размеру.

2. Надёжность выше традиционных “пяти девяток”.
В индустрии обычно говорят о 99.9% или 99.99% доступности, но для критичных AI нагрузок выжны long tail выбросы (нужен детерминизм и бесперебойная работа сети). На практике сеть должна локализовать проблемы и автоматически их обходить до того, как пользователи или процессы заметят сбой. Для этого
- Шарды изолированы друг от друга (сбои не кореллируют)
- Дополнительно введена изоляция по регионам, чтобы локальные неполадки не каскадировались глобально
- Создана технология Protective ReRoute для быстрого обнаружения потерь связи и перенаправления трафика за секунды
После включения Protective ReRoute суммарное время простоев по инцидентам сократилось на до 93%.

3. Программируемость, управляемая намерениями (Intent-driven programmability)
Сеть Google обслуживает миллиарды пользователей и множество корпоративных клиентов с разными требованиями, например
- Кому-то критична задержка
- Кому-то важно шифрование
- А кто-то должен географически раскидывать данные (с учетом регуляторики)

Для удовлетворения таких разных требований ребята сделали сеть полностью программируемой (SDN) на основе высокоуровневых политик (intent), то есть созданы
- Единые модели представления сети (например, модель MALT - Multi-Abstraction-Layer Topology)
- Открытые API для управления
- Централизованные SDN-контроллеры, которые могут трактовать намерения операторов или приложений и применять их к сети.
Такая гибкость позволяет задать политики для конкретных приложений или данных (например, чтобы определённый тип трафика шёл только через узлы в заданной стране для соблюдения суверенитета данных, или чтобы критичные сервисы всегда имели резервные каналы). А высокоуровневое управление не требует ручного конфигурирования (как в SQL достаточно указать что нужно, а умная сеть подстроится под запрос)

4. Автономная сеть
Сети уже прошли путь вида: ручное управление -> автоматизированное (скрипты) -> автоматическое (по жестким правилам). Новая цель в том, чтобы сделать сеть самоуправляемой при помощи машинного обучения и "цифрового двойника", где модели постоянно обучаются на телеметрии.Так сеть сможет симулировать и предвидеть сбои, быстро локализовать причину неполадок и даже оптимизировать планирование ёмкости каналов на будущее.
После внедрения этих инструментов время реакции на сбой сократилось с часов до минут, что существенно повысило эффективность и устойчивость работы сети без участия человека.

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

В последнем посте мы сравним эту стать/ про инфру от Google и статью от запрещенной в России Meta.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

Сравнение подходов Google и Meta к построению сетей и инфры (Рубрика #Architecture)

В этом посте я решил сравнить подходы Google запрещенной в России Meta к своей сетевой архитектуре. Суть в том, что обе эти компании в 2025 году написали статьи на тему того, как инфра меняется с учетом вызовов эры AI и я до этого разобрал обе
- Meta’s Hyperscale Infrastructure: Overview and Insights
- Google's AI‑powered next‑generation global network: Built for the Gemini era

Если обобщать, то обе компании сходятся во взгляде, что их глобальная инфраструктура должна работать как единый организм. У них похожи даже девизы
- Google: WAN – это новая LAN, континент стал датацентром
- Meta: все глобальные датацентры – это один компьютер

Но при реализация акценты у Google и Meta различаются:

1. Масштаб сети и для кого она
И Google, и Meta построили собственные глобальные сети на оптоволокне, связывающие датацентры напрямую, вместо зависимости от публичного интернета. Оба стремятся разместить узлы ближе к пользователям (кэши, PoP) для низких задержек. Но Google делает для себя и клиентов Google Cloud, а Meta только для себя и своих продуктов

2. Архитектура масштабирования
Подходы компаний к масштабируемости сети WAN очень схожи по концепции, хотя реализованы своими методами
- На уровне LAN внутри ДЦ все похоже и oversubscription нет - обе компании используют масштабируемые фабричные топологии (Clos/fat-tree) и добавляют коммутаторы на верхних уровнях
- На уровне WAN у Google шарды, у Meta отдельные planes, но у Google на уровне WAN нет oversubscription, а у Meta есть (а это влияет на возможность/невозможность распределенного обучени foundation models)

3. Надёжность и обновления
У обеих компаний сеть спроектирована с идеей локализации проблем и быстрого самовосстановления, но
- Google говорит об автономной сети - автоматическом реагировании самой сети на проблемы. Задача в том, чтобы сделать ультра-высокую надежность (beyond 9s) и для этого нужна автономная система, что обладает selfhealing возможностями
- Meta говорит об автоматизациях сетевой конфигурации - возможности быстро менять конфигурацию и софт без ущерба работе. То есть здесь закрыт уровень автоматизации, но изменения должен инициировать человек

4. Интеграция с AI-нагрузками
Оба гиганта осознают, что искусственный интеллект диктует новые требования к инфраструктуре. Однако подходы проявляются по-разному.
- У Google сеть позволяет делать распределенные тренировки и они могут горизонтально масштабироваться
- У Meta сеть позволяет распределенно гонять все нагрузки, кроме тренировок больших моделей. Там ребята ориентируютсяй на масштабирование через scale-up внутри ДЦ. Дальше они планируют допилить сеть для возможностей распределенных тренировок

5. Программируемость решений
Оба игрока применяют принципы software-defined networking и автоматизации управления. Но есть и разница
- У Google много разных клиентов (с учетом Google Cloud), поэтому им нужно было удобное централизованное управление политиками сети для разных задач (будь то обслуживание cloud-клиентов или внутренних сервисов)
- У Meta также центральные контроллеры для управления сетью - они постоянно оптимизируют распределение трафика от пользователей (PoP) к датацентрам с учётом загрузки и задержек, а в самих датацентрах контроллер может изменять маршруты при перегрузках или сбоях.

Итого, Google и Meta идут параллельными курсами: они решают схожие задачи гипер-масштабной сети, иногда разными методами, но общая цель одинакова - сеть, способная связать весь мир в единый “компьютер” для своих услуг и будущих AI-приложений. Но вот подход компаний к публикации результатов сильно отличается
- Google публикует научные статьи и продает коммерческие сервивсы, но не публикует код инструментов или дизайн железа
- Meta активно делится дизайнами аппаратного обеспечения через сообщество Open Compute Project, а также публикует многие свои наработки: фреймворки, базы данных

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось интересным отдельно рассказать про все три этапа эволюции платформы, какие у них были предпосылки, что получилось в итоге, а также что можно почерпнуть себе, если вы тоже делаете платформы в своих компаниях.

Ну и начать стоит с того, что в Uber машинное обучение (ML) уже много лет играет ключевую роль практически во всех аспектах бизнеса - от прогнозирования времени прибытия (ETA) и подбора водителя до ранжирования ресторанов в Uber Eats и выявления мошенничества. Для поддержки такого широкого применения ML Uber в 2016 году создала централизованную платформу Michelangelo (вот рассказ от 2017 года об этом), охватывающую весь жизненный цикл ML-моделей - от подготовки данных и обучения до деплоя и онлайн-инференса. Дальше платформа росла и развивалась, пройдя следующих три этапа эволюции

1️⃣ Predictive ML-платформа (2016–2019)
Фокус: табличные данные, модели типа XGBoost, классические predictive задачи: ETA, ценообразование, риск, антифрод.
Запуск Michelangelo 1.0 как централизованной ML-платформы:
- Единый Feature Store для повторного использования фичей,
- Стандартизованные пайплайны обучения/деплоя,
- Инструменты для мониторинга и дебага моделей.
Цель: перестать собирать ML-инфру в каждой команде как с нуля

2️⃣ Deep Learning & Michelangelo 2.0 (2019–2023)
Первая версия была хорошо, но требовалось порешать новые проблемы
- Deep learing начал давать выигрыш по качеству в high‑impact задачах, а платформа его плохо поддерживала
- Моделей и команд много, инструменты фрагментированы.
- Нет единого взгляда на качество моделей и приоритеты.
Ключевые изменения:
- Michelangelo 2.0: единый продукт вместо зоопарка тулов.
- Встроенная поддержка deep learning (GPU, distributed training, PyTorch/TensorFlow и т.д.).
- Добавлены следующие возможности
-- Model Excellence Score - сквозная метрика качества модели (от обучения до продакшена),
-- Tiering (Tier‑1…Tier‑4) для приоритизации ML-проектов по бизнес‑ценности.
-- Canvas / "model iteration as code": monorepo для ML, шаблоны ML-приложений, CI/CD для моделей, нормальные code review и reproducibility.

3️⃣ Generative AI и LLMOps (2023+)
После появления LLM надо было добавить в Michelangelo слой для generative AI:
- GenAI Platform / GenAI Gateway:
- Единый интерфейс к внешним и внутренним LLM (OpenAI, Llama2 и др.),
- Централизованный контроль доступа, логирование, cost‑контроль, безопасная работа с данными.

Michelangelo решили расширить до end‑to‑end LLMOps:
- Хранение и версионирование LLM,
- Репозиторий и version control для prompt’ов,
- Инструменты оценки качества и A/B-тестов LLM.

Технологический стек был выбран следующий: Hugging Face, DeepSpeed (model parallelism), Ray для распределённых вычислений и масштабирования GPU.

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

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

[2/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)

1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта

2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control

3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.

4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты

5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.

6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.

Итого, кажется, что Michelangelo показал путь эволюции платформы для успешного масштабирования AI в крупной компании. Секрет успеха - в постоянном улучшении опыта разработчиков, стандартизации процессов и гибкой архитектуре, готовой к новым технологическим веяниям.

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign