https://www.insight-it.ru/Thu, 28 Oct 2010 21:12:00 +0400https://www.insight-it.ru//highload/2010/arkhitektura-vkontakte/<p><img alt="Логотип Вконтакте" class="left" src="https://www.insight-it.ru/images/vkontakte-logo.png" title="Логотип Вконтакте"/> Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции <a href="https://www.insight-it.ru/event/2010/highload-2010/">HighLoad++</a> ответили на шквал вопросов по совершенно разным аспектам работы <a href="https://www.insight-it.ru/goto/1a5d3494/" rel="nofollow" target="_blank" title="https://vk.com">Вконтакте</a>, в том числе и техническим. Спешу поделиться своим взглядом на архитектуру проекта по результатам данного выступления.<!--more--></p> <h2 id="platforma">Платформа</h2> <ul> <li><a href="/tag/debian/">Debian</a>&ensp;<a href="/tag/linux/">Linux</a> - основная операционная система</li> <li><a href="/tag/nginx/">nginx</a> - балансировка нагрузки</li> <li><a href="/tag/php/">PHP</a> + <a href="/tag/xcache/">XCache</a></li> <li><a href="/tag/apache/">Apache</a> + <a href="/tag/mod_php/">mod_php</a></li> <li><a href="/tag/memcached/">memcached</a></li> <li><a href="/tag/mysql/">MySQL</a></li> <li>Собственная СУБД на <a href="/tag/c/">C</a>, созданная "лучшими умами" России</li> <li><a href="/tag/node-js/">node.js</a> - прослойка для реализации XMPP, живет за <a href="/tag/haproxy/">HAProxy</a></li> <li>Изображения отдаются просто с файловой системы <a href="/tag/xfs/">xfs</a></li> <li><a href="/tag/ffmpeg/">ffmpeg</a> - конвертирование видео</li> </ul> <h2 id="statistika">Статистика</h2> <ul> <li>95 миллионов учетных записей</li> <li>40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)</li> <li>11 миллиардов запросов в день</li> <li>200 миллионов личных сообщений в день</li> <li>Видеопоток достигает 160Гбит/с</li> <li>Более 10 тысяч серверов, из которых только 32 - фронтенды на <a href="/tag/nginx/">nginx</a> (количество серверов с <a href="/tag/apache/">Apache</a> неизвестно)</li> <li>30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах</li> <li>Каждый день выходит из строя около 10 жестких дисков</li> </ul> <h2 id="arkhitektura">Архитектура</h2> <h3 id="obshchie-printsipy">Общие принципы</h3> <ul> <li>Cервера многофункциональны и используются одновременно в нескольких ролях:<ul> <li>Перебрасывание полуавтоматическое</li> <li>Требуется перезапускать daemon'ы</li> </ul> </li> <li>Генерация страниц с новостями (микроблоги) происходит очень похожим образом с <a href="/tag/facebook/">Facebook</a> (см. <a href="https://www.insight-it.ru/highload/2010/arkhitektura-facebook/">Архитектура&nbsp;Facebook</a>), основное отличие - использование собственной СУБД вместо MySQL</li> <li>При балансировке нагрузки используются:<ul> <li>Взвешенный round robin внутри системы</li> <li>Разные сервера для разных типов запросов</li> <li>Балансировка на уровне ДНС на 32 IP-адреса</li> </ul> </li> <li>Большая часть внутреннего софта написано самостоятельно, в том числе:<ul> <li>Собственная СУБД (см. ниже)</li> <li>Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс :) )</li> <li>Автоматическая система тестирования кода</li> <li>Анализаторы статистики и логов</li> </ul> </li> <li>Мощные сервера:<ul> <li>8-ядерные процессоры Intel (по два на сервер, видимо)</li> <li>64Гб оперативной памяти</li> <li>8 жестких дисков (соответственно скорее всего корпуса 2-3U)</li> <li>RAID не используется</li> <li>Не брендированные</li> </ul> </li> <li>Вычислительные мощности серверов используются менее, чем на 20%</li> <li>Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:<ul> <li>Вся основная база данных располагается в одном датацентре в Санкт-Петербурге</li> <li>В Московских датацентрах только аудио и видео</li> <li>В планах сделать репликацию базы данных в другой датацентр в ленинградской области</li> </ul> </li> <li><a href="/tag/cdn/">CDN</a> на данный момент не используется, но в планах есть</li> <li>Резервное копирование данных происходит ежедневно и инкрементально</li> </ul> <h3 id="volshebnaia-baza-dannykh-na-c">Волшебная база данных на <a href="/tag/c/">C</a></h3> <p>Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он собственно говоря собой представляет, так и не было обнародовано. Известно, что:</p> <ul> <li>Разработана "лучшими умами" России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих "героев" Вконтакте (писал на слух и возможно не всех успел, так что извиняйте):<ul> <li>Андрей Лопатин</li> <li>Николай Дуров</li> <li>Арсений Смирнов</li> <li>Алексей Левин</li> </ul> </li> <li>Используется в огромном количестве сервисов:<ul> <li>Личные сообщения</li> <li>Сообщения на стенах</li> <li>Статусы</li> <li>Поиск</li> <li>Приватность</li> <li>Списки друзей</li> </ul> </li> <li>Нереляционная модель данных</li> <li>Большинство операций осуществляется в оперативной памяти</li> <li>Интерфейс доступа представляет собой расширенный протокол <a href="/tag/memcached/">memcached</a>, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)</li> <li>Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами</li> <li>Кластеризация осуществляется легко</li> <li>Есть репликация</li> <li>Если честно, я так и не понял зачем им <a href="/tag/mysql/">MySQL</a> с такой штукой - возможно просто как legacy живет со старых времен</li> </ul> <h3 id="audio-i-video">Аудио и видео</h3> <p>Эти подпроекты являются побочными для социальной сети, на них особо не фокусируются. В основном это связанно с тем, что они редко коррелируют с основной целью использования социальной сети - <em>общением</em>, а также создают большое количество проблем: видео траффик - основная статья расходов проекта, плюс всем известные проблемы с нелегальным контентом и претензиями правообладателей. Медиа-файлы банятся по хэшу при удалении по просьбе правообладателей, но это неэффективно и планируется усовершенствовать этот механизм.</p> <p>1000-1500 серверов используется для перекодирования видео, на них же оно и хранится.</p> <h3 id="xmpp">XMPP</h3> <p>Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.</p> <p>По ряду причин, среди которых проблемы с интеграцией с остальными сервисами, было решено за месяц создать собственный сервер, представляющий собой прослойку между внутренними сервисами Вконтакте и реализацией XMPP протокола. Основные особенности этого сервиса:</p> <ul> <li>Реализован на <a href="/tag/node-js/">node.js</a> (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)</li> <li>Работа с большими контакт-листами - у многих пользователей количество друзей на Вконтакте измеряется сотнями и тысячами</li> <li>Высокая активность смены статусов - люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях</li> <li>Аватарки передаются в <code>base64</code></li> <li>Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте</li> <li>60-80 тысяч человек онлайн, в пике - 150 тысяч</li> <li><a href="/tag/haproxy/">HAProxy</a> обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий</li> <li>Данные хранятся в <a href="/tag/mysql/">MySQL</a> (думали о MongoDB, но передумали)</li> <li>Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на<a href="/tag/node-js/">node.js</a> (по 4 процесса на сервер), а на трех самых мощных - еще и <a href="/tag/mysql/">MySQL</a></li> <li>В <a href="/tag/node-js/">node.js</a> большие проблемы с использованием <a href="/tag/openssl/">OpenSSL</a>, а также течет память</li> <li>Группы друзей в XMPP не связаны с группами друзей на сайте - сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся</li> </ul> <h3 id="integratsiia-so-vneshnimi-resursami">Интеграция со внешними ресурсами</h3> <p>Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:</p> <ul> <li>Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM</li> <li>Кросс-постинг статусов в <a href="/tag/twitter/">Twitter</a>, реализованный с помощью очередей запросов</li> <li>Кнопка "поделиться с друзьями", поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <code>&lt;title&gt;</code> и атрибутов alt у изображений, чуть ли не побуквенно)</li> <li>Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими</li> </ul> <h2 id="interesnye-fakty-ne-po-teme_1">Интересные факты не по теме</h2> <ul> <li>Процесс разработки близок к Agile, с недельными итерациями</li> <li>Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для <a href="/tag/debian/">Debian</a></li> <li>Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере</li> <li>Есть много доработок над <a href="/tag/memcached/">memcached</a>, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия</li> <li>Фотографии не удаляются для минимизации фрагментации</li> <li>Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на них и на реализовавшем его разработчике</li> <li>Павел Дуров откладывал деньги на хостинг с 1 курса :)</li> </ul> <h2 id="podvodim-itogi">Подводим итоги</h2> <p>В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, например, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде <code>vkontakte.ru/ivan.blinkov</code>. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.</p> <p>Завеса тайны насчет технической реализации Вконтакте была немного развеяна, но много моментов все же остались секретом. Возможно в будущем появится более детальная информация о собственной СУБД Вконтакте, которая как оказалось является ключом к решению всех самых сложных моментов в масштабируемости системы.</p> <p>Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта "круглого стола Вконтакте", так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.</p> <p>Если хотите быть в курсе новых веяний в сфере масштабируемости высоконагруженных интернет-проектов - по традиции рекомендую <a href="/feed/">подписаться на RSS</a>.</p>Иван БлинковThu, 28 Oct 2010 21:12:00 +0400tag:www.insight-it.ru,2010-10-28:highload/2010/arkhitektura-vkontakte/ApacheC++DebianfeaturedffmpegHAProxyhighloadLinuxMemcachedmod_phpMySQLnginxnode.jsopensslPHPXCachexfsАрхитектура ВконтактеВконтакте