Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции 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 вроде http://vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.
Завеса тайны насчет технической реализации Вконтакте была немного развеяна, но много моментов все же остались секретом. Возможно в будущем появится более детальная информация о собственной СУБД Вконтакте, которая как оказалось является ключом к решению всех самых сложных моментов в масштабируемости системы.
Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта «круглого стола Вконтакте», так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.
Платформа
* 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 вроде http://vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.
Завеса тайны насчет технической реализации Вконтакте была немного развеяна, но много моментов все же остались секретом. Возможно в будущем появится более детальная информация о собственной СУБД Вконтакте, которая как оказалось является ключом к решению всех самых сложных моментов в масштабируемости системы.
Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта «круглого стола Вконтакте», так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.
The most popular social network in RuNet has shed some light on how it works. Representatives of the project in the person of Pavel Durov and Oleg Illarionov at the HighLoad ++ conference answered a barrage of questions on completely different aspects of the work of Vkontakte, including technical. I hasten to share my view on the architecture of the project based on the results of this presentation.
Platform
* Debian Linux - the main operating system
* nginx - load balancing
* PHP + XCache
* Apache + mod_php
* memcached
* MySQL
* Own DBMS in C, created by the "best minds" of Russia
* node.js - layer for implementing XMPP, lives behind HAProxy
* Images are given simply from the xfs file system
* ffmpeg - video conversion
Statistics
* 95 million accounts
* 40 million active users worldwide (comparable to the Internet audience in Russia)
* 11 billion requests per day
* 200 million private messages per day
* Video stream reaches 160Gbps
* More than 10 thousand servers, of which only 32 are frontends on nginx (the number of servers with Apache is unknown)
* 30-40 developers, 2 designers, 5 system administrators, many people in data centers
* Every day about 10 hard drives fail
Architecture
General principles
* Servers are multifunctional and are used simultaneously in several roles:
o Semi-automatic transfer
o Required to restart daemons
* News pages (microblogs) are generated in a very similar way with Facebook (see Facebook architecture), the main difference is the use of your own DBMS instead of MySQL
* When balancing the load are used:
o Weighted round robin inside the system
o Different servers for different types of requests
o Balancing at the DNS level to 32 IP addresses
* Most of the internal software is written independently, including:
o Own DBMS (see below)
o Monitoring with SMS notification (Pavel himself helped to make up the interface)
o Automatic code testing system
o Analyzers of statistics and logs
* Powerful servers:
o 8-core Intel processors (two per server, apparently)
o 64GB RAM
o 8 hard drives (respectively, most likely 2-3U cases)
o RAID is not used
o Not branded, collects the company TechnoOcta
* Server computing power is used less than 20%
* Now the project is located in 4 data centers in St. Petersburg and Moscow, and:
o The entire main database is located in one data center in St. Petersburg
o In Moscow data centers only audio and video
o Plans to replicate the database to another data center in the Leningrad region
* CDN is currently not used, but there are plans
* Data backup occurs daily and incrementally
Magic Database C
This product, perhaps, was given the maximum attention of the audience, but at the same time almost no details about what it actually is, were not made public. It is known that:
* Developed by the "best minds" of Russia, winners of Olympiads and topcoder contests; even voiced the names of these “heroes” of Vkontakte (wrote by ear and probably didn’t have time for everyone, so excuse me):
o Andrey Lopatin
o Nikolai Durov
o Arseny Smirnov
o Alexey Levin
* Used in a huge number of services:
o Private messages
o Wall posts
o Statuses
o Search
o Privacy
o Friends Lists
* Non-relational data model
* Most operations are performed in RAM
* The access interface is an extended memcached protocol, in a special way composed keys return the results of complex queries (most often specific to a particular service)
* We would like to make a universal DBMS out of this system and publish it under the GPL, but so far it does not work out due to the high degree of integration with other services
* Clustering is easy
* There is replication
* To be honest, I still don’t understand why they need MySQL with such a thing - maybe just how legacy lives from the old days
Audio & Video
These subprojects are secondary to the social network and are not particularly focused on. This is mainly due to the fact that they rarely correlate with the main purpose of using a social network - communication, and also create a large number of problems: video traffic is the main expense item of the project, plus well-known problems with illegal content and claims of copyright holders. Media files are hashed by hash when deleted at the request of copyright holders, but this is inefficient
Platform
* Debian Linux - the main operating system
* nginx - load balancing
* PHP + XCache
* Apache + mod_php
* memcached
* MySQL
* Own DBMS in C, created by the "best minds" of Russia
* node.js - layer for implementing XMPP, lives behind HAProxy
* Images are given simply from the xfs file system
* ffmpeg - video conversion
Statistics
* 95 million accounts
* 40 million active users worldwide (comparable to the Internet audience in Russia)
* 11 billion requests per day
* 200 million private messages per day
* Video stream reaches 160Gbps
* More than 10 thousand servers, of which only 32 are frontends on nginx (the number of servers with Apache is unknown)
* 30-40 developers, 2 designers, 5 system administrators, many people in data centers
* Every day about 10 hard drives fail
Architecture
General principles
* Servers are multifunctional and are used simultaneously in several roles:
o Semi-automatic transfer
o Required to restart daemons
* News pages (microblogs) are generated in a very similar way with Facebook (see Facebook architecture), the main difference is the use of your own DBMS instead of MySQL
* When balancing the load are used:
o Weighted round robin inside the system
o Different servers for different types of requests
o Balancing at the DNS level to 32 IP addresses
* Most of the internal software is written independently, including:
o Own DBMS (see below)
o Monitoring with SMS notification (Pavel himself helped to make up the interface)
o Automatic code testing system
o Analyzers of statistics and logs
* Powerful servers:
o 8-core Intel processors (two per server, apparently)
o 64GB RAM
o 8 hard drives (respectively, most likely 2-3U cases)
o RAID is not used
o Not branded, collects the company TechnoOcta
* Server computing power is used less than 20%
* Now the project is located in 4 data centers in St. Petersburg and Moscow, and:
o The entire main database is located in one data center in St. Petersburg
o In Moscow data centers only audio and video
o Plans to replicate the database to another data center in the Leningrad region
* CDN is currently not used, but there are plans
* Data backup occurs daily and incrementally
Magic Database C
This product, perhaps, was given the maximum attention of the audience, but at the same time almost no details about what it actually is, were not made public. It is known that:
* Developed by the "best minds" of Russia, winners of Olympiads and topcoder contests; even voiced the names of these “heroes” of Vkontakte (wrote by ear and probably didn’t have time for everyone, so excuse me):
o Andrey Lopatin
o Nikolai Durov
o Arseny Smirnov
o Alexey Levin
* Used in a huge number of services:
o Private messages
o Wall posts
o Statuses
o Search
o Privacy
o Friends Lists
* Non-relational data model
* Most operations are performed in RAM
* The access interface is an extended memcached protocol, in a special way composed keys return the results of complex queries (most often specific to a particular service)
* We would like to make a universal DBMS out of this system and publish it under the GPL, but so far it does not work out due to the high degree of integration with other services
* Clustering is easy
* There is replication
* To be honest, I still don’t understand why they need MySQL with such a thing - maybe just how legacy lives from the old days
Audio & Video
These subprojects are secondary to the social network and are not particularly focused on. This is mainly due to the fact that they rarely correlate with the main purpose of using a social network - communication, and also create a large number of problems: video traffic is the main expense item of the project, plus well-known problems with illegal content and claims of copyright holders. Media files are hashed by hash when deleted at the request of copyright holders, but this is inefficient
У записи 1 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Владислав Яколин
