РИТ:Высокие нагрузки-2008 (Отчет Стаса Фомина)

Подстраницы (17) →

Замечания и предложения направлять автору.

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

Сразу замечу, хотя явно вроде не указано (в списке спонсоров-соорганизаторов десятки значков участников, даже «udaff.com»), что эту конференцию (highload.info, не путать с highload.ru) было бы правильней именовать «Яндекс:Нагрузки», ибо практически «контрольный пакет» всех докладов был от «Я», также было немало Я-участников в узнаваемой униформе креативных футболках. Похоже Яндекс тут был ключевым организатором, и ничего плохого в этом факте нет. Может стоило тогда так и назвать конференцию и провести ее на самой территории Яндекса, с экскурсиями по машинному залу и т. п. Когда-то (1999) я был в серверной Яндекса, но сейчас, думаю, там все сильно круче.

Общие соображения

Понравилось

• Огромные плазменные телевизоры в залах. Лучше, чем проекторы, особенно лучше, чем «проекторы с тыльной стороны экрана» (были такие на РИТ-2008, убивали все цвета в ноль).
• Специально выделенное время (порядка 15 минут на доклад) на вопросы. Зачастую интересуют именно вопросы (даже не всегда ответы), чтобы уловить, что интересует сообщество.
• Добираться метропешеходу вполне терпимо (по сравнению с дырой типа Крокус-сити). Претензии автовладельцев имеет смысл посылать лесом, ибо в Москве автомобиль уже давно ни роскошь, ни средство передвижения.

Update: Сейчас, когда в Крокус-сити провели Крокус-метро, аргумент снимается.

Проблемы и предложения

• Наверно все отметят, что один мужской половой унитаз на всю конференцию и веселая очередь встречающая входящих игривым восклицанием — «Высокие нагрузки!» — не есть гуд.
• Были заявлены бесплатные места для студентов, и у нас была красивая студентка, которую мы намеревались взять с собой. Однако, организаторы слишком поздно прислали ей приглашение (только в понедельник его получила), у нее уже сложились планы и переигрывать было поздно. В результате не попала, а жаль — это была большая потеря, таких был явный дефицит.

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

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

День первый

Что такое нагрузка

• Анатолий Орлов
• Презентация — искореженная, но пару цифр найти там можно.

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

• Диски, память, сеть. Кэш, кэш, кэш.
• Прочувствуйте «физику» процесса, подивитесь огромному GAPу эффективности диска на последовательном и рандомном доступе.
• Мимоходом «похоронены» SAS/SCSI диски — их удел только в «кеширующих» машинах с высоковероятным рандом-доступом, а в основном нечего выделываться, берите обычные SATA и используйте правильные алгоритмы (сортировки дисковых массивов — только слиянием и т. п.).
• RAIDы вроде тоже заругали (или в другом докладе, не помню) — смысл, что надежность должна обеспечиваться уровнем выше, типа вместо 3 живучих «Тигров» пусть будет 30 Т-34.
• По памяти и CPU был тезис, что хотя многопроцессность была отстой, современная многотредовость рулит (тредов должно быть не меньше, чем дисков плюс процессоров, а еще лучше заложить запас).
• AMD с привязкой памяти к процессорам must die.

О проектах, отягощенных производительностью

В Яндексе разработчик – творческое начало, создающее проекты, отягощенные нагрузкой.

• Презентация, существенно более полная, чем была на докладе.

Очень ценный доклад, наиболее профильный для нашей компании. Докладчик сразу отметил, что сейчас есть два самых распространенных полюса систем:

• общедоступная вебсистема, дофига пользователей, большие объемы, куча транзакций, никакой сложной логики, пофиг на отказы (нажмите Refresh, если что не нравится и т. п.)
• корпоративные системы — сложная логика, то есть одна транзакция дает движение в куче таблиц-счетов и т. п., и вообще объем кода в строчках и человеко-годах огромен. Ошибаться нельзя, падать нельзя, но нагрузка плевая.

Но есть и редкий третий тип. Речь зашла о редких высоконагруженных «бизнес-логичных» системах (такие имеет смысл ловить наверно только в ЖКХ — офигически сложные расчеты всяких там льгот, куча транзакций и т. п.), или какой другой массовый биллинг (телекоммуникационный). Банки думаю не — кроме яндекс.денег, любой интернет-банк по нагрузке отдыхает.

Ну а дальше докладчик прошелся по всем аспектам разработки таких систем, разрушая мифы, раздавая эпитеты и приговоры различным технологиям:

