https://www.insight-it.ru/Wed, 20 Oct 2010 13:02:00 +0400https://www.insight-it.ru//highload/2010/arkhitektura-facebook/<p><img alt="Facebook Logo" class="left" src="https://www.insight-it.ru/images/facebook_logo.jpg" title="Facebook Logo"/> На сегодняшний день <a href="https://www.insight-it.ru/goto/fbae133c/" rel="nofollow" target="_blank" title="https://www.facebook.com">Facebook</a> является пожалуй самым обсуждаемым интернет-проектом во всем мире. Не смотря на довольно низкий уровень проникновения Facebook в России, темпы захвата аудитории этим проектом мягко говоря поражают. Как же им удается управляться с таким огромным социальным графом и удовлетворять потребности в общении невероятно большого количества людей по всему миру?</p> <!--more--> <h2 id="platforma">Платформа</h2> <ul> <li><a href="/tag/linux/">Linux</a> - операционная система</li> <li><a href="/tag/php/">PHP</a> с <a href="/tag/hiphop/">HipHop</a> - код на PHP компилируется в C++</li> <li><a href="/tag/memcached/">memcached</a> - агрессивное кэширование объектов</li> <li><a href="/tag/mysql/">MySQL</a> - используется как хранилище пар ключ-значение, никаких join'ов</li> <li><a href="/tag/thrift/">Thrift</a> - интерфейс взаимодействия между сервисами, написанными на разных языках программирования</li> <li><a href="/tag/scribe/">Scribe</a> - универсальная система сбора и агрегации данных с рабочих серверов</li> </ul> <h2 id="statistika">Статистика</h2> <ul> <li>Более 500 миллионов активных пользователей (месячная аудитория)</li> <li>Более миллиарда социальных связей</li> <li>Более 200 миллиардов просмотров страниц в месяц</li> <li>Более 4 триллионов действий попадает в новостные ленты каждый день</li> <li>Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше</li> <li>Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно</li> <li>Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду</li> <li>20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых</li> <li>О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно</li> <li>Более миллиарда сообщений в чате каждый день</li> <li>Более ста миллионов поисковых запросов в день</li> <li>Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect</li> <li>Более 400 тысяч разработчиков сторонних приложений</li> <li>Менее 500 разработчиков и системных администраторов в штате</li> <li>Более миллиона активных пользователей на одного инженера</li> <li>Десятки тысяч серверов, десятки гигабит трафика</li> </ul> <h2 id="arkhitektura">Архитектура</h2> <h3 id="obshchie-printsipy">Общие принципы</h3> <ul> <li>Балансировщик нагрузки выбирает веб-сервер для обработки запроса</li> <li>PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:<ul> <li>MySQL</li> <li>memcached</li> <li>Специализированные сервисы</li> </ul> </li> <li>Если взглянуть с другой стороны, то получим трехуровневую архитектуру:<ul> <li>Вер-приложение</li> <li>Распределенный индекс</li> <li>Постоянное хранилище</li> </ul> </li> <li>Использование открытых технологий там, где это возможно</li> <li>Поиск возможностей оптимизации используемых продуктов</li> <li>Философия Unix:<ul> <li>Старайтесь делать каждый компонент системы простым и производительным</li> <li>Комбинируйте компоненты для решения задач</li> <li>Концентрируйте внимание на хорошо обозначенных точках взаимодействия</li> </ul> </li> <li>Все усилия направлены на масштабируемость</li> <li>Попытки минимизации количества точек отказа</li> <li>Простота, простота, простота!</li> </ul> <h3 id="php">PHP</h3> <p><strong>Почему PHP?</strong></p> <ul> <li>Во многом "так исторически сложилось"</li> <li>Хорошо подходит для веб-разработки</li> <li>Легок в изучении: небольшой набор выражений и языковых конструкций</li> <li>Легок в написании: нестрогая типизация и универсальный "массив"</li> <li>Легок в чтении: синтаксис похож на C++ и Java</li> <li>Прост в дебаггинге: нет необходимости в перекомпиляции</li> <li>Большой ассортимент библиотек, актуальных для веб-проектов</li> <li>Подходит для процесса разработки с короткими итерациями</li> <li>Активное сообщество разработчиков по всему миру</li> <li>Динамическая типизация, интерпретируемый язык для скриптов</li> </ul> <p><strong>Как оказалось на самом деле?</strong></p> <ul> <li>Высокий расход оперативной памяти и вычислительных ресурсов</li> <li>Сложно работать, когда объем исходного кода очень велик: слабая типизация и ограниченные возможности для статичного анализа и оптимизации кода</li> <li>Не особо оптимизирован для использования в крупных проектах</li> <li>Линейный рост издержек при подключении файлов с исходным кодом</li> <li>Механизм разработки расширений не очень удобен</li> </ul> <p><strong>Доработки:</strong></p> <ul> <li>Оптимизация байт-кода</li> <li>Улучшения в APC (ленивая загрузка, оптимизация блокировок, "подогрев" кэша)</li> <li>Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)</li> <li><strong><a href="https://www.insight-it.ru/goto/169aa287/" rel="nofollow" target="_blank" title="http://github.com/facebook/hiphop-php">HipHop</a></strong> - трансформатор исходных кодов:<ul> <li>Разработчики пишут на PHP, который конвертируется в оптимизированный C++</li> <li>Статический анализ, определение типов данных, генерация кода, и.т.д.</li> <li>Облегчает разработку расширений</li> <li>Существенно сокращает расходы оперативной памяти и вычислительных ресурсов</li> <li>У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка</li> <li>Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля</li> </ul> </li> </ul> <h3 id="mysql">MySQL</h3> <p><strong>Как используется MySQL?</strong></p> <ul> <li>Используется как хранилище пар ключ-значение</li> <li>Большое количество логических узлов распределено между физическими машинами</li> <li>Балансировка нагрузке на уровне физических серверов</li> <li>Репликация для распределения операций чтения <strong>не</strong> используется</li> <li>Большинство запросов касаются самой свежей информации: оптимизация таблиц для доступа к новым данным, архивация старых записей</li> <li>В целом быстро и надежно</li> </ul> <p><strong>Как оказалось на самом деле?</strong></p> <ul> <li>Логическая миграция данных <em>очень</em> сложна</li> <li>Создавать большое количество логических баз данных и перераспределять их между физическими узлами, балансируя таким образом нагрузку, намного удобнее</li> <li>Никаких join'ов на рабочих серверах баз данных</li> <li>Намного проще наращивать вычислительные мощности на веб-серверах, чем на серверах баз данных</li> <li>Схемы, основанные на структуре данных, делают программистов счастливыми и создают большую головную боль администраторам</li> <li>Никогда не храните не-статичные данные в централизованное базе данных</li> </ul> <p><strong>Доработки:</strong></p> <ul> <li>Практически никаких модификаций исходного кода MySQL</li> <li>Своя схема партиционирования с глобально-уникальными идентификаторами</li> <li>Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя</li> <li>Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша</li> <li>Библиотеки для доступа к данным на основе графа:<ul> <li>Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)</li> <li>Реплицированные связи (ребра графа)</li> <li>Аналоги распределенных внешних ключей (foreign keys)</li> <li>Большинство данных распределено случайно</li> </ul> </li> </ul> <h3 id="memcache">Memcache</h3> <p><strong>Как используется memcached?</strong></p> <ul> <li>Высокопроизводительная распределенная хэш-таблица</li> <li>Содержит "горячие" данные из MySQL</li> <li>Снижает нагрузку на уровень баз данных</li> <li>Основная форма кэширования</li> <li>Используется более 25TB памяти на нескольких тысячах серверов</li> <li>Среднее время отклика менее 250 микро-секунд</li> <li>Кэшируются сериализованные структуры данных PHP</li> <li>Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL - приходится делать это на уровне программного кода</li> <li>Множество multi-get запросов для получения данных на другом конце ребер графа</li> <li>Ограниченная модель данных, неэффективен для маленьких объектов</li> </ul> <p><strong>Доработки:</strong></p> <ul> <li>Порт на 64-битную архитектуру</li> <li>Более эффективная сериализация</li> <li>Многопоточность</li> <li>Улучшенный протокол</li> <li>Компрессия</li> <li>Проксирование запросов</li> <li>Доступ к memcache через UDP:<ul> <li>уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений</li> <li>управление ходом исполнения приложение (оптимизация для multi-get)</li> </ul> </li> <li>Статистика о работе потоков по запросу - уменьшает блокировки</li> <li>Ряд изменений в ядре Linux для оптимизации работы memcache:<ul> <li>распределение управления сетевыми прерывания по всем ядрам</li> <li>оппортунистический опрос сетевых интерфейсов</li> </ul> </li> <li>После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений</li> </ul> <h3 id="thrift">Thrift</h3> <p><strong>Что это?</strong></p> <ul> <li>Легкий механизм построения приложений с использованием нескольких языков программирования</li> <li>Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.</li> <li>Предоставляет язык описания интерфейсов, статический генератор кода</li> <li>Поддерживаемые языки: <a href="/tag/c/">C++</a>, <a href="/tag/php/">PHP</a>, <a href="/tag/python/">Python</a>, <a href="/tag/java/">Java</a>, <a href="/tag/ruby/">Ruby</a>, <a href="/tag/erlang/">Erlang</a>, <a href="/tag/perl/">Perl</a>, <a href="/tag/haskell/">Haskell</a> и многие другие</li> <li>Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)</li> <li>Протоколы: стандарты сериализации (бинарный, JSON)</li> <li>Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные</li> </ul> <p><strong>Почему именно Thrift?</strong></p> <ul> <li>Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers - но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию</li> <li>Он быстрый, очень быстрый</li> <li>Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы</li> <li>Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями</li> <li>Общий инструментарий, знакомый всем разработчикам</li> </ul> <h3 id="scribe">Scribe</h3> <p><strong>Что это?</strong></p> <ul> <li>Масштабированный распределенный механизм ведения логов</li> <li>Перемещает данные с серверов в центральный репозиторий</li> <li>Широкая сфера применения:<ul> <li>Логи поисковых запросов</li> <li>Публикации в новостных лентах</li> <li>Данные по A/B тестированиям</li> </ul> </li> <li>Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных</li> <li>Простая модель данных</li> <li>Построен на основе Thrift</li> </ul> <h3 id="khranenie-fotografii">Хранение фотографий</h3> <p><strong>Сначала сделали это просто:</strong></p> <ul> <li>Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS</li> <li>Загрузка с сервера: изображения отдаются из NFS через HTTP</li> <li>NFS построена на коммерческих продуктах</li> <li>Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии</li> <li>На самом деле оказалось, что:<ul> <li>Файловые системы непригодны для работы с большим количеством небольших файлов</li> <li>Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме</li> <li>Ограничивающим фактором является ввод-вывод, а не плотность хранения</li> </ul> </li> </ul> <p><strong>Потом начали оптимизировать:</strong></p> <ul> <li>Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности</li> <li>Распределение их по <a href="/tag/cdn/">CDN</a> для уменьшения сетевых задержек</li> <li>Возможно сделать еще лучше:<ul> <li>Хранение изображений в больших бинарных файлах (blob)</li> <li>Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)</li> <li>Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее "простого" подхода и в 3 раза эффективнее "оптимизированного"</li> </ul> </li> </ul> <h3 id="drugie-servisy">Другие сервисы</h3> <ul> <li><strong>SMC</strong>: консоль управления сервисами - централизованная конфигурация, определение на какой физической машине работает логический сервис</li> <li><strong>ODS</strong>:&nbsp;инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений</li> <li><strong>Gatekeeper:</strong> разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск</li> <li>И еще около 50 других сервисов...</li> </ul> <h2 id="kak-eto-rabotaet-vse-vmeste_1">Как это работает все вместе?</h2> <h3 id="novye-albomy-druzei">Новые альбомы друзей</h3> <p><img alt="Facebook Screenshot" class="responsive-img" src="https://www.insight-it.ru/images/facebook_screenshot.jpg" title="Facebook"/></p> <ol> <li>Получаем профиль по идентификатору пользователя (скорее всего из кэша, но потенциально возможно обращение к базе данных)</li> <li>Получаем список друзей (опять же на основе идентификатора пользователя из кэша или из базы данных в случае промаха)</li> <li>Параллельно запрашиваем идентификаторы последних 10 альбомов для каждого из друзей (multi-get, каждый промах мимо кэша индивидуально вытаскивается из MySQL)</li> <li>Параллельно получаем данные о всех альбомах (на основе идентификаторов альбомов из предыдущего шага)</li> <li>Все данные получены, выполняем логику отрисовки конкретной страницы на PHP</li> <li>Отправляем HTML в браузер, пользователь счастлив :)</li> </ol> <h3 id="novostnaia-lenta">Новостная лента</h3> <p><img alt="News Feed Screenshot" class="responsive-img" src="https://www.insight-it.ru/images/facebook_screenshot_2.jpg" title="News Feed"/></p> <p><img alt="News Feed Scheme" class="responsive-img" src="https://www.insight-it.ru/images/facebook_screenshot_3.jpg" title="News Feed"/></p> <h3 id="poisk">Поиск</h3> <p><img alt="Search Screenshot" class="responsive-img" src="https://www.insight-it.ru/images/facebook_screenshot_4.jpg" title="Search"/></p> <p><img alt="Search Scheme" class="responsive-img" src="https://www.insight-it.ru/images/facebook_screenshot_5.jpg" title="Search"/></p> <h2 id="podvodim-itogi_1">Подводим итоги</h2> <p>LAMP не идеален</p> <ul> <li>PHP+MySQL+Memcache решает большинство задач, но не может решить совсем все:<ul> <li>PHP не может хранить состояния</li> <li>PHP не самый производительный язык</li> <li>Все данные находятся удаленно</li> </ul> </li> <li>Facebook разрабатывает собственные внутренние сервисы, чтобы:<ul> <li>Располагать исполняемый код ближе к данным</li> <li>Скомпилированное окружение более эффективно</li> <li>Некоторая функциональность присутствует только в других языках программирования</li> </ul> </li> <li>Философия сервисов:<ul> <li>Создание сервисов только при необходимости (минимизация издержек по развертке, поддержке и ведению отдельной кодовой базы; потенциальная дополнительная точка сбоя)</li> <li>Создание общего набора инструментов для создания сервисов (Thrift, Scribe, ODS, средства мониторинга и уведомлений)</li> <li><em>Использование правильных языка программирования, библиотек и инструментов для решения задачи</em></li> </ul> </li> <li>Возвращение инноваций общественности - важный аспект разработки в Facebook:<ul> <li>Опубликованные свои проекты:<ul> <li>Thrift</li> <li>Scribe</li> <li>Tornado</li> <li>Cassandra</li> <li>Varnish</li> <li>Hive</li> <li>xhprof</li> </ul> </li> <li>Доработки популярных решений:<ul> <li>PHP</li> <li>MySQL</li> <li>memcached</li> </ul> </li> <li>Информация о взаимодействии Facebook с opensource-сообществом, этих и других проектах расположена на <a href="https://www.insight-it.ru/goto/535d8e6b/" rel="nofollow" target="_blank" title="http://developers.facebook.com/opensource/">странице, посвященной opensource</a>.</li> </ul> </li> <li>Ключевые моменты культуры разработки в Facebook:<ul> <li><strong>Двигайся быстро</strong> и не бойся ломать некоторые вещи</li> <li><strong>Большое влияние</strong> маленьких команд</li> <li><strong>Будь откровенным</strong> и инновационным</li> </ul> </li> </ul> <h2 id="istochniki-informatsii">Источники информации</h2> <p>Данная статья не является переводом готовой статьи, в качестве источников информации послужили записи выступлений сотрудников Facebook на конференциях:</p> <ul> <li><a href="https://www.insight-it.ru/goto/4c672c94/" rel="nofollow" target="_blank" title="http://www.infoq.com/presentations/Facebook-Software-Stack">Facebook Architecture: Science and the Social Graph</a></li> <li><a href="https://www.insight-it.ru/goto/2ccd1899/" rel="nofollow" target="_blank" title="http://www.infoq.com/presentations/Facebook-Moving-Fast-at-Scale">Facebook: Moving Fast at Scale</a></li> <li><a href="https://www.insight-it.ru/goto/3867625a/" rel="nofollow" target="_blank" title="http://www.infoq.com/presentations/Scale-at-Facebook">Scale at Facebook</a></li> </ul> <p>Очень рекомендую посмотреть материалы в оригинале, так как естественно я осветил в статье далеко не все, да и неточности какие-либо неисключены. Помимо этого возможно многим будет интересно мероприятие <a href="https://www.insight-it.ru/goto/ff11ad2b/" rel="nofollow" target="_blank" title="http://styleru.timepad.ru/event/3571">"Facebook: how we scaled to 500 000 000 users "</a>, где Robert Johnson выступает 22 октября в Москве. Еще он числится в списке докладчиков <a href="https://www.insight-it.ru/goto/727c9436/" rel="nofollow" target="_blank" title="http://www.highload.ru">Highload++</a> с аналогичным выступлением. Дополнительную информацию можно почерпнуть в <a href="https://www.insight-it.ru/goto/f38bc794/" rel="nofollow" target="_blank" title="http://facebook.com/eblog">блоге инженеров Facebook</a>.</p> <p><strong>UPD:</strong> Обновил некоторые моменты после посещения вышеупомянутого выступления Роберта.</p> <p>И по традиции напоминаю, что так как я пишу довольно редко - читать мой блог намного удобнее по <a href="/feed/">RSS</a>. Спасибо за внимание :)</p>Иван БлинковWed, 20 Oct 2010 13:02:00 +0400tag:www.insight-it.ru,2010-10-20:highload/2010/arkhitektura-facebook/CDNFacebookfeaturedHipHopLinuxMemcachedMySQLODSPHPScribeThriftАрхитектура Facebook