Главная » Интернет и IT » Архитектура и масштабируемость Facebook и Vkontakte

Архитектура и масштабируемость Facebook и Vkontakte

Может не самые посещаемые сайты планеты, но наиболее посещаемые – это Vkontakte.ru и Facebook.com. Наверняка многим из вас было интересно какова же архитектура Вконтакте и Facebook’а. Как такие гиганты выдерживают неимоверные нагрузки от миллионов пользователей каждые сутки? Естественно, что для  этого требуется мощное Сетевое оборудование, а так же множество профессионалов. Наткнулся я сегодня на статьи, освящающие данную проблематику и предлагаю вам для ознакомления и общего развития.

Сначала о близком, т.е о Вконтакте:

Платформа

* 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 теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега и атрибутов alt у изображений, чуть ли не побуквенно)
* Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

Интересные факты не по теме

* Процесс разработки близок к Agile, с недельными итерациями
* Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian
* Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
* Есть много доработок над memcached, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия
* Фотографии не удаляются для минимизации фрагментации
* Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы — на них и на реализовавшем его разработчике
* Павел Дуров откладывал деньги на хостинг с 1 курс

Подводим итоги

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, напимер, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

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

А теперь то же самое, только о Facebook:

Платформа
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, пользуясь данными из различных источников:
MySQL
memcached
Специализированные сервисы
Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
Вер-приложение
Распределенный индекс
Постоянное хранилище
Использование открытых технологий там, где это возможно
Поиск возможностей оптимизации используемых продуктов
Философия Unix:
Старайтесь делать каждый компонент системы простым и производительным
Комбинируйте компоненты для решения задач
Концентрируйте внимание на хорошо обозначенных точках взаимодействия
Все усилия направлены на масштабируемость
Попытки минимизации количества точек отказа
Простота, простота, простота!
PHP

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

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

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

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

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

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

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

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

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

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

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

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

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

Потом начали оптимизировать:
Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
Распределение их по CDN для уменьшения сетевых задержек
Возможно сделать еще лучше:
Хранение изображений в больших бинарных файлах (blob)
Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»
Другие сервисы
SMC: консоль управления сервисами — централизованная конфигурация, определение на какой физической машине работает логический сервис
ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
И еще около 50 других сервисов…
Как это работает все вместе?
Новые альбомы друзей

Получаем профиль по идентификатору пользователя (скорее всего из кэша, но потенциально возможно обращение к базе данных)
Получаем список друзей (опять же на основе идентификатора пользователя из кэша или из базы данных в случае промаха)
Параллельно запрашиваем идентификаторы последних 10 альбомов для каждого из друзей (multi-get, каждый промах мимо кэша индивидуально вытаскивается из MySQL)
Параллельно получаем данные о всех альбомах (на основе идентификаторов альбомов из предыдущего шага)
Все данные получены, выполняем логику отрисовки конкретной страницы на PHP
Отправляем HTML в браузер, пользователь счастлив
Новостная лента
Поиск

Подводим итоги

LAMP не идеален
PHP+MySQL+Memcache решает большинство задач, но не может решить совсем все:
PHP не может хранить состояния
PHP не самый производительный язык
Все данные находятся удаленно
Facebook разрабатывает собственные внутренние сервисы, чтобы:
Располагать исполняемый код ближе к данным
Скомпилированное окружение более эффективно
Некоторая функциональность присутствует только в других языках программирования
Философия сервисов:
Создание сервисов только при необходимости (минимизация издержек по развертке, поддержке и ведению отдельной кодовой базы; потенциальная дополнительная точка сбоя)
Создание общего набора инструментов для создания сервисов (Thrift, Scribe, ODS, средства мониторинга и уведомлений)
Использование правильных языка программирования, библиотек и инструментов для решения задачи
Возвращение инноваций общественности — важный аспект разработки в Facebook:
Опубликованные свои проекты:
Thrift
Scribe
Tornado
Cassandra
Varnish
Hive
xhprof

Источник: SocEngine.ru

Все эти сайты выдерживают неимоверную нагрузку пользователей. Разумеется, далеко не у каждого сайта такая нагрузка, но для мощных, ресурсоемких сайтов рекомендуется купить свой сервер,а можно заказать  vds хостинг. VPS хостинга вам хватит под большинство задач. Грамотно подходите к выбору хост-площадки.

1 комментарий:

  • спасибо за статью.

Оставить комментарий

Подпишитесь на наш паблик в ВК

Рейтинг@Mail.ru