Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции 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.

Метки: Apache, C++, Debian, featured, ffmpeg, HAProxy, highload, Linux, Memcached, mod_php, MySQL, nginx, node.js, openssl, PHP, XCache, xfs, Архитектура Вконтакте, Вконтакте