Insight IT

Twitter Storm

Иван Блинков — Sat, 31 Mar 2012 00:08:00 +0400

Storm является распределенной системой для выполнения вычислений в реальном времени. Она родилась в рамках проекта Backtype, который специализировался на аналитике твитов и который в июле 2011 был приобретен Twitter. Так же как Apache Hadoop предоставляет набор базовых абстракций, инструментов и механизмов для пакетной обработки данных, Twitter Storm делает это для задачи обработки данных в режиме реального времени. Хотите узнать в чем их отличие?

Отличие

Не смотря на то, что Storm изначально появился на свет в процессе неудачных попыток приспособить Hadoop к задаче обработки данных в реальном времени, сравнивать их некорректно. Никакой хак или патч не сможет заставить Hadoop работать по-настоящему в режиме реального времени, так как в его основе лежит фундаментально другая концепция и набор принципов, которые актуальны лишь в контексте задачи пакетной обработки данных. Storm можно представить как "Hadoop для вычислений в реальном времени", но по факту между ними нет практически ничего общего, кроме изначально-распределенной природы, слегка похожей архитектуры, работы внутри JVM и публичной доступности. Для понимания задачи, которая стоит перед Storm, лучше взглянуть на то, как она обычно решается.

Традиционно, если перед проектом или бизнесом вставала задача обработки какой-то информации в реальном времени, то она в итоге сводилась к цепочке преобразований данных и распределялась по серверам, которые их выполняют и передают результаты друг другу посредством сообщений и очередей-посредников. При таком подходе существенная часть времени уходила на маршрутизацию сообщений, настройку и развертывание новых промежуточных очередей и обработчиков, обеспечение отказоустойчивости и надежности. По сути Storm берет все вышеперечисленное на себя, позволяя разработчикам сосредоточиться на реализации логики обработки сообщений.

Особенности

Итак, основные особенности Storm, вытекающие из требований к подобным системам:

Три основных варианта использования, но ими он не ограничивается:
- Обработка потоков сообщений (stream processing) в реальном времени, с возможностью внесения изменений во внешние базы данных;
- Постоянные вычисления (continuous computation) на основе источников данных с публикацией результатов произвольным клиентам в реальном времени;
- Распределенные удаленные вызовы (distributed RPC) с выполнением комплексных вычислений параллельно во время запроса.
Масштабируемость: Storm может обрабатывать огромное количество сообщений в секунду. Для масштабирование необходимо лишь добавить сервера в кластер и увеличить параллельность в настройках топологии. В одном из первых приложений для Storm обрабатывался 1 миллион сообщений в секунду на кластере из 10 серверов, при этом выполнялось несколько сотен запросов в секунду к внешней базе данных.
Гарантия отсутствия потерь данных: в отличии от других систем обработки сообщений в реальном времени (например S4 от Yahoo!) это свойство изначально является частью архитектуры Storm. Для этого используется механизм подтверждения (acknowledgement) успешной обработки каждого конкретного сообщения.
Стабильность: в то время как Hadoop позволительны простои по несколько часов, так как он априори не является системой реального времени, одной из основных целей Storm является стабильная бесперебойная работа кластера, с максимально безболезненным его управлением.
Защита от сбоев: если что-то пошло не так во время выполнения вычисления, Storm переназначит задачи и попробует снова. В его задачи входит обеспечение бесконечной работы вычислений (или до момента запланированной или ручной остановки).
Независимость от языка программирования: в то время как большая часть системы написана на Clojure и работает в JVM, сами компоненты системы могут быть реализованы на любом языке, что удобно для проектов, использующих в основном другие технологии.

У Вас уже могло сложиться общее представление, о том что собой представляет Twitter Storm и насколько он актуален лично для Вас или Вашего проекта. Если интерес все еще не погас, предлагаю перейти к концепции, предлагаемой Storm для разработки приложений под эту платформу.

Концепция

Для начала пройдемся по основным абстракциям, которые используются в Storm:

