Highload++ 2011. Репортаж с места событий.
3 и 4 октября 2011 года в Москве проходила пятая ежегодная конференция разработчиков высоконагруженных систем Highload++.
На два дня конференции было запланировано более 40 докладов, разбитых на два потока. Среди выступавших были представители мировых лидеров (Facebook, Microsoft, Google, Badoo) и флагманов отечественного сегмента отрасли (ВКонтакте, Одноклассники, Mail.ru и др.).
На этот раз стены «Инфопространства» вместили в себя более 700 человек. Эти внушительные цифры ощущались даже физически.
Из бытовых нововведений порадовал огромный экран в холле, который позволял лицезреть докладчика, не отрываясь от приема пищи и праздношатания, а также непрерывно функционирующую фуршетную линию, которая позволяла прием пищи практически не прекращать.
Ярослав Сергеев из Mamba рассказал об эволюции разработки веб-проекта. Особенно о той стадии, когда сил одного технического лидера, управляющего небольшой (до 10-12 человек) группой равноправных разработчиков, начинает не хватать, и необходимы качественные изменения в стркутуре девелоперского подразделения компании.
Чтобы масштабировать разработку, программистов требуется разбить на рабочие группы во главе со старшим разработчиком-тимлидом, каждая из которых занимается определенным направлением и привязывается к определенному product-менеджеру, который отвечает за выполнение поставленных перед группой задач (т.е. у каждого PM'а своя группа).
Важной составляющей успешного процесса также является выделение отдельной группы на support — именна она (а не разработчики) занимается исправлением ошибок после выпуска очередной версии на production (при спорах вмешивается технический директор). Это разгружает разработчиков, которые не отвлекаются от решения последующих задач и потому делают их в гораздо более предсказуемые сроки, что очень повышает удобство и успешность планирования.
Костяк support-группы должны составлять люди с определенным складом характера, любящие такую работу (таких немного, и подобрать этот костяк непросто), но саппорт подходит и для обкатки новичков, ознакомления их с внутренней структурой системы.
Андрей Сас из Badoo похвастался мощностями, пригодными для успешной отправки 100 миллионов писем в день (97% доставка в Inbox, среднее время от события до доставки — 25 секунд).
Добиться таких выдающихся результатов удалось, спроектировав и построив мощную, но достаточно простую систему отправки писем, развернутую на двух географически распределенных кластерах из 10 машин, на разработку которой потребовалось 1.5 человеко-года.
Система работает асинхронно: есть отдельная очередь на генерацию писем и отдельная — на отправку. Состояние обеих очередей включено в мониторинг и отслеживается на предмет переполнений. Андрей утверждает, что грамотная организация мониторинга (включая сбор информации об открытии писем с помощью вставки в них изображений-маркеров с уникальным адресом) — один из ключевых факторов успеха, без которого невозможно организовать качественную работу сервиса.
Письма хранятся в виде физических файлов (управление ими осуществляется манипуляциями на уровне каталогов файловой системы). Поэтому самый главный hardware-ресурс — это диск (в текущей конфигурации используется RAID 1+0 из 4 SSD), загрузка процессора не превышает 2-3% в пике, памяти также хватает немного — 2-4 Гб.
В качестве MTA используются Communigate Pro (быстрый) и Postfix (медленный, но гибкий, бывает нужен для определенных типов писем).
Единственный секрет, который Андрей не стал раскрывать — как все-таки удается спастись от спам-фильтров.
Максим Лапшин выступил с докладом Высокая нагрузка на erlang-приложения: erlyvideo на гигабитном канале.
Видеостриминговый сервер erlyvideo позволяет одновременно обслуживать более 2000 пользователей с одного источника. Добиться такого результата Максиму удалось, призвав на помощь язык erlang, на освоение которого до уровня, необходимого для решения задачи, он потратил всего несколько дней.
Erlang был выбран в силу своих архитектурных особенностей, в частности очень хорошей (практически линейной) автоматической масштабируемости по ядрам процессора и возможности "горячей" отладки (можно внедриться прямо в работающий процесс, не приводя к заметному росту нагрузки).
Отмечатся также высокое качество работы сборщика мусора: утечек не было даже при многомесячной непрерывной работе сервера.
Domas Mituzas рассказывал, как в Facebook готовят MySQL.
При сверхвысоких нагрузках MySQL может давать сбои в самых неожиданных местах. В Facebook, где может происходить до 60 миллионов MySQL-запросов в секунду, об этом знают не понаслышке.
Возникшие проблемы команда из Facebook обычно решает самостоятельно, не дожидаясь исправления ошибок или новых релизов, и выпускает для MySQL собственные патчи. Среди целевых объектов патчей — оптимизация операций DROP TABLE и ALTER TABLE (online schema change), разнообразные детали функционирования InnoDB, работа с диском и многое другое.
Впрочем, Domas назвал несколько приемов, доступных и при использовании обычных версий MySQL. Напримрер, запуск нескольких MySQL-серверов на одной машине, а также плотное использование FORCE INDEX (чтобы избежать ненужного обращения к альтернативным индексам, которые все равно использоваться не будут).
Сейчас в Facebook используют MySQL версии 5.1, но переходить планируют сразу на 5.6.
Ссылка по теме: MySQL в Facebook.
Константин Осипов и Александр Календарев (Mail.ru) представили noSQL-хранилище Tarantool как альтернативу Redis.
По производительности Tarantool находится примерно на том же уровне, что и конкурент (сотни тысяч операций чтения и записи в секунду), но имеет важные отличительные черты в архитектуре.
Tarantool является однопоточным сервером с точки зрения использования процессора. Это делает невозможным масштабирование по ядрам, однако на практике более важным оказываются такие следствия однопоточности, как отсутствие блокировок и конкуренции за системную шину, в результате чего ограничивающими факторами производительности являются пропускная способность памяти и сетевых интерфейсов, а не процессор (на рабочих системах загрузка процессора не превышает 10-20%).
Данные Tarantool хранятся в виде пространств (аналог таблиц в традиционных СУБД) с неограниченным количеством столбцов произвольных типов, в которых хранятся записи в т.н. кортежей, имеющих произвольную размерность и типы полей.
Помимо базовых команд, есть стандартный SQL-интерфейс, а также возможность писать хранимые процедуры на языке Lua, которые выполняются сервером атомарно (без переключения контекста процессора).
Tarantool используется в ряде крупных работающих систем (в т.ч. для хранения сессий Mail.ru: 40 млн. активных пользователей, 80 Гб данных, 2 мастера + 2 реплики, шардинг по user_id).
Официальная страница Tarantool:
http://tarantool.org
Pconnect: граната в руках обезьяны — яркое выступление Сергея Аверина (Badoo Development) на тему того, как может навередить неумелое использование persistent-соединений.
Работа с постоянными соединениями имеет свои подводные камни, о которых в обычной ситуации даже не задумываешься. Подводят исправно служившие в обычной ситуации средства.
Например, зачастую средствами библиотеки нельзя понять, является ли переданное соединение новым или существующим, нет возможности управлять текущими открытыми соединениями, а иногда соединение вообще нельзя закрыть.
Протокол должен предусматривать закрытие соединения при ошибках синтаксиса синхронизации (в противном случае может появляться "полоса сбивки" — битые байты проигнорируются и ответ продолжит читаться, но со сдвигом на неизвестное число байт) и идентификацию запрашивающего клиента (т.к. одно и то же соединение может передаваться между разными клиентами, без таких проверок данные могут попасть не тому, кому они предназначались; например, так в Badoo однажды залогинили 10 000 пользователей не в свои аккаунты).
"Курочка по зёрнышку клюет" — так можно кратко охарактеризовать доклад Андрея Аксёнова о низкоуровневой оптимизации C/C++
Создатель сервера полнотекстового поиска sphinx делился маленькими секретами низкоуровневой оптимизации, которые могут дать большой результат ("1% я беру"): от учета тонких нюансов в работе процессора и памяти до замены switch на if и byte на int.
Эти небольшие оптимизации, сложенные воедино, могут давать ощутимый прирост производительности и делать системы действительно быстрее некуда.
Иван Авсеянко выступил с рассказом о column-oriented СУБД.
Хранение и обработка статистики зачастую требует работы со столь большими объемами данных (характерный пример — журнал посещаемости сайта с милионной посещаемостью), что традиционные СУБД не справляются. Специально для таких задач и предназначено семейство column-oriented СУБД, в которых ячейки данных при хранении группируются не по строкам, а по столбцам (где данные, вдобавок, еще и отсортированы).
Одна из ключевых особенностей таких СУБД — степень сжатия хранимых данных, которая у некоторых из них может достигать нескольких раз (данные, однако, обычно являются read-only, поэтому частые обновления нежелательны; скорость загрузки данных — важная характеристика при практической работе с СУБД)
Другая хитрость — предварительный расчет и хранение результатов групповых операций над данными (которые для этого разбиваются на блоки, для каждой из которых и вычисляются результаты), ведь чаще всего для статистики треуются именно MAX(), MIN(), SUM() и AVG(). Кроме того, граничные значения записей позволяют планировщику определить, какие из блоков данных содержат запрашиваемые значения, и распаковывать только нужные.
Из существующих реализаций были упомянуты InfoBright, InfiniDB и MonetDB, лучшей по быстродействию и функциональности оказалась InfoBright.
Александр Христофоров и Олег Анастасьев рассказали, как в социальной сети Одноклассники хранятся бинарные данные.
Организовать работу с более чем полутора миллиардами фотографий (каждая из которых еще и в четырех копиях разных размерах) общим объемом 200 Тб — задача не из простых. Главными целями при этом являются достижение максимально быстрого чтения и возможность расширения кластера. Поэкспериментировав с различными ФС (Reizer, HDFS, некоторые noSQL-решения) пришли к выводу, что нужно разрабатывать своё. Что и было сделано силами одного человека в течение 3 месяцев с использованием Java (выбор пал именно на Java, т.к. на ней же написаны многие другие компоненты системы).
Минимальная единица оборудования — один диск (а не один сервер). Каждый диск разбивается на сегменты по 256 Мб, принадлежность конкретных файлов сегментам хранится в хэш-таблице, располагающейся в памяти (плюс копия на диске). На каждый диск приходится только один активный сегмент (тот, в который идет запись).
Всего используется 24 физических сервера, фактор реплики - тройка. Маршрутизация (определение хранилища, на котором располагается конкретный файл) осуществляется на основе хэша id. Таблица маршрутизации построена с использованием подхода virtual buckets: пространство хранилищ делается во много раз раз большим, чем их есть на самом деле, и несколько виртуальных хранилищ могут указывать на одно реальное (это позволяет добавлять в кластер новые единицы без необохдимости перестраивать маршрутизацию, а также распределять нагрузку по хранилищам асимметрично, если это требуется).
Слайды презентации: http://www.highload.ru/2011/abstracts/13514.html.
Тезисы всех прозвучавших докладов доступны для скачивания в виде презентаций одним архивом.
© Все права на данную статью принадлежат порталу webew.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции.