Архитектура Twitter. Два года спустя.

Иван Блинков — Sat, 05 Mar 2011 20:47:00 +0300

В далеком 2008м я уже публиковал статью про архитектуру Twitter, но время летит стремительно и она уже абсолютно устарела. За это время аудитория Twitter росла просто фантастическими темпами и многое поменялось и с технической точки зрения. Интересно что новенького у одного из самых популярных социальных интернет-проектов?

Статистика

3 год, 2 месяца и 1 день потребовалось Twitter, чтобы набрать 1 миллиард твитов
На сегодняшний день, чтобы отправить миллиард твитов пользователям нужна всего одна неделя
752% рост аудитории за 2008 год
1358% рост аудитории за 2009 год (без учета API, по данным comScore)
175 миллионов зарегистрированных пользователей на сентябрь 2010 года
460 тысяч регистраций пользователей в день
9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
50 миллионов твитов в день год назад, 140 миллионов твитов в день месяц назад, 177 миллионов твитов в день на 11 марта 2011г.
Рекорд по количеству твитов за секунду 6939, установлен через минуту после того, как Новый Год 2011 наступил в Японии
600 миллионов поисков в день
Лишь 25% трафика приходится на веб сайт, остальное идет через API
Росто числа мобильных пользователей за последний год 182%
6 миллиардов запросов к API в день, около 70 тысяч в секунду
8, 29, 130, 350, 400 - это количество сотрудников Twitter на январь 2008, январь 2009, январь 2010, январь и март 2011, соответственно

Самая свежая статистика про Twitter.

Платформа

Сравните с аналогичным разделом предыдущей статьи о Twitter - увидите много новых лиц, подробнее ниже.

Оборудование

Сервера расположены в 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 тысяч операций чтения в секунду
Грани хранятся и индексируются в обоих направлениях
Поддерживает распределенный подсчет количества строк
Open source!

Среднее время на выполнение операций:

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

Подробнее про эволюцию систем хранения данных в Twitter в презентации Nick Kallen.

Cassandra

Распределенная система хранения данных, ориентированная на работу в реальном времени:

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

Подробнее почему Twitter пришел к решению использовать 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 тестирование
Предсказания, анализ графов, естественные языки:
- Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
- Какая структура графа ведет к успешным популярным сетям
- Пользовательская репутация
- Анализ эмоциональной окраски
- Какие особенности заставляют людей ретвитнуть твит?
- Что влияет на глубину дерева ретвитов ?
- Долгосрочное обнаружение дубликатов
- Машинное обучение
- Обнаружения языка

Подробнее про обработку данных в презентации Kevin Weil.

HBase

Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:

HBase используется как изменяемая прослойка над HDFS
Данные экспортируются из HBase c помощью периодической MapReduce работы:
- На этапе Map используются также данные из FlockDB и нескольких внутренних сервисов
- Собственная схема разбиения данных
- Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala (подробнее о построении распределенных сервисов на 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 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения. Подробнее про работу команды оперативного реагирования в презентации John Adams.

"Темный режим"

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

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

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

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

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

Спасибо за внимание, жду Вас снова! Буду рад, если Вы подпишитесь на меня в Twitter, с удовольствием пообщаюсь со всеми читателями :)

Insight IT