Поток (Stream): неограниченный поток сообщений, представленных в виде кортежей (произвольных именованный список значений). При этом все кортежи в одном потоке должны иметь одинаковую схему: элемент на каждой позиции должен иметь один и тот же тип данных и значение.
Струя воды из крана (Spout): источник потоков, который берет их из какой-то внешней системы.
Cтруя состояния (state spout): предоставляет распределенный доступ к некому общему состоянию, которое кэшируется в памяти на исполнителях и синхронно обновляется при внешних изменениях. Таким образом возможно избежать обращений к внешней базе данных при обработке каждого сообщения. В случае с Twitter этим общим состоянием является сам социальный граф.
Молния (Bolt): обрабатывает входящие потоки и создает исходящие потоки, производя какую-либо обработку данных (по сути здесь реализуется основная бизнес-логика). Помимо этого никто не запрещает использовать при обработке какие угодно внешние сервисы вроде СУБД.
Топология (Topology): произвольная связанная сеть из "молний" и "струй". При создании топологии можно указать:
- уровень параллелизма для каждого компонента, что создаст необходимое количество его потоков исполнения в кластере.
- группировку потоков, то есть как именно сообщения будут распределяться между созданными потоками исполнения каждого компонента, есть четыре основных варианта - случайно (shuffle), каждый получит по копии (all), хэш по определенным полям сообщения (fields), один поток получает все сообщения (global).

Таким образом, для создания приложения для обработки данных в реальном времени с использованием Storm, необходимо:

Определить схему(ы) потока(ов) сообщений.
Реализовать источник(и) сообщений, основанные на парсинге каких-то внешних данных (для Backtype это был Twitter firehose, поток всех твитов) или реакции на события (допустим действия пользователей в виде HTTP-запросов).
Реализовать обработчик(и) сообщений, которые преобразуют входящие сообщения и либо создают новые потоки сообщений, либо как-то влияют на внешний мир, например изменяя что-то в базе данных (они используют Cassandra для этого).
Объединить реализованные компоненты в топологию и запустить её на кластере.
При необходимости оптимизировать систему, включив общее состояние в топологию.

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

Архитектура

Проект очень сильно завязан на Zookeeper для координации работы кластера, с чем он очень неплохо справляется. Все остальные компоненты системы системы не содержат в себе состояния, что обеспечивает их быстрый запуск, даже после kill -9.

В остальном все достаточно просто:

Мастер-сервер (Nimbus) отвечает за распространение кода, распределение задач и мониторинг сбоев.
На каждом сервере в кластере запускается процесс-надсмотрщик (Supervisor), который запускает локально потоки исполнения, отвечающие за выполнение назначенных ему компонентов топологий.
Передача сообщений между компонентами топологий осуществляется напрямую, посредством ZeroMQ.
Топологии являются Thrift-структурами, а мастер-сервер - Thrift-сервисом, что позволяет осуществлять регистрацию топологий и другие операции программно из любого языка программирования.

Присутствующий в единственном экземпляре мастер-сервер является единственной точкой отказа лишь на первый взгляд. По факту он используется лишь для внесение изменений в кластер и топологии, так что его непродолжительное отсутствие не повлияет на функционирование запущенных вычислений. А так как состояние кластера хранится в Zookeeper, то запуск мастера на другой машине в случае аппаратного сбоя - вопрос лишь грамотно настроенного мониторинга и максимум одной минуты.

Используемый механизм подтверждений успешной обработки сообщения (acknowledgement) гарантирует, что все сообщения, попавшие в систему, рано или поздно будут обработаны, даже при локальных сбоях оборудования. Хотя более глобальные катаклизмы вроде "потери" стойки все же могут нарушить функционирование системы, про работу в нескольких датацентрах речь также не идет.

Планы на будущее

Использование Mesos для распределения и изоляции вычислительных ресурсов.
Изменение кода "на лету", сейчас для этого нужно остановить старую топологию и запустить новую, что может означать простой в пару минут.
Автоматическое определения необходимого уровня параллельности и адаптация под изменения в интенсивности входящего потока сообщений.
Еще более высокоуровневые абстракции.

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

