Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции 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ервера многофункциональны и используются одновременно в нескольких ролях: o Перебрасывание полуавтоматическое o Требуется перезапускать daemon'ы * Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие — использование собственной СУБД вместо MySQL * При балансировке нагрузки используются: o Взвешенный round robin внутри системы o Разные сервера для разных типов запросов o Балансировка на уровне ДНС на 32 IP-адреса * Большая часть внутреннего софта написано самостоятельно, в том числе: o Собственная СУБД (см. ниже) o Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс ) o Автоматическая система тестирования кода o Анализаторы статистики и логов * Мощные сервера: o 8-ядерные процессоры Intel (по два на сервер, видимо) o 64Гб оперативной памяти o 8 жестких дисков (соответственно скорее всего корпуса 2-3U) o RAID не используется o Не брендированные, собирает компания ТехноОкта * Вычислительные мощности серверов используются менее, чем на 20% * Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем: o Вся основная база данных располагается в одном датацентре в Санкт-Петербурге o В Московских датацентрах только аудио и видео o В планах сделать репликацию базы данных в другой датацентр в ленинградской области * CDN на данный момент не используется, но в планах есть * Резервное копирование данных происходит ежедневно и инкрементально Волшебная база данных на C Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он собственно говоря собой представляет, так и не было обнародовано. Известно, что: * Разработана «лучшими умами» России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих «героев» Вконтакте (писал на слух и возможно не всех успел, так что извиняйте): o Андрей Лопатин o Николай Дуров o Арсений Смирнов o Алексей Левин * Используется в огромном количестве сервисов: o Личные сообщения o Сообщения на стенах o Статусы o Поиск o Приватность o Списки друзей * Нереляционная модель данных * Большинство операций осуществляется в оперативной памяти * Интерфейс доступа представляет собой расширенный протокол 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. Завеса тайны насчет технической реализации Вконтакте была немного развеяна, но много моментов все же остались секретом. Возможно в будущем появится более детальная информация о собственной СУБД Вконтакте, которая как оказалось является ключом к решению всех самых сложных моментов в масштабируемости системы. Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта «круглого стола Вконтакте», так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям. по материалам: http://www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/
Кстати, на этом сайте http://www.insight-it.ru (не сочтите за рекламу) представленна архитектура не только Вконтакте, но различных других соц. сетей. Да еще много есть чего интесеного. Сам недавно о нем узнал.
Судя по описанию функционала, ихняя база "на C" сделана все-таки для продвинутого кэширования, а не на замену MySQL. Хотя кто знает как там на самом деле.
