Insight IT

Обзор Riak

Иван Блинков — Tue, 13 Nov 2012 02:09:00 +0400

Riak - распределенная opensource база данных, разработанная на Erlang и спроектированная в расчете на:

Высокую доступность и устойчивость к сбоям;
Масштабируемость и простоту обслуживания;
Универсальность.

У проекта отличная официальная документация на английском, далее же в этой статье я расскажу об основных её особенностях чуть подробнее, а также хитростях и подводных камнях, выявленных в процессе применения на практике (с перспективы веб-разработки).

Высокая доступность и устойчивость к сбоям

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

Масштабируемость и простота обслуживания

Добавление нового сервера тривиально путем копирования конфига и одной команды.
Перераспределение данных и все остальное прозрачно происходит за сценой.
Минимальный рекомендуемый размер Riak кластера - 5 серверов, меньшее количество не дает раскрыть весь потенциал.
Одинаково легко обслуживать как маленький, так и большой кластер.
Есть коммерческая Enterprise версия с поддержкой от Basho, компании-разработчика Riak (изначально выходцы из Akamai), равноправной зашифрованной репликацией между датацентрами и поддержкой SNMP.
Есть встроенный веб-интерфейс для мониторинга и управления кластером, у меня правда так и не дошли руки его освоить:

Универсальность

Схема отсутствует, ключи и данные - произвольные бинарные строки. Ключи располагаются в пространствах имен (bucket).
Сериализация - на усмотрение разработчика, популярные варианты - Erlang'овский BERT, JSON для других платформ, можно использовать просто как файловую систему.
Модульная система хранилищ данных, альтернатив много, основная - Google LevelDB; еще интересный вариант с хранением полностью в оперативной памяти - получается продвинутый распределенный кэш с репликацией, поиском и пр.
Гибко настраиваемое количество узлов кластера, которые должны подтвердить успешность операции, чтобы она считалась успешной: можно указывать для всего кластера, пространства имен и даже конкретного запроса. Riak в любом случае остается eventually consistent базой данных (AP из CAP теоремы), но с возможностью управлять балансом производительности операций и надежностью выполнения запросов.
Три интерфейса доступа (API):
- Google ProtocolBuffers - для основного использования в боевых условиях.
- HTTP REST - для использования в языках, где нет готового клиента на ProtocolBuffers и для того, чтобы по-быстрому что-то посмотреть из консоли через curl. Хотя по факту клиенты для большинства языков программирования есть и проще делать запросы через интерпретатор.
- Еще есть прямой интерфейс Erlang-сообщений, но даже из самого Erlang им пользоваться не рекомендуют, не говоря уже о реализациях Erlang node (BERT) на других платформах.
Вместе с данными хранятся метаданные для разных целей, которые используются в соответствующих типах запросов:
- Векторные часы для разрешения конфликтов версий данных (обязательно, есть автоматическое разрешение);
- Индекс для полнотекстного поиска (концептуально позаимствован у Lucene/Solr, опционально);
- Индекс для простых выборок (по бинарным и числовым полям, опционально);
- Связанные ключи (отдаленный аналог внешних ключей, опционально).
Встроенная поддержка MapReduce, фазы можно реализовывать на Erlang или JavaScript; для обоих языков есть библиотека с наиболее популярными случаями, которые можно использовать для образца.
Есть поддержка выполнения операций до/после операций записи/чтения (hooks), чаще всего используются для построения полнотекстного индекса, но можно реализовать и свои, специфичные для приложения.

Недокументированные возможности

Пока я их нашел всего две:

Счетчики: как такового API в для увеличения/уменьшения числовых значений (increment/decrement) в Riak нет, так как он не лезет внутрь хранящихся данных. Зато есть векторные часы, которые растут с каждой операцией записи по ключу. Чтобы реализовать увеличение (increment) необходимо записать в Riak пустую бинарную строку с опцией return_body, и у вернувшегося значения сложить все поля в векторных часах. Пример на Erlang. Если нужно еще и уменьшение (decrement) этого можно добиться с помощью пары счетчиков "плюс и минус" и вычитать второе значение из первого. Для авто инкремента основных ключей не самый лучший вариант, но для не особо критичных случаев вполне себе работает.
Выборка по списку ключей (multiget): такого API тоже нет, но здесь на выручку приходит MapReduce. Это, пожалуй, наиболее популярное его применение. На вход подаем имеющийся список ключей и используем фазы из готовой библиотеки: reduce_set_union и map_identity. Данные возвращаются неотсортированные и требуют небольшой обертки на выходе, но все равно это намного быстрее, чем последовательно проходить по списку ключей и делать для каждого обычный get. Пример на Erlang.

Буду рад, если Вы поможете мне дополнить этот список, оставив известные Вам подобные трюки в комментариях.

Подводные камни

Если в Вашем приложении необходима функциональность постраничного просмотра отсортированных данных (pagination), то будьте готовы реализовать её на клиенте. То есть Riak быстро сделал нужную выборку всех "страниц" и уже на клиенте её придется отсортировать и выкинуть лишнее. Вообще в большинстве случаев результаты запросов к Riak приходят в произвольном порядке из-за его распределенной природы.
В продолжение к предыдущему: в REST Solr интерфейсе есть аргументы (в ProtoBuf это тоже добавили в одной из последних версий), которые, казалось бы, достаточны для реализации постраничного просмотра: sort, start, rows - что еще нужно? На практике оно работает не так, как было бы логично. Сортировка по значению (заданная в sort) применяется ПОСЛЕ того, как была отсчитана страница по start и rows. Они отмеряются по ключам или рейтингу значения в полнотекстном поиске и никак иначе. С тем же успехом эти 5-10 значений можно очень быстро отсортировать и на клиенте. Зачем-то это может быть и нужно, но в моем случае оказалось совершенно бесполезно.
У Riak есть 4 основных типа запросов: простой get/set, полнотекстовый поиск, вторичные ключи (secondary indices), МapReduce и проход по связанным ключам (link walking).
- Если Ваши данные являются сериализованным JSON, BERT или XML, то в большинстве случаев Вам нужны лишь первые два из них, исключение - упомянутая выше выборка по списку ключей через MapReduce.
- Основной сценарий использования вторичных индексов - метаданные к произвольным неструктурированным бинарным данным, например в случае с аналогом файловой системы. Либо совсем примитивные случаи, когда правда нужно сделать простую выборку по одному целочисленному полю, что бывает редко.
- Если данные сериализованы, то связанные ключи проще хранить внутри данных, а не средствами СУБД. Разницы в производительности нет, в итоге делается тот же MapReduce с теми же фазами.
Хоть Riak "из коробки" и правда надежнее многих других СУБД и 1-2 упавших/отключенных сервера в кластере внешне практически не заметны, есть одно но. Если один узел упал - соединения всех подключенных к нему клиентов теряются. Два основных пути преодоления этого момента:
- Если кластер клиентов и кластер Riak расположены на разных серверах, то между ними можно поставить отказоустойчивый TCP балансировщик нагрузки, в частности HAProxy или IPVS здесь наиболее органично вписываются.
- Если на одних и тех же, то есть вариант поставить балансировщик нагрузки перед клиентами (для веба возможно и в HTTP/HTTPS режиме), а каждый клиент подключается к своему локальному серверу Riak и если один, другой или оба сразу упали, то отрубать весь физический сервер целиком.