На самом деле подход, лежащий в основе Storm, не является чем-то кардинально-новым. Помимо упоминавшегося выше S4 можно найти еще несколько альтернатив, пускай и менее близких по идеологии. Подробнее про эту тему можно узнать погуглив complex event processing или real-time stream processing.
Storm выделяет из их числа простота, гибкость, масштабируемость и отказоустойчивость в одном флаконе. Обеспечивает это в первую очередь простая и понятная архитектура, основанная на (уже) проверенном временем и многими проектами распределенном координаторе в виде Zookeeper.
Хоть за проектом и стоит крупный интернет-проект в лице Twitter, он достаточно молод и нужно быть морально готовым к возможным сбоям и неудачным моментам. Плюс не забывайте, что существенная часть написана на Clojure - для, пожалуй, большинства разработчиков изучение исходников проекта будет капитальным "выносом мозга". Мое первое знакомство с Lisp (Clojure - его диалект, работающий в JVM) надолго засело в памяти из-за обилия скобочек за каждым углом :)
В любом случае из доступных opensource реализаций систем для распределенных вычислений в реальном времени Storm на мой взгляд является наиболее перспективным для применения в интернет-проектах.
Если Вашему проекту нужна лишь одна-две топологии и особо большого кластера не планируется, то подобную схему достаточно не сложно реализовать и просто посредством Zookeeper + ZeroMQ или альтернативных технологий. Это избавит проект от возможных заморочек с Clojure и другими "особенностями" Storm, ценой вероятно существенно большей собственной кодовой базы, которую придется самостоятельно тестировать и поддерживать. Какой путь ближе - команда каждого проекта решает для себя сама.
Помимо различных вариаций веб-аналитики заманчивыми применениями подобной системы в Интернете может стать:
- построение индекса для поисковых систем, на сколько я знаю от MapReduce здесь отказался только Google;
- поведенческий таргетинг для рекламы - собираем действия пользователей и делаем на их основе выводы в реальном времени;
- ведение рейтингов чего-либо в реальном времени - в зависимости от специфики проекта можно определять и показывать лучшие, самые просматриваемые или самые комментируемые статьи/фото/видео/музыку/товары/комментарии/что-нибудь-еще;
- предлагаем свои варианты в комментариях.

Удачи в построении приложений для вычислений в реальном времени и до встречи на страницах Insight IT!

Источники информации

Кардинальный переворот в архитектуре поиска Twitter

Иван Блинков — Fri, 15 Apr 2011 23:03:00 +0400

Не успел я опубликовать обновление об архитектуре Twitter, как они снова перекроили половину проекта =) На этот раз к паре Ruby+Scala активно вплелись технологии из мира Java. Наибольшим изменениям подверглась подсистема поиска твитов , о которой сегодня и пойдет речь.

Новая архитектура поиска твитов

Backend

Поиск осуществляется теперь не с помощью MySQL-кластера, а посредством версии Lucene, адаптированной для работы в реальном времени. Разработка этой подсистемы началась весной прошлого года, но полноценно использоваться она начала лишь недавно.

Так как поиск в Twitter является одной из самых часто используемых поисковых систем в мире (более миллиарда поисковых запросов в день), то требования к новой системе поиска были сопоставимо строгими: - Обработка более 12000 запросов в секунду - Индексация потока в 1000 новых твитов в секунду - Задержка между написанием твита и его появлением в индексе должна быть менее 10 секунд

Lucene была взята за основу, так как на сегодняшний день это одно из лучших решений для реализации поиска в мире opensource. Но в текущей ее реализации она не была приспособлена к поиску в реальном времени. Команде Twitter пришлось переписать существенную часть основных структур в памяти, особенно списки записей. При этом внешний API Lucene остался неизменным, что позволило использовать поисковые алгоритмы в практически неизменном виде. Среди основных изменений в Lucene можно выделить:

