Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте, в том числе и техническим. Спешу поделиться своим взглядом на архитектуру проекта по результатам данного выступления.

Платформа

• Debian Linux — основная операционная система
• nginx — балансировка нагрузки
• PHP + XCache
• Apache + mod_php
• memcached
• MySQL
• Собственная СУБД на C, созданная «лучшими умами» России
• node.js — прослойка для реализации XMPP, живет за HAProxy
• Изображения отдаются просто с файловой системы xfs
• ffmpeg — конвертирование видео

Статистика

• 95 миллионов учетных записей
• 40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
• 11 миллиардов запросов в день
• 200 миллионов личных сообщений в день
• Видеопоток достигает 160Гбит/с
• Более 10 тысяч серверов, из которых только 32 — фронтенды на nginx (количество серверов с Apache неизвестно)
• 30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
• Каждый день выходит из строя около 10 жестких дисков

Архитектура

Общие принципы

• Cервера многофункциональны и используются одновременно в нескольких ролях:
  • Перебрасывание полуавтоматическое
  • Требуется перезапускать daemon'ы
• Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура  Facebook), основное отличие — использование собственной СУБД вместо MySQL
• При балансировке нагрузки используются:
  • Взвешенный round robin внутри системы
  • Разные сервера для разных типов запросов
  • Балансировка на уровне ДНС на 32 IP-адреса
• Большая часть внутреннего софта написано самостоятельно, в том числе:
  • Собственная СУБД (см. ниже)
  • Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс )
  • Автоматическая система тестирования кода
  • Анализаторы статистики и логов
• Мощные сервера:
  • 8-ядерные процессоры Intel (по два на сервер, видимо)
  • 64Гб оперативной памяти
  • 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
  • RAID не используется
  • Не брендированные, собирает компания ТехноОкта
• Вычислительные мощности серверов используются менее, чем на 20%
• Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
  • Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
  • В Московских датацентрах только аудио и видео
  • В планах сделать репликацию базы данных в другой датацентр в ленинградской области
• CDN на данный момент не используется, но в планах есть
• Резервное копирование данных происходит ежедневно и инкрементально

Волшебная база данных на C

Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он собственно говоря собой представляет, так и не было обнародовано. Известно, что:

• Разработана «лучшими умами» России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих «героев» Вконтакте (писал на слух и возможно не всех успел, так что извиняйте):
  • Андрей Лопатин
  • Николай Дуров
  • Арсений Смирнов
  • Алексей Левин
• Используется в огромном количестве сервисов:
  • Личные сообщения
  • Сообщения на стенах
  • Статусы
  • Поиск
  • Приватность
  • Списки друзей
• Нереляционная модель данных
• Большинство операций осуществляется в оперативной памяти
• Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
• Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
• Кластеризация осуществляется легко
• Есть репликация
• Если честно, я так и не понял зачем им MySQL с такой штукой — возможно просто как legacy живет со старых времен

Аудио и видео

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

1000—1500 серверов используется для перекодирования видео, на них же оно и хранится.

XMPP

Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.

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

• Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
• Работа с большими контакт-листами — у многих пользователей количество друзей на вконтакте измеряется сотнями и тысячами
• Высокая активность смены статусов — люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
• Аватарки передаются в base64
• Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
• 60-80 тысяч человек онлайн, в пике — 150 тысяч
• HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
• Данные хранятся в MySQL (думали о MongoDB, но передумали)
• Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на node.js (по 4 процесса на сервер), а на трех самых мощных — еще и MySQL
• В node.js большие проблемы с использованием OpenSSL, а также течет память
• Группы друзей в XMPP не связаны с группами друзей на сайте — сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся

Интеграция со внешними ресурсами

Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:

• Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
• Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
• Кнопка «поделиться с друзьями», поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
• Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

Интересные факты не по теме

• Процесс разработки близок к Agile, с недельными итерациями
• Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian
• Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
• Есть много доработок над memcached, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия
• Фотографии не удаляются для минимизации фрагментации
• Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы — на них и на реализовавшем его разработчике
• Павел Дуров откладывал деньги на хостинг с 1 курса

