Как устроены Facebook и Vkontakte

Вот какую информацию удалось найти в рунете.



«Facebook» — социальная сеть, основанная в 2004 году Марком Цукербергом и его соседями по комнате во время обучения в Гарвардском университете Эдуардо Саверином, Дастином Московицем и Крисом Хьюзом. Благодаря своему сайту Марк Цукерберг стал самым молодым миллиардером в свои 23 года.

Первоначально веб-сайт был назван thefacebook.com (позже изменён на современный вариант facebook) и открыт только для студентов Гарвардского Университета, затем доступ был расширен для других университетов Бостона, а затем и для студентов любых учебных учреждений США, имеющих электронный адрес с доменом .edu. Начиная с сентября 2006 года сайт был открыт для всех пользователей в возрасте от 13 лет, имеющих электронную почту. По состоянию на 21 июля 2010 года Facebook насчитывает более 500 миллионов пользователей по всему миру. При этом количество уникальных посетителей сайта в апреле 2010 года составило 540 млн, а количество просмотров страниц — 570 млрд. Прибыль Facebook за 2009 год по собственной оценке компании составила 700 млн долларов США.

Платформа
* Linux — операционная система
* PHP с HipHop — код на PHP компилируется в C++
* memcached — агрессивное кэширование объектов
* MySQL — используется как хранилище пар ключ-значение, никаких join'ов
* Thrift — интерфейс взаимодействия между сервисами, написанными на разных языках программирования
* Scribe — универсальная система сбора и агрегации данных с рабочих серверов

Статистика

* Более 500 миллионов активных пользователей (месячная аудитория)
* Более миллиарда социальных связей
* Более 200 миллиардов просмотров страниц в месяц
* Более 4 триллионов действий попадает в новостные ленты каждый день
* Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше
* Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно
* Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду
* 20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых
* О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно
* Более миллиарда сообщений в чате каждый день
* Более ста миллионов поисковых запросов в день
* Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect
* Более 400 тысяч разработчиков сторонних приложений
* Менее 500 разработчиков и системных администраторов в штате
* Более миллиона активных пользователей на одного инженера
* Десятки тысяч серверов, десятки гигабит трафика

Архитектура

Общие принципы

* Балансировщик нагрузки выбирает веб-сервер для обработки запроса
* PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:
o MySQL
o memcached
o Специализированные сервисы
* Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
o Вер-приложение
o Распределенный индекс
o Постоянное хранилище
* Использование открытых технологий там, где это возможно
* Поиск возможностей оптимизации используемых продуктов
* Философия Unix:
o Старайтесь делать каждый компонент системы простым и производительным
o Комбинируйте компоненты для решения задач
o Концентрируйте внимание на хорошо обозначенных точках взаимодействия
* Все усилия направлены на масштабируемость
* Попытки минимизации количества точек отказа
* Простота.

PHP

Почему PHP?

* Во многом «так исторически сложилось»
* Хорошо подходит для веб-разработки
* Легок в изучении: небольшой набор выражений и языковых конструкций
* Легок в написании: нестрогая типизация и универсальный «массив»
* Легок в чтении: синтаксис похож на C++ и Java
* Прост в дебаггинге: нет необходимости в перекомпиляции
* Большой ассортимент библиотек, актуальных для веб-проектов
* Подходит для процесса разработки с короткими итерациями
* Активное сообщество разработчиков по всему миру
* Динамическая типизация, интерпретируемый язык для скриптов

Как оказалось на самом деле?

* Высокий расход оперативной памяти и вычислительных ресурсов
* Сложно работать, когда объем исходного кода очень велик: слабая типизация и ограниченные возможности для статичного анализа и оптимизации кода
* Не особо оптимизирован для использования в крупных проектах
* Линейный рост издержек при подключении файлов с исходным кодом
* Механизм разработки расширений не очень удобен

Доработки:

* Оптимизация байт-кода
* Улучшения в APC (ленивая загрузка, оптимизация блокировок, «подогрев» кэша)
* Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)
* HipHop — трансформатор исходных кодов:
o Разработчики пишут на PHP, который конвертируется в оптимизированный C++
o Статический анализ, определение типов данных, генерация кода, и.т.д.
o Облегчает разработку расширений
o Существенно сокращает расходы оперативной памяти и вычислительных ресурсов
o У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка
o Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля

MySQL

Как используется MySQL?

* Используется как хранилище пар ключ-значение
* Большое количество логических узлов распределено между физическими машинами
* Балансировка нагрузке на уровне физических серверов
* Репликация для распределения операций чтения не используется
* Большинство запросов касаются самой свежей информации: оптимизация таблиц для доступа к новым данным, архивация старых записей
* В целом быстро и надежно

Как оказалось на самом деле?

* Логическая миграция данных очень сложна
* Создавать большое количество логических баз данных и перераспределять их между физическими узлами, балансируя таким образом нагрузку, намного удобнее
* Никаких join'ов на рабочих серверах баз данных
* Намного проще наращивать вычислительные мощности на веб-серверах, чем на серверах баз данных
* Схемы, основанные на структуре данных, делают программистов счастливыми и создают большую головную боль администраторам
* Никогда не храните не-статичные данные в централизованное базе данных

Доработки:

* Практически никаких модификаций исходного кода MySQL
* Своя схема партиционирования с глобально-уникальными идентификаторами
* Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя
* Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша
* Библиотеки для доступа к данным на основе графа:
o Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)
o Реплицированные связи (ребра графа)
o Аналоги распределенных внешних ключей (foreign keys)
o Большинство данных распределено случайно

