Архитектура Вконтакте

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

 

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

www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/

Вверх