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

Рассмотрим практический разбор слабых мест в технических заданиях на разработку систем, сервисов и т.д.

Идеальное ТЗ — утопия, но многие болезненные моменты и конфликты на стадии приемки можно предсказать и минимизировать. Часто они возникают не из-за злого умысла, а из-за слепых зон в документе.

Привет, Хабр! Меня зовут Андрей Комягин, я CTO компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей, включая налоговое администрирование, телеком, track & trace и многие другие.

В своей работе мы широко используем open-source-решения, в том числе Apache Kafka. Этот распределённый программный брокер сейчас применяется практически во всех наших проектах, и сегодня я предлагаю заглянуть внутрь чёрного ящика, чтобы понять, как там всё внутри устроено. В своей работе мы широко используем open-source-решения, в том числе Apache Kafka. Этот распределённый программный брокер сейчас применяется практически во всех наших проектах, и сегодня я предлагаю заглянуть внутрь чёрного ящика, чтобы понять, как там всё внутри устроено.

Этот текст написан на основе моего доклада на конференции SaintHighload++ 2025 в Санкт Петербурге. Так что, если вы были там в качестве слушателя, информация не будет для вас новой. Впрочем, повтор полезного материала никогда не бывает лишним. Поехали!

Я изучаю Kubernetes как часть практики по контейнеризации и автоматизации развертывания. Чтобы системно выстроить понимание, я веду рабочий конспект в формате статьи: фиксирую используемые команды, практические наблюдения и способы решения возникающих проблем. Моя цель — уверенно понимать, как устроен кластер изнутри, и уметь работать с ним в реальных условиях. Эта статья будет полезна тем, кто также начинает путь в Kubernetes и сталкивается с тем, что документация даёт базу, но не всегда описывает полную последовательность действий и типичные ошибки, возникающие в процессе.

Для практики я использую локальный кластер на Minikube — он позволяет экспериментировать с компонентами Kubernetes без аренды серверов или облачных инфраструктуры.

Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.

Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.

Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.

Меня зовут Андрей Серебрянский, и я люблю Apache Kafka. И гарантии доставки exactly once. И рассказывать обо всём этом на конференциях. Пять лет я строил платформы потоковой обработки данных в финтехе, а теперь вместе с командой работаю над YDB Topics: частью YDB (СУБД Яндекса), которая заменяет Apache Kafka в роли брокера сообщений. СУБД Яндекса уже некоторое время поддерживает Apache Kafka API. Недавно мы расширили этот API, добавив поддержку Kafka-транзакций.

Но наличия транзакций в брокере сообщений недостаточно для получения гарантий exactly once. Чтобы неудачно зависший или перезагрузившийся сервер не привёл к дублированию или потере сообщений, нужно хорошо понимать, как именно работают транзакции в брокерах сообщений вообще и в Apache Kafka в частности.

Эта статья будет полезна начинающим разработчикам и тем, кто хочет освежить знания или разобраться в тонкостях exactly once обработки данных с помощью YDB Topics или других брокеров сообщений.

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

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

Переходим к заключительной третьей части регламентного обслуживания баз данных. И сегодня акцент сделаем на обслуживании статистик в СУБД PostgreSQL. Актуальные статистики в PG важны ничуть не менее, чем в MS SQL, но разница в настройках и алгоритмах есть, соответственно, подходы будут чуть различаться.

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

Привет! Меня зовут Влад, и я разрабатываю сердце витрины Ozon — сервис product-facade. Пару лет назад мы уже делились нашим опытом в этой статье, но с тех пор многое изменилось: выросли нагрузки, появились новые фичи и оптимизации, система стала сложнее и надёжнее.

Прежде чем перейти непосредственно к актуальности кешей, давайте разберёмся, почему это так важно. Представьте: вы добавляете товар в корзину, но что-то пошло не так, и покупку совершить не удаётся — склад больше не возит в ваш ПВЗ. Даже 0.1% таких ошибок — это тысячи недовольных пользователей каждую секунду. А когда что-то массово меняется, разработчики вынуждены расследовать инцидент, чтобы понять, что проблема была всего лишь в устаревших кешах.

Если вы задаётесь вопросом, что лучше — Apache Kafka или RabbitMQ, или думаете, что RabbitMQ надёжнее Apache Kafka, хочу сразу остановить вас. Эта статья рассматривает обе системы с более широкой точки зрения и сосредоточится на функциональности, которую они предоставляют. Это поможет вам принять обоснованное решение о том, какую систему использовать и в каких случаях.

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

Привет, меня зовут Иван Волков, я CTO продукта CDN MediaBasket в Wildberries. Это большое распределенное файловое хранилище, используемое различными внутренними продуктами Wildberries. Одним из продуктов, с которым взаимодействуют внешние клиенты, является каталог товаров. Это ставит перед хранилищем высокую планку по оптимизации и готовности к экстремальным нагрузкам. В этой статье я расскажу, какие решения мы использовали в архитектуре продукта и как при миллионном RPS мы доставляем картинки пользователям за считанные миллисекунды.

Современные ML-системы опираются на CPU и ускорители — тензорные или графические. Но их производительность часто ограничена пропускной способностью шины между CPU и GPU: данные приходится постоянно перегонять туда-сюда, и выигрыш от ускорителя нередко тает.

Что если есть архитектура, где этого узкого места нет? RISC-V предоставляет гетерогенность принципиально нового уровня, объединяя ключевые компоненты устройства на одном кристалле, что снимает одно из главные ограничений производительности в ML. Но одних процессоров здесь мало — нужна еще экосистема библиотек.

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

Привет, Хабр! Меня зовут Андрей Саранчин, и я разработчик СУБД Tarantool в VK Tech. Вот уже полтора года мы строим MemCS — новый колоночный движок Tarantool для HTAP. И вот парадокс: даже с индексами иногда не уйти от сплошного прохода таблицы. Поделюсь, почему мы не смогли миновать Sequential Scan и как мы смягчили эту проблему с помощью Data Skipping.

Эта статья написана по мотивам доклада для Saint HighLoad++ и отражает одну из проблем, которую мы затрагивали в этом докладе.

В современных реалиях объёмы данных постоянно растут и появляются всё более жёсткие требования к производительности. Тут традиционный PostgreSQL сталкивается с фундаментальной проблемой: отсутствие нативной поддержки горизонтального масштабирования. 

Сегодня мы, команда платформы данных в Yandex Cloud, хотим рассказать о SPQR — нашем опенсорс‑инструменте, который который создавался как ответ на боль шардирования и эксплуатации крупных OLTP‑систем. Под катом — история о том, что стало отправной точкой для его создания, какие задачи он помогает решать, на чём основано наше решение и что помогает ему быть довольно простым в эксплуатации.

Приложение тормозит. Это жалоба номер один, которую слышат разработчики и архитекторы. Но "тормозит" — это не диагноз. Это симптом. За этим простым словом может скрываться что угодно: от плохо написанного SQL-запроса до "шумного соседа" в облаке или неправильной настройки сборщика мусора.

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

У нас было пять руководителей проекта, семь лет разработки, несколько почти законченных решений, меняющиеся цели, задачи и разнообразные системы всех цветов и размеров. Не то, чтобы это было нужно для успешной реализации, но раз уж начал пилить долгострой, то иди в своём увлечении до конца. Единственное, что меня пугало — это разработка серебряной пули, которая якобы исправит все проблемы. В ИТ нет ничего более иллюзорного, чем попытка разработать универсальную систему для решения всех проблем. И я знал, что мы скоро в это окунёмся.

Для CTO, CIO, DevOps, SRE и эксплуатации в целом

Всем привет!

Если Вы продаете товары или оказываете какие-то услуги, то скорее всего ваши маркетологи уже придумали чем заманить пользователей в черную пятницу. Как пережить всплеск нагрузок без даунтайма я Вам без понимания вашего прода не расскажу, а вот ключевые моменты в виде чеклиста подсветить - это пожалуйста:

Если что-то пойдет не так - Вы должны узнать об этом сразу

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.