• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решения
 

Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решения

on

  • 1,000 views

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

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

Statistics

Views

Total Views
1,000
Views on SlideShare
1,000
Embed Views
0

Actions

Likes
1
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решения Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решения Presentation Transcript

    • . Erlang и Haskell в production: проблемы и решения. Dmitry Groshev (@lambdadmitry), Fedor Gogolev (@knsd), @Selectel FProg 2012-10 04.10.2012 1 / 36
    • . Общий план Вступление Коротко о пони YAWNDB Selecon-web Коротко об облаках Rainbowdash Twilightsparkle Резюме 2 / 36
    • Вступление 3 / 36
    • . Вступление 1.5 года production-experience с Erlang 1 год с Haskell In-memory timeseries database (YAWNDB) Система нотификации (Spike) Веб-консоль (Selecon-web) Облако (Rainbowdash/Twilightsparkle) 4 / 36
    • Коротко о пони 5 / 36
    • .
    • YAWNDB 7 / 36
    • . YAWNDB — Yet Another Weel iNvented Timeseries данные (утилизация CPU per second) Много операций записи (десятки тысяч в секунду — виртуальных машин много) Хочется аггрегацию (max/min/avg за период) Graphite медленный, RRD не умеет аггрегацию 8 / 36
    • . YAWNDB . Path Disk manager New path request path 1 handler 1 Dumper path 2 request handler 2 path 3 ... ... request handler N path M 9 / 36
    • . YAWNDB . Path Disk manager New path request path 1 handler 1 Dumper path 2 request handler 2 path 3 ... ... request handler N path M 10 / 36
    • . YAWNDB: выводы NIF (Native Implemented Functions) это круто, но опасно мутабельные NIF binaries предоставляют изолированную мутабельность писать NIF неприятно, документация полна, но не всегда помогает property-based тестирование при использовании NIF необходимо, т.к. ошибки нетривиальны (C же!), а segfaultы травматичны fuzz-тесты на случайных/бессмысленных данных полезны писать высококонкурентные системы сложно, Erlang не добавляет сложности устойчивость к ошибкам Erlangа помогает, в продакшне почти полгода был редкий рейс без последствий вообще 11 / 36
    • . YAWNDB: выводы 2 код лаконичен (650 строк на C, 1500 строк на Erlangе) если вы пишите что-то сетевое, нет ни одной причины не использовать Cowboy если ваш проект длиннее 30 строк, нет ни одной причины не использовать gproc поддержка SMP Erlangом не миф 12 / 36
    • . YAWNDB: ссылки Graphite https://github.com/graphite-project Ecirca https://github.com/band115/ecirca Cowboy https://github.com/extend/cowboy Cowboy https://github.com/uwiger/gproc McErlang https://github.com/fredlund/McErlang 13 / 36
    • Облака 14 / 36
    • .
    • . Об облаках Xen: Dom0, DomU запуск и остановка доменов простой и неубиваемый XAPI (XenAPI) от Citrix: Миграция Пулы Динамическое управление памятью ... 16 / 36
    • . Больше, чем XAPI учёт используемых ресурсов (биллинг, статистика) управление машинами из биллинга, веб-интерфейса, API и администраторами детекция нештатных ситуаций (падение хранилища либо сети) динамическая балансировка нагрузки предоставление интерфейсов к машине, не предусмотренных XAPI (web-консоль, realtime потребление, MemoryOnDemand) Много сложной «бизнес»-логики 17 / 36
    • . Старая архитектура Make it work, make it right, make it fast Python+Bash помойка Коммуникация через HTTP, Mongo и redis (aka «как получится») WTF is summationd? WTF is yawndbtiond-obsolete? боль с Python+Mongo — много раздельного кода, размазывание схемы 18 / 36
    • . Новая архитектура Make it work, make it right, make it fast Построение «от API» VBD/VDI/VIF/BDSM → Disk/Network interface/... Фиксированная схема данных Erlang для сети и рантайма, Haskell для «бизнес»-логики Механизм Erlang ports — stdin/stdout + Erlang External Term Format 19 / 36
    • . Новая архитектура PostgreSQL Twilight Sparkle Happy Rainbow . Twilight Legacy customer Dash Sparkle Mongo Twilight Sparkle XAPI 20 / 36
    • Rainbowdash 21 / 36
    • .
    • . Rainbowdash Милая, быстрая, немного простоватая, но reliable для друзей REST + RPC: HTTP REST API → RPC API на фронтенде по конфигу с верификацией (type safety!) Асинхронность + синхронность: интерфейс синхронный, rainbowdash асинхронна, twilightsparkle синхронна «Задачи» с уникальным идентификатором для каждого запроса 2-phase commit задачи: проверка корректности и ожидаемой ресурсоёмкости, запуск (возможно, отложенный) балансировка нагрузки на бекендах по ожидаемым ресурсам и внешним характеристикам процессов (ping, mem) отчёты о состоянии системы (ping, mem, cpu, rps, latency) 2-phase commit конфига почти live reloading Haskell-кода с персистентными задачами и HTTP-коннектами 23 / 36
    • . Rainbowdash: выводы переход программистов Python → Erlang занимает неделю-полторы запаковка не-Erlang кода с помощью rebar это боль (Make+bash+cabal+cabal-dev) jobs — прекрасная библиотека, но документации почти нет любить себя полезно, несколько часов на автоматизацию перезагрузки бекенда при изменении бинарника окупились многократно кода до первой работоспособной версии достаточно мало (1k строк) 24 / 36
    • . Rainbowdash: ссылки jobs https://github.com/uwiger/jobs/ 25 / 36
    • Twilightsparkle 26 / 36
    • .
    • . TwiligthSparkle Общая архитектура Template Haskell и генерация сервера Контроль ошибок на уровне типов Барьеры — откат изменений Persistent ORM Проблемы при разработке 28 / 36
    • . TwiligthSparkle: общая архитектура Сервер, занимающийся чтением запросов из stdin и пишущий ответы в stdout Используется стандартный для Эрланга способ коммуникации — порты Был написан модуль реализующий ETF (External Term Format) Воркеры, выполняющиеся в отдельных процессах Сложное ядро, максимально простой API для написания непосредственно обработчиков запросов Каждый запрос определяется тремя параметрами: source, input и result source — Источник задачи, в нашем случае это пользователь API, администратор или внутренний сервис input — Входные данные запроса result — Результат на выполнение запроса class TaskSource source => Task source input result 29 / 36
    • TwiligthSparkle: Template Haskell и генерация. сервера Template Haskell используется для генерации функций разбора запросов от сервера. Например из кода: [erlServer| vm_start :: TS User VMStartTask () |] генерируется код: dispatch ref "vm_start" (ErlTuple [ErlBinary "user", ErlInt userId]) inputV = case fromErl inputV of Nothing -> invalidTask Just (i :: VMStartTask) -> do ... -- Process request dispatch ref "vm_start" _user _input = invalidTask 30 / 36
    • . TwiligthSparkle: Контроль ошибок Прерывание выполнения подобно ErrorT трансформеру Отдельные типы для каждого вида ошибок Требование явного декларирования списка возможных ошибок instance AllowError source VMStartTask () VMNotFound instance AllowError source VMStartTask () VMIsAlreadyRunning Пока нет, но хочется контроль декларированных и не вызываемых ошибок 31 / 36
    • . TwiligthSparkle: Барьеры Существует необходимость отката изменений в случае ошибок Барьеры устанавливаются после изменения, для которого требуется откат и выполняются в случае возникновения ошибки vm <- createVm barrier $ destroyVm vm disk <- createDisk barrier $ destroyDisk disk error "Any error" Технически реализовано как [TS source input result ()] внутри TVar контекста ReaderT 32 / 36
    • . TwiligthSparkle: Persistent ORM Первая версия не использовала ORM vm@(VM { vmUuid, vmTemplate }) <- fetch VMCollection [ "id" =: iVmId ] Регулярно возникали опечатки в названиях полей, в передаваемых данных Для Хаскеля нет рабочих альтернативных ORM кроме persistent vm@(VM { vmUuid, vmTemplate }) <- fetch [ VmId ==. iVmId ] Пришлось использовать патченную версию persistent-mongodb, так как модель хранения отличается от подразумеваемой разработчиками 33 / 36
    • . TwiligthSparkle: Проблемы при разработке Space leaks Очень трудно найти источник проблемы при большом объёме кода Не хватает некоторых пакетов на hackage, либо не устраивает их состояние Написали библиотеку для работы с ETF Стали поддерживать библиотеки bson и mongoDB Вероятно, более высокий порог вхождения Тем не менее в проект, кроме ядра, успешно пишут программисты без какого-либо функционального бэкграунда 34 / 36
    • . TwiligthSparkle: Выводы Заметно упало количество не логических ошибок, например: Параметризованные идентификаторы, например (UUID VM), не допускают их использование для не VM объектов Отдельные типы для различных семантически данных, например DiskSize Template Haskell — позволяет удобно решать проблемы, но катастрофически плохо читается Использовать cabal-dev — очень хорошая идея 35 / 36
    • Вопросы? 36 / 36
    • Copyrighted stuff:https://en.wikipedia.org/wiki/File:Cirrus_sky_panorama.jpghttp://www.wallpapervortex.com/wallpaper-15684_1_other_wallpapers_my_little_pony.htmlhttp://www.tikihumor.com/3287/rainbow-dash-makes-it-rain/rainbow-dash-makes-it-rain-2/http://qeinone.deviantart.com/art/Twilight-Sparkle-205789859 37 / 36