velzevul (dubva1) wrote,
velzevul
dubva1

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


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

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


Большая часть внутреннего софта написано без помощи других, в том числе:


Собственная СУБД (см. ниже)


Мониторинг с извещением по СМС (Павел сам помогал верстать интерфейс )


Автоматическая система тестирования кода


Анализаторы статистики и логов


Массивные сервера:


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 процесса на сервер), а на 3-х самых массивных - к тому же MySQL


В node. js огромные трудности с внедрением OpenSSL, также течет память


Группы друзей в XMPP не связаны с группами друзей на веб-сайте - изготовлено по требованию юзеров, которые не желали чтоб их друзья из-за плеча лицезрели в какой группе они находятся


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


Наибольшая кроссбраузерность для виджетов на базе библиотек easyXDM и fastXDM


Кросс-постинг статусов в Twitter, реализованный при помощи очередей запросов


Кнопка «поделиться с друзьями», поддерживающая openGraph теги и автоматом подбирающая подходящую иллюстрацию (методом сравнивание содержимых тега и атрибутов alt у изображений, чуть не побуквенно)


Возможность загрузки видео через посторонние видео-хостинги (YouTube, RuTube, Vimeo, и. т. д. ), открыты к интеграции с другими


Достойные внимания факты не по теме


Процесс разработки близок к Agile, с недельными итерациями


Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian


Фото загружаются на два жестких диска 1-го сервера сразу, после этого создается запасная копия на другом сервере


Есть много доработок над memcached, в. т. ч. для более размеренного и долгого размещения объектов в памяти; есть даже persistent версия


Фото не удаляются для минимизации фрагментации


Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на их и на реализовавшем его разработчике


Павел Дуров откладывал средства на хостинг с 1 курса


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


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


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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments