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

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.

Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

Если вы работаете с системами для управления корпоративным контентом, то понимаете, что главная их проблема — это недостаточный уровень производительности. То, что прекрасно работает на 20 документах, тормозит и выдает ошибки на 2 млн. Как узнать об этой проблеме до того, как система сдана клиенту в промышленную эксплуатацию? Ответ: провести нагрузочное тестирование.

Привет! Мы — Владимир Семенов, старший системный архитектор LDM (входит в холдинг LANSOFT), и Олеся Панкова, инженер по нагрузочному тестированию. В нашей статье — не сухие цифры из отчета, а экспертиза инженеров команды.

Мой мемный сервис «Шакализатор» победил в премии Яндекс Практикума, но меня больше интересовал другой вопрос: как VPS с одним ядром и 1 ГБ RAM пережил 1,2 млн запросов за сутки?

Серверную часть в основном писал Codex, а я во время наплыва обновлял статистику и ждал падения. Теперь разбираю код, логи и серверные срезы: что именно спасло систему, где нам просто повезло и почему миллион запросов оказался не тем, чем кажется.

Меня зовут Сигида Алексей, я старший архитектор по развитию технологий CVM (Customer Value Management) в компании Мегафон. Много лет решения о том, что показать клиенту, у нас принимал Teradata RTIM (Real-Time Interaction Manager) - движок real-time маркетинга. Если вы когда-нибудь получали смс-сообщение от Мегафона или заходили в личный кабинет в 99% случаев сообщение для вас было подобрано этой системой. Вы заходите на сайт или в приложение, и за миллисекунды решается, какое предложение показать. Логика выбора описывается деревьями принятия решений: запрос проходит по веткам дерева, а условия переходов в узлах - критерии - определяют, к какому сегменту отнести клиента и какое предложение ему подобрать.

В какой-то момент перед командой встала задача перейти на собственное решение. Стало ясно, что RTIM превратился из удобного инструмента в тяжелую гирю на наших ногах. Оставаться на больше нельзя, накопилась критическая масса причин: закрытая архитектура приложения без возможности кастомизации, тотальная зависимость от вендора, стоимость лицензии. В моменты инцидентов оказывались связаны руки, ожидая помощи извне. Фундаментом нового движка стал Go. Нужен был инструмент, стабильно работающий под хайлоад, быстрый, достаточно распространённый, чтобы не было проблем ни с экспертизой ни с экосистемой.

В статье рассматривается планирование ребаланса кластера Greengage DB (open-source fork Greenplum) после shrink, декомиссии и добавления хостов: формальная модель размещения primary- и mirror-сегментов, минимизация числа перемещений, сравнение точных и эвристических алгоритмов и реализация планировщика в ggrebalance

«У нас было две горячих ноды, 75 дев-стендов, 5 видов тестов, горка внешних сервисов, и целое множество тест-кейсов всех сортов и расцветок, а также CI/CD, core-модель, пачка customer-модулей и DBUnit. Не то чтобы это был необходимый запас для интеграционного тестирования. Но если начал делать свой тестовый фреймворк, становится трудно остановиться. Единственное, что вызывало у меня опасение – это Excel. Нет ничего более беспомощного и обреченного, чем тестировщик, который вынужден заполнять 20 листов записей вручную. Я знал, что рано или поздно мы перейдем и на эту дрянь». © Хантер Томпсон, если бы работал гонзо-тестировщиком

Привет, Хабр! Меня зовут Настя Кензина, я – QA-инженер в компании HFLabs и занимаюсь тестированием CDI (Customer Data Integration) — системы управления клиентскими данными. В этой статье я расскажу, какие сложности накопились у нас за годы эксплуатации и развития тестового фреймворка, в чем минусы табличного хранения тестовых данных, и какое итоговое решение выявленных проблем мы для себя нашли.

Привет, Хабр! В день, когда весь мир в очередной раз обсуждает «умные» ассистенты, генеративные сети и спорит, заменит ли ИИ разработчиков, хочется немного сместить фокус. Генеративные модели — это вершина айсберга, но весь его вес держится на менее заметном, куда более приземленном ИИ: на системах, которые ежедневно переваривают терабайты данных, считают сложные модели и обслуживают высокопроизводительные вычисления. Меня зовут Вячеслав Дегтярев, я руковожу развитием продуктовых решений в К2 НейроТех, и в этой статье мы как раз поговорим об этой «инженерной» стороне искусственного интеллекта — инфраструктуре и платформах, без которых никакой модный LLM или ассистент в IDE просто не взлетит в проде.

16 июля, во Всемирный день ИИ, особенно заметен разрыв между хайпом и реальностью: с одной стороны — обещания «магии» генеративного ИИ, с другой — очередной упавший инстанс с CUDA-конфликтом и рабочий день, потраченный на согласование доступа к GPU-серверу. Поэтому я предлагаю поговорить о критически важном уровне ИИ — готовой инфраструктуре для ML, которая просто работает и позволяет командам дата-сайентистов запускать эксперименты, а не заниматься администрированием. Ниже — о том, как мы подошли к задачам ИИ и высокопроизводительных вычислений через ПАК‑ML и как организована современная зрелая инфраструктура для внедрения технологий искусственного интеллекта в enterprise-мире.  

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

