Максим Лапшин. Erlang production

Erlang в настоящем продакшне

Максим Лапшин Эрливидео

[email protected]

Пишем про ФП, но пишем не на ФП?

• Бизнесу нужен продукт, а не софт

• Программистам интересно писать софт

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

• Бизнес избегает ФП

• Без коммерческого применения нет опыта

• Замкнутый цикл

Опасения бизнеса в непредсказуемости

технологии

Эрланг годится для коммерческой разработки!

Эрливидео• Высоконагруженный видеостриминговый сервер

(10 ГБит/с без проблем)

• 5 лет разработки и успешной продажи ПО

• Беспроблемный найм людей

• Очень мало критичных багов (и те в C)

• Крайне быстрая разработка

• Без эрланга мы бы не справились!

Эрланг в продакшне

• Надежно

• Дешево

• Предсказуемо

• Имеет смысл использовать для коммерческого софта

Продакшн познается через год

• Софт дорастает до использования живыми пользователями

• Начинается поддержка старого кода

• Приходят новые программисты, перед которыми стыдно за исходники

• Пользователи создают нагрузку

Проблемы эксплуатации

• Работа со своим и чужим кодом

• Работа с багами на недевелоперских серверах

• Поведение под нагрузкой

Поддержка старого кода

• Через год даже свой код уже не вспомнить

• Автора кода не достать, он пошел на IPO

• Статической типизации в эрланге нет

Реалии старого кода

• Код 10-летней давности запускается и работает

• Очень сильная обратная совместимость между версиями VM

• Немутабельность сильно помогает отладке

• Не-OTP код — зло, OTP код — хорошо

Старый код в Эрливидео

• Есть куски кода, которым по 5 лет

• Иногда проводятся массовые рефакторинги

• Интеграционные тесты помогают, юнит-тесты нет

Борьба с багами• 95% падений рантайма — нехватка памяти

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

• Остальное лечится чтением стектрейсов сверху вниз, потому что let it fail

• Если пишем хорошо, то ошибки изолируются по процессам

Алгоритмы багфикса• По нажатию кнопки «загрузить логи», система сама пакует всё

• Пользователи всегда вырезают самое интересное из логов, их логи мы не читаем

• Изучаем стектрейсы и периодический дамп самых прожорливых процессов

• Пытаемся восстановить ситуацию у себя. Если не можем, идем на сервер заказчика

Авральные работы на сервере

• recon, htop в помощь что бы понять, какой ресурс сожран

• to_erl дает больший контроль, чем другие варианты (remsh и ssh)

• erlang:processes() что бы найти самого обжору

• ищем причину утечки памяти и/или тормозов

• непроходимость в пайплайне данных -> утечка памяти

Интроспекция• supervisor:which_children/1 для обхода структуры

• sys:get_state/1 что бы добраться до нутра

• lager:pr/2 для изучения состояния

• lager:md/1 для тегирования логов

• самодельные хелперы: ems_debug:top(binary)

Само-мониторинг

• На сервера не набегаешься

• Система должна сама себя мониторить

• Поиск источника багов

• Поиск потенциальных тормозов (для highload)

Мониторинги• Потребление памяти (раз в 10 секунд)

• Мониторинг длин очередей

• Мониторинг размера ets таблиц

• Внутренние очереди

• Контроль за тем, что данные втекают не быстрее, чем вытекают

Capacity control• Что бы не лопнуть, надо уметь отказываться

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

• Узкие места должны сообщать о собственной загрузке

• Без обратного контроля можно быстро, но недолго

Работа под нагрузкой• Эрланг — одна из нескольких multicore платформ

• Можно получить линейное ускорение по ядрам

• Интроспекция на живом продакшне под полной нагрузкой

• Как всё не затормозить?

Шаги на пути к Highload

• Развязывание узких мест: одно ядро не может, а 10 смогут

• Ускорение линейного кода

• Перенос данных в память

Развязывание узких мест• Singleton это узкое место, потому что одно ядро

• gen_server:call сам по себе не спасает

• Нужно разносить однопроцессные сервисы на несколько ядер

• Способы: пулы, шардирование, ets

• ETS — это очень быстро и эффективно

Примеры распараллеливания

• У одного открытого файла пул процессов, читающих с диска

• В comet сервере шардинг процессов мониторинга по hash(channel_id) % pool_size

• Подписка через ets типа bag: по ключу много значений сразу

Профилирование• Возможность профилировать отдельный процесс

• В эрланге оно всё так себе

• Анализ стектрейсов

• Тайминги в заголовках HTTP ответов

• Не особо много хитростей

ETS для памяти• In-memory database

• Великолепно масштабируется на 40-70 ядер

• Прекрасно годится для отдачи готовых данных

• Рекомендуется вместе с zerocopy протоколами

• Вторичные индексы руками

Примеры в Эрливидео

• Раздача live потоков: данные готовятся заранее, укладываются в ets таблицы. 20 Гбит/с без надрыва

• Стриминг файлов с диска: пляски с бубном и 10-15 Гбит/с можно

Архитектура стриминга с диска

• В линуксе синхронное чтение с диска, тред на запрос.

• Держим 50 или 1000 одновременных запросов к диску

• Процесс файла — арбитр между динамическим пулом процессов ридеров

• Ридеры идут в лимитированную очередь с таймаутом: N одновременных запросов и M в ожидании

• Мониторинг загрузки диска и времени чтения

• Спасибо POSIX API

Продакшн

• Писать код на Эрланге интересно

• Возможно устранять баги в бою

• Можно поддерживать старый код и жить с ним

• Можно делать крайне производительный код, притом очень быстро

Вопросы?Максим Лапшин [email protected]