Высоконагруженные системы *

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

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

Почему Dispatchers.IO + Hikari + чуть-чуть лагов БД = каскадная деградация всего сервиса, и как bulkhead-паттерн в одну строку это лечит.

Привет, Хабр! Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня расскажу о разработке системы, которая строит свечные графики для трейдинг-бота на Python. Это полноценный инструмент анализа, который помогает принимать торговые решения в реальном времени. Важная часть этой системы — быстрая связь с пользователем через бота в Телеграме. 

Привет, Хабр! На связи — Ольга Кравченко, техдиректор по разработке моделей Газпромбанк.Тех. Сегодня я поделюсь кейсом, как наша команда создала инструмент, позволяющий нам продвигаться от просроченной задолженности к прибыли через персонализацию коммуникаций. Эта статья основана на моём выступлении на HighLoad++.

Прогресс не остановить — ML и здесь! Внутри — про развитие модельного скоринга и о том, как это повлияло на опыт пользователей и архитектуру решения.

Любое оборудование подвержено Первому закону девайсдинамики: Электроника рано или поздно должна зависнуть!

Как определить, что ваш объект мертв? – Ну, наверное, надо поставить внешнее устройство для его постоянной проверки. А если внешнее устройство зависло?

Хотя, какое это имеет значение, если завис Интернет-роутер или любой хаб в сети? Ну, определили вы, что он висит, не пингуется офис, пропала связь с охранной системой дачи, не отвечает антарктическая станция. Что вы сделаете? - доступа то все равно нет!

Вместо растрат бензина и времени, чтобы добраться до далекого объекта, ставим Розетку надежности...

Всем привет!

Меня зовут Тарас, я автор библиотеки picows — ультрабыстрых вебсокетов для asyncio. В этой статье я расскажу, почему вообще появилась ещё одна библиотека для вебсокетов, покажу результаты бенчмарков и заодно порассуждаю о производительности в asyncio.

Предистория

В далёком-предалёком 2021 году мне довелось поучаствовать в разработке алготрейдинг-платформы для криптовалютных бирж. Выбор языка пал на Python из-за разнообразия ML-библиотек, возможность быстро собирать прототипы и проверять идеи, отсутствия этапа компиляции и в целом наличия богатой экосистемы. Если какая-то идея взлетит, критичный участок всегда можно оптимизировать, хотя бы частично переписав его на C/C++/Cython.

Архитектурный принцип Lakehouse предполагает, что вы оперируете всеми данными, загруженными в систему. Но иногда нужно выполнить ad hoc анализ за ее периметром, потому что необходимых данных по каким-либо причинам нет в Lakehouse-платформе. В этом случае на помощь приходит федеративный доступ. Стандартом для такой задачи является движок Trino. Он умеет извлекать данные из внешних СУБД и даже в некоторых случаях может делать push-down определенных вычислений на сторону системы-источника. Главное, чтобы под рукой был подходящий connector для нужной СУБД, который умеет эффективно с ней работать.

Недавно в состав Data Ocean Nova был добавлен новый Trino Teradata Connector. Он позволяет пользователям «подтягивать» необходимые срезы данных из Teradata в рамках ad hoc запросов и решает задачу эффективной передачи данных: можно передавать терабайты в несколько потоков без существенного увеличения нагрузки на источник.

В данной статье разберем:
• Как организовать эффективную многопоточную работу с Teradata: где часто допускают ошибки, как должно выглядеть правильное решение;
• Какие возможности дает Nova Trino Teradata Connector: многопоточная передача, push-down оптимизации.

Uber — это хороший пример System Design задачи, где сочетаются geo-search, real-time уведомления, многошаговый workflow и строгие требования к согласованности. В статье разберём, как проектировать такую систему, чтобы она быстро находила водителей поблизости, гарантировала назначение водителю только одной поездки и выдерживала пиковую нагрузку.

Привет, Хабр!

Кратко о том что такое потоковая обработка данных и в чем её отличие от пакетной.

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

Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3.

Как найти причину латенси в пайплайне обработки HTTP запроса за 5 минут: разбираем шаг за шагом

Я достаточно ленивый и рациональный человек. В конце прошлого года у CloudFlare и его клиентов были непростые дни и утро Infra инженеров начиналось не с кофе. Плюс, те, кто много работает с CF знают про 503 и 520 ошибки и, если вы не на Enterprise тарифе, они также могу доставить неприятности. Хочу поделиться подходом и инструментом, которые помогли решить эти проблема и рационализировать/автоматизировать их решение в последствии.

Алерт в три часа ночи: время ответа выросло с 150 ms до 1.2 секунды. Или хуже — пользователи получают 502/503/504. Дежурный инженер открывает дашборд и видит красный график. Что-то тормозит. Но что именно?

Это CDN? Ingress? Приложение? База? Сеть между чем-то из вышеперечисленного? Каждый вариант ведёт к совершенно разному исправлению: перезапуск пода не поможет, если проблема в маршрутизации CDN, а звонок в поддержку хостера бесполезен, если у вас медленный SQL-запрос. Гадать дорого — особенно в три часа ночи.

В этой статье я покажу системный подход к поиску узкого места. Шаг за шагом, с минимумом телодвижений, используя данные, которые у вас скорее всего уже есть (или которые легко начать собирать). Акцент будет на CDN, Hosting Provider, Ingress.

Путь запроса

Прежде чем искать проблему, давайте зафиксируем, через какие этапы проходит типичный HTTP-запрос. Это простая архитектура, характерная для небольшой команды — но знакомая и наглядная(межсерверное взаимодействие в Netflix в качестве примера не будем использовать):

User → CDN → SLB (Nginx) → App(POD) → Connection Pooler → RDBMS