значительно улучшена производительность сбора мусора;
структуры и алгоритмы более не используют блокировки;
списки записей с поддержкой обхода в обратном направлении;
эффективное раннее прекращение обработки запроса.

Все вышеперечисленные изменения находятся в процессе публикации обратно в Lucene, какие-то прямо в основную ветку, какие-то в отдельную для поиска в реальном времени.

После внедрения этой системы поиск стал потреблять лишь 5% доступных ему ресурсов, что оставило приличный запас для роста даже по меркам невероятно быстро развивающегося Twitter. Новая подсистема индексации способна обрабатывать в 50 раз больше твитов в секунду, чем они получали на момент запуска, что также является очень позитивным показателем. Помимо улучшения производительности, Lucene повысила и качество поиска, а также открыла простор для новых улучшений в этом направлении.

Frontend

Кардинальный переворот в этой части системы можно описать одной фразой: Ruby on Rails заменен на Java-сервер, который они назвали Blender.

За неделю до развертывания Blender, количество поисков по твитам существенно возросло из-за #tsunami в Японии. Среднее время поиска достигало 800-900мс.

После введения Blender в эксплуатацию среднее время отклика 95% запросов упало втрое: до 250мс, при этом уровень использования вычислительных ресурсов на frontend серверах упал вдвое. Тот же поток запросов стало возможным обрабатывать меньшим количеством серверов.

Чтобы понять, откуда взялся такой прирост производительности, необходимо показать в чем были слабые стороны старого поиска на Ruby on Rails. На каждом frontend сервере было запущено фиксированное количество однопоточных Rails процессов, каждый из которых занимался следующим:

обработкой поисковых запросов
синхронным обращением к серверам с индексами
агрегацией и составлением результатов

Они давно понимали, что синхронные запросы ведут к неэффективному использованию вычислительных ресурсов. Со временем накопилось много технически неудачных моментов, что делало все сложнее введение нового функционала и поддержание надежности системы. Blender позволил преодолеть эти функции следующим образом:

Создание полностью асинхронного сервиса агрегации. Ни один поток не ждет пока осуществятся сетевые операции.
Агрегация результатов с различных сервисов: индексы поиска в реальном времени, топа твитов и гео-информации, а также базы данных пользователей и твитов.
Элегантная работа с зависимостями сервисов. Алгоритм обработки запросов автоматически обрабатывает зависимости между используемыми сервисами.

Что же, собственно, представляет собой Blender?

Это HTTP и Thrift сервер, разработанный на основе Netty, масштабируемой неблокирующей клиент-серверной библиотеки на Java, позволяющей легко и быстро разрабатывать клиенты и серверы для различных протоколов. Выбор пал именно на неё, а не на аналоги (например Jetty или Mina) из-за более чистого API, детальной документации и, что более важно, так как некоторые другие сервисы в Twitter уже используют её. Интеграции с Thrift у нее не было, но этот вопрос решился написанием простого кодека, обрабатывающего сообщения на низком уровне.

Обработка поисковых запросов представляет собой цепочку запросов к внутренним сервисами, обработку ответов и генерацию результата. Внутренние сервисы имеют зависимости, которые можно представить в виде ацикличного направленного графа. После топологической сортировки графа Blender получает последовательность выполнения запросов, которые назначаются к выполнению в поток Netty, что в совокупности с обработчиками событий и образует workflow обработки поисковых запросов.

Заключение

Эта диаграмма демонстрирует текущую архитектуру поиска с использованием Blender и Lucene: все входящие поисковые запросы проходят через аппаратный балансировщик нагрузки и попадают в Blender, где они анализируются и перераспределяются между внутренними сервисами с использованием workflow для обработки зависимостей и генерации результатов.