Memcache

Как используется memcached?

* Высокопроизводительная распределенная хэш-таблица
* Содержит «горячие» данные из MySQL
* Снижает нагрузку на уровень баз данных
* Основная форма кэширования
* Используется более 25TB памяти на нескольких тысячах серверов
* Среднее время отклика менее 250 микро-секунд
* Кэшируются сериализованные структуры данных PHP
* Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL — приходится делать это на уровне программного кода
* Множество multi-get запросов для получения данных на другом конце ребер графа
* Ограниченная модель данных, неэффективен для маленьких объектов

Доработки:

* Порт на 64-битную архитектуру
* Более эффективная сериализация
* Многопоточность
* Улучшенный протокол
* Компрессия
* Проксирование запросов
* Доступ к memcache через UDP:
o уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений
o управление ходом исполнения приложение (оптимизация для multi-get)
* Статистика о работе потоков по запросу — уменьшает блокировки
* Ряд изменений в ядре Linux для оптимизации работы memcache:
o распределение управления сетевыми прерывания по всем ядрам
o оппортунистический опрос сетевых интерфейсов
* После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений

Thrift

Что это?

* Легкий механизм построения приложений с использованием нескольких языков программирования
* Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.
* Предоставляет язык описания интерфейсов, статический генератор кода
* Поддерживаемые языки: C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell и многие другие
* Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)
* Протоколы: стандарты сериализации (бинарный, JSON)
* Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные

Почему именно Thrift?

* Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers — но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию
* Он быстрый, очень быстрый
* Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы
* Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями
* Общий инструментарий, знакомый всем разработчикам

Scribe

Что это?

* Масштабированный распределенный механизм ведения логов
* Перемещает данные с серверов в центральный репозиторий
* Широкая сфера применения:
o Логи поисковых запросов
o Публикации в новостных лентах
o Данные по A/B тестированиям
* Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных
* Простая модель данных
* Построен на основе Thrift

Хранение фотографий

Сначала сделали это просто:

* Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
* Загрузка с сервера: изображения отдаются из NFS через HTTP
* NFS построена на коммерческих продуктах
* Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
* На самом деле оказалось, что:
o Файловые системы непригодны для работы с большим количеством небольших файлов
o Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
o Ограничивающим фактором является ввод-вывод, а не плотность хранения

Потом начали оптимизировать:

* Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
* Распределение их по CDN для уменьшения сетевых задержек
* Возможно сделать еще лучше:
o Хранение изображений в больших бинарных файлах (blob)
o Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
o Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»

Другие сервисы

* SMC: консоль управления сервисами — централизованная конфигурация, определение на какой физической машине работает логический сервис
* ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
* Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
* И еще около 50 других сервисов.




В Контакте — крупнейшая в Рунете социальная сеть, российский аналог сервиса Facebook. По данным Alexa Internet - второй по посещаемости сайт России, второй на Украине и в Белоруссии, четвёртый в Казахстане, 34-й в мире. Сайт изначально позиционировал себя в качестве социальной сети студентов и выпускников элитных российских высших учебных заведений, позднее — как универсальный способ связи для всех социальных групп и возрастов. В январе 2009 года «В Контакте» впервые обогнал по посещаемости в России своего главного конкурента — «Одноклассники». А уже в апреле на сайт «В Контакте» зашло 14,3 миллиона уникальных российских пользователей, тогда как на «Одноклассники» — 7,8 миллиона, что почти в 2 раза меньше.

Платформа

* 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, и.т.д.), открыты к интеграции с другими

Информация попахивает плесенью, откуда она вообще? Похоже описывается изначальное положение дел на момент запуска, сейчас обе социальные сети имеют в своем арсенале целую кучу специализированных разработок для масштабируемости и отзывчивости аудитория то вырасла мягко скажем значительно...

LogLex пишет: Информация попахивает плесенью, откуда она вообще? Похоже описывается изначальное положение дел на момент запуска, сейчас обе социальные сети имеют в своем арсенале целую кучу специализированных разработок для масштабируемости и отзывчивости аудитория то вырасла мягко скажем значительно...

Информация не нова, об этом говорит попросту дата публикации. Но выгодно отличается от вашего сообщения, которое, уж простите, попахивает флеймом, т.к. не содержит терминологии, а только общие фразы. Коль скоро вывалили целую кучу специализированного ни о чем - okay; подробности, описание и аргументацию в студию.

Практически никаких модификаций исходного кода MySQL

Как раз наоборот, Facebook взял за основу MySQL 5.1 и сделал свои доработки. И так как в то время как раз началась смена разработчиков MySQL, все основные разработчики ушли в Monty AB, и патчи Facebook никто в Oracle не принимал, получилась отдельная своя ветка. Какая интересно СУБД используется у них сейчас. Wikipedia перешла на MariaDB, а многие крупные сайты используют PostgreSQL, например, StackOverflow использует PostgreSQL.

Если честно, я так и не понял зачем им MySQL с такой штукой — возможно просто как legacy живет со старых времен

А что тут не понятного, то что они разработали - это временной хранилище ключ-значение c NoSQL-запросами, а не персистент. Для персистента чаще используют SQL RDBMS с реализацией ACID. Хотя у Redis довольно хорошо реализован персистент. Тут не понятно зачем разрабатывать свое хранилище, когда есть замечательный Redis.

В блоге опубликован краткий анонс нового приложения Вконтакте... вполне возможно, что по окончании разработки смогу добавить кое-что новое к содержащейся в данном топике инфе. А может быть и нет, посмотрим.