Шесть слоёв. Каждый может вносить свою задержку, свои ошибки — и каждый дает свои сигналы для диагностики.

Ключевое наблюдение: SLB (балансировщик, Nginx, HAProxy, ALB) сидит в центре и является вашей точкой отсчёта. Его логи подскажут, куда смотреть — налево (сеть, CDN) или направо (приложение, база).

Шаг 1. Точка опоры: логи балансировщика

Это лучший стартовый шаг — особенно если у вас еще нет развитого observability-стека и внешнего мониторинга. Достаточно Nginx access log.

Два ключевых значения:

Переменная Nginx Что измеряет $request_time Полное время обработки запроса — от первого байта клиента до последнего байта ответа $upstream_response_time Время ожидания ответа от upstream (вашего приложения)

Если вы ещё не логируете эти значения, добавьте их в log_format:

log_format timing '$remote_addr - $request_uri ' 'status=$status ' 'rt=$request_time ' 'uct=$upstream_connect_time ' 'urt=$upstream_response_time'; access_log /var/log/nginx/access.log timing;

Теперь у ва

О чём дизайн сегодня? Про украшение? Про управление вниманием или про помощь и заботу? Разберём чем мы занимались когда я работал в Лабсе, а именно главной страницей Госуслуг. Хоть со стороны и не заметно что изменения внушительны, когда ты находишься внутри этой структуры становится понятно что всё совсем не так.

Серверный рынок снова лихорадит: память дорожает на десятки процентов, GPU в дефиците, облака готовятся поднимать цены. Разбираем, что происходит в 2026 году и как не переплатить.

Баланс между производительностью, читаемостью и поддерживаемостью — ключевая задача при разработке микросервисов на Go. На практике всё сложнее из-за неочевидных факторов: от влияния частоты вызовов GC на время отклика до последствий избыточной вложенности в контрактах API. Если не учесть эти нюансы, даже грамотно спроектированный сервис может просаживаться по RPS (requests per second) — или его может быть сложно обновлять и дорабатывать.

Меня зовут Артём Кущ. Я Go-разработчик в команде VK Видео. В статье поделюсь подходами к оптимизации микросервисов и расскажу, как балансировать между скоростью и простотой.

Volga — open-source движок обработки данных, созданный как альтернатива Apache Spark и Apache Flink и ориентированный на требования real-time AI/ML систем: консистентное вычисление фичей между online и offline режимами, point-in-time корректные агрегации, длинные скользящие окна, а также ML-ориентированные функции, такие как top- и категориальные агрегации.

В статье рассматриваются мотивация и история разработки, архитектура системы и её ключевые компоненты, а также проводится сравнение с ML-ориентированными решениями (Chronon, OpenMLDB) и универсальными стриминговыми движками (Apache Flink, Apache Spark, Arroyo).

В предыдущей статье о Vinyl я рассказывал об архитектуре LSM-движка Tarantool. Восемь лет, прошедшие с момента с написания статьи, показали, что Vinyl сразу получился идеальным и менять его не нужно :). Если серьёзно, сегодня я расскажу о тех изменениях, которые мы внесли в алгоритм в форке Tarantool от Picodata, и неизбежно коснусь более глубокой проблематики работы LSM-деревьев, а конкретнее – работы планировщика слияний (compaction scheduler).

До недавнего времени для реализации сложной многошаговой логики в экосистеме Apache Spark разработчикам приходилось выходить за рамки декларативного SQL. Оркестрация последовательных вызовов, вычисление промежуточных переменных и ветвление логики требовали привлечения внешних языков программирования, таких как Python (PySpark) или Scala и дополнительных инструментов.

Spark SQL Scripting, который стал доступен, начиная с 4-й версии, кардинально меняет этот подход, представляя собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику.

В данной публикации мы, команда вендора Data Sapience, разберем возможности Spark scripting на практике.

Апдейт: идеи, изложенные в этой статье, позволили сформулировать оптимальные стратегии warp-специализации, описанные в научной публикации, которую можно посмотреть здесь.

Недавно я глубоко задумался о специализации варпов в контексте высокопроизводительных ядер для современных графических процессоров (GPU) на тензорных ядрах. Примеры таких процессоров — H100 и B200 от NVIDIA. Я стал полнее понимать, чего можно добиться при помощи специализации варпов, а также задался интересным вопросом: а нужна ли нам вообще специализация варпов (и вся та сложность, которую она с собой влечёт)? В итоге я пришёл к выводу, что, да, нуждаемся, но она не столь обязательна, как может показаться. В этом посте обсудим, в каких случаях без специализации варпов действительно не обойтись, а также я опишу, на каком пространстве компромиссов она зиждется, и какие границы этого пространства я вижу. Притом, что я обрисую некоторый контекст, касающийся графических процессоров, необходимый для обсуждения тем, которые мы взялись здесь рассмотреть, эту статью нельзя считать туториалом. Предполагается, что читатель имеет некоторый опыт работы с GPU и имеет опыт параллельного программирования.

Год назад запуск модели на 35 миллиардов параметров подразумевал облако, очередь на GPU, и счёт от провайдера в конце месяца. Сегодня я покажу, как мы сделали это на одной потребительской видеокарте AMD за $500 — без ROCm, без CUDA, без MLX, одним бинарником на Zig.

Это пост про ZINC — inference engine, который мы строим с нуля под железо, которое люди реально покупают. Не как proof of concept, а как рабочий инструмент с OpenAI-совместимым API, потоковой генерацией и встроенным чатом.

Когда мне пришла идея написать эту статью, я предполагала, что это будет хроника ошибок, от которых мы бы хотели предостеречь техническое сообщество: как мы наивно полагались на «синтетику», а «видовое многообразие» сервисов раскрыло нам глаза.

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

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