На моей памяти эти нововведения в Twitter - практически единственный случай, когда крупный успешный проект настолько кардинально поменял основную часть стека используемых технологий. Да, они получили существенный выигрыш в производительности не в ущерб масштабируемости, но не поменяли же они большую часть команды разработчиков с Ruby-программистов на Java-программистов... Понятно, что это лишь инструменты, но довольно приличная часть людей, особенно те, кто в возрасте, не способны резко переключиться с привычных технологий на что-то совершенно новое. Хотя, скорее всего, в команде Twitter особо не было разработчиков "за 40", так что для них это не было особой проблемой.

Источник информации

Twitter Search 3x Faster (cпасибо Сергею Гуляеву за предоставленную ссылку)
Twitter's New Search Architecture

Архитектура 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, с удовольствием пообщаюсь со всеми читателями :)

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

Иван Блинков — Sat, 10 May 2008 12:36:00 +0400

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

Поначалу все винили Ruby on Rails во всех проблемах с масштабированием, но Blaine Cook, главный архитектор Twitter, встал на его защиту:

Основной для нас на самом деле является проблема горизонтального масштабирования, с этой точки зрения Ruby on Rails ничем не хуже других языков программирования или framework'ов: переход на "более быстрый" язык программирования дал бы нам 10-20% прирост производительности, в то время архитектурные преобразования, легко реализованные средствами Ruby on Rails, сделали Twitter быстрее на 10000%.

Даже если Ruby on Rails оказался невиновен, как же тогда Twitter научился с его помощью рости до все больших и больших высот?

Источники информации

Этот текст является продолжением серии переводов, автор оригинала - Todd Hoff. На этот раз написать что-либо своими силами у меня не сложилось, все мысли ушли на другой пост, который я скоро опубликую, а перевод этот получился несколько менее строгим, чем обычно, но я думаю ничего страшного.

Scaling Twitter Video от Blaine Cook.
Scaling Twitter Slides
Good News блог пост от Rick Denatale
Scaling Twitter блог пост от Patrick Joyce
Twitter API Traffic is 10x Twitter’s Site
A Small Talk on Getting Big. Scaling a Rails App & all that Jazz

Платформа

Статистика

Более 350000 пользователей. Точная цифра, как обычно, держится в секрете.
Около 600 запросов в секунду.
В среднем система поддерживает 200-300 соединений в секунду. Максимум обычно достигается при значении 800.
MySQL обрабатывает примерно 2400 запросов в секунду.
180 экземпляров приложений на Rails, использующих Mongrel как веб-сервер.
1 MySQL сервер (одна большая машина с 8 ядрами) и 1 slave, используемый лишь для статистики и отчетов.
30+ процессов для выполнения произвольных работ.
8 Sun X4100
Обработка запроса обычно занимает у Rails 200 миллисекунд.
В среднем ответ на запрос к базе данных занимает 50-100 миллисекунд.
Более 16 GB выделено под memcached.

Архитектура