• СУБД кроме Oracle, DB2, MySQL и PostgreSQL — ересь,
• Oracle DBA зажрались и в массе лохи,
• Микрософтовский стек ASP.NET+MSSQL — дорого из-за серверных лицензий.
• Java есть современный надежный Cobol, и это есть хорошо. Вообще «убогость языка — бонус к надежности».
• С# сам по себе ничего, но развертывание дороговато, (в основном за виндовс-сервер-лицензии).
• Python прет (особенно Django), возможно будущее за Java+Python.
• Всех (обоих) творцов на Erlangе гнать-избегать,
• RoR — тормозит,
• двухзвенка масштабируется отстойно (привет «Oracle и PL/SQL» подходу), по сравнению с трехзвенкой, потому что кэш СУБД слишком тупой-низкоуровневый.
• нефиг выделываться с XML-сериализацией — CPU на ветер.

Другие мысли:

• на инфраструктуру не больше 10 % прибыли.
• автоматизация тестирования вебформ — обязательно.

В общем, наверно самый полезный для нас доклад, надо дождаться видео (я даже запросил DVD-диски, может пришлют), и смотреть всем.

Диски не прислали.

Как писать высокопроизводительные сервера

• Презентация

Жаркий дискуссионный вопрос. Давным-давно, во времена первого апача, порождавшего при обслуживании пул с трудом переключаемых процессов, все уяснили, что переключение контекста процесса есть штука чудовищно дорогая, и ее надо минимизировать. На помощь пришли методы телекоммуникационщиков из систем реального времени — никакой многозадачности с планировщиком («кузнец нам не нужен»), должна быть однопроцессная система с конечным автоматом (FSM), обрабатывающем события. На таких принципах реалован очень популярный вебсервер статики nginx. Но много минусов — кроме статики он ничего не умеет, стандартные вебфреймворки к нему не прикрутишь.

Автор же доклада принес благую весть — треды в apache2 уже достаточно эффективны и хороши, можно держать их тысячами и пользоваться всеми благами апача (или они пока только в BSD хороши, а в линуксе тормозят — уже не помню, но это не принципиально).

А если применить собственный механизм переключения облегченных тредов (которых обозвали «зелеными тредами», «ко-рутинами»), то вообще никакого проигрыша конечному автомату не будет. Да, у этих корутин есть некоторые болезни (для переключения используется тот же механизм, что для обработки C++ исключений, поэтому от исключений придется отказаться), но в целом, это прогресс и возможно гвоздь в гроб идеи FSM.

Ну еще известна шизофреничная сложность отладки программы с тредами, на что докладчик искренне удивлялся — «зачем отлаживать? не проще ли писать без ошибок?».

Вроде как проверено на крупных яндекс-проектах, типа краулера и верхнего уровня поиска.

Была жесткая дискуссия, требовали доказательств, цифр, корректного эксперимента.

Я лично склонен поверить докладчику. Причем с корутинами думаю не столкнусь, а то что апач2 с тредами хорош (пусть даже чуть хуже FSM) — это хорошо, возможно альтернативы ему отомрут сами со временем.

HCS — система хранения данных в Рамблере

• Презентация и видео

HCS (Hierarchically Compressed Stream) — некая библиотека для реализации некоторой алгебры операций (слияния, фильтрация, агрегация,…) над сверхбольшими плоскими файлами. (10¹¹ строк, 10Tb/ 200Gb обновлений в день).

Работает быстро (сравнивали правда с неоптимизированными движками MySQL), но, насколько я понял, это не параллелиться (а ведь есть Hadoop, который вроде как можно было бы применить для этих задач).

Вроде готовится к публикации в опен-сорс.

Примечание два года спустя — так и не выложили.

Сервис хранения данных на базе SQL Server Data Services

• Аннотация+видео

Маркетинговый доклад. Верный признак «чисто маркетинга», когда всякие «архитектурные» картинки рисуются блоками с градиентной заливкой, всякий гламур и анимация на слайдах. По сути некая компиляция whitepaperов разных технологий (SaaS, DaaS, PaaS,… все модные buzzwords, все в кучу).

Интерес (судя по заполненности зала) был слабоват.

Проблемы работы с большими объемами реляционно слабосвязанных данных в высоконагруженных веб-проектах

• Аннотация и видео

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

В общем и новизны нет, и не похоже, что решение оптимально и вообще адекватно задаче.

