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

Привет! Меня зовут Влад, и я разрабатываю сердце витрины 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 и часть межсервисных интеграций.

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

Иногда в архиве нашего сервиса анализа планов запросов к PostgreSQL встречаются примеры не очень эффективных, мягко говоря, запросов.

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

Традиционным оверклокингом сегодня никого не удивить. Даже если вы не большой профессионал, для вас не составит особого труда немного поколдовать с множителем или напряжением и поднять производительность сборки без апгрейда самих комплектующих. Но экстремальный разгон – это совсем другое. Тут можно неделями подбирать стабильную конфигурацию, настраивать систему и заливать каждый компонент, который хоть как-то влияет на результат, жидким азотом. Чего ради, спросите? Ради цифр, конечно. Все ради них.

8 ноября американский оверклокер AiMax установил новый мировой рекорд, разогнав память Patriot Viper Xtreme 5 до 13 211 МТ/с. 

ИИ вывел IT-индустрию в область физических пределов: энергии, охлаждения, поставок GPU и регулируемости данных. В этих условиях инфраструктура перестаёт быть обслуживающим сегментом и становится системным ограничителем всей цифровой экономики. Это текст о том, почему роль инфраструктурных компаний меняется не из-за хайпа на AI, а потому что физические и юридические лимиты растут быстрее, чем технологии, которые пытаются их обойти.

В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz. 

Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.

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

Привет! Меня зовут Андрей Пелешок, я инженер L3 команды PaaS в Cloud.ru. Я отвечаю за работу платформенных сервисов и за поддержку инфраструктуры.

Вы, скорее всего, сталкивались с вопросом: «Какую видеокарту выбрать для Inference, чтобы обеспечить баланс между производительностью, стоимостью и доступностью?» Проблема выбора осложняется тем, что многие материалы сосредоточены на обучении (Training), а для Inference требования отличаются.

В статье попробуем разобраться в чем разница между Training и Inference и ключевых критериях выбора GPU. Еще я приведу сравнительный анализ решений (H100, A100, V100) и предложу методику выбора на основе реальных кейсов.

YDB — отказоустойчивая геораспределённая СУБД класса Distributed SQL. Она появилась в недрах Яндекса более десяти лет назад и прошла длительный путь от узкоспециализированного хранилища, применявшегося в поисковом движке, до полновесной СУБД общего назначения. Открытие исходного кода YDB в 2022 году стало одной из наиболее ярких опенсорс-инициатив Яндекса.

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

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

Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. В современной разработке программного обеспечения всё чаще встречаются распределённые системы и микросервисная архитектура. Один из ключевых инструментов, обеспечивающих надёжное и масштабируемое взаимодействие между сервисами, — это Apache Kafka — распределённая платформа потоковой обработки и передачи сообщений. Для специалиста по обеспечению качества понимание принципов работы Kafka критически важно.