Проект столкнулся с массой проблем, связанных с масштабируемостью. Маленькая птичка частенько давала сбои.
Изначально не было реализовано никаких форм мониторинга, графиков или статистики, это очень затрудняло обнаружение м решение возникающих проблем. Впоследствии были внедрены Munin и Nagios. Разработчики столкнулись с некоторыми трудностями при использовании этих продуктов в Solaris. Помимо этого был использован сервис Google Analytics, но от него обычно мало толку, особенно когда страницы даже не загружаются.
Активное использование кэширования средствами memcached:
- Например, если подсчет количества чего-либо выполняется медленно, намного эффективнее один раз запомнить результат в memcached, чем каждый раз считать его заново.
- Получение информации о статусе своих друзей - непростая задача. Вместо использования запросов информация о статусе друзей обновляется в кэше. База данных совсем не используется. Такой подход позволяет получить предсказуемое время отклика (ограниченное сверху примерно 20 миллисекундами).
- Объекты ActiveRecord настолько велики, что кэширование их нецелесообразно. Критичные атрибуты хранятся в хэше, а остальная их часть подвергается "ленивой загрузке" в момент запроса на доступ.
- 90% запросов являются запросами к API. Таким образом кэширование страниц или их фрагментов становится бессмысленным, зато никто не мешает им кэшировать сами API запросы.
Внутренняя организация работы с сообщениями:
- Сообщения очень активно используются: производители генерируют сообщения, они образуются в очереди, а затем распространяются по потребителем.
- Основная функция Twitter заключается в реализации своеобразного моста между различными форматами электронных сообщений (SMS, электронная почта, сервисы мгновенного обмена сообщениями и так далее).
- Чтобы инвалидировать в кэше информацию можно просто отправить внутреннее сообщение, зачем выполнять все действия синхронно?
- Изначально этот механизм основывался на DRb (distributed Ruby) - библиотека, позволяющая отправлять и принимать сообщения сообщения между удаленными Ruby-объектами по TCP/IP. Но она была несколько странноватой, да и являлось потенциально слабым местом с точки зрения стабильности.
- Со временем сервис перевели на Rinda, представляющую собой набор общих для всей системы очередей. Но и у нее были недостатки: все очереди были постоянными, а данные терялись при сбоях.
- Следующей попыткой был Erlang. Но однажды возникла проблема: каким образом сломавшийся сервер может продолжать работать, но при этом в очереди откуда-то возникли целых 20000 ожидающих пользователей? Разработчики не знали. На лицо явный недостаток документации...
- В конце концов решение было разработано своими силами: Twitter выпустил Starling, распределенный легковесный сервер очередей, написанный на Ruby и поддерживающий протокол memcache. Сейчас серверная часть Twitter управляется именно им.
- Распределенные очереди позволяют переживать сбои путем записи их на диск в критических ситуациях. Другие крупные интернет-проекты также часто пользуются таким подходом.
Работа с SMS осуществляется с помощью сторонних сервисов и предоставляемых ими шлюзов. Достаточно дорогое удовольствие.
Развертывание:
- Просто запускаются дополнительные сервера с mongrel, более элегантного решения пока нет.
- Все внутренние ошибки выдаются пользователям, если обслуживающий их mongrel сервер на данный момент заменяется.
- Все сервера останавливаются одновременно. Отключение их по одному по определенным причинам не используется.
Неправильное использование сервиса:
- Много времени сервис был не доступен, так как люди проходились специальными программами по сайту с целью добавить всех кто попадался под руку в друзья. 9000 друзей за 24 часа. Это просто-напросто останавливало работу сайта.
- Были разработаны средства для своевременного обнаружения таких ситуаций.
- Будте беспощадными, таких пользователей нужно просто удалять.
Сегментирование:
- Пока оно только в планах, сейчас оно не используется.
- В будущем оно будет основываться на времени, а не на пользователях, так как запросы обычно очень локальны по времени.
- Сегментирование будет не так просто реализовать благодаря автоматическому запоминанию результатов выполнения функций для последующего повторного их использования. Никто не даст гарантии, что операции "только для чтения" на самом деле будут таковыми являться. Запись в slave, работающий в режиме read-only, - не самая лучшая идея.
API Twitter генерирует в 10 раз больше трафика, чем сам сайт.
- Их API - самая важная вещь из всех, что они разработали.
- Простота сервиса позволила разработчикам строить свои приложения поверх инфраструктуры Twitter, привнося все новые и новые идеи. Например, Twitterrific - красивый способ использовать Twitter в небольшой команде.
Мониторинг используется для остановки слишком больших процессов.

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

Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) - они сыграют свою роль и спасут работоспособность системы.
Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
Оптимизируйте базу данных:
- Индексируйте все таблицы, Rails не будет делать это за Вас.
- Используйте "explain" для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.
- Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.
- Избегайте комплексного объединения данных из нескольких таблиц.
- Избегайте сканирования больших наборов данных.
Кэшируйте все, что только можно.
Тестируйте все максимально тщательно:
- Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.
- Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.
Длительно функционирующие процессы стоит оформить в виде daemon'ов.
Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
Не делайте глупостей!
- Масштаб проект несколько меняет понятие "глупость".
- Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 - этот механизм прекрасно работал.
Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!