Table of Contents
|
Без малого 100 миллионов пользователей — такова аудитория ВКонтакте, которую надо обслуживать. Быстро и без перебоев. Долгое время подробности технической реализации ВКонтакте оставались секретом. Но недавно самая популярная в России социальная сеть пролила немного света на то, как она все-таки устроена. В конце октября в Москве состоялась конференция HighLoad++, на которой представители ВКонтакте в лице Павла Дурова и Олега Илларионова, наконец, рассказали кое-что об архитектуре социальной сети. Парней буквально завалили вопросами по совершенно различным аспектам работы ВКонтакте, в том числе и техническим. Еще бы. Легко представить нагрузку на серверную часть сервиса: как много людей ты знаешь, которые не пользуются этой социальной сетью? А сколько времени ты там проводишь, тратя бесценные часы своей жизни на общение с друзьями, просмотр видео, игры, музыку? Математика довольно проста: баснословное количество пользователей * масса проведенного времени на ресурсе = запредельное количество запросов к веб-серверам и базе данных + терабайты постоянно загружаемых и просматриваемых фотографий, видео и аудио. Взаимодействие участников социальной сети происходит практически в режиме реального времени: все друзья должны немедленно узнавать о том, что произошло с каждым из участников. Сайт должен быть доступен 100% времени. Как это удается?
ПлатформаДля нас, конечно, особый интерес представляет именно архитектура проекта: как взаимодействуют основные компоненты системы, какие собственные разработки потребовались, какими трюками пришлось воспользоваться. Но прежде, чем перейти к ней, необходимо ознакомиться с базовыми вещами — используемыми технологиями и продуктами. В качестве основной операционной системы используется Debian Linux — решение, проверенное временем, один из самых старых и стабильных современных дистрибутивов. Для балансировки нагрузки между серверами приложений используется HTTP-сервер nginx, работающий в режиме reverse proxy. В его обязанности входит держать соединение с браузером пользователя и передавать запросы серверам, ответственным за исполнение PHP-кода, а также контролировать попадание результата обратно в браузер. PHP-код исполняется посредством модуля mod_php для Apache — альтернативных вариантов довольно много, особенно на основе протокола FastCGI, но руководство ВКонтакте пошло по более консервативному пути в этом вопросе, воспользовавшись самым проверенным временем решением. Никаких особых систем оптимизации производительности PHP-кода не используется (например, в Facebook написали свой компилятор из PHP в C под названием HipHop), единственной внешней оптимизацией является кэширование оп-кода посредством всем доступного решения XCache. Ситуация с хранением данных выглядит достаточно размыто: с одной стороны, активно используется собственная система управления базами данных, написанная на C и созданная "лучшими умами" России, с другой — часто упоминалась MySQL в роли основного хранилища. Подробнее про собственную базу данных ВКонтакте я расскажу ниже. Говоря о хранении данных, нельзя не упомянуть о таком важном аспекте, как кэширование часто используемой информации (расположение её в оперативной памяти для быстрого доступа). Для этого используется очень популярный продукт в этой области — memcached. Если ты не слышал: эта система позволяет осуществлять очень простые атомарные операции, такие как расположение и получение произвольных данных по ключу. Основной фишкой является молниеносно быстрый доступ и возможность легкого объединения оперативной памяти большого количества серверов в общий массив для временного хранения "горячих" данных. Сторонние проекты, не являющиеся ключевыми для ВКонтакте, часто реализуются либо с использованием довольно экзотических решений, либо, наоборот, на самых простых технологиях. Например, сервис мгновенного обмена сообщениями реализован на node.js (подробнее об этой разработке ты можешь прочитать в статье "Серверный JavaScript" в ][ 08/2010) с использованием протокола XMPP aka Jabber (мы еще к нему вернемся). Конвертирование видео реализовано на самой простой и эффективной библиотеке — ffmpeg, на ней же работает очень популярный видео-плеер VLC.
АрхитектураСамым заметным отличием от архитектуры многих других крупных интернет-проектов является тот факт, что сервера ВКонтакте многофункциональны. Т.е. нет четкого разделения на серверы баз данных, файловые серверы и т.д. — они одновременно используются в нескольких ролях. При этом перераспределение ролей происходит в полуавтоматическом режиме с участием системных администраторов. С одной стороны, это оптимизирует эффективность использования системных ресурсов, что хорошо, но с другой — повышает вероятность конфликтов на уровне операционной системы в рамках одного сервера, что влечет за собой проблемы стабильности. Впрочем, несмотря на использование серверов в разных ролях, вычислительные мощности проекта обычно используются менее чем на 20%. Балансировка нагрузки между серверами происходит по многоуровневой схеме, которая включает в себя балансировку на уровне DNS (домен обслуживается с помощью 32 IP-адресов), а также маршрутизацию запросов внутри системы, причем разные сервера используются для разных типов запросов. Например, генерация страниц с новостями (теперь это принято называть микроблогом) работает по хитрой схеме, использующей возможности протокола memcached по параллельной отправке запросов на получение данных по большому количеству ключей. В случае отсутствия данных в кэше, аналогичный запрос отправляется системе хранения данных, а полученные результаты подвергаются сортировке, фильтрации и отбрасыванию лишнего уже на уровне PHP-кода. Похожим образом этот функционал работает и в Facebook (они недавно обменивались опытом), только вместо собственной СУБД в Facebook используют MySQL. В стенах ВКонтакте было разработано большое количество софта, который более точно удовлетворяет потребностям проекта, чем доступные opensource и коммерческие решения. Помимо упоминавшейся собственной СУБД у них есть система мониторинга с уведомлением по СМС (Павел сам помогал верстать интерфейс), автоматическая система тестирования кода и анализаторы статистики и логов. В проекте используется достаточно мощное оборудование, ориентировочно были названы следующие характеристики серверов:
Примечательно, что сервера не брендированные, а собираются специализированной российской компанией. Сейчас оборудование проекта расположено в 4 датацентрах в Санкт-Петербурге и Москве, причем вся основная база данных располагается в питерском датацентре, а в Москове хостится только аудио и видео. В планах сделать репликацию базы данных с другим датацентром в Ленинградской области, а также использовать Content Delivery Network для повышения скорости скачивания медийного контента в регионах. Многие проекты, сталкивающиеся с большим количеством фотографий, часто изобретают собственные решения по их хранению и отдаче пользователям. Об этом был первый вопрос, заданный Павлу из зала: "Как вы храните изображения?" — "На дисках!". Так или иначе, представители ВКонтакте заявили, что вся эта куча фотографий всех цветов и размеров просто хранится и отдается с файловой системы (используют xfs) большого количества серверов, без дополнительных изысков. Смущает разве что тот факт, что у других крупных проектов такой подход не сработал — наверное, они не знали волшебного слова :). Не менее волшебной представляется та самая собственная база данных на C. Этому продукту, пожалуй, было уделено основное внимание аудитории, но при этом почти никаких подробностей о том, что он, собственно говоря, собой представляет, так и не было обнародовано. Известно, что СУБД разработана "лучшими умами" России, победителями олимпиад и конкурсов TopCoder, а также что она используется в самых высоконагруженных сервисах ВКонтакте:
В отличие от MySQL используется нереляционная модель данных, а большинство операций осуществляется в оперативной памяти. Интерфейс доступа представляет собой расширенный протокол memcached. Специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса). Система проектировалась с учетом возможности кластеризации и автоматической репликации данных. Разработчики хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами.
ПодпроектыСервисы аудио и видео являются побочными для социальной сети, на них создатели проекта особо не фокусируются. В основном это связано с тем, что они редко коррелируют с основной целью использования социальной сети — общением, а также создают большое количество проблем. Видеотрафик — основная статья расходов проекта, плюс всем известные проблемы с нелегальным контентом и претензиями правообладателей. 1000—1500 серверов используются для перекодирования видео, на них же оно и хранится. Медиа-файлы банятся по хэшу при удалении по просьбе правообладателей, но это неэффективно и планируется усовершенствовать этот механизм. Очевидно, речь идет о разработке более интеллектуального алгоритма распознавания аудио- и видео-контента по тегам, как это, к примеру, реализовано в YouTube, где загруженный видеоролик, нарушающий лицензию, может быть автоматически удален уже через несколько минут после загрузки. Как известно, некоторое время назад появилась возможность общаться на ВКонтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций. По ряду причин (среди которых проблемы интеграции с остальными сервисами ВКонтакте) было решено за месяц создать собственный сервер, представляющий собой прослойку между внутренними сервисами ВКонтакте и реализацией XMPP протокола. Реализован он на node.js — выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, к тому же это хороший набор инструментов для реализации задачи. Сложным моментом стала работа с большими контакт-листами. У многих пользователей количество друзей ВКонтакте измеряется сотнями и тысячами, высока активность смены статусов: люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях. К тому же необходимо было реализовать тесную интеграцию с внутренней системой обмена личными сообщениями ВКонтакте. В результате на сервисе 60-80 тысяч человек онлайн, в пике — 150 тысяч. TCP/HTTP-балансировщик нагрузки HAProxy обрабатывает входящие соединения и используется для распределения запросов по серверам, а также развертывания новых версий. При выборе системы хранения данных думали о нереляционных системах хранения данных (в частности, о MongoDB), но в итоге решили воспользоваться привычной MySQL. Сервис функционирует на 5-ти серверах разной конфигурации, на каждом из которых работает код на node.js (по 4 процесса на сервер), а на трех самых мощных — еще и MySQL. Интересной особенностью является отсутствие связи между группами друзей в XMPP с группами друзей на сайте — сделано по просьбе пользователей, которые не хотели, чтобы их друзья из-за плеча видели, в какой группе они находятся. Важным подпроектом является также интеграция с внешними ресурсами, которую в условиях высоконагруженного сервиса реализовать далеко не так просто. Все чаще на страницах сторонних проектов можно увидеть виджеты "Мне нравится", позволяющими быстро поделиться интересным постом со своими друзьями, а также небольшие блоки "Мы ВКонтакте" с данными о пользователях внутри привязанной группы. Основные шаги, предпринятые в этом направлении, с небольшими комментариями:
Не секретЗавеса тайны насчет технической реализации ВКонтакте была немного развеяна, опубликовано куча интересных аспектов, но все же многие моменты по-прежнему остаются секретом. Возможно, в будущем появится более детальная информация о собственной СУБД ВКонтакте, которая, как оказалось, является ключом к решению всех самых сложных моментов в масштабируемости системы. Сейчас, как бы кто ни относился к ВКонтакте, сервис является очень интересным с точки зрения построения высоконагруженных систем. Все-таки 11 миллиардов запросов в день, высочайший аптайм и почти 100 миллионов пользователей — дорогого стоят.
|