Не успел я опубликовать обновление об архитектуре 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