- PVSM.RU - https://www.pvsm.ru -
На днях в Москве прошла «конференция разработчиков высоконагруженных систем» HighLoad++ [1], участником которой мне посчастливилось стать. Ниже я хочу кратко пройтись по докладам, которые посетил в рамках конференции, выделив в них интересные на мой взгляд моменты.
Сразу предупрежу, что какие-то вещи я мог понять неправильно, какие-то переврать. Если для вас это важно — не читайте этот пост, а приходите на следующую конференцию лично! :)
Доклад начался с истории двухлетней давности, когда я спросил у Паши Дурова, как ВКонтакте хранит пользовательские данные? В тот день Паша ответил «на дисках». С тех пор я его не люблю :) В этот раз Олег (докладчик) обещал ответить на этот вопрос полноценно, посвятив ему целый доклад :)
Изначально все файлы (фотографии) хранились на том же сервере, что и код — в папке upload. Этот подход прост, но имеет два изъяна: безопасность (заливка кода, XSS) и масштабируемость.
Далее ребята озадачились масштабируемостью, организовав следующую схему: файлы заливаются на основной сервер,
а потом переносятся на вспомогательные (предназначенные специально для пользовательских данных).
Каждому пользователю всегда соответствует один и тот же вспомогательный сервер, определяемый по id пользователя.
Однако, у этого подхода есть bottle neck — основной сервер.
Поэтому следующим шагом стала загрузка файлов сразу на контент-сервер без использования основного сервера с приложением. Однако, для реализации такого подхода необходимо ответить на вопрос: на какой именно сервер загружать фотографию?
Поиск и устранение узких мест. Обычно самое узкое место одно — остальное узлы системы по сравнению с ним работают на порядок лучше. Bottle neck'и при хранении большого объёма пользовательских данных могут быть следующие:
В качестве файловой системы используется XFS. Однако пользовательские файлы хранятся не в файловой системе, а в одном большом файле. Файл всегда открыт для чтения, индекс файла хранится в оперативке. Дальнейшее развитие данной технологии ребята видят в полном абстрагировании от физических носителей.
В виду того, что широко распространения WiFi ВКонтакте переходит на HTTPS. Так как серверов с контентом огромное количество — на каждый из них сертификат не купишь (слишком дорого). Поэтому у ВКонтакте стоит несколько серверов, которые проксируют контент через HTTPS.
Что каcается картинок:
Что касается аудио:
Что касается видео:
Вообще у меня сложилось ощущение, что контакт устроен относительно несложно. Несложно, но эффективно.
Доклад о том, как NoSQL используется в Mamba. Особенности рассматриваемой системы заключаются в том, что более 30% выполняемых запросов — инкремент и чтение счётчиков.
Начинали поиск подходящего хранилища для данных как и полагается с Memcache. Не устроило отсутствие персистентности и RAM ONLY. Попробовали Radis — RAM ONLY.
Кроме того при большой нагрузке производительность Memcached падает в 100 раз (Для тестирования нагрузки использовали инcтрумент Brutis).
Долго ли, коротко ли, ребята пришли к использованию TokyoTyrant. Однако, у него внезапно обнаружились проблемы с целостностью БД при выключении сервера из розетки :) Решили их новой разработкой от автора TokyoTyrant — KoytotTycoon. Однако, записать в базу 30М записей не удалось в виду архитектурных ограничений.
Поэтому ребята пошли в сторону LevelDB от Google. В этой БД используется технология LSM-tree. Данные хранятся в SSTable-файлах: отсортированные неизменяемые пары ключ-значение.
Пишутся данные в аналогичную (но уже изменяемую) структуру в оперативной памяти. Время от времени происходит слияние поддеревьев из памяти на диск.
Что бы не отхватить проблем при внезапном отключении питания — пишется Write Ahead Log.
Ребята ещё раз протестировали и получили, что в большинстве случаев библиотека LevelDB на порядок выигрывает у всех используемых ранее вариантов. Сейчас они держат 4700 get/sec и 1600 update/sec при 200М записей в БД.
MultiVersion Concurency Control — механизм, позволяющий reader'ам не блокировать write'ов, а write'ам reader'ов. В общем — значительно уменьшает количество блокировок в БД. Присутствует в Oracle, Mysql InnoDB, PostgreSQl и некоторых других.
Каждая запись в таблицах MVCC систем имеет два атрибута: creaton (xmin) — номер транзакции, в которой запись была создана, expiration (xmax) — номер транзакции, в которой запись была удалена.
INSERT xmin 40, xmax Null DELETE xmin 40, xmax 47 UPDATE xmin 64, xmax 78 / xmin 78, xmax NUll
При выполнении каждого statement'а создаётся MVCC snapshot, который определяет, какие данные в БД видимы/доступны statement'у.
Алгоритм определения видимости строки следующий:
Поля xmin и xmax присутствуют в каждой таблице, но скрыты по-умолчанию. Однако, их можно всегда указать в выборке явно: SELECT xmin, xmax, * FROM test;
Получить id текущей транзакции можно с помощью запроса SELECT txid_current(). Данный запрос выбирает данные из таблицы pg_clog. Важно понимать, что откат транзакции — это просто установка соответствующего маркера для записи о транзакции в этой таблице. Ни какие данные при этом не удаляются. Транзакция просто помечается как откаченная.
Не MVCC CУБД требуют непосредственного изменения данных при изменении или удалении записей. MVCC СУБД лишены этой проблемы — все неактуальные данные чистятся отложено.
Тут хочется добавить от себя, что отложенная чистка (так называемый VACUUM) — не так совершенен, как хотелось бы… но это тема для отдельного разговора.
Кстати, вот сайт докладчика [2], на котором он обещал много интересных статей.
Пожалуй, самое большое разочарование среди докладов. Если коротко, то суть его сводится к одному тезису: «Да, у нас есть слегка пропатченный нами MySQL».
Может у меня завышенные требования, но я ожидал от Корпорации Добра чего-то более интересного.
Крупнейшие проекты: Ads, Checkout и, конечно же, YouTube.
Для дата центров используется не самое дорогое железо, а самое «продвинутое». Комплектующие (диски) приходят в негодность очень часто, но легко и дешево могут быть заменены.
MySQL используется в виде кластера. Для каждой шарды есть отдельный отдельный процесс (decider), который отвечает за выбор нового мастера в случае падения старого.
Heartbeat осуществляется простым скриптом, который пишет некоторые данные в мастера и проверяет их наличие на репликах.
Для того, что бы организовать масштабирование и отказоустойчивость ребята вводят много ограничений на работу с БД. Например, транзакция на запись не может идти дольше 30 секунд. Нужно для того, что бы можно было оперативно сделать мастера из другого слэйва.
SPDY — бинарный протокол поверх TCP/TLS соединения. Является транспортом для HTTP. Разработан Google.
Основные фичи:
Из плюсов: встроенный HTTPS (за счёт TLS), хорошая работа при большом количестве картинок (за счёт мультиплексирования);
Из минусов: работает с одним доменом, как следствие — не поддерживает CDN;
По исследованиям (боевым) WordPress'a: SPDY быстрее HTTPS, но медленнее обычного HTTP.
Доклад представлял собой список интересных, но не всем знакомым фич SQL/PostgreSQL:
Докладчик, кстати, реально опасен: написал с помощью Recursive CTE и Regexp'a парсер JSON'а в Postgres массив одним запросом! :)
«Здравствуйте, меня зовут Андрей, я Воронежское быдло». На этом описание доклада можно окончить :) В общем Аксёнов во всей своей красе.
Основные тезисы:
Мировые константы — важно понимать, какое действие сколько стоит.
Getting started и Hello, World на языке GO.
Утренний опохмел от Андрея Аксёнова :)
В работе Любой поисковой системы можно выделить 4 вехи: получение данных (робот-паук), индексация, поиск, масштабирование.
Индексация включает в себя:
Данные в индексе необходимо сжимать. Сжатие может быть битовым, байтовым, блочным. Чем меньше данных — тем меньше нужно обрабатывать при запросе.
Поиск состоит из двух ортогональных этапов: быстро matching (найти) и качественно raking (отранжироать).
Критерии matching'a могут отличаться в зависимости от области его использования (web, data mining). Что касается ранжирования — оно в принципе до конца не может быть релевантным, ибо релевантность персональная для каждого пользователя. Поэтому для ранжирования используются хитрые алгоритмы типа BM25 (TF, IDF, DocLength), результаты которых по возможности персонализируются.
Что касается масштабирования — поиск требует ресурсов. Поэтому у Гугла миллионы серверов поиска, у Яндекса — десятки тысяч.
Ребята умудрялись использовать fullscan поиск (на MsSQl) при 30М пользователях. На кластере их 16-ти баз один поисковый запрос работал в среднем 15-30 секунд.
Поняв, что так жить нельзя — решили искать решение.
По скольку проект на Java, начали смотреть в сторону Lucene. За 3 года работы с Lucene внесли в него следующие изменения:
Сейчас в инфраструктуре выделен отдельный сервер-индексер, который создаёт поисковый индекс. Индекс реплицируется на query-сервера, которые хранят индекс как на диске, так и у себя в памяти (для обработки запросов используется индекс из памяти). Индексер получает данные через очередь, что позволяет ему быть недоступным время от времени.
Большой недоработкой было отсутствие логики прямого обновления индекса из БД, минуя очередь. Так как некоторые сообщения из очереди иногда пропадали. Эту же проблему я могу констатировать и у себя в компании. Вывод: sanity check при работе с очередями должен быть всегда.
Постоянно находятся в кеше только 5% запросов (самые часто запрашиваемые). Попадание в кеш 60%.
Для персональных запросов создаются временные кеши (по запросу), которые живут несколько минут.
За каждым пользователем на портале закреплён отдельный app-сервер (вычисляется на основе userId). В случае проблемы с сервером пользователь перекидывается на резерв.
Поиск онлайн-пользователей сначала делали по общему индексу, фильтруя по флагу «онлайн» вне индекса. Потом создали отдельный индекс для этой цели.
Обзорный доклад про устройство и цифры Evernote.
Software: Java 6, MySQl 5.1, Debian (Stable), DRBD (распределённая система хранения данных), Xen.
HardWare: SuperMicro 1U, 2x L5630 COU, 96 GB RAM, 6x 300GB Intel SSD, LSI RAID 5 (+ spare) ~ $8000.
DataBase: MySQL, 10TB (peak riops 350, peak wiops 50)
Search engine: Lucene (peak riops 800, peak wiops 50)
Сервера расположены в США и Китае (400 Linux серверов).
Доступ к файлам контролируется через Apache/WebDAV. Данные всегда хранятся на одном хосте и не переносятся. По сравнению с NFS WebDav имеет небольшой overhead, но в разы проще и дешевле в развёртывании и поддержке.
Балансировка нагрузки используется железный балансер A10 with SSL (во внешку смотрит HTTPS, во внутрь проксируется HTTP).
С учётом особенностей сервиса (хранение множества мелких файлов) проблемы и их критичность можно описать следующей таблицей:
/ | size | normal load | peak load |
bandwith | — | medium | medium |
latence | — | low | low |
cpu | — | low | medium |
file size | high | low | medium |
meta data | low | medium | low |
Автор не рекомендует использовать облачные платформы, если ваше приложение требовательно к ресурсам (bandwidth, storage, cpu) или использует их в переменном количестве.
Если возникают сомнения — посчитайте, во сколько обойдётся покупка и поддержка своих серверов под нужды приложения, и сколько это будет стоить у Amazon. В случае с Evernote разница в 1-4 порядка.
Этот доклад я пропустил почти полностью, так как был на обеде :) Из финальной части мне удалось вычленить только пару тезисов.
Самая простая защита от HTTP атак — limit зоны в Nginx. Так же можно обратить внимание на модуль NGINX «testcookie».
Тем не менее важно понимать, что Nginx — не средство от DDOS атак.
Всего атак за 2012 год было >2600 атак (в прошлом году было где-то >1700).
Ботнета в 3000 машин достаточно, что бы завалить среднестатистический сайт. Самый крупный ботнет состоял из 150К машин. Больше всего бонетов живёт в Германии, США, Украине, Казахстан (по убыванию).
Активность DDOS совпадает с активностью e-commerce (ну и немного политики).
Политические DDOS'ы используют ботнеты из Пакистана, Индии (там, куда не добраться правоохранительным органам).
Большинство атак генерирует трафик меньше 1GB (обычная пропускная способность сайта не больше).
При атаке первым делом нужно проанализировать логи (access.log) и сделать слепок трафика (tcpdump -s0 -c1000000 -w attack.dump). Далее нейтрализация атаки: вывести из-под мусорного трафика, заблокировать ip-адреса, с которых происходит атака, сменить IP.
Всегда стоит иметь как минимум 2х-кратный запас производительности сайта.
Особенности российского DDOS — Full Browser Stack (использование реальных браузеров, которые могут пройти все анти-ddos тесты).
Ну и да — если ожидаете проблем, обращайтесь в Qrator :)
Скорее всего доклад был про оптимизацию нагрузок или чём-то ещё. Увы, всё его начало я провёл в туалете :) Упомянуть его я решил только ввиду довольно интересной дискуссии, развернувшейся во время вопросов.
Докладчик упомянул об отсутсnвии какого-либо резервирования и масштабирования на его проекте. Это повлекло сперва довольно неожиданный вопрос: какова бизнес модель вашего сайта? Как оказалось, на проекте докладчика люди платят за доступ к фичам сайта с помощью подписок (на 6, 12, 24 месяца). С учётом того, что факапы, при которых сайт ложится случаются всего пару раз в год, и того, что все пользователи сайта уже оплатили за его использование, — высокая отказоустойчивость есть достаточно дорогая, сложная, а самое главное — не так уж сильно нужная вещь :) Другое дело, если бы монетизация проекта зависела от каждого запроса к проекту! :)
Предполагалось, что доклад будет читать сотрудник Twitter, поэтому лично я ждал доклад с большим нетерпением, предвкушая что-то интересное. Однако, сразу после начала доклада оказалось, что в Twitter он работает недавно и до этого большую часть времени занимался web-оптимизацией. А что бы окончательно добить толпу, расскажет нам про замечательное средство/утилиту/профайлер/плагин для web-оптимизации — YSlow :(
По большому счёту доклад повествует о том, как в Parallels сымплементили свою версию GoogleFS с chunk'ами, серверами метаданных и остальными атрибутами.
Отличительной (для меня) чертой является то, ребята предполагают использование пока ещё дорогих, но быстрых SSD-дисков. В Google, вроде бы, политика сводится к покупке
дешевого железа, которое не жалко выкинуть и заменить.
Основное предназначение виртуализации — разделение ресурсов одного хоста, эффективный бекап и деплоймент.
Лучшее решение для объединение дисков в массив и их последующего разделения между виртуальными машинами SAN storage. Но это дорого, поэтому все используют обычные диски.
В случае журналируемых ФС данные сначала попадают в журнал, а лишь потом на диск. Это нужно для того что бы при внезапном выключении диска мы имели возможность воспроизвести журнал и добавить недостающие данные на диск.
Из доклада запомнилось упоминание о PAXOS алгоритме. Рассматривается греческий остров PAXOS, на котором есть парламент. В парламенте заседают депутаты, которые по совместительству являются и бизнесменами. В виду последнего они очень часто находятся в отъезде так, что в парламенте всегда находится не более половины парламентариев. Связаться с отсутсnвующими можно только с помощью гонцов. При этом парламент должен всегда работать и принимать законы. Кроме того все парламентарии всегда должны быть в курсе последних законов. На сколько я понял, ребята используют этот алгоритм для синхронизации chunk-серверов.
Отключение электропитания можно эмулировать с помощью посылки SIGSTOP процессу. В этом случае приложение на другом конце TCP соединения будет в той же ситуации, что и при отключении питания. Это быстрее, чем реальное отключение питания.
Ребята сделали map/reduce задачу «сервис рекомендаций на сайте» с помощью Hadoop. В пример приводятся их частные пhоблемы и решения, так что написать тут, пожалуй, нечего :(
Обзорный доклад про Maria DB. Форк MySQL полностью переписанный с нуля основателем MySQL, после того, как MySQL перешёл от Sun к Oracle.
В качестве движка по-умолчанию использует XtraDB от Percona. Поддерживает InnoDB.
По сути доклад сводится к Сhangelog'у MariaDB версии 5.5.
Доклад от Oracle. В основном о том, что будет в новых версиях. Своего рода RoadMap MySQl.
В докладе прозвучал ответ на довольно интересный вопрос: почему Oracle поддерживает MySQL? Компания хочет быть представлена на всех рынках, а MySQL покрывает Web, Mobile и Embedded. Кроме того не хочется терять таких клиентов как Facebook и Twitter. Про огромное comunity можно не упоминать :)
Отдельно хочется отметить, что В MySQL Installer for Windows включена утилита миграции с таких БД как MsSQL, Sybase и т.д. К сожалению, она не умеет за одно переписывать весь сопутствующий код проекта. В виду чего её смысл для меня остаётся потерянным :)
Доклад о том, что такое индексы и с чем их едят. В докладе было не мало матчасти и примеров, так что всем, кто интересуется вопросом рекомендую посмотреть презентацию.
Наибольшую ценность на мой взгляд представляют следующие тезисы:
Все презентации доступны [3] на SlideShare.
Пост оставлю без картинок, так как WiFi в кафешке «МуМУ» у Киевского Вокзала не многим лучше, чем местный Оливье :)
Автор: krestjaninoff
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/vy-sokaya-proizvoditel-nost/17875
Ссылки в тексте:
[1] HighLoad++: http://www.highload.ru/
[2] сайт докладчика: http://momjian.us
[3] доступны: http://www.slideshare.net/profyclub_ru
Нажмите здесь для печати.