Выводы

Riak отлично подходит для многих вариантов использования, как в Интернет среде, так и в смежных вроде телекома. Обладает отличным набором положительных "черт характера", о которых шла речь в начале статьи. Прекрасно справляется с большим потоком как операций записи, так и операций чтения.

Как уже упоминалось, практически единственный сценарий, где Riak совсем не справляется, это выборки по большим объемам данных с сортировкой и постраничным выводом. Но даже в этом случае никто не мешает использовать отдельный сервис, который будет индексировать нужным образом данные и подготавливать список идентификаторов для последующей multiget выборки из Riak. К слову, проекты по этой части уже появляются, например Yokozuna - интеграция полноценного Solr с Riak (Riak Search - лишь частичный порт Solr+Lucene на Erlang).

Moscow Erlang Factory Lite 2012

Иван Блинков — Sat, 23 Jun 2012 02:40:00 +0400

Давненько я не выбирался на IT-мероприятия, так что продолжу традицию делиться впечатлениями. Как следует из заголовка она была исключительно про Erlang, причем в самых разных его проявлениях. Недавно я написал пару статей про него, можно найти по соответствующему тегу. Конференция была всего на пол дня, так что пост получится явно небольшой - много времени не займет ;)

Организация

Мероприятие проводили совместно Erlang Solutions (международная организация, которая регулярно проводит подобные Erlang-мероприятия, сертификации и т.п.) и Яндекс. Проходило все в двух шагах от офиса Яндекса, плюс они же занимались собственно всеми организационными вопросами. Единственный представитель Erlang Solutions видимо не знал что в Москве бывают пробки и сильно опоздал, к слову у меня на телефоне его фотка нашлась, заодно можно оценить масштабы мероприятия (весь единственный зал):

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

Еще из косяков к началу конференции никто не удосужился проверить звук и удаленный переключатель слайдов.

А в остальном все ок, простенько и со вкусом. Едем дальше.

Доклады

Яндекс

В Яндексе всего три Erlang-программиста, кажется все присутствовали
Используют свой форк ejabberd примерно пятилетней давности для их мессенджера и пуш-уведомлений:
- С момента своего создания изменения из основной ветки развития не мерджились и обратно выкладываться в opensource не собираются из-за "сильной интеграции с другими сервисами Яндекса"
- Для хранения постоянных данных используют MongoDB, на вопрос почему именно докладчик так честно ответил "не знаю"
- Основная часть доклада ушла на рассказ об оптимизациях внутри самого ejabberd, реализованных в их форке, в частности:
  - Добавили проверку на то, жив ли процесс перед тем как отправлять ему сообщение, изначально ejabberd в этом плане был более оптимистичен и их это по непонятным причинам не устроило.
  - Уменьшили объем используемой оперативной памяти за счет "ленивой подгрузки" части данных, которые редко используются. Из зала, кстати, кто-то добавил что у аналогичного форка от Erlang Solutions повсеместное использование бинарных строк вместо обычных дало очень ощутимую экономию оперативной памяти.
  - И, кажется, объединили принимающий и отправляющий сообщения процессы в один.
- На вопрос о цифрах выдали только порядки: несколько десятков серверов обслуживают несколько сотен тысяч пользователей онлайн.

Fedora Project

Обсуждался вопрос сильного "отставания" доступных по-умолчанию в Linux-дистрибутивах версий Erlang, да и не только Erlang, от последней стабильной. Я думаю очень актуальный вопрос для тех, кто занимается продажей коммерческого софта для Linux, или для тех, кто занимается сборкой и поддержкой пакетов для opensource проектов.

Erlang сделан так, что подход "все свое ношу с собой", существенно проще и удобнее, чем управление зависимостями. Хотя докладчик приводил пример, что CouchDB как раз использует альтернативный подход требования точных версий зависимостей и у них в Fedora были большие заморочки с тем, что они обновили JavaScript-движок на одну версию выше, чем от которого зависела последняя версия CouchDB. Я так и не уловил как в итоге эту ситуацию решили, наверное пришлось оставить в репозитории две версии зависимости или дождаться и обновления CouchDB.

Mochi Media

Вместо рассказа о mochiweb речь шла о различных вариантах как можно реализовать случайный выбор элемента из списка и их слабых и сильных сторонах. Причем для примера использовался не реальный проект, где они подобным занимаются (баннерная сеть), а IRC-бот написанный для развлечения. Да и к Erlang практически никакого отношения, единственной что узнал полезного: стандартный модуль random написан по не самому удачному алгоритму, созданному в начале 80-х, и если это сколько-либо критично для приложения - лучше вместо него использовать crypto или сторонние библиотеки.

Макс Лапшин

Докладчик является, пожалуй, самым активным участником российского Erlang-сообщества, известен в узких кругах как автор Erlyvideo, opensource решения для потокового вещания видео. Рассказывал про какой-то другой проект, в частности о парсере протокола FIX, использующегося на фондовых биржах и отличающегося огромной спецификацией с более чем сотней типов сообщений. Основная идея доклада: если нужно написать много однотипного кода, его лучше сгенерировать, чем копипастить.

К счастью, авторы этого протокола заботятся о разработчиках и публикуют спецификацию в виде XML-файла, который Макс предлагает парсить и генерировать на его основе необходимые .erl файлы, не дерево синтаксиса, а прямо текстовые .erl файлы. В конкретно этом случае ему нужно было из proplist-ов создавать record'ы, а сам парсинг сообщений он решил написать на C. Хотя мне кажется эту конвертацию тоже можно было бы убрать в C.

Алекс Гунин

Это был единственный доклад на 80% на русском, так как попытка начать его на английском закончилась полным провалом. Хотя заголовок у доклада был самый, пожалуй, интересный - "как сделать Erlang по-настоящему распределенным и отказоустойчивым". Основная идея была использовать часть распределенной СУБД Riak, отвечающую за распределение и поиск данных в кластере (Riak Core), для маршрутизации простых Erlang сообщений и по аналогии с несколькими репликами данных запускать несколько копий одинаковых процессов. Для реализации этой затеи они написали совместимые со стандартными модули gen_server2, gen_fsm2 и т.п. (что, кстати, плохая практика - из-за таких названий можно легко столкнуться с конфликтами в пространстве имен модулей, например в RabbitMQ и каком-то еще популярном проекте тоже есть gen_server2, как-то сталкивался)

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

Лев Валкин

Это был последний доклад, где я присутствовал, в оставшейся секции из трех докладов мне совсем ничего не приглянулось, но зато этот мне больше всего понравился. Думаю в первую очередь так как Лев косвенно пропагандировал очень близкую мне тему использования Erlang для создания интерактивных веб-сайтов. Большинство докладов были все же про другие предметные области. Раньше про его компанию Echo ничего не слышал, но список клиентов на главной у них солидный, надо будет почитать на досуге.

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

Изначально Лев планировал доклад на тему Erlang vs node.js, но её забраковали организаторы, видимо за холиварность. В итоге она все же местами затрагивалась, да и вопросы после доклада в основном были по ней.

Основные моменты:

Повторное использование кода между серверным JavaScript и клиентским - в большинстве случаев миф.
Легко найти серверного node.js-разработчика, так как все и так уже знают JavaScript - тоже миф, клиентская разработка концептуально сильно отличается от серверной, намного больше node.js-разработчиков приходит с других серверных платформ, а не с клиентского JavaScript.
node.js хоть и сильно проигрывает Erlang по ряду объективных показателей применительно к веб разработке, благодаря своей популярности именно среде молодых веб-разработчиков (во многом благодаря вышеизложенным мифам) сильно угрожает популяризации Erlang в этой же самой среде.

Свое мнение про JavaScript в целом и node.js в частности оставлю за кадром, недавно в одном из постов высказывался уже на эту тему.

Основы Erlang: синтаксис и пунктуация

Иван Блинков — Fri, 22 Jun 2012 01:27:00 +0400

Мои теоретичесие рассуждения о месте Erlang в ~~современном мире~~ Интернете Вы можете почитать в отдельной статье. Если сомневаетесь интересно Вам это все или нет - то прочтите сначала её. Сегодня я постараюсь вернуться с небес на землю и пройтись по азам этого пугающего многих языка программирования. Коротко и по делу.

Установка ничем особым не выделяется, дистрибутив рекомендую брать отсюда, если до сих пор пользуетесь отсутствующей в списке ОС - лучше сначала исправить этот факт.

После установки в $PATH окажутся исполняемые файлы:

erl - одновременно интерактивная консоль и запуск приложений;
erlc - компилятор в байт-код для виртуальной машины BEAM или нативный код посредством HiPE, напрямую использовать не придется практически.

Со всем что будет обсуждаться в этой статье можно эксперементировать просто в интерактивной консоли, которая запускается просто командой erl без аргументов.

Пунктуация

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

Все функции заканчиваются точкой
После каждого выражения в функции - запятая;
Все ветви кода (case, if, ...), кроме последней, заканчиваются точкой с запятой
После заголовка функции и условий ветвления пишется стрелка ->

Маленькая демонстрация:

foo(X, Y) ->
  Z = X * X,
  if
    Y > 0 ->
      Z + Y;
    true ->
      Z - Y
  end.

К слову, функции возвращают результат выполнения последнего выражения, в данном случае оно представляет собой весь блок if, а end обозначает его окончание (не функции).

Синтаксис

Foo - все что начинается с английской заглавной буквы - переменная, специально объявлять ничего не нужно
_ - сам знак нижнего подчеркивания и все что с него начинается - особый случай переменной, значение которой не значимо для программы и при первой возможности "выкидывается"
Цифры в основном как обычно, есть научная нотация в духе 1.23e4 (1.23 умножить на 10 в степени 4) и системы исчисления с другим основанием, скажем двоичная - 2#101010
foo - с строчной буквы начинаются атомы, по сути константы, используются повсеместно:
- названия функций и модулей
- true и false - булевые значения
- ok - типичный результат успешный результат выполнения
?FOO - хоть официально и называются константами, но по сути - макросы, перед компиляцией заменяются на заранее определенный кусок кода
{foo, bar} - кортеж, набор данных фиксированной длины
[foo, bar] - простой однонаправленный список произвольной длины
"foo" - текстовая строка, представленная в виде однонаправленного списка (что не эффективно с точки зрения потребления памяти, до 4 байт на символ)
<<"foo">> - бинарная строка, может содержать что угодно, в.т.ч. и текст; все что не цифры по возможности лучше хранить в этом типе данных.

Сопоставление (pattern matching)

Очень мощная концепция сопоставления используется в Erlang на каждом углу. В базовом варианте работает примерно так:

{ok, Result} = foo().

Если в функции foo все прошло нормально, то она возвращает, например {ok, 123}, и переменной Result окажется лишь значение 123.

Если же возникла какая-то проблема, то она вернет что-то другое, скажем {error, timeout}, приложение столкнется с несоответствием левой и правой части (атомы ok и error разные) и прекращает свое выполнение (если бы было чего выполнять).

Базовый принцип, надеюсь, понятен. Подобным образом выбирается какую из реализаций функции использовать, в какую ветвь case идти и т.п. В общем есть много других более сложных применений, но о них в другой раз.

Списки

Со списками есть три особые операции:

[Head | Tail ] = [1, 2, 3, 4] - вытащить элемент с головы списка, работает по принципу сопоставления, в Head окажется 1, а в Tail - [2, 3, 4]
[1, 2] ++ [3, 4] - конкатенация, результатом будет [1, 2, 3, 4]
[N * N || N <- [1, 2, 3], N > 1] - выглядит замороченно, по сути это обычный отображение (map) с фильтрацией (filter) - то есть выражение перед || применяется к каждому элементу списка, значение которых попадает в переменную N, а после запятой - условие, накладываемое на N; таким образом результат будет [4, 9]

Бинарные строки

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

Binary = <<Integer:64>> - преобразовать целое число Integer в бинарную строку Binary длиной 64 бита (для примера, может быть любой
<<Integer1:32, Integer2:32>> = Binary - распокавать обратно бинарную строку в целые числа, но уже два по 32 бита; чем-то похоже на операцию [H | T] у списков, но намного более гибко
Binary3 = <<Binary1/binary, Binary2/binary>> - конкатенация бинарных строк, результат окажется в Binary3
<< <<(N * N)/integer>> || <<N>> <= <<1, 2, 3>>, N > 1 >> - аналог последнего примера для списков, только для бинарных данных; результат аналогичен - <<4, 9>>; к слову официально это называется binary comprehensions, а для списков - list comprehensions

Заключение

Очень многое пришлось опустить, иначе самое главное затерялось бы, да и объем статьи сильно вырос. Подробности всегда можно найти на официальном сайте, в man'ах, да и просто погуглив.

Удачного освоения Erlang!

Серверная часть интерактивного сайта и потоки сообщений

Иван Блинков — Mon, 04 Jun 2012 05:38:00 +0400

Вернемся к теме интерактивных сайтов с обратной стороны, серверной. В ней есть огромный простор для творчества, так как в отличии от клиентской части отсутствуют ограничения, накладываемыми браузерами. С "простором" же приходит и неоднозначность/неопределенность, вариантов как реализовать одно и то же множество, так что возможно приводимые мной примеры Вам окажутся не по душе - и это нормально, правильный путь не единственный, их много :)

Приступим!

Внутренние сервисы

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

Я не буду здесь особо вдаваться в возможные детали реализации самой бизнес-логики - она практически всегда уникальна, скорее заслуживает внимания её "обертка" - сам процесс, принимающий и создающий внутренние запросы.

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

На практике есть масса способов воплотить эту модель в жизнь, перечислю с пояснениями наиболее заслуживающие внимания на мой взгляд:

Функциональные языки программирования, в Erlang и Scala модель акторов является практически "сердцем" всего языка и связанной платформы; у обоих есть библиотеки для реализации надежных, высокопроизводительных и масштабируемых акторов (OTP и Akka, соответственно). Если не боитесь кардинально отличающейся от нынче модного ООП парадигмы разработки, этот вариант наиболее жизнеспособный, рекомендую.
Асинхронный HTTP-сервер, в частности Tornado и node.js - они основаны на epoll и помимо эффективной обработки HTTP-запросов умеют и эффективно их отправлять посредством идущего в комплекте асинхронного же клиента. При таком подходе по сути получается несколько "уровней" HTTP-серверов, первый из которых публично доступен для общения с внешним миром и в ответ на каждый входящий запрос обращается сразу к нескольким внутренним HTTP-сервисам (вероятно параллельно) и на их основе составляет ответ пользователю. Этот подход одно время активно пропагандировали на конференциях ребята из одного крупного отечественного сайта с вакансиями. Особенным бонусом этого варианта является возможность использовать в роли внутреннего сервиса какую-то старую, доставшуюся по наследству (legacy), систему, которая с одной стороны по-прежнему нужна, а с другой - человек, который в ней разбирался уже давно уволился.
С++ и Thrift - хоть одного из участников этой пары можно легко заменить на альтернативу, вместе они смотрятся наиболее органично: потенциально высокопроизводительная реализация бизнес-логики на С++ плюс проверенная в деле многими крупными и очень крупными проектами обертка для создания серверов и клиентов, легко общающихся из разных языков программирования (речь о Thrift, если не очевидно). Если в команде проекта есть гуру C++ - этот вариант Ваш, в противном случае не рекомендую, т.к. очень легко накосячить.

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

База данных и кэширование

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

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

В соответствии с этим стоит выбирать хранилище данных и политику кэширования:

Стабильная информация, которая редко обновляется и в тысячи раз чаще читается, прекрасно поддается кэшированию и возможно даже прекрасно будет себя чувствовать в реляционной СУБД.
Свежую информацию вероятно вообще важнее доставить в кратчайшие сроки получателю, а сохранять в персистентном виде можно вообще постфактум для архива, на маловероятный случай когда она повторно понадобится. Про кэширование лучше вообще забыть. Для этого самого "архива" часто используют нереляционные распределенные базы данных вроде HBase, Cassandra или Riak. А про оперативную доставку получателю поговорим в следующем разделе.
Хранилища данных в памяти вроде memcached или Redis с отключенной персистентностью можно использовать независимо для временного хранения каких-то побочных данных (восстановимых производных данных или просто чего-то не особо важного, вроде счетчиков пользователей онлайн).

Потоки сообщений

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

Часть системы, отвечающую за маршрутизацию таких сообщений, обычно назвают брокером сообщений (message broker). Для доставки сообщений в браузер чаще всего используют интерфейс сериализованных данных, подробно обсуждавшийся в одной из предыдущих статей серии. Когда пользователь устанавливает соединение с этим интерфейсом, он, в свою очередь, напрямую или через внутренний сервис регистрируется в брокере сообщений для оперативного получения сообщений, предназначенных соответствующему пользователю.

Предлагаю рассмотреть типичные сценарии маршрутизации сообщений, они довольно просты:

Конкретный получатель, к сообщению (которое обычно никак не анализируется брокером) прикрепляется метка-идентификатор, обозначающий кому именно оно предназначено. Такое сообщение получит только процесс, зарегистрировавшийся с аналогичным идентификатором. Типичный пример использования - личные сообщения от пользователя к пользователю.
Группа получателей, актуально для проектов, где пользователи взаимодействуют не на глобальном пространстве, а разбиты на части по какому-то признаку. Скажем это может быть какой-то B2B сервис и сообщения ходят только между сотрудниками одной компании-клиента. Обычно используется такие же метки, как и при конкретном получателе, только с одной из сторон (обычно принимающей) вместо конкретного идентификатора указывается какой-то паттерн, вроде CompanyA.*.
Публичные сообщения - получают все пользователи, метки не используются. Обычно это уведомления о глобальных для сайта событиях или публикации каких-то материалов.

Реализаций брокеров сообщений есть много разных, общий принцип работы у всех примерно одинаковый и соответствует трем изложенным выше пунктам. Для интернет-проектов очень рекомендую RabbitMQ, в нем эти стратегии маршрутизации называются direct, topic и fanout exchange, соответственно.

Отправлять сообщения через брокер в большинстве случаев будут различные внутренние сервисы в случае возникновения определенных событий (читай: получения ими определенных входящих сообщений и попадания в определенную ветвь алгоритма их обработки). Какую стратегию маршрутизации использовать - тоже на их совести.

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

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

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

Заключение

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

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

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

Эта статья - пятая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Erlang в интернет-проектах

Иван Блинков — Sat, 17 Mar 2012 19:43:00 +0400

С моей точки зрения, Erlang - один из наиболее продуманных языков программирования. Его создатели выбирали каждую деталь и особенность реализации так, чтобы сделать его идеальным для решения вполне конкретных телекоммуникационных задач, с которыми они сталкивались в 80-90-х годах. Во многом из-за этого он так и не стал универсальным языком программирования как C++, Python и другие, а так и остался спустя многие годы специализированным инструментом. Сегодня спрос и предложение на специалистов по Erlang на рынке труда относительно малы, что для большинства проектов является основным аргументом против Erlang, хотя порой они и сталкиваются с задачами, где он запросто бы стал тем самым "идеальным инструментом". В этой статье я хотел бы обсудить, в каких именно ситуациях применительно к интернет-проектам использование Erlang оправдано и почему. Но начать придется издалека - с того, чем же он так уникален.

Что такое Erlang?

Под словом Erlang обычно подразумевают совокупность сразу нескольких компонентов:

Сам одноименный язык программирования - по сути синтаксис и идеологию;
ERTS (Erlang Run-Time System) - реализация всех низкоуровневых абстракций на C. Подробнее о них ниже.
BEAM (Bogdans' Erlang Abstract Machine) - стандартная реализация виртуальной машины, с помощью которой обычно исполняются программы на Erlang после компиляции в байт-код (она очень эффективна; хотя компиляция Erlang в нативный код и возможна, оно того чаще всего не стоит). BEAM используется по-умолчанию в основных дистрибутивах Linux и других операционных системах. Когда говорят "виртуальная машина Erlang" обычно подразумевается совокупность ERTS и BEAM.
OTP (Open Telecom Platform) - набор качественно реализованных высокоуровневых абстракций, использование которых стало почти стандартом де-факто в мире Erlang, так как оно позволяет не изобретать велосипеды и избегать типичных ошибок при реализации типичных же паттернов. Немного забегая вперед, приведу несколько примеров: gen_server (просто процесс, который принимает какие-то запросы и как-то на них реагирует), gen_fsm (конечный автомат), supervisor (мониторинг других процессов).

Ключевые особенности

Параллельное программирование (concurrent programming) - программы на Erlang состоят из независимых задач, которые могут выполняться параллельно, что на практике дает свободу виртуальной машине планировать их выполнение наиболее эффективным образом с учетом доступных системных ресурсов.
Процессная модель (process model) - единицей параллельного выполнения в Erlang является процесс, который технически представляет собой лишь часть потока исполнения (thread) операционной системы и обладает нижеизложенными свойствами, которые обеспечивает их реализация в ERTS:
- Параллельность (concurrency) - каждый процесс выполняет свою часть кода вне зависимости от других процессов, со своим темпом.
- Изоляция процессов (process isolation) - в отличии от потоков исполнения в операционных системах и других языках программирования, между процессами Erlang'а нет общей памяти. Помимо этого сбой в одном из процессов напрямую не влияет на другие процессы в системе. Именно по-этому они называются процессами, так как в этом ключе скорее похожи на полноценные процессы операционной системы.
- Низкое потребление ресурсов (low resource consumption) - так как процессы Erlang являются лишь абстракцией внутри потока исполнения операционной системы, используют зачастую меньше килобайта оперативной памяти и требует минимальных вычислительных ресурсов, то один сервер может при необходимости иметь сотни тысяч и даже миллионы запущенных процессов (теоретически возможный максимум - 268435456, хотя по-умолчанию стоит ограничение в 32768 процессов). Для сравнения: суммарное количество потоков выполнения на сервере обычно измеряется сотнями и редко превышает тысячу.
- Слабая связанность (loose coupling) - процессы общаются друг с другом посредством асинхронного обмена сообщениями (message passing), для чего часть памяти каждого процесса выделяется под "почтовый ящик". При отправке сообщения в списке входящих сообщений процесса-получателя создается копия сообщения, составленного в процессе-отправителе. При этом протокол отправки сообщений между процессами скрыт от разработчика и не зависит от того, находится ли получатель в той же виртуальной машине или в удаленной (на другом сервере), что позволяет легко и практически прозрачно распределять приложения по многим физическим серверам (горизонтальное масштабирование, scale out).
- Дерево ответственности (responsibility tree) - создаваемые внутри системы процессы образуют иерархию, где родители несут ответственность за потомков. В упомянутом чуть выше примере сбой одного из процессов вызывает его завершение и рассылку уведомлений связанным процессам-соседям по иерархии (с информацией о том, где и почему произошел сбой), на которые они могут как-то реагировать. Типичных сценария реагирования два: также завершить работу и разослать аналогичные уведомления, вызывая цепную реакцию (такие процессы называют исполнителями, worker), либо на основе уведомления принять какое-то действие, например попытаться заново запустить часть дерева процессов, аналогичную остановленной (такие называют надсмотрщиками, supervisor). Использование этого механизма позволяет приложению добиться отказоустойчивости.
Ссылочная прозрачность (referential transparency) - как только переменная получила какое-то значение его уже нельзя изменить (single assignment), для нового значения нужно заводить новую переменную. На первый взгляд выглядит полным бредом, но именно эту цену нужно заплатить для гарантии того, что какая-то другая часть кода втихаря не "испортит" значение. Плюс отсутствие изменений в структурах данных в памяти дает большую свободу для применения различных оптимизаций компилятору, сборщику мусора и планировщику процессов.
Планировщик процессов (scheduler) - виртуальная машина Erlang с точки зрения операционной системы выглядит как один процесс с несколькими потоками исполнения (threads), каждый из которых имеет собственный планировщик, управляющий группой Erlang-процессов. Процессы могут прозрачно перемещаться из одного потока в другой для балансировки нагрузки. Помимо этого планировщик берет на себя управление вводом-выводом, которые на низком уровне реализованы в неблокирующей, основанной на событиях, манере с использованием epoll или аналогов, но для конечного разработчика представляется в упрощенном виде.
Сборщик мусора в памяти (garbage collector) - в отличии от других виртуальных машин (в частности JVM) сборка мусора в Erlang не влечет за собой значимых задержек в работе приложений, так как благодаря изоляции процессов для сборки мусора они останавливаются по очереди, пока все остальные продолжают работать. Обычно область памяти выделенная под один процесс очень невелика (для сравнения: под новый процесс в Erlang выделяется около 1 килобайта, под новый поток исполнения в Java - более 512 килобайт в зависимости от реализации), так что сборка мусора для каждого процесса не занимает много времени. Планировщик может определить какие процессы нужно пропустить при очередной сборке мусора, если они не исполнялись с момента предыдущей сборки. Если процесс создается для выполнения кратковременной задачи, то он может успеть сделать свое дело и завершиться без единой сборки мусора, полностью освободив свою память по окончании работы.
Функциональное программирование (functional programming) - если рассмотреть один Erlang-процесс внутри, отбросив его связь с внешним миром (обмен сообщениями), то можно увидеть программу, полностью соответствующую функциональной парадигме: алгоритмы выражаются в виде вызовов функций, которые, в свою очередь, являются единицами данных наравне с числами и сложными структурами. На практике же это означает другой стиль программирования и используемые абстракции (рекурсия вместо циклов, поведения вместо интерфейсов и т.п.), по сравнению с более распространенными объектно-ориентированными языками; подробно это будет интересно лишь программистам, так что оставим это для другой статьи про Erlang.
Доступно три механизма хранения данных вне памяти процессов:
- ETS (erlang term storage) - очень похожий на хранилище пар ключ-значение механизм, работающий в оперативной памяти самой виртуальной машины и доступный всем или части её процессов (есть ограничения доступа). Данные хранятся в пространствах имен (таблицы без жесткой структуры), а доступ осуществляется по ключу, который являются частью значения (обычно первым элементом в хранящейся структуре данных).
- DETS (disk erlang term storage) - предоставляется аналогичный ETS интерфейс и формат хранения данных, с той лишь разницей, что данные хранятся в файлах на диске, а не в памяти виртуальной машины. При использовании нетвердотельных дисков операции поиска данных значительно медленнее аналогов из модуля ETS.
- Mnesia - полноценная СУБД на основе ETS/DETS, с поддержкой атомарных транзакций (atomic transactions), репликации (replication) и партиционирования (sharding). Позволяет абстрагироваться от физического расположения данных, осуществлять поиск/выборки данных в реальном времени, а также вносить изменения в конфигурацию и схему данных без перезапуска.
Горячее обновление кода (hot code loading) - виртуальная машина может держать в памяти и параллельно выполнять две версии одного и того же кода (единицей измерения здесь является модуль, то есть один скомпилированный файл исходного кода), процесс переключается со старого кода на новый при выполнении внешнего вызова к одной из его функций (что в целом полностью в руках разработчика). Эта возможность позволяет полностью избежать недоступности приложения при обновлениях, что очень важно для всех приложений, работающих в реальном времени, к которым также относятся все сайты и интернет-сервисы.

Применение на практике

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

Входящие пользовательские соединения

Еще в далеком 2002 году в сети часто мелькал сравнительный бенчмарк Apache (C) и Yaws (Erlang) по обработке HTTP-запросов, где Yaws представлялся "победителем" с огромным отрывом. С тех пор конечно же многое поменялось, появился стремительно набирающий обороты nginx и "популярные в узких кругах" решения вроде node.js или Tornado.

Но Erlang тоже не стоит на месте. Благодаря целенаправленной работе по оптимизации ERTS в целом и планировщика процессов в частности, современные реализации HTTP-серверов на Erlang по-прежнему легко дают фору более распространенным решениям.

В последние годы появляется все больше интернет-проектов, использующие постоянные соединения (websocket, long polling, etc.) между браузером и HTTP-сервером для обновления страниц сайта в реальном времени. Здесь также Erlang легко справляется с задачей, так как для поддержания постоянного соединения обычно используется лишь 1 Erlang-процесс (хотя иногда 2), которые, как уже упоминалось, потребляют минимум оперативной памяти и вычислительных ресурсов. Как следствие, HTTP-сервер на Erlang способен поддерживать очень постоянное соединение с онлайн пользователями, даже если их количество измеряется десятками тысяч.

Хочется отметить, что в этом примере речь идет именно об обработке соединений с пользователями, то есть внутри HTTP-сервера минимум логики, он просто "разбирает" запрос и, вероятно, передает его дальше внутрь системы через брокер сообщений или напрямую внутренним сервисам. К вопросу с сколько-либо сложной бизнес-логикой вернемся чуть позже.

Отдача статики

Для отдачи статики в Erlang часто используют тот же системный вызов sendfile, что и в nginx. Но на практике ситуация здесь неоднозначна:

прямой доступ к sendfile через встроенные вызовы (BIF, Built-In Functions) появился в Erlang только в самом последнем на сегодняшний день релизе - R15B;
раньше использовалась обертка с использованием нативных функций (NIF, native implemented functions) или просто чтение файла, что работало не очень хорошо.

На готовые бенчмарки по отдаче статики из последних версий Erlang'а я не натыкался, так что могу предложить взглянуть на небольшой тест cowboy vs nginx на обычном домашнем оборудовании: Ubuntu в роли сервера, iMac в роли клиента (JMeter), 100Мбит между ними. Какого-либо тюнинга настроек не производилось.

1.1Мб картинка в 10 потоков (нехитрая математика говорит о том, что все упираются в сеть):
- Cowboy без sendfile: 853мс. в среднем, 639 запросов в минуту, отклонение 428мс.
- Cowboy с sendfile: 853мс. в среднем, 639 запросов в минуту, отклонение 395мс.
- Nginx: 882мс. в среднем, 638 запросов в минуту, отклонение 515мс.
112б текстовый файл в 1000 потоков:
- Cowboy без sendfile: 37мс. в среднем (но медиана - 3мс., то есть небольшая часть запросов сильно тормозит, а с остальной все нормально), 259 тыс. запросов в минуту, отклонение 234мс.
- Cowboy с sendfile: 17 мс. в среднем, 267 тыс. запросов в минуту, отклонение 27мс.
- Nginx: 2мс. в среднем, 315 тыс. запросов в минуту, отклонение 3мс.

Не претендуя на хоть на какую-либо точность и применимость в боевых условиях, эти цифры и графики показывают, что в деле отдачи статики nginx хоть и по-прежнему лидер, но в не-экстремальных ситуациях особой разницы можно и не заметить. Хотя при использовании решений на Erlang определенно можно начать "скучать" по нестандартным конфигурациям nginx с какой-нибудь компрессией на лету, rewrite'ами и пр. В любом случае, для отдачи статики в сколько-либо серьезных интернет-проектов рекомендую пользоваться услугами CDN.

Балансировка нагрузки

Откровенно говоря, я не слышал о каком-либо проекте на Erlang для балансировки HTTP и/или TCP запросов, хотя бы отдаленно сравнимом по возможностям, надежности и производительности с HAProxy и "железными" решениями.

Хотя по мне так сами свойства Erlang прекрасно подходят для решения этой задачи, но те проекты, на которые я натыкался (пример), выглядят просто как "поделки" по сравнению с проверенными временем решениями.

В любом случае HTTP/TCP балансировщик нагрузки на Erlang - отличная тема для нового opensource проекта, если вдруг кому-то нечем заняться в свободное время :)

Брокер сообщений

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

В дополнение хочется сказать, что хоть изобретать велосипед и редко когда оказывается хорошей затеей, Erlang отлично подошел бы и для реализации собственной схемы обмена сообщениями внутри системы, например без использования централизованного брокера, как это в итоге получается с использованием RabbitMQ или аналогов.

Бизнес-логика

Этот аспект является практически уникальным от проекта к проекту, так что здесь придется ограничиться лишь какими-то общими рекомендациями.

Основной слабой стороной Erlang является обработка данных, в частности:

Текстовые строки в Erlang реализованы как однонаправленный связанный список целых чисел, то есть на каждый символ выделяется восемь байт памяти: четыре на код символа, четыре - на указатель на следующий символ; плюс еще четыре байта для указателя на начало списка. Для 64-битных систем эти цифры нужно удвоить, так как машинное слово вдвое длиннее. Помимо неоправданных расходов памяти, эта схема усложняет различные операции со строками, например чтобы посчитать длину строки нужно "пройтись" по ней целиком. А чтобы приписать один символ в конец строки, нужно сделать её полную копию (для записи в начало это не так, как не трудно догадаться).
Бинарные строки хранятся в памяти последовательно, так что объем не удваивается из-за указателей. Изменения в итоге также создают копии данных, что для больших строк накладно. В любом случае там где это возможно я бы рекомендовал использовать бинарные строки вместо текстовых.
С математическими задачами все не так плачевно: хоть и реализация базовых операций в виртуальной машине несколько отстает по производительности от чистого С, при желании его можно практически догнать средствами нативной компиляции, грамотной реализации алгоритма и отсутствия "палок в колесах" у компилятора. Альтернативный сценарий: использование NIF.

Для не-англоязычных проектов трудностью может оказаться довольно сомнительная поддержка Unicode: особого типа данных нет, в тех же текстовых строках код символа может выходить за пределы таблицы ASCII (не зря же на него 32 или 64 бита выделили), а в бинарных строках можно хранить что угодно, в т.ч. и Unicode-текст. Как прореагирует на Unicode тот или иной встроенный модуль или используемая библиотека никто не гарантирует, но обычно все более-менее нормально.

Хоть на самом деле это и является роскошью, но при реализации бизнес-логики на Erlang порой недостает ORM-подобных механизмов в духе "вытащил объект из базы, поменял в нем что-нибудь, положил обратно". Не то чтобы таких библиотек нет, просто эта схема не очень хорошо "ложится" на функциональную парадигму и реализуется обычно через не особо предназначенные для этого механизмы словарей (dict) или именованных кортежей (record).

В качестве резюме хочется сказать, что на Erlang можно реализовать бизнес-логику практически любого интернет-проекта. Просто если она сложнее, чем просто передать какие-то данные от одного пользователя другому, то вероятно из-за искусственных ограничений и недостаточной выразительности языка для эффективной её разработки на Erlang может потребоваться существенно больше времени и усилий, чем на более приспособленных для этого языках вроде Ruby, PHP и Python.

Базы данных

Здесь все довольно просто: обычно Erlang используется как распределенная надстройка над встраиваемыми СУБД или особыми форматами файлов. Основные представители: Riak (Google LevelDB), CouchDB (свой формат), Mnesia (DETS), Couchbase (memcached и SQLite) - все совершенно разные, обсуждать и сравнивать можно до бесконечности, так что оставим это на другой раз.

Из общих особенностей вышеперечисленных решений можно выделить:

Прозрачная горизонтальная масштабируемость;
Настраиваемый уровень репликации данных;
Обычно доступность и персистентность в ущерб строгой целостности (AP из CAP-теоремы);
Поддержка сложных распределенных выборок (MapReduce, многокритериальная фильтрация, полнотекстный поиск и т.п., за исключением Couchbase)
Способность легко справляться с большим потоком изменений данных (за исключением, пожалуй, CouchDB);
Отсутствие строгой схемы данных и SQL-подобного интерфейса.

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

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

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

В комментариях предлагаю обсудить по каким еще причинам на сегодняшний день Erlang столь редко можно увидеть в технологическом стеке интернет-проектов? Какие еще вопросы смущают руководство и разработчиков? В каких ситуациях преодоление сложностей и ограничений, связанных с Erlang, того стоит?

Эта статья определенно будет далеко не последней про Erlang, так что если эта тема Вам близка - рекомендую подписаться на RSS.

RabbitMQ

Иван Блинков — Sat, 10 Mar 2012 01:19:00 +0400

Когда веб-приложение перестает быть просто коллекцией скриптов, генерирующих HTML, встает вопрос о взаимодействии различных компонентов системы. Есть два основных подхода:

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

Сегодня я хотел бы рассказать об одной из лучших, на мой взгляд, реализаций брокера сообщений, RabbitMQ. Хотите узнать почему я так считаю? - Дочитайте до конца :)

Основные понятия

Слоганом RabbitMQ является "обмен сообщениями, который просто работает". Отчасти с этим утверждением можно согласиться, для того чтобы сервис обмена сообщениями "просто заработал" достаточно простой команды aptitude install rabbitmq-server или аналога для операционных систем, не основанных на Debian. Но кому этого будет достаточно? Как минимум нужно научить свой проект эти сообщения отправлять и принимать, а как максимум - обрабатывать десятки и сотни тысяч сообщений в секунду, но обо всем по порядку.

В основе RabbitMQ лежит протокол AMQP, который вводит три основных понятия:

Сообщение (message) - единица информации, которая передается от отправителя к получателю(ям); состоит из набора заголовков и содержания, которое брокером никак не интерпретируются.
Точка обмена (exchange) - распределяет отправленные сообщения между одной или несколькими очередями в соответствии с их заголовками.
Очередь (queue) - место, где хранятся сообщения до тех пор, пока их не заберет получатель.

Базовые механизмы взаимодействия с брокером очень просты:

Отправить сообщение (publish) - сообщение сериализуется в определенный формат, при необходимости снабжается маршрутной меткой (routing key) и передается в RabbitMQ;
Получать сообщение (consume или subscribe) - приложение регистрируется в RabbitMQ с указанием какие именно сообщения оно готово получать и обрабатывать, после чего ожидает их доставки.

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

Отправка всем (fanout) - как следует из названия, каждое сообщение получат все очереди, связанные с данной точкой обмена, типичная публикация-подписка (publish-subscribe).
Прямая (direct) - сообщение получит только та очередь, которая имеет название, соответствующее маршрутной метке сообщения, типичная очередь сообщений (message queue).
Тематическая (topic) - очереди при регистрации указывают паттерн маршрутных меток сообщений, которые они хотели бы получать. Этот механизм позволяет наиболее гибко управлять маршрутизацией сообщений и строить нетривиальные схемы доставки. Вместо регулярных выражений используется очень простая схема: метки в виде слов, разделенных точками; в паттерне * заменяет ровно одно слово, # - ноль или больше; при отсутствии этих символов работает как прямая точка обмена.

