Rails, Eventmachine, Erlang

Эволюция:Rails, Eventmachine, Erlang

Макс Лапшин[email protected]

Sunday, December 16, 12

mailto:[email protected]


Программы древности

• Написаны на С

• Запутанная логика• Огромная сложность программирования



• Данные хранятся в памяти• Ручная сериализация на диск• Сложные протоколы IPC




PHP

• Запрос-ответ• Программа живет одну секунду• Share nothing

• Персистентность внешняя• Нулевой контроль за ресурсами• Естественный контроль за overload


PHP


Rails

• Идея PHP в совершенстве

• Лучший инструмент для сайтов• Лучший выбор для Web 1.5


Rails


Web меняется

• Веб становится динамичным• Хватит перезагружать страницу• Ajax в рельсах реализован прекрасно



• Веб становится интерактивным• Страница меняется сама!• Беда!




Интерактивный веб в Rails

• Меняется источник активности• Теперь опять сервер инициирует поток данных• Старые концепции опять не годятся• Comet, WebSockets, ServerSentEvents — рельсы это не могут


Проблемы

• Подключенные клиенты• Возникает стейт в памяти• Проблемы обработки ошибок

• Архитектурная непригодность для решения проблем


Rails

• Организованы жестко по принципу запрос-ответ

• Огромный расход памяти на каждого клиента• Один запрос — один инстанс

• Только для коротких запросов


Типичная архитектураonline-игры на Rails

• Rails

• Comet сервер

• СУБД• Сотни лишних запросов к БД• Постоянная (де)сериализация и синхронизация


Fail!


Eventmachine

• Решает проблемы с подключением клиентов

• Держит стейт в памяти• В сотни раз сокращает трафик к БД


Online игра наEventmachine

• Стейт игры держится в памяти

• Пользователи подключаются к одному серверу• Команды передаются внутри Ruby VM

• Запись в БД только из игры


Eventmachine

• Сохраняется вся экосистема Rails

• Можно прибить гвоздями асинхронную БД

• Расшаренный код с Rails-приложением


Win?!


Eventmachine

• Страдает реализация (нелепые баги)• Callbacks hell

• Как жить с ошибками?• Учет ресурсов• Контроль перегрузки• Репликация и failover


Callbacks


Fibers

• Спасают• Глючат• Но спасают• Ещё сложнее, чем коллбеки


Обработка ошибок

• Ошибки происходят• Баги в коде• Неожиданные входные данные• Все ошибки не убрать



• Как обрабатывать?• Как не повалить весь сервер?• Какие данные разрушаются от одной ошибки?• Как не превратить код в сплошную обработку ошибок?



• В Ruby ошибка привязана к потоку выполнения

• Объекты живут отдельно от потоков

• Это ключевая проблема почти для всех языков• Надо связывать объекты и ошибки руками, делая новые ошибки


Утечки памяти

• В Ruby сотни утечек

• Данные не группируются по объектам предметной области

• Утекла, так утекла. Ребутнем потом.


Fail!


Контроль за нагрузкой

• Как не дать сервису упасть под нагрузкой?• Как правильно отказать новым клиентам?

• Как не навредить старым клиентам?





• Бесконтрольно принимаем клиентов

• Начинаем тормозить всех

• Все получают таймаут от фронт-прокси, делают retry

• В системе удваивается количество работы





• Требуется backpush в каждом компоненте системы

• Важно не дать затыку пролезть вглубь системы• Для этого нужен адекватный контроль загрузки• Торможение клиента и отказ на ранней стадии• Требуется удобная сборка данных по состоянию клиентов


Репликация и failover

• У вас только один Comet-сервер?

• Как пережить его падение?• Репликация по сети — только руками.


Fail!


Erlang

• Построен вокруг изоляции ошибок• Обработка клиентов строго изолирована и группирована• Все ресурсы строго разграничены

• Обработка клиентов прогнозируема• Прозрачная сетевая кластеризация


Процессы в Erlang

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

• Данные только внутри процессов• Их могут быть миллионы


Процессы в Erlang

• Процессы чертовски удобны!

• Ими проще моделировать предметную область

• Они совпадают с теми квадратиками на флипчарте• Проще проектировать в таких терминах


Ошибки

• Любая ошибка привязана к процессу• Самое частое поведение — упасть процессу по ошибке

• Не тратишь время на обработку ошибок• Система устойчива к нерегулярным сбоям


Ресурсы

• Все ресурсы строго изолированы

• Со смертью процесса всё освобождается, включая файлы и сокеты

• Консоль прям внутри работающей системы

• Элементарный поиск потребителя памяти• Утечки — вообще не проблема


Ресурсы

• Год аптайма — не проблема


Контроль нагрузки

• Синхронные call-ы сообщениями сдерживают нагрузку

• Длина очереди процесса — прекрасная метрика

• Можно интроспектить загрузки процессов• Гораздо проще вовремя отказать


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

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

• Надо быть аккуратным, что бы не положить канал


Win!


Win?


Проблемы Erlang

• Говорливый синтаксис после Ruby

• Неудобная работа со строками (много текста), но есть серьезные фичи для скорости (iolists)

• Нет и не планируется удобного ORM типа ActiveRecord

• Зато можно хранить данные в памяти. Пользуйтесь этим!


С чего начать?

• “Erlang Programming” by Francesco Cesarini

• http://learnyousomeerlang.com by Fred

• http://groups.google.com/group/erlang-programming

• http://groups.google.com/group/erlang-russian


http://learnyousomeerlang.com

http://learnyousomeerlang.com

http://groups.google.com/group/erlang-programming

http://groups.google.com/group/erlang-programming

http://groups.google.com/group/erlang-russian

http://groups.google.com/group/erlang-russian

Что будет полезно?

• ChicagoBoss — веб-фреймворк а-ля Rails 0.5

• https://github.com/doubleyou/dps Распределенный Comet сервер


https://github.com/doubleyou/dps

https://github.com/doubleyou/dps

Итого

• Rails — чудесный инструмент для сайтов

• Rails становится непригоден для интерактивного веба

• Eventmachine хороший мостик в новый веб

• В Eventmachine есть нерешаемые проблемы

• Erlang их чудесно решает. Написали и забыли.


Вопросы?

Макс Лапшин

[email protected]

http://levgem.livejournal.com






Technology

Rails, Eventmachine, Erlang