Насколько я понял, это ребята из команды пытавшейся оптимизировать наследие Фицпатрика, что им так и не удалось, и в результате все они покинули проект.

Масштабирование системы баннерной рекламы с централизованной базой данных

• Презентация

Несколько топорная (без гениальности, изящества, и т.п.) реализация баннероторговли и баннеропубликации на Oracle.

Зачем там Oracle — совершенно непонятно, скорее всего унаследованный код финансовых модулей на PL/SQL, которых лень переписывать, вокруг чего начали воротить все остальное. Ибо надежность там не нужна, транзакционность и немедленность реакции — тоже (грузят апельсины бочками данные SQLLoaderом), вообще как-то все ---. Похоже еще есть момент экономии на лицензиях (другой логики для централизованности СУБД я не вижу).

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

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

День второй

Sphinx в примерах и задачах

• Презентация и видео

Мне ужасно стыдно, но я проспал и пришел только к концу. Хотя тема явно интересная, уже есть два эффективных бесплатных и опен-сорс движка полнотекстового поиска — Sphinx и встроенный поиск PostgreSQL (Lucene таки тормозной). Очень интересно кто-кого, и даст ли «синергию» конкуренция и перекрестное опыление.

Например в некоторых наших внутренних MySQL-системах я уже подключил Sphinx для поиска, в некоторых — думаю подождать и сразу перейти на PostgreSQL, и делать полнотекстовый поиск с морфологией напрямую в БД.

На PostgresQL не перешли, но в трекере теперь используем полнотекстовый поиск MySQL (с морфологией), в принципе, тоже неплохо.

Организация асинхронной обработки задач

• Презентация.

Частично опоздал, но в целом доклад не оправдал моих ожиданий. Судя по названию можно было бы ждать опыта использования специализированных продуктов — от вендоров, типа Oracle Advanced Queuing (в тезисах говорилось про оракл), IBM WebSphere MQ,…, а может даже и опен-сорс. Увы, рассказали о простом самодельном решении на оракле (очереди на дорогой и жирной РСУБД). Как-то невозбуждающе.

Практическое использование Hadoop в системе интернет-статистики

• Презентация

Разумное и модное решение задачи параллельной обработки и агрегации логов посещения сайтов. Используется фреймворк Hadoop (параллельные вычисления в парадигме map/reduce), который для таких задач вроде как идеально предназначен, и в общем-то единственно доступный (опен-сорс), ибо гугловый аналог закрыт, а больше вроде ничего нет.

Кластер относительно небольшой (12 восьмиядерников с 8Gb памяти), но справляется. Два прохода:

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

Ну и всякие там хитрости, вроде все разумно. Опять таки, убьют наверно баннерорезки и этот бизнес.

CAS — сервер приложений C++

• Статья.

Как-то не. Ждал «сервер приложений на C++». Оказалось, «не сервер», «не приложений», «не C++». То есть ребята написали очередной шаблонизатор, для вызова из скриптовых языков. Вроде как быстрый (судя по картинке-гистограмме с неподписанными осями и без единой цифры), но как-то не то, что ожидалось.

Насколько я понял, им он позарез нужен, чтобы спасать от высоких нагрузок написанное на перле поделие Бреда Фицпатрика, что же, посмотрим.

Но я в общем, не в теме, шаблонизаторы меня если интересуют, то не с точки зрения максимальной производительности, а с точки зрения максимальной гибкости и удобства для разработки и модификации. Т.е. я готов например, согласится, что XML/XSLT, и Template Toolkit — не ОК, но не знаю, действительно ли все настролько плохо, что нужно изобретать свой велосипед.

Виртуализация в среде highload servers

• Видео.

Вроде по содержанию маркетинговый доклад, подвигающий фишку виртуализации от SWSoft — вместо выполнения виртуальных машин целиком (VMWare, Hyper-V, Virtual PC, VirtualBox, …), на хост машине размещается одно ядро операционной системы, а виртуализуется все остальное — файловая система и все что на ней.

Для маркетингового доклада выглядел как-то вяло, но оказалось, что докладывал не маркетолог, а инженер техподдержки (для него это нормально).

Выгоды сферической виртуализации в вакууме понятны, угрозы тоже (взлом виртуальной машины высоковероятно приводет к взлому машины хостера, и конец всей сотне виртуальных машин). См. например An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments. Да и без всяких взломов, как выяснилось, трудно рулить физическими ресурсами — например можно ограничить виртуальную память каждой машине, но живую память квотировать нельзя — соответственно одна «оборзевшая» виртуальная машина может поставить «раком» остальных.