Если Вашему приложению достаточно простых подписки-публикации или очереди сообщений, а также нет необходимости гарантировать доставку сообщений или обрабатывать потоки сообщений, превышающие возможности одного сервера, то можно рассмотреть более простые в эксплуатации решения, не основанные на AMQP. В такой ситуации я рекомендовал бы первым делом взглянуть на Redis. Если это не про Вас, то продолжаем разбираться с RabbitMQ.

Типичные сценарии

Выполнение длительных операций

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

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

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

Удаленный вызов (RPC)

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

Для этого предусмотрено два заголовка сообщений:

Обратный адрес (reply to) - исполнитель должен отправить результат в очередь с указанным именем; отравитель сразу же после передачи сообщения-запроса брокеру начинает получать сообщения из указанной в этом заголовке очереди.
Идентификатор запроса (correlation id) - должен быть уникальным среди запросов, чтобы отправитель мог сопоставить результаты с запросами.

Сообщения пользователям

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

В этом примере очень важно использовать режим постоянных сообщений (persistant, путем установки заголовка delivery_mode=2), так как получатель сообщения может появиться очень не скоро и важно чтобы сообщения "переживали" даже полный перезапуск брокера сообщений. Для более короткоживущих сообщений это менее критично, но тоже порой актуально, особенно как еще одна мера для обеспечения отказоустойчивости.

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

Двустороннее соединение с браузером

Пожалуй, самый "вкусный" пример, хоть и лежащий на поверхности. На многих крупных интернет-проектах, особенно социальной направленности можно увидеть уведомления в реальном времени о событиях на сайте - кто-то что-то написал, поставил +1, проголосовал и т.п.

Реализация этого функционала требует довольно серьезной работы как на стороне браузера, так и на серверной стороне. Браузерный вопрос выходит за рамки этой статьи (хотя тут у меня тоже есть что рассказать, отдельным постом когда-нибудь обязательно напишу), а вот на серверной стороне брокер сообщений окажется очень даже кстати, особенно в реализации RabbitMQ.

На серверной части эта задача делится на две части:

Поддерживать постоянное соединение со всеми пользователями, кто находится онлайн - здесь на помощь обычно приходит либо Erlang, либо неблокирующий сервер на epoll. Оба варианта очень неплохие, выбирайте сами.
Дальше нужно как-то организовать доставку сообщений (информацию о событиях в системе) между пользователями, где и вступает в игру брокер. Обработчик соединения подписывается на сообщения о публичных событиях (точка обмена "отправить всем"), и туда же отправляет информацию о действиях пользователя-владельца.

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

Кластеризация

Многое из вышеизложенного справедливо и для других реализаций AMQP, но в вопросе кластеризации RabbitMQ предстает во всей красе. Залогом этого в первую очередь является использование Erlang, не знаю почему я до сих пор не написал статью про этот язык программирования, здесь достаточно было бы на нее сослаться и все стало бы ясно.

Если вкратце, то в Erlang реализована внутренняя система легковесных процессов, не имеющая общего состояния и взаимодействующая друг с другом исключительно посредством обменом сообщений. При этом с точки разработчика отправка сообщений другому процессу на том же физическом сервером и на удаленном выглядит одинаково, и даже является одним из операторов языка - "!", наравне с "=", "+" и.т.п. Этот факт позволяет приложениям или их частям взаимодействовать по сети так же легко, как и в рамках одного сервера.

Чтобы определить разрешено ли разным Erlang-сервера взаимодействовать друг с другом, они обмениваются хэшем пароля (который правда называют cookie, хотя с одноименным механизмом браузеров он ничего общего не имеет) и продолжают работу только если он совпал. Он должен быть одинаковым на всех узлах и хранится в файле ~/.erlang.cookie, для RabbitMQ это обычно /var/lib/rabbitmq/.erlang.cookie - первым делом нужно решить этот вопрос, а также убедиться, что используется нестандартное значение.

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

Важно понимать, что под состоянием системы здесь имеются ввиду лишь привязки и настройки брокеров, каждая же очередь и хранящиеся в ней сообщения располагаются на одном конкретном узле, что приведет к потери части сообщений при сбое одного из серверов. Этот вопрос можно решить и средствами операционной системы, но чаще всего правильнее выделить критически-важные для системы очереди сообщений и включить их репликацию средствами RabbitMQ, этот механизм называется зеркальные очереди (mirrored queues). Репликация происходит по принципу мастер-слуга (master-slave), как и в реляционных СУБД: все операции осуществляются на основном сервере (мастере), он транслирует их на один или несколько вторичных серверов (слуги), при каком-либо сбое на основном один из слуг "повышается" до статуса мастера и берет на себя его функции. Очереди могут быть объявлены зеркальными только при создании, но новые узлы в роли слуг могут добавляться и позже, в таком случае новый слуга начнет получать входящие сообщения и рано или поздно начнет полностью отражать его состояние, механизма синхронизации при подключении дополнительного слуги не предусмотрено. Последним шагом для гарантированной доставки сообщений, не упоминавшимся ранее, является механизм уведомления отправителя об успешной записи сообщения в очередь (на все сервера для зеркальных).

В кластерном окружении может понадобиться объединение точек обмена (exchange federation), что реализуется посредством пересылки сообщений по однонаправленным связям. При этом учитывается наличие на принимающей стороне очередей, готовых принять каждое конкретное сообщение. Практического применения в веб-проектах этому пока особо не вижу, разве что при кросс-датацентровой работе. Кстати, для этого поддерживается работа поверх SSL.

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

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

Используя брокер сообщений при технической реализации интернет-проекта, можно перевести его на совершенно новый уровень с точек зрения отказоустойчивости и горизонтальной масштабируемости. Во многих случаях он становится "сердцем" приложения, без которого его существование было бы немыслимо, но в то же время благодаря кластеризации не становится единственной точкой отказа (single point of failure).

Хоть многое из упомянутого в статье можно реализовать и с помощью других технологий, RabbitMQ является наиболее приспособленной к реалиям современного Интернета реализацией брокера сообщений и AMQP в частности, в первую очередь благодаря распределенной природе Erlang и качественно спроектированной архитектуре этого продукта.

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

Жду Вас среди постоянных читателей Insight IT, число которых недавно перевалило за 14 тысяч :)

Архитектура 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, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!