#[derive(Serialize, Deserialize)] это какая-то одна строка в коде. На холодной сборке за ней прячется двадцать с лишним секунд компиляции, даже если в проекте больше ничего нет. Откройте cargo build --timings на любом не самом маленьком проекте с serde, и serde_derive почти наверняка окажется в первой тройке самых медленных крейтов. При том что в самом serde_derive всего несколько тысяч строк.

Между этой строкой и этими секундами лежит вся инфраструктура процедурных макросов: TokenStream, syn, quote, proc-macro2, watt. Пройдёмся по ней в этой статье.

Модуль ядра может собраться без предупреждений, успешно загрузиться и несколько минут выглядеть полностью исправным. А потом под нагрузкой поймать гонку, зависнуть на блокировке или уронить всю систему. Разберём пять типичных ошибок, которые не видит компилятор, но хорошо видит продакшен.

Привет, Хаброжители! «Книга с кабанчиком» — вы наверняка слышали о ней? Бестселлер Мартина Клеппмана, изданный почти 10 лет назад, знают и любят все, кому приходится строить высоконагруженные системы, обрабатывающие огромное количество запросов.

Хотим сообщить всем заинтересованным: мы открыли предзаказ на книгу «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд.». Новое издание значительно переработано под современные реалии. Наибольшие технические изменения связаны с развитием ИИ и облачных архитектур. Хотите узнать, что в нем изменилось? Расскажем коротко.

GPU-версия ByteTrack, где математика всех камер считается общими батчами: один вызов на все потоки вместо трекера-на-камеру. На 16 потоках это ускоряет трекинг в 6 раз (104 → 17 мс/кадр на RTX 4090). А за первой, «наивной» версией пряталось всего 1.2x — почему, показали три антипаттерна PyTorch, на которых легко застрять и вне трекинга: GPU-вызовы в цикле, заливка кадров на 1.6 ГБ/с вместо 25, и FP16, который тихо съедал по 300 мс на кадре. Все цифры воспроизводимы, есть сравнение с NVIDIA DeepStream и открытый код.

Первая статья из цикла «Аналитик в чужом процессе»

145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.

В статье разберём, как Pact закрывает этот разрыв между модульными и E2E‑тестами, как устроены consumer‑driven контракты, Pact Broker и can-i-deploy, и что нужно учесть, чтобы contract testing действительно останавливал несовместимые релизы, а не создавал новую точку боли.

Kafka часто появляется на System Design интервью, когда нужно асинхронно обрабатывать события и масштабировать систему.

Но за словами “добавим Kafka” скрывается много важных деталей: как выбрать ключ, сохранить порядок сообщений, распределить разделы между потребителями и не создать горячий раздел. В статье рассмотрим архитектуру Kafka, репликацию, смещения, повторные попытки и политики хранения.

Привет, Хабр! В этой статье я расскажу об эволюции подсистемы сериализации one-nio — фреймворка для создания высоконагруженных сервисов, работающего в Одноклассниках с 2012 года. Прошлой осенью я работал над обновлением подсистемы и добавил в нее новый режим работы, совместимый с актуальными версиями JDK.

Ситуация, с которой мы столкнулись, довольно прозаична. Библиотеке больше десяти лет, и экстремально быстрая сериализация (превращение объекта в последовательность байтов и обратно) с самого начала строилась в ней на внутренних лазейках JVM, к которым обычный прикладной код доступа не имеет. Когда one-nio только писали, это был стандартный паттерн для высоконагруженных фреймворков.

Сейчас же платформа методично «закручивает гайки»: старые бэкдоры помечаются как устаревшие, а затем безжалостно удаляются. И перед нами встал серьезный вызов: как перевести библиотеку на легальные API вплоть до JDK 25, сохранив производительность и не сломав то, что годами крутится в проде?

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

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

Не будем объяснять базу, но все знают, что магнитные головки HDD, прицепленные с одного конца "коромысла", приводятся в движение магнитной катушкой "Voice Coil" зажатой между двух неодимомых магнитов с другой стороны (а в современных дисках есть ещё и точный "доворот" пьезоэлементами на конце, недалеко от самих головок). Когда HDD надо переместить БМГ (Блок Магнитных Головок) на другую далёкую дорожку, он подаёт на Voice Coil резкий импульс тока, чтобы сорвать массивную металлическую конструкцию с места в нужном направлении, а потом ещё один обратный импульс тока для резкого торможения. Если посмотрите на фото БМГ, то поймёте как велика Voice Coil во всей этой конструкции и что ускорения и торможения происходят с довольно большими перегрузками. Это как если бы автомобиль весом 1.5 тонны разгонялся до 100 км/ч за 0.05...0.1 сек, а тормозил со скорости 100 км/ч на дистанции 1 метр и человек массов 80 кг потяжелел бы до 4 тонн. Если головки нужно перемещать в диапазоне до 50 дорожек, то Voice Coil не работает, достаточно пошевелить кончиком с головками с помощью пьезо-актуатора, который умеет гнуть металлический конец "коромысла" на 1...5 микрометров. И прыгать за 8 миллисекунд нужно не между тысячами дорожек, а по всей поверхности блина от края до края.

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

Как одна фича сократила число системных вызовов на TUN-интерфейсе моего VPN почти вдвое — а на bulk-трафике до 44 раз.

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