Вконтакте изнутри.

[easily_l]

В конце 2010 года Вконтакте раскрыли принцип работы соцсети. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции 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-адреса

• Большая часть внутреннего софта написано самостоятельно, в том числе:

Собственная СУБД (см. ниже)
Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс :) )
Автоматическая система тестирования кода
o Анализаторы статистики и логов

• Мощные сервера:

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 теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега и атрибутов alt у изображений, чуть ли не побуквенно)
• Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

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

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

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

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

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

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

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