Распределённые системы *

Когда у компании много сервисов и данных, то лучше всего иметь план Б на любую ситуацию, например когда нужно быстро оптимизировать ресурсы и работать в режиме «минус один дата‑центр» без просадок, в то время как утилизация серверов при этом стремится к 100%. Смертельный номер? Вполне посильная задача, с которой справилась команда Яндекс Go. 

Мы провели аудит и поняли, что у нас очень много синхронных походов из критичных сервисов в некритичные, а ещё и поллинг. И это требовало внедрения событийной модели. Тысяча микросервисов, 150 команд разработки, несколько языков программирования, и у каждого разработчика своё представление о том, как правильно читать сообщения из Kafka. Библиотека, которую мы раздали командам, быстро бы обросла форками, заплатками и костылями.

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

Меня зовут Алексей Терентьев, я руководитель одной из служб отдела эффективности Яндекс Go. В этой статье я расскажу, как мы прошли путь от простого «прочитал — обработал — закоммитил» к по‑настоящему масштабной архитектуре: со всеми граблями, факапами и конкретными решениями.

Привет, Хабр! Я — Сева, разработчик в Yandex Infrastructure. Уже больше десяти лет я занимаюсь разработкой внутреннего облака Яндекса, которое охватывает около 150 000 физических хостов и поддерживает все сервисы платформы.

Сегодня я представлю вам практический кейс по обеспечению очень высокой надёжности комплексной системы на примере собственного облака Яндекса. Принципы обеспечения надёжности будут продемонстрированы на всех уровнях архитектуры системы, чтобы в итоге сложилась картина, как достичь наивысшей отказоустойчивости. Статья написана по мотивам моего доклада для HighLoad++.

В последнее время из общего ИИ-пузыря выделилось несколько хайповых тем:

• автономные ИИ-агенты и другие инструменты, которые якобы помогают человеку выполнять рутинные задачи и экономить время (это обман, на самом деле всё наоборот: загруженность человека с ИИ сильно возрастает — увеличивается интенсивность труда, усталость, риски выгорания и требования к производительности),
• частные облака для «локального» инференса,
• децентрализованный ИИ, который будет работать на компьютерах пользователей.

С агентами всё понятно, а вот частные облака и P2P-суперинтеллект можно рассмотреть внимательнее.

Допустим, вы — типичный обитатель этого ресурса. Сидите по 10 часов перед экраном, компенсируете магнием и омегой-3, мониторите HRV через Oura или Apple Watch, слушаете Хабермана, ходите в зал три раза в неделю, спите по трекеру. Вы, возможно, даже знаете, что такое глимфатическая система и зачем нужен глубокий сон. И всё равно — что-то не складывается. Может энергии не хватает, или шея хронически зажата, сон нестабилен, тревога фоновая, а последний ОРВИ длился три недели вместо пяти дней.

Знакомо? Тогда у меня для вас новость: вы дебажите симптомы, а не архитектуру.

Современный биохакинг — это попытка чинить систему перебором драйверов. Для обычного пользователя — нормальная стратегия. Но вы же не обычные пользователи. Вы — люди, которые умеют читать логи, понимают, что такое архитектура, и знают, что перебор драйверов без понимания, какая подсистема сбоит, — это не дебаг, а карго-культ. Так вот: у организма есть архитектура. И её можно описать.

Я потратил изрядное количество времени на то, чтобы собрать воедино результаты шести независимых областей нейронауки, которые последние 30 лет, каждая по-своему, приходят к одному и тому же выводу: информационные состояния высшего порядка реально, измеримо, через конкретные биохимические каскады влияют на физиологию. И написал научную статью (PDF на английском), в которой эти разрозненные наблюдения собраны в единый фреймворк.

Эта статья на Хабре — попытка рассказать о том же самом человеческим языком, с IT-аналогиями, практическими выводами и без единой мантры.

«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.

Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».

А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.

Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.

Привет, Хабр! Меня зовут Сергей, я работаю в компании InfoWatch разработчиком на продукте ARMA Стена (NGFW). Подробнее о том, что такое ARMA Стена, можно прочитать тут.

В этой статье я хочу поделиться опытом применения метода формальной верификации в решении практической бизнес-задачи.

Сразу оговорюсь, что в статье используется TLA+, без введения в инструмент, чтобы не увеличивать объём статьи. Подробнее про инструмент вы можете почитать на сайте создателя, тут и тут. Необходимые объяснения даются по ходу изложения.

Статья состоит из двух частей:

1) Что такое формальная верификация и где она применятся

2) Решение бизнес-задачи в NGFW

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

Привет, Хабр. Меня зовут Олег Жуковец. Я руководитель команды «Экосистема» в Tarantool R&D компании VK Tech.

Многие разработчики сталкивались с ситуацией, когда запросы к базе данных выполняются быстро, индексы настроены, оборудование справляется с нагрузкой, но конечное приложение все равно работает медленно. Нередко проблема кроется не в самой базе данных, а в некорректно реализованном клиенте, который может стать «бутылочным горлышком» для всего ИТ-ландшафта. Именно поэтому оптимизация клиентов для работы с БД имеет важное значение.

