Серверная оптимизация *

Рано или поздно один сервер перестает справляться. Вы можете купить ему больше памяти, больше CPU, более быстрые диски (вертикальное масштабирование), но в конце концов вы упретесь в потолок. Самый большой сервер конечен. Горизонтальное шардирование — это признание этого факта.

Это философия разделяй и властвуй, примененная к данным. Вместо одной гигантской таблицы users на одном сервере, вы создаете 10, 100 или 1000 маленьких таблиц users, разбросанных по разным серверам (шардам). Это дает почти безграничную масштабируемость на запись и чтение.

Истории из реальных аудитов, где всё пошло «чуть‑чуть не так».

Мы бываем в десятках компаний в год — от заводов и банков до IT‑стартапов. Кто‑то зовёт нас «для галочки», кто‑то «перед проверкой Роскомнадзора», кто‑то просто «посмотреть, всё ли у нас нормально».

И каждый раз мы приезжаем в уверенную, стабильную, «защищённую» компанию. Админы показывают аккуратные схемы сети, SIEM светится зелёным, политики паролей лежат в папке "ИБ_утверждено.pdf".

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

И самое поразительное - почти никогда нет злого умысла. Только спешка, удобство и уверенность, что «оно же работает, зачем трогать».

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

1. История про Wi-Fi, который слышал всё

Обычный корпоративный Wi-Fi. Для сотрудников — одна сеть, для гостей — другая, через VLAN. На бумаге всё идеально.

Но когда мы посмотрели arp -a, внезапно появился контроллер домена.

Трассировка показала, что гостевая сеть идёт тем же маршрутом, что и внутренняя. А DNS-запросы обслуживает корпоративный DNS с SRV-записями Kerberos.

Любой гость с ноутом в переговорке мог поднять responder, перехватить NTLM-хэши и начать брутить офлайн.

Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.

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

Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.

Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.

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

Рынок серверных процессоров эволюционировал от универсальных решений первых поколений Intel Xeon Scalable до современных специализированных CPU пятого и шестого поколений с встроенными ускорителями. Понимание этой эволюции и правильная интерпретация характеристик процессоров становится критически важным навыком при построении облачной инфраструктуры.

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

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.

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

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

Меня зовут Максим Гончаров, и я расскажу, как мы оптимизировали кодовую базу на C++ по размеру конечного образа, чтобы новые фичи были доступны на всех уже работающих у заказчиков серверах.

Каждая контейнерная платформа — Docker, Podman, Kubernetes — реализует собственную DNS-архитектуру со специфическими особенностями, преимуществами и подводными камнями. Понимание этих различий критически важно для построения надежных и производительных контейнерных инфраструктур. С чем мы и попробуем разобраться в этой статье.

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

Когда мы запускали наш API на Cloudflare Workers, они казались идеальным выбором для сервиса API-аутентификации. Глобальная периферийная инфраструктура, автоматическое масштабирование и оплата только за использование. Разве это не замечательно?

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

TL;DR:

• Мы перешли с Cloudflare Workers на Go-серверы
• Снизили задержки в шесть раз
• Устранили сложные механизмы обхода кэшей и оверхед конвейеров данных
• Упростили архитектуру, перейдя от распределённой системы к простому приложению
• Обеспечили возможность самохостинга и платформонезависимость

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

Привет, Хабр. С гордостью, триумфом и трепетом хотим рассказать вам об одной из наших флагманских новинок, вышедшей в пылающем июле — книге «Экскурс в неопределённое поведение C++».

Cегодня книжные полки изобилуют нестареющими пособиями по C++. Этот язык чрезвычайно важен не только в разработке игр, финансового софта и встраиваемого ПО, но и как основной материал для изучения алгоритмов. Именно поэтому мы даже выпустили две книги-билингвы по алгоритмам, в которых код на C++ соседствует с идентичным ему кодом на Python. Это наш многолетний бестселлер «Алгоритмический тренинг. Решения практических задач на Python и C++» Максима Иванова и недавняя новинка «Базовые алгоритмы. Реализации на Python и C++ на примере классических игр» Павла Довгалюка. Но язык C++ не только очень полезен, но и опасен, так как на этапе преобразования исходного кода в машинный многие решения отдаются на откуп компилятору. Поскольку компилятор в большинстве режимов изначально заточен на оптимизацию кода, он регулярно привносит в код C++ непредсказуемые и порой необъяснимые варианты неопределённого поведения (UB, Undefined Behavior). Титаническую работу по систематизации неопределённого поведения в C++ проделал уважаемый Дмитрий Свиридкин @Nekrolm. В настоящее время он работает инженером по программированию встраиваемых систем в отделе Cloudfront Compute компании AWS. Дмитрий преподавал курсы по Linux и C++ в Санкт-Петербургском государственном университете и Высшей школе экономики, а также имеет богатейший послужной список, в котором есть и олимпиады по информатике, и машинное обучение, и программирование прошивок и, конечно же, выжимание последних капель производительности из самого неукротимого облачного железа. Некоторое время его заметки публиковались на сайте компании PVS-Studio, разрабатывающей известный российский статический анализатор кода. Далее под катом - предисловие Андрея Карпова, а также обзор самой книги.

Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.

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