Подводим итоги

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, напимер, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта «круглого стола Вконтакте», так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.

Если хотите быть в курсе новых веяний в сфере масштабируемости высоконагруженных интернет-проектов — по традиции рекомендую подписаться на RSS.

Добавить в социальные закладки

• Blink
• del.ici.ous
• Digg
• Furl
• Google
• Simpy
• Spurl
• Y! MyWeb
• БобрДобр
• Мистер Вонг
• Яндекс.Закладки
• Текст 2.0
• News2
• AddScoop
• RuSpace
• RUmarkz
• Memori
• Закладки Google
• Писали
• СМИ 2
• Моё Место
• Сто Закладок
• Ваау!
• Technorati
• RuCity
• LinkStore
• NewsLand
• Lopas
• Закладки - I.UA
• Connotea
• Bibsonomy
• Trucking Bookmarks
• Communizm
• UCA

Так всё-таки, MySQL юзается или не юзается? Просветите по поводу взаимоисключающих параграфов в тексте.

Я так понял что основной поток даных ложится на самописную СУБД, а с MySQL раюотает только XMPP

я вот этого момента не понял: # RAID не используется

это где он не используется? на серверах балансировки?

**** Левин — Это Алексей Левин.

Левин — Это Лев Левин.

vkontakte.ru/lev

На него зарегистрирован был vkontakte.ru

А там не говорилось, как они уникальные id создают?

Например, для каждого нового пользователя, фотографии или группы.

Очень интересен данный вопрос.

А почему вместо mongodb выбрали mysql?

>Льва Левиева вписал, остальные замечания тоже поправил.

Зря. Он точно не программист, да и имея 4 миллиарда долларов он врятли тратит время на программирование Базы Данных на C

Гоша, возможно там был кто-то другой, писал на слух и не могу что-либо гарантировать: есть другие варианты, кто бы это мог быть?

Artyom, у них активность определенно существенно меньше в этом направлении, по сравнению с Facebook, этот вопрос затрагивался очень мало.

Интересно. Спасибо за «беглый обзор» )))

То, что они свой Jabber сервер решили писать это вообще удивило. Есть же отличный производительный ejabberd. То что на эрланге написан думаю не такая большая проблема. Теперь вон пишут что с SSL проблемы...

>> Льва Левиева

>> есть другие варианты, кто бы это мог быть?

Сеня Смирнов и Леша Левин в одной команде на ACM соревнованиях. В прошлом году взяли серебро на ACM World Finals. Так что пишите Лешу, не ошибетесь

на счет ихней бд, скорее всего это очередная nosql

11 млрд на 40 млн пользователей это чуть больше 11 запросов в час, вообще-то

Иван Блинков, от Олега Илларионова

[...] описание архитектуры социальной сети ВКонтакте; [...]

[...] джерело VK.Widgets.Like ("vk_like", {type: "mini"}); Теги: XMPP, Інтеграція, Архітектура, Аудіо та відео, база даних на C, Платформа, статистика VK.Widgets.Comments ("vk_comments", {limit: 10, width: "574"}); [...]

На счет более 10000 серверов — это что, физические серверы?

крайне удивило использование mod_php

«...собственный сервер, представляющий собой прослойку между внутренними сервисами Вконтакте и реализацией XMPP протокола...»

имеется в виду, что собственный сервер на node.js это только HTTP-bind frontend или по сомвместительству и XMPP сервер? Если так, то какой XMPP сервер используется?

Слишком много в статье додумок и неверных трактовок.

Т.к. я спрашивал про бэкап данных, то точно помню, что сказано было — «данные дублируются на разных серверах», и потом добавлено «и бекап есть».

И Такие замечания почти по всем пунктам этой статьи. Автор очень вольно трактует сказанное. А Павел явно местами порол хрень собачью.

macabre, там сказано про 60-80 тысяч онлайн пользователей (в пике до 150тыс). Хотелось бы надеяться, что пользователи оффлайн запросов не отправляют.

Привет!

Буду благодарен за ссылку на конференцию

Олег, да, конечно стоило поставить ее.

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

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