В этой статье я на примере коннектора к Tarantool расскажу о доступных и простых оптимизациях клиента для БД, которые позволяют минимизировать аллокации и число горутин, чтобы выкрутить скорость обработки запросов (RPS) на максимум.

Привет, Хаброжители! «System Design. Распределенные системы. Подготовка к сложному интервью» — это практическое руководство для инженеров и архитекторов, которое поможет справиться с самыми трудными техническими заданиями. Алекс Сюй и Сан Лэм предлагают стратегию, проверенную на практике, пошаговые алгоритмы и реальные примеры, позволяющие научить вас проектировать масштабируемые системы — от новостной ленты до поисковых сервисов и чат-приложений.

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

Это явление давно известно в архитектуре вычислительных систем как разрыв между процессором и памятью (или Memory Wall). Сегодня он определяет производительность серверов, баз данных, платформ данных и AI/ML-платформ сильнее, чем выбор конкретной модели процессора или видеокарты. А в будущем определит то, какие продукты и решения индустрия будет использовать для решения задачи хранения данных.

Привет! Я Александр Гришин, руководитель по развитию продуктов хранения данных в Selectel. В этой статье я попробую подробно разобрать, что такое этот ваш разрыв между процессором и памятью, как он сформировался, как устроена иерархия памяти в сервере и почему эти ограничения подталкивают индустрию к новым архитектурам и решениям. Погнали!

Загадка: во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2? 

Ответ: в 2,5 раза!

Привет! Меня зовут Стёпа, и я разработчик в Яндекс Go. Я хочу поделиться тем, как математика может встречаться в самых неожиданных местах — даже в такой рутинной задаче, как настройка интервала поллинга. В статье я рассмотрю модельный пример, который встречался каждому разработчику, и просчитаю его с математической точки зрения, использовав базовые факты из теории вероятностей и статистики.

CedrusData Engine — это lakehouse-движок, основанный на Trino. На реальных нагрузках наш продукт рутинно превосходит по производительности другие технологии (Trino, Doris, Dremio, StarRocks) в 1.5-3 раза, с еще более значительным отрывом от устаревших Greenplum и Impala. Эти результаты — следствие постоянных вложений в разработку новейших техник обработки больших данных. В этой статье я расскажу про проект Oxide — одну из наших ключевых инициатив прошлого года по переписыванию ядра Trino с Java на Rust.

Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.

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

В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности. 

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

В этой статье мы поделимся некоторыми подробностями работы над новыми функциями Greengage, такими как shrink и expand кластера, улучшение вставки для foreign-таблиц и подготовка к интеграции с Apache Iceberg.

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.

Компании ежедневно генерируют большие объемы данных, но далеко не вся информация одинаково важна: со временем многие данные становятся менее востребованными, продолжая занимать дорогие и высокопроизводительные накопители (SSD, RAM). В результате хранение таких «холодных» данных обходится неоправданно дорого, поскольку потребность в постоянном доступе к ним минимальна.

Решение проблемы — технология охлаждения данных, которая предполагает перемещение редко используемой информации на более дешевые и емкие носители, то есть файлы остаются доступными, но перестают нагружать дорогие и быстрые устройства. Именно такой механизм охлаждения данных мы добавили в Tarantool DB 3.0.

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. В этой статье я расскажу, как именно мы реализовали механизм охлаждения и какие бизнес-выгоды могут получить компании при его использовании.

Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы Temporal: почему мы его выбрали как основу нового процессинга, в чём его сильные стороны и как изменилась наша жизнь после перехода. 

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

Всем привет! Меня зовут Сергей, я занимаюсь backend-разработкой уже больше 15 лет, а последние несколько лет разрабатываю объектное хранилище для ваших файлов в компании Сloud.ru. Мы пишем свое собственное распределенное хранилище данных с нуля.

В этой статье я хочу рассказать про грабли, которые часто вижу в проектах и на которые периодически наступаю сам. Рассказываю, как их избежать, чтобы сделать ваши сервисы более стабильными и предсказуемыми. Статья будет полезна junior- и middle-разработчикам.

Transactional Outbox часто подаётся как простой рецепт: записали событие в отдельную таблицу, фоновый воркер разберётся. В реальности именно этот «временный костыль» неожиданно превращается во вторую очередь со своей конкуренцией за блокировки, дубликатами, нарушенным порядком и тихо растущими таблицами.

В статье разберемся, что именно начинает ломаться в outbox-паттерне под нагрузкой, как выбирать и блокировать события в разных СУБД, почему ретранслятор стоит отделить от API и какие гарантии доставки на самом деле получаются. А ещё — почему консюмеры должны быть идемпотентными, как следить за внутренней очередью в базе и не узнавать о проблемах уже после инцидента.