Это был обычный понедельник. Я пил кофе, проверял почту, и вдруг — волна уведомлений в Slack. «Сайт не грузится!», «Отчеты зависли!», «Что происходит?».

Наш проект, который успешно работал с несколькими сотнями тысяч записей, перешагнул психологически важный рубеж — 10 миллионов строк в таблице заказов. И PostgreSQL, который раньше летал, внезапно начал ползти как улитка.

Всем привет! Меня зовут Константин. Моя карьера в сетевой разработке началась со времен Symbian OS, когда я участвовал в создании сетевого стека этой платформы. С 2010 года я работаю в «Лаборатории Касперского», разрабатывая мобильные и сетевые продукты, а последний год плотно погружен в проект NGFW. В мои задачи входит как проработка архитектурных решений, так и написание кода ключевых модулей. 

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

- об архитектуре передающего слоя (data plane) нашего продукта, основанной на связке DPDK/VPP;
- о пути сетевого пакета в рамках data plane NGFW;
- о частых ошибках при разработке решений на базе VPP;
- о разработке и сценариях встраивания в высокоскоростной конвейер обработки пакетов VPP некоторых из наших движков безопасности;
- об истории создания наших собственных движков безопасности DPI и IDPS (хочу выразить благодарность за неоценимую помощь в подготовке материала для данного раздела коллегам из команды IDPS и лично Евгению Прусову);
- об интеграции data plane с протоколами динамической маршрутизации.

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

Чтобы запускать задачи инференса, рендеринга 3D‑графики или обработку видеопотока нужны параллельные вычисления. Серверы на одних только центральных процессорах не справятся, требуются графические ускорители.

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

Здравствуйте!

В большинстве своём мы не думаем о том, как Go размещает поля структуры в памяти. И правильно делаем, пока наши структуры не используются в миллионах экземпляров, не передаются в каналах или не сериализуются каждую миллисекунду.

Также неправильное выравнивание может негативно сказаться на кеш-памяти процессора и скорости доступа к данным. На 32-битных платформах некорректное выравнивание 64-битных атомарных переменных (например, int64 для sync/atomic) вообще способно привести к панике.

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

В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.

Но эта простота обманчива. Внедрение шлюза порождает свой собственный набор сложных архитектурных проблем. Решить их неправильно — значит построить себе очень дорогую и хрупкую тюрьму.

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

Предыстория

Уже пару лет я собираю коллекцию одноразовых вейпов, полученных от друзей и членов семьи. Поначалу я только извлекал аккумуляторы для «будущих» проектов (это точно не синдром Плюшкина), но в последнее время одноразовые вейпы стали гораздо более продвинутыми. Не хотел бы я быть юристом, которому придётся доказывать, что устройство с разъёмом USB C и перезаряжаемым аккумулятором можно классифицировать, как «одноразовое». К счастью, в ближайшее время я не планирую подаваться в юриспруденцию.

В прошлом году я разбирал одну из этих технологичных сосок для взрослых и заметил нечто любопытное: вместо обычной чёрной капли, которой заливают ASIC (Application Specific Integrated Circuit), я увидел небольшую интегральную схему с маркировкой «PUYA». Не буду винить читателей, если это название не вызвало у вас того же восторга, что и у меня — большинство людей никогда его не слышало. Эта компания больше всего знаменита своими флэш-чипами, но впервые я узнал о них из поста Джея Карлсона о самом дешёвом флэш-микроконтроллере. Это довольно мощные крошечные микроконтроллеры ARM Cortex-M0+.

За последний год у меня скопилось довольно много таких одноразок с PY32; это были разные модели вейпов одного производителя. Я не буду бесплатно рекламировать табачный бренд, но выражу благодарность проектировщику за маркировку на отладочных контактах!

API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.

Привет! С вами Кабанов Олег — ведущий ML-инженер Flocktory.

В этой статье расскажу об опыте внедрения YandexDB в качестве хранилища для ML Online Feature Store. А также о том, как нам удалось ускорить загрузку данных в 40 раз и убрать влияние на скорость чтения данных при обновлении.

Привет, Habr! На связи эксперты команды сервиса WatchDog — Дмитрий Коновалов и Геннадий Переломов.

В ВТБ, у нашего основного заказчика, мы развиваем сервисы автоматизации сопровождения баз данных. Одной из ключевых СУБД в инфраструктуре является PostgreSQL. Поддержка её в актуальном состоянии требует периодических мажорных обновлений, которые остаются одной из самых трудоёмких задач для DBA, особенно в ночные или выходные технологические окна.

В этой статье мы расскажем, как разработали внутренний сервис, позволяющий администраторам прикладных систем запускать мажорное обновление PostgreSQL в один клик и без участия DBA.