https://www.insight-it.ru/Wed, 15 Aug 2012 22:26:00 +0400https://www.insight-it.ru//highload/2012/arkhitektura-pinterest/<p><a href="https://www.insight-it.ru/goto/975fdd8/" rel="nofollow" target="_blank" title="https://www.pinterest.com/">Pinterest</a> - по непонятным для меня причинам популярная в определенных кругах социальная сеть, построенная вокруг произвольных картинок чаще всего не собственного производства. Как и <a href="https://www.insight-it.ru/highload/2012/arkhitektura-instagram/">Instagram</a> проект довольно молодой, с очень похожей историей и стеком технологий. Тем не менее, Pinterest определенно заслуживает внимания как один из самых быстрорастущих по посещаемости вебсайтов за всю историю.</p> <!--more--> <h2 id="platforma">Платформа</h2> <ul> <li><a href="/tag/amazon/">Amazon</a> <a href="/tag/aws/">AWS</a>&nbsp;- хостинг и вспомогательные сервисы</li> <li><a href="/tag/nginx/">nginx</a>&nbsp;- вторичная балансировка нагрузки, отдача статики</li> <li><a href="/tag/python/">Python</a>&nbsp;- язык программирования</li> <li><a href="/tag/django/">Django</a>&nbsp;- фреймворк</li> <li><a href="/tag/mysql/">MySQL</a>&nbsp;- основная СУБД</li> <li><a href="/tag/memcached/">memcached</a>&nbsp;- кэширование объектов</li> <li><a href="/tag/redis/">Redis</a>&nbsp;- кэширование коллекций объектов</li> <li><a href="/tag/solr/">Solr</a>&nbsp;- поиск</li> <li><a href="/tag/hadoop/">Hadoop</a>&nbsp;- анализ данных</li> </ul> <h2 id="statistika">Статистика</h2> <ul> <li>3 миллиона уникальных посетителей в день</li> <li>18 миллионов уникальных посетителей в месяц</li> <li>4-я по популярности социальная сеть в США после <a href="/tag/facebook/">Facebook</a>,&nbsp;<a href="/tag/twitter/">Twitter</a>&nbsp;и <a href="/tag/linkedin/">LinkedIn</a></li> <li>Порядка 500 виртуальных машин в EC2</li> <li>80 миллионов объектов в S3</li> <li>410Тб пользовательских данных</li> </ul> <h2 id="razvitie">Развитие</h2> <h4>Март 2010</h4> <ul> <li>1 маленький виртуальный веб-сервер</li> <li>1 маленький виртуальный сервер MySQL</li> <li>Все это в Rackspace, 1 разработчик</li> </ul> <h4>Январь 2011</h4> <ul> <li>1 сервер nginx для балансировки нагрузки, 4 веб-сервера</li> <li>2 сервера MySQL с master/slave репликацией</li> <li>3 сервера для отложенного выполнения задач</li> <li>1 сервер MongoDB</li> <li>Переехали на Amazon <a href="/tag/ec2/">EC2</a> + <a href="/tag/s3/">S3</a> + <a href="/tag/cloudfront/">CloudFront</a></li> </ul> <h4>Осень 2011</h4> <ul> <li>2 сервера nginx, 16 веб-серверов, 2 сервера для API</li> <li>5 функционально разделенных серверов MySQL с 9 read slave</li> <li>Кластер из 4 узлов Cassandra</li> <li>15 серверов Membase в 3 отдельных кластерах</li> <li>8 серверов memcached</li> <li>10 серверов Redis</li> <li>7 серверов для отложенной обработки задач</li> <li>4 сервера Elastic Search</li> <li>3 кластера MongoDB</li> <li>3 разработчика</li> <li>Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.</li> </ul> <h4>Зима 2011-2012</h4> <ul> <li>Заменили CloudFront на <a href="/tag/akamai/">Akamai</a> - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный&nbsp;<a href="/tag/cdn/">CDN</a> для сайта с большим количеством изображений - чуть ли не залог успеха.</li> <li>90 веб серверов и 50 серверов для API</li> <li>66 + 66 MySQL серверов на m1.xlarge инстансах EC2</li> <li>59 серверов Redis</li> <li>51 серверов memcached</li> <li>25+1 сервер для отложенной обработки задач на основе Redis</li> <li>Кластеризованный Solr</li> <li>6 разработчиков</li> </ul> <h4>Весна-лето 2012</h4> <ul> <li>Снова сменили CDN, на этот раз в пользу ранее неизвестного мне <a href="/tag/edge-cast/">Edge Cast</a>. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.</li> <li>135 веб серверов и 75 серверов для API</li> <li>80 + 80 серверов MySQL</li> <li>110 серверов Redis</li> <li>60 серверов memcached</li> <li>60 + 2&nbsp;сервера&nbsp;для отложенной обработки задач на основе Redis</li> <li>25 разработчиков</li> </ul> <h2 id="vybor">Выбор</h2> <h4>Почему Amazon Ec2/S3?</h4> <ul> <li>Очень хорошая надежность, отчетность и поддержка</li> <li>Хорошие дополнительные сервисы: кэш, базы данных, балансировка нагрузки, <a href="/tag/mapreduce/">MapReduce</a> и т.п.</li> <li><em>Новые виртуальные машины готовы за считанные секунды</em></li> </ul> <h4>Почему MySQL?</h4> <ul> <li>Очень "зрелая", хорошо известная и любимая многими</li> <li>Редки катастрофичные потери данных</li> <li>Линейная зависимость времени отклика от частоты запросов</li> <li>Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)</li> <li>Надежное активное сообщество</li> <li>Отличная поддержка от Percona</li> <li>Бесплатна</li> </ul> <h4>Почему memcached?</h4> <ul> <li>Очень "зрелый", отличная производительность, хорошо известный и любимый многими</li> <li>Никогда не ломается</li> <li>Бесплатен</li> </ul> <h4>Почему Redis?</h4> <ul> <li>Много удобных <strong>структур данных</strong></li> <li>Поддержка персистентности и репликации</li> <li>Также многим известен и нравится</li> <li>Стабильно хорошая производительность и надежность</li> <li>Также бесплатен</li> </ul> <h2 id="arkhitektura">Архитектура</h2> <h4>Сlustering vs Sharding</h4> <ul> <li>Большую часть презентации, на основе которой написана данная статья (<a href="https://www.insight-it.ru/goto/10005efe/" rel="nofollow" target="_blank" title="http://www.slideshare.net/eonarts/mysql-meetup-july2012scalingpinterest">ссылка</a>, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.</li> <li>Вообще есть два фундаментальных способа распределить данные между несколькими серверами:<ul> <li><strong>Вертикально:</strong>&nbsp;разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.</li> <li><strong>Горизонтально:</strong> каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.</li> </ul> </li> <li>С первого взгляда казалось, что они пытаются вертикальное разбиение назвать <em>sharding</em>, а горизонтальное - <em>clustering</em>. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.</li> <li>По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду <a href="/tag/cassandra/">Cassandra</a>, <a href="/tag/membase/">Membase</a>, <a href="/tag/hbase/">HBase</a> и <a href="/tag/riak/">Riak</a>, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.</li> <li>За словом <em>sharding</em> в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством <del>физических серверов</del> виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в <a href="https://www.insight-it.ru/highload/2010/arkhitektura-facebook/">Facebook</a>.</li> <li>От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:<ul> <li><a href="/tag/vitess/">Vitess</a> от <a href="/tag/google/">Google</a> / <a href="/tag/youtube/">YouTube</a></li> <li><a href="/tag/flockdb/">FlockDB</a> от <a href="/tag/twitter/">Twitter</a></li> </ul> </li> <li>В их проекте данная подсистема развивалась следующим образом:<ul> <li>1 БД + внешние ключи + join'ы&nbsp;&rarr;</li> <li>1 БД + денормализация + кэш&nbsp;&rarr;</li> <li>1 БД + master/slave + кэш&nbsp;&rarr;</li> <li>несколько функциональных разделенных БД + master/slave + кэш&nbsp;&rarr;</li> <li>вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш</li> </ul> </li> <li>При использовании аналогичного решения остерегайтесь:<ul> <li>Невозможности выполнять большинство запросов с join</li> <li>Отсутствия транзакций</li> <li>Дополнительных манипуляций для поддержания ограничений уникальности</li> <li>Необходимости тщательного планирования для изменений схемы</li> <li>Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов</li> </ul> </li> </ul> <h4>Остальные моменты</h4> <ul> <li>Кэширование многоуровневое:<ul> <li>Коллекции объектов хранятся в списках Redis</li> <li>Сами объекты - в memcached</li> <li>На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL</li> <li>Кэш файловой системы - само собой</li> </ul> </li> <li>Еще пара фактов про кэширование в Pinterest:<ul> <li>Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования</li> <li>В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен</li> </ul> </li> <li>Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.</li> <li>Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.</li> <li>Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц</li> <li>Текущие проблемы:<ul> <li>Масштабирование команды</li> <li>Основанная на сервисах архитектура:<ul> <li>Ограничения соединений</li> <li>Изоляция функционала</li> <li>Изоляция доступа (безопасность)</li> </ul> </li> </ul> </li> </ul> <h2 id="uroki-ot-komandy-pinterest">Уроки от команды Pinterest</h2> <ol> <li><em>"Оно сломается. Все должно быть просто."</em> - столько раз уже слышу это наставление, но ни разу не видел разработчиков, которые реально к нему прислушивались.</li> <li><em>"Кластеризация - страшная штука."</em> - конечно страшная, большая и сложная. Но кому сейчас легко?</li> <li><em>"Продолжайте получать удовольствие."</em> - с этим не могу не согласиться, без удовольствия работать совершенно невозможно в любой сфере.</li> </ol> <h2 id="istochniki-informatsii">Источники информации</h2> <ul> <li><a href="https://www.insight-it.ru/goto/10005efe/" rel="nofollow" target="_blank" title="http://www.slideshare.net/eonarts/mysql-meetup-july2012scalingpinterest">Scaling Pinterest @ MySQL Meetup</a><ul> <li>В презентации можно посмотреть примеры кода и SQL-запросов</li> <li>Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста</li> </ul> </li> <li><a href="https://www.insight-it.ru/goto/ac4a03d6/" rel="nofollow" target="_blank" title="http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html">Pinterest Architecture Update</a></li> <li>Вакансии в Pinterest</li> </ul>Иван БлинковWed, 15 Aug 2012 22:26:00 +0400tag:www.insight-it.ru,2012-08-15:highload/2012/arkhitektura-pinterest/AkamaiAmazonApache HadoopAWSCDNCloudFrontdjangoEC2Edge CastHadoopMemcachedMySQLnginxPinterestPythonRedisS3SolrАрхитектура PinterestархиткутераМасштабируемостьhttps://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