Сравнений с конкурентами тоже не было. Но тема интересная.

Application Streaming

Жесткий маркетинговый («парилово») доклад от ENDEAVORS (доклада кстати, не было в программе — вероятно это такой вот метод инкорпорирования «джинсы» в конференцию). Презентация с гламуром и анимацией, причем разработанная видимо зарубежом — ни слова по-русски (даже не локализовали).

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

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

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

Архитектура Photofile.ru

• Видео (тот же доклад на другой конференции), докладчик.

История эволюции архитектуры фотохостинга, от совсем любительской (на одном сервере), до более-менее масштабируемой. В деталях, как появлялись разные узкие горла, и какими эвристиками с ними боролись — как включали второй сервер, как перетаскивали файлы, оставляя на их месте симлинки, как делали шардинг через Dynamic DNS и т.п.

Алсо, ругали Cache Smarty.

В общем, с появлением таких монстропроектов, как «я.фотки», «netprint.ru», с огромным машинным и человеческим ресурсом, с изначально масштабируемой архитектурой, фотофайлу наверно высокие нагрузки более не угрожают.

Архитектура и реализация сервиса печати фотографий netprint.ru

Крутые парни. Большой промышленный проект — практически уже монополия на фотопечать (почти все фотохостинги печатающие фотки, печатают через них). Типичный пример, как централизованный онлайн-сервис убил все кустарные лаборатории.

Архитектура — Java, вроде как разваленная на вебсервисы (JMS), плюс PHP+XCACHE+LightHttpd для вебморды. Кстати, опять таки PostgreQL.

Максимальная асинхронность, все операции не более константной сложности, причем константу загоняют до нижнего предела:

• вместо удаления — пометка об удалении, удаляет специальный демон потом;
• перекодировка изображений — написали сами оптимизированный под Intel код, вроде как порвал ImageMagick в десятки раз.

Ребята не ведутся на марки, тренды и авторитетов:

• бэкап делают на ленты, ибо посчитали, что чуть дешевле (для новых систем вроде как ленты лет уж пять как похоронили общемировым консенсусом).
• опять таки самописная обработка изображений,
• RAID — sucks.
• тренировки по восстановлению в формате «внезапная пожарная тревога» (может шутили?),
• изучение поведения системы под нагрузкой в дни естественных пиков (пост-праздники, НГ).

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

Решение проблем высоких нагрузок на примере проекта Яндекс.Фотки

• Видео

Сервис очень хороший, и докладчики наверно хорошие (редкий зверь — два докладчика, практически «парный конферанс»), но доклад вызвал раздражение и аллергию.

Презентация намеренно сделана «банально-попсовой», символы архитектуры заменены всякой порнографией (типа женский бюст — Cisco, банан с двумя апельсинами — сами додумайте и т.п.). Плюс дурацкие фото, как эмоциональная иллюстрация идей. Что-то похожее я видел на презентациях с конференции автоматизаторов торговых сетей — тупые и тривиальные тезисы слайдов засыпаны содержимым с fishki.net чуть более чем полностью.

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

А так типа все круто, масштабируемость, распределенные датацентры, супернадежность (мониторинг мониторинга) — остальным фотохостингам остается или закрыватся, или искать нишу (ЕВПОЧЯ).

Доставка контента пользователям

• Презентация
• Статья

Обнаружил, что есть сервис smotri.com, позиционирующийся как самый крутой в рунете. Вообще в этой теме (протоколы передачи видео и т. п.) практически не разбираюсь, посмотрел архитектуру — местами «стандартно фотохостинговая», местами есть специальные гитики.

Средняя температура по больнице — 4 минуты на ролик, 250Кб/сек — доставка. Отметил, что пользуются WebDAVом для трансляции операций по загрузке и редактированию и не жалуются.

Слегка возбудился, когда докладчик начал утверждать, что маршрутизацию оптимального пути от хранилища видеоконтента до потребителя делают стандартным алгоритмом кратчайших путей на графе с весами обратными пропускной способности — очевидно должна получатся фигня. Тут надо либо специальный BFS-алгоритм использовать, либо вообще, учесть загрузку от передаваемых потоков, может даже линейным программированием попользоваться… — но оказалось (в беседе с автором), что там вообще все на глаз — просто «эксперт» разбрасывает целые оценки ребрам (плохой канал — побольше, хороший — поменьше), а потом кратчайшие пути.

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

Примечания и ссылки

• WebPlanetный обзор конференции

---

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