1. Вы находитесь в архивной версии форума xaker.name. Здесь собраны темы с 2007 по 2012 год, большинство инструкций и мануалов уже неактуальны.

Архитектура Twitter

  1. ozs
    Twitter стартовал как побочный подпроект, но не смотря на это темпы его роста были впечатляющими: путь от 0 до миллионов просмотров страниц занял всего несколько коротких месяцев. Ранние решения о проектировании системы неплохо справлялись с небольшими нагрузками, но они быстро таяли под напором огромного количества пользователей, желающих разослать весточки всем своим друзьям с ответом на простой вопрос: а чем ты занимаешься?


    Статистика
    • 752% рост аудитории за 2008 год
    • 1358% рост аудитории за 2009 год (без учета API, по данным comScore)
    • 120 миллионов зарегистрированных пользователей
    • 9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
    • 70 миллионов твитов в день (800 в секунду в среднем, пики до 2000)
    • Каждый твит читают в среднем 600 раз, то есть 1.2 миллионов показов твитов в секунду
    • 600 миллионов поисков в день
    • Лишь 25% трафика приходится на веб сайт, остальное идет через API
    • 6 миллиардов запросов к API в день, около 70 тысяч в секунду

    Платформа
    • Apache + mod_proxy
    • Unicorn
    • Ruby + Ruby on Rails
    • Scala
    • Flock
    • memcached
    • Kestrel
    • MySQL
    • Cassandra
    • Scribe
    • Hadoop, HBase и Pig

    Оборудование
    • Сервера расположены в NTT America
    • Никаких облаков и виртуализации, существующие решения страдают слишком высокими задержками
    • Более тысячи серверов
    • Планируется переезд в собственный датацентр

    Что такое твит?
    • Сообщение длиной до 140 символов + метаданные
    • Типичные запросы:
      • по идентификатору
      • по автору
      • по @упоминаниям пользователей

    Архитектура


    Unicorn
    Сервер приложений для Rails:
    • Развертывание новых версий кода без простоя
    • На 30% меньше расход вычислительных ресурсов и оперативной памяти, по сравнению с другими решениями
    • Перешли с mod_proxy_balancer на mod_proxy_pass

    Rails
    Используется в основном для генерации страниц, работа за сценой реализована на чистом Ruby или Scala.
    Столкнулись со следующими проблемами:
    • Проблемы с кэшированием, особенно по части инвалидации
    • ActiveRecord генерирует не самые удачные SQL-запросы, что замедляло время отклика
    • Высокие задержки в очереди и при репликации

    memcached
    • memcached не идеален. Twitter начал сталкиваться с Segmentation Fault в нем очень рано.
    • Большинство стратегий кэширования основываются на длинных TTL (боллее минуты).
    • Вытеснение данных делает его непригодным для важных конфигурационных данных (например флагов «темного режима», о котором пойдет речь ниже).
    • Разбивается на несколько пулов для улучшения производительности и снижения риска вытеснения.
    • Оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached + FNV hash, вместо чистого Ruby и md5.
    • Twitter является одним их наиболее активных проектов, участвующих в разработке libmemcached.

    MySQL
    • Разбиение больших объемов данных является тяжелой задачей.
    • Задержки в репликации и вытеснение данных из кэша является причиной нарушения целостности данных с точки зрения конечного пользователя.
    • Блокировки создают борьбу за ресурсы для популярных данных.
    • Репликация однопоточна и происходит недостаточно быстро.
    • Данные социальных сетей плохо подходят для реляционных СУБД:
      • NxN отношения, социальный граф и обход деревьев — не самые подходящие задачи для таких баз данных
      • Проблемы с дисковой подсистемой (выбор файловой системы, noatime, алгоритм планирования)
      • ACID практически не требуется
      • Для очередей также практически непригодны
    • Twitter сталкивался с большими проблемами касательно таблиц пользователей и их статусов
    • Читать данные с мастера при Master/Slave репликации = медленная смерть

    FlockDB
    Масштабируемое хранилище для данных социального графа:
    • Разбиение данных через Gizzard
    • Множество серверов MySQL в качестве низлежащей системы хранения
    • В Twitter содержит 13 миллиардов ребер графа и обеспечивает 20 тысяч операций записи и 100 тысяч операций чтения в секунду
    • Грани хранятся и индексируются в обоих направлениях
    • Поддерживает распределенный подсчет количества строк

    Среднее время на выполнение операций:
    • Подсчет количества строк: 1мс
    • Временные запросы: 2мс
    • Запись: 1мс для журнала, 16мс для надежной записи
    • Обход дерева: 100 граней/мс

    Cassandra
    Распределенная система хранения данных, ориентированная на работу в реальном времени:
    • Изначально разработана в Facebook
    • Очень высокая производительность на запись
    • Из слабых сторон: высокая задержка при случайном доступе
    • Децентрализованная, способна переносить сбои оборудования
    • Гибкая схема данных
    • Планируется полный переход на нее по следующему алгоритму:
      • Все твиты пишутся и в Cassandra и в MySQL
      • Динамически часть операций чтения переводится на Cassandra
      • Анализируется реакция системы, что сломалось
      • Полностью отключаем чтение из Cassandra, чиним неисправности
      • Начинаем сначала

    Scribe
    Пользователи Twitter генерируют огромное количество данных, около 15-25 Гб в минуту, более 12 Тб в день, и эта цифра удваивается несколько раз в год.

    Изначально для сбора логов использовали syslog-ng, но он очень быстро перестал справляться с нагрузкой.

    Решение нашлось очень просто: Facebook столкнулся с аналогичной проблемой и разработал проект Scribe, который был опубликован в opensource.

    По сути это фреймворк для сбора и агрегации логов, основанный на Thrift. Вы пишете текст для логов и указываете категорию, остальное он берет на себя.

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

    Поддерживаются различные системы для записи в данным, в том числе обычные файлы и HDFS (о ней ниже).

    Этот продукт полностью решил проблему Twitter со сбором логов, используется около 30 различных категорий. В процессе использования была создана и опубликована масса доработок. Активно сотрудничают с командой Facebook в развитии проекта.

    Hadoop
    Как Вы обычно сохраняете 12Тб новых данных, поступающих каждый день?

    Если считать, что средняя скорость записи современного жесткого диска составляет 80Мбайт в секунду, запись 12Тб данных заняла бы почти 48 часов.

    На одном даже очень большом сервере данную задачу не решить, логичным решением задачи стало использование кластера для хранения и анализа таких объемов данных.

    Использование кластерной файловой системы добавляет сложности, но позволяет меньше заботиться о деталях.

    Hadoop Distributed File System (HDFS) предоставляет возможность автоматической репликации и помогает справляться со сбоями оборудования.

    MapReduce framework позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение.

    Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter:
    • Вычисление связей дружбы в социальном графе (grep и awk не справились бы, self join в MySQL на таблицах с миллиардами строк — тоже)
    • Подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 миллиардах записей)
    • Подсчет PageRank между пользователями для вычисления репутации.
    В твиттер используется бесплатный дистрибутив от Cloudera, версия Hadoop 0.20.1, данные храняться в сжатом по алгоритму LZO виде, библиотеки для работы с данными опубликованы под названием elephant-bird.

    Pig
    Для того чтобы анализировать данные с помощью MapReduce обычно необходимо разрабатывать код на Java, что далеко не все умеют делать, да и трудоемко это.

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

    Немного напоминает SQL, но намного проще. Это позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce работ. Большая часть работы по анализу данных в Twitter осуществляется с помощью Pig.

    Данные
    Полу-структурированные данные:
    • логи Apache, RoR, MySQL, A/B тестирования, процесса регистрации
    • поисковые запросы

    Структурированные данные:
    • Твиты
    • Пользователи
    • Блок-листы
    • Номера телефонов
    • Любимые твиты
    • Сохраненные поиски
    • Ретвиты
    • Авторизации
    • Подписки
    • Сторонние клиенты
    • География

    Запутанные данные:
    • Социальный граф
    Что же они делают с этим всем?
    • Подсчет математического ожидания, минимума, максимума и дисперсии следующих показателей:
      • Количество запросов за сутки
      • Средняя задержка, 95% задержка
      • Распределение кодов HTTP-ответов (по часам)
      • Количество поисков осуществляется каждый день
      • Количество уникальных запросов и пользователей
      • Географическое распределение запросов и пользователей
    • Подсчет вероятности, ковариации, влияния:
      • Как отличается использование через мобильные устройства?
      • Как влияет использование клиентов сторонних разработчиков?
      • Когортный анализ
      • Проблемы с сайтом (киты и роботы, подробнее ниже)
      • Какие функциональные возможности цепляют пользователей?
      • Какие функциональные возможности чаще используются популярными пользователями?
      • Корректировка и предложение поисковых запросов
      • A/B тестирование
    • Предсказания, анализ графов, естественные языки:
      • Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
      • Какая структура графа ведет к успешным популярным сетям
      • Пользовательская репутация
      • Анализ эмоциональной окраски
      • Какие особенности заставляют людей ретвитнуть твит?
      • Что влияет на глубину дерева ретвитов ?
      • Долгосрочное обнаружение дубликатов
      • Машинное обучение
      • Обнаружения языка

    HBase
    Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:
    • HBase используется как изменяемая прослойка над HDFS
    • Данные экспортируются из HBase c помощью периодической MapReduce работы:
      • На этапе Map использются также данные из FlockDB и нескольких внутренних сервисов
      • Собственная схема разбиения данных
      • Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala
    На основе HBase разрабатываются и другие продукты внутри Twitter.

    Основными её достоинствами являются гибкость и легкая интеграция с Hadoop и Pig.
    По сравнению с Cassandra:
    • «Их происхождение объясняет их сильные и слабые стороны»
    • HBase построен на основе системы по пакетной обработке данных, высокие задержки, работает далеко не в реальном времени
    • Cassandra построена с нуля для работы с низкими задержками
    • HBase легко использовать при анализе данных как источник или место сохранения результатов, Cassandra для этого подходит меньше, но они работают над этим
    • HBase на данный момент единственную точку отказа в виде мастер-узла
    • В твиттере HBase используется для аналитики, анализа и создания наборов данных, а Cassandra — для онлайн систем

    Loony
    Централизованная система управления оборудованием.
    Реализована с использованием:
    • Python
    • Django
    • MySQL
    • Paraminko (реализация протокола SSH на Python, разработана и опубликована в opensource в Twitter)
    Интегрирована с LDAP, анализирует входящую почту от датацентра и автоматически вносит изменения в базу.

    Murder
    Система развертывания кода и ПО, основанная на протоколе BitTorrent.
    Благодаря своей P2P природе позволяет обновить более тысячи серверов за 30-60 секунд.

    Kestrel
    Распределенная очередь, работающая по протоколу memcache:
    • set — поставить в очередь
    • get — взять из очереди

    Особенности:
    • Отсутствие строгого порядка выполнения заданий
    • Отсутствие общего состояния между серверами
    • Разработана на Scala

    Daemon'ы
    Каждый твит обрабатывается с помощью daemon'ов.

    В unicorn обрабатываются только HTTP запросы, вся работа за сценой реализована в виде отдельных daemon'ов.

    Раньше использовалось много разных демонов, по одному на каждую задачу (Rails), но перешли к меньшему их количеству, способному решать несколько задач одновременно.

    Как они справляются с такими темпами роста?
    Рецепт прост, но эффективен, подходит практически для любого интернет-проекта:
    • обнаружить самое слабое место в системе;
    • принять меры по его устранению;
    • перейти к следующему самому слабому месту.

    На словах звучит и правда примитивно, но на практике нужно предпринять ряд мер, чтобы такой подход был бы реализуем:
    • Автоматический сбор метрик (причем в агрегированном виде)
    • Построение графиков (RRD, Ganglia)
    • Сбор и анализ логов
    • Все данные должны получаться с минимальной задержкой, как можно более близко к реальному времени
    • Анализ:
      • Из данных необходимо получать информацию
      • Следить за динамикой показателей: стало лучше или хуже?
      • Особенно при развертывании новых версий кода
      • Планирование использования ресурсов намного проще, чем решение экстренных ситуаций, когда они на исходу

    Примерами агрегированных метрик в Twitter являются «киты» и «роботы», вернее их количество в единицу времени.

    Что такое «робот»?
    • Ошибка внутри Rails (HTTP 500)
    • Непойманное исключение
    • Проблема в коде или нулевой результат

    Что такое «кит»?
    • HTTP ошибка 502 или 503
    • В твиттер используется фиксированный таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах)
    • Убитый слишком длинный запрос к базе данных (mkill)

    Значительное превышение нормального количества китов или роботов в минуту является поводом для беспокойством.

    Реализован этот механизм простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения.

    «Темный режим»
    Для экстренных ситуаций в Twitter предусмотрен так называемый «темный режим», который представляет собой набор механизмов для отключения тяжелых по вычислительным ресурсам или вводу-выводу функциональных частей сайта. Что-то вроде стоп-крана для сайта.

    Имеется около 60 выключателей, в том числе и полный режим «только для чтения».

    Все изменения в настройках этого режима фиксируются в логах и сообщаются руководству, чтобы никто не баловался.

    Подводим итоги
    • Не бросайте систему на самотек, начинайте собирать метрики и их визуализировать как можно раньше
    • Заранее планируйте рост требуемых ресурсов и свои действия в случае экстренных ситуаций
    • Кэшируйте по максимуму все, что возможно
    • Все инженерные решения не вечны, ни одно из решений не идеально, но многие будут нормально работать в течение какого-то периода времени
    • Заранее начинайте задумываться о плане масштабирования
    • Не полагайтесь полностью на memcached и базу данных — они могут Вас подвести в самый неподходящий момент
    • Все данные для запросов в реальном времени должны находиться в памяти, диски в основном для записи
    • Убивайте медленные запросы (mkill) прежде, чем они убьют всю систему
    • Некоторые задачи могут решаться путем предварительного подсчета и анализа, но далеко не все
    • Приближайте вычисления к данным по возможности
    • Используйте не mongrel, а unicorn для RoR
    (c)insight-it.ru
     
    1 человеку нравится это.