Pull to refresh

Миграция с Ruby

Social networks and communities
imageУверен, что на Хабре обитает огромное число юзеров, облизывающихся при чтении описаний технологий и архитектур, используемых в молодых, динамичных и, что наиболее важно, быстрорастущих в своей пользовательской базе, компаний. К сожалению, относительно небольшое количество наших соотечественников работает в таких компаниях по всему миру, а те, кто все-таки трудится во внутренней кухне, связаны различными условиями трудовых договоров или банальным NDA, запрещающим сливать публике самые интересные подробности. Тем не менее, я лично знаю большое количество специалистов, особенно заинтересованных в высоких нагрузках и не знающих, где получить эту информацию из первых рук.

Эту проблему можно решить единственным способом — предоставить слово кому-то из менеджеров отдела разработки или любому другому человеку, занимающему адекватно высокий пост и разбирающемуся в разработке, а после — тянуть, тянуть из него все подробности. Примерно так поступили в Information Queue, опросив одного из инженеров Twitter'а — Эвана Уивера (Evan Weaver) о том, почему компания так долго развивавшаяся на «рельсах», решила переключиться на использование других технологий и какие это имело последствия.

В этом материале я буду всецело ссылаться на слова Эвана, объясняющего суть миграции и выгод, получаемых от использования JVM, в первую очередь — производительности и, все той же, масштабируемости. Но как мы узнаем чуть позже, решение было так же продиктовано желанием изолировать отдельные сервисы, а так же слегка изменить общую архитектуру продукта.

Итак, история начинается в прошлом году, когда Twitter анонсировал изменения в архитектуре бэкэнда (message queue), а так же заявил о намерении переписать Twitter Storage на Scala, а весной началась работа по переписыванию всего поискового движка. Как часть этих изменений, БД MySQL (лежавшая в основе поиска) была заменена Lucene. И, наконец, совсем недавно команда разработчиков заявила о замене Ruby on Rails в области поиска — на его место встал Java-сервер, который они сами называют Blender. Результатом этой замены стало трехкратное снижение задержки при выполнении поискового запроса.

Overview


Один из первых выводов, который можно сделать глядя на общую архитектуру Twitter'а заключается в том, что многие решения его разработчиков кажутся идеально прагматичными. Например, в бэкэнде продукта используется как MySQL, так и распределенная БД Cassandra. Немногие знают о собственной разработке инженеров Twitter'а: Gizzard — фреймворке, используемом для создания распределённых хранилищ на основе БД MySQL. По словам Уивера: «он в основном используется для высоко-структурированных данных (SLA-data) так как не является относительно гибким».

Все данные реального времени получаются либо из Gizzard/MySQL, либо из Cassandra. Так же в архитектуре активно используется стек для распределенных вычислений Hadoop для оффлайн калькуляций, в онлайне же используется система, построенная с помощью key-value базы данных Redis и вышеупомянутого Gizzard.

Взаимосвязь между уровнями фронтэндом и бэкэндом реализована за счет разработки компании Facebook — Thrift (язык описания интерфейсов, используется в качестве RPC) и JSON REST API, используемого во всех «официальных» клиентах от Twitter и новом сайте продукта.

Languages


Похожий, прагматичный, подход мы видим и в выборе языков программирования, используемых в компании. Языки первого уровня: JavaScript, Ruby, Scala и Java. Так же работа отчасти поддерживается и на C, однако новые сервисы на нем не пишутся. В общем и целом Эван говорит о переходе на Scala разработчиков со знанием Ruby и использовании Java теми, кто до этого крутился в области C/C++.

Что касается команды, занимающейся поисковым движком — здесь инструменты диктуют выбор языков. Так как Lucene построен на Java, то и программистам приходится оперировать в первую очередь этим языком.

Для того чтобы позволять разработчикам самим выбирать идеальный для них язык работы, Twitter вложил много усилий и средств в написание внутренних фреймворков, которые инкапсулируют общие старания всех команд. Finagle (написана на Scala), к примеру — это библиотека для создания асинхронных RPC-серверов и клиентов на Java, Scala или любом другом языке на платформе JVM.

В то время, как весь бэкэнд постепенно переходит в сторону JVM, фронтэнд (клиентский) код все больше склоняется в сторону использования браузерного JavaScript, уменьшая долю языка Ruby.

Search: From Ruby to Java



image

Переход с Ruby на построенный на Java фреймворк Blender был осуществлен в два шага. Первым была замена существующего MySQL back-end'а на реверсированный индекс в реальном времени, основанный на Lucene и носящий имя Earlybird. Его введение в эксплуатацию удвоило эффективность используемой памяти, а так же гибкость в добавлении различных поисковых фильтров, помогающих поддерживаться быстрорастущий спрос на поиск по продукту. Более подробное описание механизма работы этой части системы описывали инженеры Twitter'а.

Для того чтобы решить проблему низкой производительности фронтэнда, команда разработчиков построила сервер Java Blender. Blender — это уже упомянутый сервис Thrift и HTTP API, построенный на Netty и масштабируемой клиент-серверной библиотеке NEW I/O (NIO), написанной на Java и позволяющей разрабатывать различные протоколы сервера. Netty дает возможность компании создавать полностью асинхронные сервисы аггрегации, которые могут собирать результаты из нескольких сервисов back-end'а (такие как индексы в реальном времени, топ-твиты и гео-данные).

Это позволило избежать высоких очередей в I/O, оптимизируя работу CPU и быстрее обрабатывая текущие запросы. Вдобавок, многие запросы в бэкэнде могут быть обработаны параллельно, что значительно снижает задержки.

image

Поисковой двигатель Twitter'а является одним из самых загруженных в мире, обрабатывая около миллиарда запросов в сутки. Результат перехода на Blender был просто фантастическим: 95% запросов стали обрабатываться в три раза быстрее, задержка снизилась с 800ms до 250ms, а загрузка процессоров на обоих концах (фронтэнд — бэкэнд) продукта снизилась наполовину. Сегодняшние мощности компании позволяют продукту обрабатывать в 10 раз больше запросов на машину, чем это было до применения этих технологий в архитектуре. Тем самым компания снижает стоимость услуг, необходимых для поддержания всей архитектуры в высоко-производительном состоянии.

И хотя производительность и масштабируемость были немаловажными проблемами, из-за которых пришлось повышать использование JVM — Эван говорит о том, что инкапсуляция все же является ключевым моментом такого перехода, т.к. текущая архитектура Twitter'а, в общем-то, справляется неплохо. Переход на JVM во многом был продиктован тем, что производительность разработчиков на нем выше и как следствие — выше производительность всего продукта.

Комбинация фреймворка Ruby on Rails вкупе с БД MySQL была очень популярна для западных стартапов на протяжении последних лет. Плюсы понятны: разработчики могли быстро испытывать новые и простые идеи для того чтобы проверить их отдачу в условиях работы на реальном рынке, где предложение диктуется спросом пользователей. Впрочем, минусы такой связки тоже достаточно очевидны — проблемы масштабируемости и производительности, а так же некоторой незрелости библиотек и инструментов, что касается в первую очередь RoR.

Спасибо за помощь в точных формулировках хабраюзеру ivaxer

InfoQ via RRW
Tags:
Hubs:
Total votes 72: ↑65 and ↓7 +58
Views 4.5K
Comments Comments 82